Hello all,
When building dunfell branch of meta-linaro for qemux86-64 target, the following parse error occurs:
ERROR: ../sources/meta-linaro/meta-linaro/recipes-linaro/images/linaro-image-lng.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'qcow2' - possibly invalid type name or missing support class
It seems that qcow2 should be replaced with wic.qcow2 according to this oe-core commit from 2017:
https://git.openembedded.org/openembedded-core/commit/?h=dunfell&id=929ba56…
Indeed doing so fixes the build for me.
The master branch of meta-linaro also uses 'qcow2' (while being updated to the newer yocto variable override syntax). So I would expect it to fail similarly there.
Should this get fixed in meta-linaro? Are other people building the dunfell branch successfully?
Thanks,
Ralph
Hello!
We've been encountering a problem with recent kernels (post 5.15,
since this commit [0]) which require a Python3 package called dtschema
[1] (Rob Herring is a maintainer). This is easily installed via pip3
[2] and a recipe works fine for OpenEmbedded [3], even in the ancient
Sumo we're using (well, at least everything seems to be in place).
The problem we're seeing is with the PATH set by the recipe, which has
/poky/build/tmp/hosttools/ as the last bit in it. but no reference to
the native Python (recipe-sysroot-native/usr/bin/python3-native/)
built within OE. This version of Python (3.7.3) is from the host, and
does not have the dtschema package in it (even if it's installed,
dtschema fails to run).
I have tried inheriting python3native in the kernel recipe, which
defines PYTHON and other related variables, but it still fails to use
the right python3 binary.
Is there a recommended way to get the python3-native path into the PATH?
Thanks and greetings!
Daniel Díaz
daniel.diaz(a)linaro.org
[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
[1] https://github.com/devicetree-org/dt-schema/
[2] https://pypi.org/project/dtschema/
[3] https://github.com/mrchapp/meta-lkft/blob/d/add-dtschema/recipes-devtools/p…
There is an issue in meta-rust master, affecting cargo-native with no
checksum.
I will look into.
Regards,
Anibal
On Tue, 19 Oct 2021 at 04:07, <ci_notify(a)linaro.org> wrote:
> Hello CI User,
>
> This is notification from ci.linaro.org for project Qualcomm OpenEmbedded
> RPB (master).
>
> The project Qualcomm OpenEmbedded RPB (master) Build # 692 - Still
> Failing.
>
> Please check console output at
> https://ci.linaro.org/job/lt-qcom-openembedded-rpb-master/692/ to view
> the results.
>
> Thanks!!!
> CI Team
There as been a lot time that is failing NXP iMX, anyone is
using/maintaining it?,
Regarda,
Anibal
El vie., 27 de noviembre de 2020 15:54, <ci_notify(a)linaro.org> escribió:
> Hello CI User,
>
> This is notification from ci.linaro.org for project Reference Platform -
> OpenEmbedded (dunfell).
>
> The project Reference Platform - OpenEmbedded (dunfell) Build # 234 -
> Still Failing.
>
> Please check console output at
> https://ci.linaro.org/job/rpb-openembedded-dunfell/234/ to view the
> results.
>
> Thanks!!!
> CI Team
On Sat, 1 Aug 2020 at 19:40, Sumit Garg via lists.yoctoproject.org
<sumit.garg=linaro.org(a)lists.yoctoproject.org> wrote:
>
> On Sat, 1 Aug 2020 at 14:57, Ryan Harkin <ryan.harkin(a)linaro.org> wrote:
> >
> >
> >
> > On Sat, 1 Aug 2020 at 10:09, Ryan Harkin <ryan.harkin(a)linaro.org> wrote:
> >>
> >> Hi Khem,
> >>
> >> On Fri, 31 Jul 2020, 21:58 Khem Raj, <raj.khem(a)gmail.com> wrote:
> >>>
> >>> On Fri, Jul 31, 2020 at 8:35 AM Ryan Harkin <ryan.harkin(a)linaro.org> wrote:
> >>> >
> >>> > Hello,
> >>> >
> >>> > I'm migrating from Warrior to Dunfell and I'm getting a curious build failure in gcc-sanitizers.
> >>> >
> >>> > Here's the full gory detail:
> >>> > https://pastebin.ubuntu.com/p/nh4cDKMvgS/
> >>> >
> >>> > However, the main error is this:
> >>> >
> >>> > | In file included from ../../../../../../../../../work-shared/gcc-arm-8.3-r2019.03/git/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:193:
> >>> > | ../../../../../../../../../work-shared/gcc-arm-8.3-r2019.03/git/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:317:72: error: size of array 'assertion_failed__1152' is negative
> >>> > | typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
> >>> >
> >>> > I have no idea where to begin with this. I don't even know why gcc-sanitizers is included in the build, what it does, or why I need it. I'm building an image with dev packages and gcc, so I guess that's why.
> >>> >
> >>> > I've hacked meta-arm to patch sanitizer_platform_limits_posix.cc to null out the macros and that builds fine. I'm sure it won't work, should someone want to use it, mind you.
> >>> >
> >>> > Is there something obvious that I should be doing as part of a Warrior -> Dunfell migration to get this to work?
> >>> >
> >>> > note: Warrior used meta-linaro-toolchain and for Dunfell, it's moved to meta-arm-toolchain.
> >>> >
> >>>
> >>> is gcc 8.3 the latest for linaro
> >>
> >>
> >> I assume so. I haven't attempted to change the default.
> >
> >
> > I'm sorry, that's incorrect: local.conf has an over-ride to specify 8.3.
> > I've just removed it and now it's using 9.3. And it's building fine.
> >
It's using GCC 9.3 from OE core. If you wish to use Arm toolchain then
you need to override the default OE core GCC version with Arm
toolchain GCC version:
GCCVERSION = "arm-9.2"
-Sumit
> > Sumit, do you know if there's a reason for using 9.2 in RPB instead of 9.3?
> >
>
> Arm GCC 9.3 toolchain isn't released yet (see here [1]).
>
> [1] https://developer.arm.com/tools-and-software/open-source-software/developer…
>
> -Sumit
>
> >>
> >>>
> >>> > Regards,
> >>> > Ryan.
> >>> >
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#50161): https://lists.yoctoproject.org/g/yocto/message/50161
> Mute This Topic: https://lists.yoctoproject.org/mt/75909560/1777089
> Group Owner: yocto+owner(a)lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [sumit.garg(a)linaro.org]
> -=-=-=-=-=-=-=-=-=-=-=-
Hello,
I'm migrating from Warrior to Dunfell and I'm getting a curious build
failure in gcc-sanitizers.
Here's the full gory detail:
https://pastebin.ubuntu.com/p/nh4cDKMvgS/
However, the main error is this:
| In file included from
../../../../../../../../../work-shared/gcc-arm-8.3-r2019.03/git/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:193:
|
../../../../../../../../../work-shared/gcc-arm-8.3-r2019.03/git/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:317:72:
error: size of array 'assertion_failed__1152' is negative
| typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
I have no idea where to begin with this. I don't even know why
gcc-sanitizers is included in the build, what it does, or why I need it.
I'm building an image with dev packages and gcc, so I guess that's why.
I've hacked meta-arm to patch sanitizer_platform_limits_posix.cc to null
out the macros and that builds fine. I'm sure it won't work, should someone
want to use it, mind you.
Is there something obvious that I should be doing as part of a Warrior ->
Dunfell migration to get this to work?
note: Warrior used meta-linaro-toolchain and for Dunfell, it's moved to
meta-arm-toolchain.
Regards,
Ryan.
Hello!
I mentioned a few weeks back that I had some doubts on the difference
between this override:
SRCREV_kernel = "5821a5593fa9f28eb6fcc95c35d00454d9bb8624"
and this one:
SRCREV_kernel_juno = "5821a5593fa9f28eb6fcc95c35d00454d9bb8624"
The following is the definition in the kernel recipe itself:
SRCREV_kernel = "3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162"
Turns out that with _only_ the first override in local.conf (without
MACHINE), the kernel uses the right SRCREV but Perf uses the one from
the recipe; I have to include the second override (with MACHINE) so
that Perf can use the right SRCREV.
Does anyone have a pointer that could shed more light on that subject?
Thanks and greetings!
Daniel Díaz
daniel.diaz(a)linaro.org
On Fri, 10 Apr 2020 at 23:11, Jon Mason <jdmason(a)kudzu.us> wrote:
>
> On Fri, Apr 10, 2020 at 06:05:57PM +0200, Nicolas Dechesne wrote:
> > hi there,
> >
> > over the last few months, we've transitioned the gcc-arm toolchain from
> > meta-linaro-toolchain for master. Since we are approaching the next YP
> > release, I would like to remove/cleanup recipes in meta-linaro-toolchain
> > before we create the dunfell branch.
> >
> > as of now, meta-linaro-toolchain has the following recipes:
> > gcc_arm-8.2.bb
> > gcc_arm-8.3.bb
> > gcc_arm-9.2.bb
> > gcc_linaro-7.2.bb
> >
> > including all their usual dependencies, and the 'external' toolchain
> > recipes.
> >
> > meta-arm-toolchain has
> > gcc_arm-8.2.bb
> > gcc_arm-8.3.bb
> > gcc_arm-9.2.bb
> >
> > and it's strictly the same metadata, as of now.
> >
> > As such, I am proposing to remove all recipes from meta-linaro-toolchain
> > master branch, and require every user to transition to meta-arm.
> >
> > it will effectively become an empty layer.. so I have 2 options:
> > 1. keep an empty layer with conf/layer.conf
> > 2. remove the layer completely (e.g. remote meta-linaro-toolchain folder)
> >
> > I am not sure which one is better.. #2 will generate an obvious error
> > message for anyone using the layer. Maybe that would be a strong signal..
> >
> > I will default to #2 right before we create the dunfell branch (in a couple
> > of weeks max), unless someone speaks before that!
>
> I agree with you that #2 is the correct choice (in case you were
> wanting a secondary opinion).
>
+1
-Sumit
> Thanks,
> Jon
>
> >
> > Nothing will change of course for our stable branches.
> >
> > cheers
> > nico
>
> >
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#196): https://lists.yoctoproject.org/g/meta-arm/message/196
> Mute This Topic: https://lists.yoctoproject.org/mt/72924576/1777089
> Group Owner: meta-arm+owner(a)lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/leave/7647878/863301594/xyzzy [sumit.garg(a)linaro.org]
> -=-=-=-=-=-=-=-=-=-=-=-
hi there,
over the last few months, we've transitioned the gcc-arm toolchain from
meta-linaro-toolchain for master. Since we are approaching the next YP
release, I would like to remove/cleanup recipes in meta-linaro-toolchain
before we create the dunfell branch.
as of now, meta-linaro-toolchain has the following recipes:
gcc_arm-8.2.bb
gcc_arm-8.3.bb
gcc_arm-9.2.bb
gcc_linaro-7.2.bb
including all their usual dependencies, and the 'external' toolchain
recipes.
meta-arm-toolchain has
gcc_arm-8.2.bb
gcc_arm-8.3.bb
gcc_arm-9.2.bb
and it's strictly the same metadata, as of now.
As such, I am proposing to remove all recipes from meta-linaro-toolchain
master branch, and require every user to transition to meta-arm.
it will effectively become an empty layer.. so I have 2 options:
1. keep an empty layer with conf/layer.conf
2. remove the layer completely (e.g. remote meta-linaro-toolchain folder)
I am not sure which one is better.. #2 will generate an obvious error
message for anyone using the layer. Maybe that would be a strong signal..
I will default to #2 right before we create the dunfell branch (in a couple
of weeks max), unless someone speaks before that!
Nothing will change of course for our stable branches.
cheers
nico
Hi all,
Well, I don't even know where to start debugging this, so that isn't very
good.
I had working OE-RPB builds for the WaRP7 board (MACHINE=imx7s-warp), then
repo locked out the relative symlinks. Nico fixed that in OE-RPB, and I
rebased to his fix.
But it didn't fix my builds.
My manifest repo is here:
https://git.linaro.org/people/ryan.harkin/oe-rpb-manifest.git/log/?h=warrior
My meta-layer is here:
https://git.linaro.org/people/ryan.harkin/meta-warp7.git/log/?h=warrior
As you can see, they're both simple, just to get the board added to OE-RPB.
I now have two environments: my original warrior workspace that still
builds, so long as I don't try to "repo sync", and my new workspace from a
fresh clone that gives me this error:
ERROR: OE-core's config sanity checker detected a potential
misconfiguration.
Either fix the cause of this error or at your own risk disable the
checker (see sanity.conf).
Following is the list of potential problems / advisories:
MACHINE=imx7s-warp is invalid. Please set a valid MACHINE in your
local.conf, environment or other configuration file.
I'm guessing the problem is in meta-freescale-3rdparty where imx7s-warp is
defined, not my simple layers, but I have no clue where to start debugging
this.
Any advice on where to start??
Here's a CI job that builds and fails as described above:
https://ci.linaro.org/job/warp7-openembedded-warrior/161/DISTRO=rpb,label=d…
Here's the previous job from before the changes that succeeded:
https://ci.linaro.org/job/warp7-openembedded-warrior/160/DISTRO=rpb,label=d…
Thanks,
Ryan.
hi Jassi,
On Wed, Mar 4, 2020 at 1:34 AM Jassi Brar <jassisinghbrar(a)gmail.com> wrote:
> On Tue, Mar 3, 2020 at 1:15 AM Nicolas Dechesne
> <nicolas.dechesne(a)linaro.org> wrote:
> >
> > hi Jassi,
> >
> > On Tue, Mar 3, 2020 at 1:06 AM Jassi Brar <jassisinghbrar(a)gmail.com>
> wrote:
> >>
> >> Hi Team,
> >>
> >> I understand ubuntu-19.10 maybe too modern for Sumo builds, but I can
> >> not even build RPB distro with Zeus. Poky builds fine though.
> >
> >
> > Zeus was released at the same time as 19.10, so 19.10 is not marked as a
> supported distro in zeus, see
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/p…
> >
> I see now, thanks.
>
> > Can you please provide build log that is showing errors with RPB/zeus on
> 19.10?
> >
> I use the 'zeus' branch of oe-rpb-manifest.git and build
> rpb-console-image
>
I tried to reproduce. I am using the qcom/zeus branch in the manifest which
is pretty much the same as zeus (only shows the QCOM BSP). And I am using a
19.10 docker build env. For the record, my Dockerfile is here:
https://github.com/ndechesne/docker-me/blob/eoan/Dockerfile
So that you can see what packages are installed on my host.
> Build Configuration:
> BB_VERSION = "1.44.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING = "ubuntu-19.10"
> TARGET_SYS = "aarch64-linaro-linux"
> MACHINE = "hikey960"
> DISTRO = "rpb"
> DISTRO_VERSION = "3.0+linaro"
> TUNE_FEATURES = "aarch64 cortexa53 crc"
> TARGET_FPU = ""
> meta-rpb = "HEAD:c54331aacc7cd1e40b5e32fd1a7b3484904fbcb0"
>
My build config is:
Build Configuration:
BB_VERSION = "1.44.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "ubuntu-19.10"
TARGET_SYS = "aarch64-linaro-linux"
MACHINE = "dragonboard-410c"
DISTRO = "rpb"
DISTRO_VERSION = "3.0+linaro"
TUNE_FEATURES = "aarch64 cortexa53 crc"
TARGET_FPU = ""
meta-rpb = "HEAD:c54331aacc7cd1e40b5e32fd1a7b3484904fbcb0"
meta-oe
meta-gnome
meta-xfce
meta-initramfs
meta-multimedia
meta-networking
meta-webserver
meta-filesystems
meta-perl
meta-python = "HEAD:e855ecc6d35677e79780adc57b2552213c995731"
meta-rust = "HEAD:0f950f5e333a1c8999320bf18232144f3dd9c80e"
meta-browser = "HEAD:7378141606822ef0bb985aaa00e442c9ea806429"
meta-qt5 = "HEAD:432ad2aa6c3a13253fefc909faba368851d21fb1"
meta-virtualization = "HEAD:f4262ab75d36a06c528cc1630b48b817fb0acf8f"
meta-clang = "HEAD:0c393398a91713a108f319ac75337c02b7ebeaa7"
meta-selinux = "HEAD:44d760413920ba440439b8bc7c2a71ca26cd7a2d"
meta-96boards = "HEAD:a96a1dd635f32d8eb1d644db51c0e0d8297060d8"
meta-qcom = "HEAD:3e5569032856f4f1ab98687257dd0049342473c5"
meta-linaro
meta-linaro-toolchain
meta-optee = "HEAD:d9accce97e73d0be0037d22a5c155efddd216301"
meta = "HEAD:754d0ae5a960056468cdf50e5965a4c22515f8f9"
> 1) autoconf-native/2.69-r11/build/man/Makefile fails with
> "help2man: command not found"
> hacking it call /usr/bin/help2man instead of help2man makes it
> work.
>
> 2) libtool-native_2.4.6.bb:do_install fails with
> "func_fatal_help: command not found"
> Which does sound like host setup issue and not RPB specific.
> However, I can build Poky/Zeus for RPi4 just fine (from another
> how-to).
>
both autoconf-native and libtool-native build fine for me. So i cannot
reproduce your issues. Note that help2man package is not installed on my
host.
I can build core-image-minimal just fine, however rpb-console-image fails
to build, because of:
| Traceback (most recent call last):
| File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
| "__main__", mod_spec)
| File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
| exec(code, run_globals)
| File
"/home/nicolas.dechesne/work/oe-rpb-qcom-zeus/build-eoan/tmp-rpb-glibc/work/x86_64-linux/icu-native/64.2-r0/icu/source/data/buildtool/__main__.py",
line 19, in <module>
| import BUILDRULES
| File
"/home/nicolas.dechesne/work/oe-rpb-qcom-zeus/build-eoan/tmp-rpb-glibc/work/x86_64-linux/icu-native/64.2-r0/icu/source/test/testdata/BUILDRULES.py",
line 4, in <module>
| from distutils.sysconfig import parse_makefile
| ModuleNotFoundError: No module named 'distutils.sysconfig'
| configure: error: Python failed to run; see above error.
| WARNING:
/home/nicolas.dechesne/work/oe-rpb-qcom-zeus/build-eoan/tmp-rpb-glibc/work/x86_64-linux/icu-native/64.2-r0/temp/run.do_configure.13974:1
exit 1 from 'exit 1'
|
ERROR: Task
(virtual:native:/home/nicolas.dechesne/work/oe-rpb-qcom-zeus/build-eoan/conf/../../layers/openembedded-core/meta/recipes-support/icu/icu_64.2.bb:do_configure)
failed with exit code '1'
which is yet another error...
> Thanks!
>
hi Jassi,
On Tue, Mar 3, 2020 at 1:06 AM Jassi Brar <jassisinghbrar(a)gmail.com> wrote:
> Hi Team,
>
> I understand ubuntu-19.10 maybe too modern for Sumo builds, but I can
> not even build RPB distro with Zeus. Poky builds fine though.
>
Zeus was released at the same time as 19.10, so 19.10 is not marked as a
supported distro in zeus, see
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/p…
Can you please provide build log that is showing errors with RPB/zeus on
19.10?
> Any suggestions please, how can I build zeus/sumo rpb on ubuntu-19.10
> (I don't want to downgrade to 19.04 which is reported to build Sumo
> ok).
>
> I tried the zeus branch of https://github.com/96boards/oe-rpb-manifest
>
> Thanks!
>
hi,
we are hitting some errors with repo init since last night. After
looking into it , I came up with the following explanation and fix..
If I am correct, it will impact all our OE RPB build setup..
Can you please review that carefully?
The PR is on github:
https://github.com/96boards/oe-rpb-manifest/pull/121
I put a copy of the commit message below to bring it to your attention!
cheers
nico
==
All along we have been using a relative symlink for setup-environment
which points outside of the project path. While we've enjoyed this
hack for several years, a recent change was in repo, and repo init now
fails with:
error.ManifestInvalidPathError: <linkfile> invalid "src":
../../.repo/manifests/setup-environment: bad component: .repo
The change in repo is this one:
https://gerrit.googlesource.com/git-repo/+/07392ed32662006c029299bc06617310…
The repo documentation states: The symlink is created at “dest”
(relative to the top of the tree) and points to the path specified by
“src” which is a path in the project.
As such, repo clearly expects that 'src' is in the project path, which
is not the cause when using ../../.repo/ path.
This patch changes our folder structure in such a way that:
* the manifest git is checked out as ./conf/ folder in the top level
directory
* setup-environment link is created by repo, as a link to
conf/setup-environment-internal
The main drawback is that it feels non standard to duplicate the whole
manifest project again (since it's already checked out in .repo)
however using .repo content also meant we were making assumptions on
implementation details of repo itself.
Signed-off-by: Nicolas Dechesne <nicolas.dechesne(a)linaro.org>
Hi,
I changed the RPB qcom-lt builds to use docker-buster-amd64 because we have
been experimenting image corruption with ext2simg tool in new RPB zeus
builds [1], there is a related bug report [1] and that's the reason why our
Debian builds uses img2simg.
I tried to use img2simg in Debian stretch but is an old version (5.x) and
fails to create images when are small size (ramdisk).
So it's a good opportunity to change the docker builder to Debian buster
with a newer img2simg (8.x) tool in qcom-lt builds, I made the change in a
way that doesn't affect current builds that uses Debian stretch [3] and
give time to other users to switch (if needed).
Regards,
Anibal
[1] https://validation.linaro.org/scheduler/job/1965964
[2] https://discuss.96boards.org/t/ext2simg-is-corrupting-custom-rootfs/8792
[3]
https://git.linaro.org/ci/job/configs.git/commit/?id=2798029ae4a2772c9b51ef…
Hi Everyone,
We are pleased to announce that support for ARM GCC 9.2-2019.12 [1]
toolchain has been added in meta-linaro [2].
- Support for ARM GCC 9.2 toolchain built from source, steps to use it:
- Add <path-to-meta-linaro-repo>/meta-linaro-toolchain/ to BBLAYERS
in conf/bblayers.conf.
- Configure: GCCVERSION = "arm-9.2" in conf/local.conf.
- Support for prebuilt ARM GCC 9.2 toolchain, steps to use it:
- Add <path-to-meta-linaro-repo>/meta-linaro-toolchain/ to BBLAYERS
in conf/bblayers.conf.
- Configure: TCMODE = "external-arm" in conf/local.conf.
- For AArch64 (eg. qemuarm64 machine in poky distro)
- Configure: EXTERNAL_TOOLCHAIN =
"<installation-path>/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu"
in
conf/local.conf.
- For AArch32 (eg. qemuarm machine in poky distro)
- Configure: EXTERNAL_TOOLCHAIN =
"<installation-path>/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf"
in conf/local.conf.
Distro testing:
===========
- poky distro (branch: zeus, machines: qemuarm and qemuarm64)
- Build and boot tested.
- RPB distro (branch: zeus, machine: dragonboard-410c)
- Build and boot tested.
- World builds (branch: zeus, machines: qemuarm and qemuarm64) for
following layers:
- poky/meta
- poky/meta-poky
- poky/meta-yocto-bsp
- meta-openembedded/meta-oe
- meta-openembedded/meta-python
- meta-openembedded/meta-networking
Known issues:
===========
- mariadb build failure with ARM GCC 9.2 toolchain built from source:
- Recipe fix patch [3] accepted in OE upstream.
- Native tools dependency issues seen with multiple recipes (psmisc,
xclock, ndisc6, dovecot, man-db, drbd-utils and unbound) when using
prebuilt ARM GCC 9.2 toolchain.
- Fixes posted in OE upstream [4] [5].
Reporting bugs:
============
Please report any issue here [6].
[1]
https://developer.arm.com/tools-and-software/open-source-software/developer…
[2] https://git.linaro.org/openembedded/meta-linaro.git/?h=master
[3] https://patchwork.openembedded.org/patch/169296/
[4] https://patchwork.openembedded.org/patch/169289/
[5] https://patchwork.openembedded.org/series/22188/
[6] https://bugs.linaro.org/enter_bug.cgi?product=Linaro%20OpenEmbedded
Happy hacking!,
Regards,
Sumit
Hi Nico,
My WaRP7 builds are failing because meta-clang has dropped warrior support
from its master branch. The same problem will happen in oe-rpb's warrior
branch, as you're also using meta-clang master.
The meta-clang warrior branch is quite old and is missing a lot of the
patches from master that I've been building with for a long time. I wanted
to send a patch to fix oe-rpb, but I don't know if you'd prefer to use the
last known good SHA from the meta-clang master branch, or to use their
warrior branch.
I'm not using clang, so for my WaRP7 builds, I've just reverted to the
warrior branch to see if it builds, at least.
Cheers,
Ryan.
---------- Forwarded message ---------
From: <ci_notify(a)linaro.org>
Date: Thu, 14 Nov 2019 at 05:57
Subject: [CI-NOTIFY]: WaRP7 OpenEmbedded (warrior) - Build # 154 - Still
Failing!
To: <ryan.harkin(a)linaro.org>
Hello CI User,
This is notification from ci.linaro.org for project WaRP7 OpenEmbedded
(warrior).
The project WaRP7 OpenEmbedded (warrior) Build # 154 - Still Failing.
Please check console output at
https://ci.linaro.org/job/warp7-openembedded-warrior/154/ to view the
results.
Thanks!!!
CI Team
On Wed, Nov 6, 2019 at 2:19 PM Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote:
>
> Yes, I did.
>
> On Wed, 6 Nov 2019 at 15:58, Nicolas Dechesne
> <nicolas.dechesne(a)linaro.org> wrote:
> >
> > hi Maxim,
> >
> > your original email didn't make it to the mailing list.. not sure why,
> > you might want to check. I am adding the list here again.
> >
> > On Wed, Nov 6, 2019 at 10:54 AM Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote:
> > >
> > > looks like it is. after this patch:
> > > http://lists.openembedded.org/pipermail/bitbake-devel/2017-November/009097.…
> > > I see error:
> > > ERROR: ExpansionError during parsing
> > > /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb
> > > Traceback (most recent call last):
> > > File "Var <SRCPV>", line 1, in <module>
> > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > > line 768, in get_srcrev(d=<bb.data_smart.DataSmart object at
> > > 0x7faa98f59e48>, method_name='sortable_revision'):
> > > raise FetchError("The SRCREV_FORMAT variable must be set
> > > when multiple SCMs are used.\n"\
> > > > "The SCMs are:\n%s" % '\n'.join(scms))
> > >
> > > bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
> > > expression was ${(a)bb.fetch2.get_srcrev(d)} which triggered exception
> > > FetchError: Fetcher failure: The SRCREV_FORMAT variable must be set
> > > when multiple SCMs are used.
> >
> > I don't understand the situation. do we have a problem or did you fix it?
> >
> > and btw, are we really still using this recipe from 2014? or did you
> > find that by accident?
> >
> yea fresh version of openjdk is in meta-java. But it has some issues
> to compile on aarch64.
>
> Issue with meta-linaro can be fixed in a few ways:
> 1. add SRCREV_FORMAT = "jdk8" and apply this patch
> http://lists.openembedded.org/pipermail/bitbake-devel/2017-November/009097.…
>
> or
>
> 2. HG can allow to download tar balls. So we can switch from hg:// to https://.
>
> or
>
> 3. Simple drop openjdk from meta-linaro and fix meta-java version.
>
> For my issue meta-linaro/aarch64 was in ledge rp build. And parser
> of .bb files started to fail on that recipe after we switched to zeus
> branch. Because we don't need openjdk I simply removed it from ledge
> rp layer. That fixed my current issue. But in general it will be good
> to fix it.
I think we should fix upstream. I think we used this recipe initially
for the bring up, but it should be removed now. Would be nice to have
some background on this recipe.. or at least someone who can confirm
it's safe to be removed now.
>
> Maxim.
>
> > > The SCMs are:
> > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jdk8;name…
> > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/corba;nam…
> > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/hotspot;n…
> > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jaxp;name…
> > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jaxws;nam…
> > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jdk;name=…
> > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/langtools…
> > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/nashorn;n…
> > >
> > >
> > >
> > > On Wed, 6 Nov 2019 at 12:33, Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote:
> > > >
> > > > Hi Nicolas,
> > > >
> > > > is that known bug?
> > > >
> > > > ---------- Forwarded message ---------
> > > > From: Maxim Uvarov <maxim.uvarov(a)linaro.org>
> > > > Date: Tue, 5 Nov 2019 at 23:09
> > > > Subject: openjdk is broken on zeus branch
> > > > To: <openembedded(a)lists.linaro.org>
> > > >
> > > >
> > > > It looks like ${AUTOREV} with hg tool project is broken. openjdk from
> > > > meta-java also does not use AUTOREV. I'm not sure what is better fix
> > > > for that - remove AUTOREV or fix it?
> > > >
> > > > BR,
> > > > Maxim.
> > > >
> > > > WARNING: /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb:
> > > > Exception during build_dependencies for AUTOREV | ETA:
> > > > --:--:--
> > > > WARNING: /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb:
> > > > Error during finalise of
> > > > /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb
> > > > ERROR: ExpansionError during parsing
> > > > /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb
> > > > Traceback (most recent call last):
> > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > > > line 1302, in FetchData.setup_revisions(d=<bb.data_smart.DataSmart
> > > > object at 0x7fddc1423b38>):
> > > > for name in self.names:
> > > > > self.revisions[name] = srcrev_internal_helper(self, d, name)
> > > >
> > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > > > line 1167, in srcrev_internal_helper(ud=<bb.fetch2.FetchData object at
> > > > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>,
> > > > name='jdk8'):
> > > > if srcrev == "AUTOINC":
> > > > > srcrev = ud.method.latest_revision(ud, d, name)
> > > >
> > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > > > line 1558, in Hg.latest_revision(ud=<bb.fetch2.FetchData object at
> > > > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>,
> > > > name='jdk8'):
> > > > revs = bb.persist_data.persist('BB_URI_HEADREVS', d)
> > > > > key = self.generate_revision_key(ud, d, name)
> > > > try:
> > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > > > line 1570, in Hg.generate_revision_key(ud=<bb.fetch2.FetchData object
> > > > at 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at
> > > > 0x7fddc1423b38>, name='jdk8'):
> > > > def generate_revision_key(self, ud, d, name):
> > > > > key = self._revision_key(ud, d, name)
> > > > return "%s-%s" % (key, d.getVar("PN") or "")
> > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/hg.py",
> > > > line 225, in Hg._revision_key(ud=<bb.fetch2.FetchData object at
> > > > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>,
> > > > name='jdk8'):
> > > > """
> > > > > return "hg:" + ud.moddir
> > > >
> > > > bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
> > > > expression was ${(a)bb.fetch2.get_srcrev(d)} which triggered exception
> > > > AttributeError: 'FetchData' object has no attribute 'moddir'
hi Maxim,
your original email didn't make it to the mailing list.. not sure why,
you might want to check. I am adding the list here again.
On Wed, Nov 6, 2019 at 10:54 AM Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote:
>
> looks like it is. after this patch:
> http://lists.openembedded.org/pipermail/bitbake-devel/2017-November/009097.…
> I see error:
> ERROR: ExpansionError during parsing
> /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb
> Traceback (most recent call last):
> File "Var <SRCPV>", line 1, in <module>
> File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> line 768, in get_srcrev(d=<bb.data_smart.DataSmart object at
> 0x7faa98f59e48>, method_name='sortable_revision'):
> raise FetchError("The SRCREV_FORMAT variable must be set
> when multiple SCMs are used.\n"\
> > "The SCMs are:\n%s" % '\n'.join(scms))
>
> bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
> expression was ${(a)bb.fetch2.get_srcrev(d)} which triggered exception
> FetchError: Fetcher failure: The SRCREV_FORMAT variable must be set
> when multiple SCMs are used.
I don't understand the situation. do we have a problem or did you fix it?
and btw, are we really still using this recipe from 2014? or did you
find that by accident?
> The SCMs are:
> hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jdk8;name…
> hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/corba;nam…
> hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/hotspot;n…
> hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jaxp;name…
> hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jaxws;nam…
> hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jdk;name=…
> hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/langtools…
> hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/nashorn;n…
>
>
>
> On Wed, 6 Nov 2019 at 12:33, Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote:
> >
> > Hi Nicolas,
> >
> > is that known bug?
> >
> > ---------- Forwarded message ---------
> > From: Maxim Uvarov <maxim.uvarov(a)linaro.org>
> > Date: Tue, 5 Nov 2019 at 23:09
> > Subject: openjdk is broken on zeus branch
> > To: <openembedded(a)lists.linaro.org>
> >
> >
> > It looks like ${AUTOREV} with hg tool project is broken. openjdk from
> > meta-java also does not use AUTOREV. I'm not sure what is better fix
> > for that - remove AUTOREV or fix it?
> >
> > BR,
> > Maxim.
> >
> > WARNING: /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb:
> > Exception during build_dependencies for AUTOREV | ETA:
> > --:--:--
> > WARNING: /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb:
> > Error during finalise of
> > /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb
> > ERROR: ExpansionError during parsing
> > /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb
> > Traceback (most recent call last):
> > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > line 1302, in FetchData.setup_revisions(d=<bb.data_smart.DataSmart
> > object at 0x7fddc1423b38>):
> > for name in self.names:
> > > self.revisions[name] = srcrev_internal_helper(self, d, name)
> >
> > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > line 1167, in srcrev_internal_helper(ud=<bb.fetch2.FetchData object at
> > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>,
> > name='jdk8'):
> > if srcrev == "AUTOINC":
> > > srcrev = ud.method.latest_revision(ud, d, name)
> >
> > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > line 1558, in Hg.latest_revision(ud=<bb.fetch2.FetchData object at
> > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>,
> > name='jdk8'):
> > revs = bb.persist_data.persist('BB_URI_HEADREVS', d)
> > > key = self.generate_revision_key(ud, d, name)
> > try:
> > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > line 1570, in Hg.generate_revision_key(ud=<bb.fetch2.FetchData object
> > at 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at
> > 0x7fddc1423b38>, name='jdk8'):
> > def generate_revision_key(self, ud, d, name):
> > > key = self._revision_key(ud, d, name)
> > return "%s-%s" % (key, d.getVar("PN") or "")
> > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/hg.py",
> > line 225, in Hg._revision_key(ud=<bb.fetch2.FetchData object at
> > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>,
> > name='jdk8'):
> > """
> > > return "hg:" + ud.moddir
> >
> > bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
> > expression was ${(a)bb.fetch2.get_srcrev(d)} which triggered exception
> > AttributeError: 'FetchData' object has no attribute 'moddir'
hi there,
I've pushed all needed changes to get started with Zeus builds for the
Linaro OE RPB CI:
* created zeus branch on meta-backports, meta-qcom
* created zeus branch on oe-rpb-manifest
* i did not create zeus and i am keeping master for meta-rpb,
meta-96boards, meta-linaro. it's compatible, at least for now
* our zeus manifest is using master for other layers when they don't
have a zeus branch
Build #1 is scheduled for now.. we will see how bad it goes.
I have also create the qcom/zeus branch (I recall that it is a
stripped down version of the overall Linaro manifest that only focuses
on Qualcomm BSP).
Of course, if you can keep an eye on builds and help fixing issues,
that would be much appreciated.
cheers
nico
Hi,
I have a working system based on Sumo. The system boots with a read-only
rootfs, then applies are read-write overlay for /etc.
When I migrate to Warrior, systemd-resolved fails to start. If I mount the
same rootfs via NFS, it starts and works fine. systemd-timesyncd is also
failing, but I haven't looked into that yet. It also works fine on the NFS
mounted system.
The resolve problem seems to be caused by two things:
- /var/volatile is read-only
- /run/systemd/resolve has the wrong ownership
drwxr-xr-x 2 systemd-network systemd-journal 80 Jul 12 16:23
resolve/
I think this permissions problem may be a result of the /var/volatile
mounting
problems; it looks fine on the NFS mounted system.
If I manually mount /var/volatile (it's in fstab) and change the ownership
on /run/systemd/resolve, the service starts just fine.
I also notice that /tmp is not mounted at all, which may be related.
Here are the various tmp mount points on my read-only rootfs:
$ mount | grep tmp
devtmpfs on /dev type devtmpfs
(rw,nosuid,size=112036k,nr_inodes=28009,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
overlay on /etc type overlay
(rw,relatime,lowerdir=/tmp/lower/etc,upperdir=/tmp/upper/etc,workdir=/tmp/upper/work/etc)
tmpfs on /run/user/0 type tmpfs
(rw,nosuid,nodev,relatime,size=23840k,mode=700)
On the NFS mounted system, I see these:
$ mount | grep tmp
devtmpfs on /dev type devtmpfs
(rw,relatime,size=118180k,nr_inodes=29545,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
tmpfs on /var/volatile type tmpfs (rw,relatime)
tmpfs on /run/user/0 type tmpfs
(rw,nosuid,nodev,relatime,size=23840k,mode=700)
As you can see, NFS has these extra mounts:
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
tmpfs on /var/volatile type tmpfs (rw,relatime)
I've tried reverting a few commits that may be related, but I haven't had
any luck working out things have changed, eg:
c4acf1b531 2018-10-19 volatile-binds: use overlayfs if available
[Matt Hoosier]
Advice would be appreciated. Are there any particular areas I should be
looking to work out what's going wrong?
Kind regards,
Ryan.
Hi Team, I have downloaded the lhg-oe-manifest source and builded it successfully for Dragonboard-410c.After flashing it on device i am only able to play the clearkey encrypted video but when i am trying to play the widevine encrypted content,it is showing like there is no supported key system.Is there any support of playing widevine encrypted content in this code.If not can you help me how to play widevine encrypted video.I have downloaded the code from below manifest $repo init -u https://github.com/linaro-mmwg/lhg-oe-manifests.git -b morty
It would be a great help for me if you provide me any way to get out of it.
Thanks and RegardsN.Tarani
Daniel,
as discussed, I've experimented with meta-rpb and the Yocto Compatible
check scripts.. see :
https://www.yoctoproject.org/docs/2.6/mega-manual/mega-manual.html#making-s…
There are many obvious reasons why it's a good idea to make sure that
layers can pass this script..
I was able to get meta-rpb to pass the compatibility check with the
following patches:
https://github.com/ndechesne/meta-rpb/tree/check-layer
The simplest way to run the script is to use a copy of Poky git:
$ git clone http://git.yoctoproject.org/git/poky
$ cd poky
$ source oe-init-build-env
$ yocto-check-layer <oe-rpb folder>/layers/meta-rpb/ --dependency
<oe-rpb folder>/layers/
The main things that the script will test are:
1. Adding your layer in bblayers.conf will not change any recipe
content/checksum
2. All dependencies are properly tracked
For meta-rpb, we depend on meta-virtualization (docker) and that layer
breaks compatibility in many ways.. so I had to remove references to
docker and meta-virt to run the script..
I will be doing a bit more testing/review, and submit the PR.
cheers
nico
hi,
i've started to push some updates about OE warrior for our Linaro builds.
The branch warrior was added to meta-rpb, meta-96boards, meta-qcom,
meta-linaro, meta-backports.
I have added a 'warrior' branch to the oe-rpb-manifest as well, see:
https://github.com/96boards/oe-rpb-manifest/commit/dd60a2322845adb9cfe7e82e…
Some layers still don't have a warrior branch, in which case we use master.
I have submitted a change to start build based on warrior..
Let's see how things go with this new branch!
cheers
nico
Hi all,
I'm trying to use the thud branch of Yocto Project with the Arago distro and the Linaro toolchain.
The external-linaro-toolchain.bb recipe includes glibc-package.inc from oe-core which has been modified in 2018 to install a makedbs.sh script [1] and to handle the floatn.h header introduced in glibc 2.26 [2]. The first change definitely breaks the external-linaro-toolchain recipe as no makedbs.sh script is present - in the oe-core glibc recipe this is included as a file and referenced in SRC_URI. The second change breaks if the Linaro toolchain includes a version of glibc prior to 2.26.
I see that an attempt to fix the above issues has been posted to this mailing list [3] but this wasn't merged and no other fix has gone into the meta-linaro repository. The was also a report of this issue posted to the Yocto mailing list in January [4]. So it looks like this has been broken for a few months but obviously hasn't been noticed more widely.
Is the external-linaro-toolchain recipe expected to work on the thud branch? If not, what should I be using instead?
[1]: https://git.openembedded.org/openembedded-core/commit/?h=thud&id=13cf502fce…
[2]: https://git.openembedded.org/openembedded-core/commit/?h=thud&id=650c59c8b6…
[3]: https://lists.linaro.org/pipermail/openembedded/2019-January/000159.html
[4]: https://lists.yoctoproject.org/pipermail/yocto/2019-January/043747.html
--
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
From: Denys Dmytriyenko <denys(a)ti.com>
libc.so linker script should use relative paths to not clash with host libs.
Using absolute paths in libc.so is fine with standalone toolchain or when
used inside a rootfs. But when used inside OE SDK for cross-compilation,
the absolute path confuses compiler with libs from host environment. In the
past, Linaro prebuilt toolchains always had relative paths inside libc.so
linker script. Adjust it the same for the Arm prebuilt toolchain.
Signed-off-by: Denys Dmytriyenko <denys(a)ti.com>
---
.../recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta-linaro-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb b/meta-linaro-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
index 6fb5a4d..a4067d8 100644
--- a/meta-linaro-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
+++ b/meta-linaro-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
@@ -233,6 +233,7 @@ do_install() {
if [ -f ${D}${libdir}/libc.so ];then
sed -i -e "s# /${EAT_LIBDIR}/${EAT_TARGET_SYS}# ../../${EAT_LIBDIR}#g" -e "s# /usr/${EAT_LIBDIR}/# /usr/lib/#g" -e "s# /usr/${EAT_LIBDIR}/${EAT_TARGET_SYS}# .#g" -e "s# /${EAT_LIBDIR}/ld-linux# ../../${EAT_LIBDIR}/ld-linux#g" ${D}${libdir}/libc.so
sed -i -e "s# /${EAT_LIBDIR}/libc.so.6# /lib/libc.so.6#g" ${D}${libdir}/libc.so
+ sed -i -e "s# /lib# ../../lib#g" -e "s# /usr/lib# .#g" ${D}${libdir}/libc.so
fi
if [ -f ${D}${base_libdir}/libc.so ];then
--
2.7.4
From: Denys Dmytriyenko <denys(a)ti.com>
This set cleans up and adds additional features to external-arm-toolchain recipe.
It packages up libc binaries like ldconfig, locale, tzselect, ldd and so on.
That results in a proper non-empty glibc-utils package, which gets pulled by
LIBC_DEPENDENCIES variable defined in tclibc-glibc.inc in OE-Core
It also packages up necessary static libs, stubs and headers for -dev variants
of libgcc, libgfortran, etc., satisfying packagegroup-core-standalone-sdk-target
recipe from OE-Core.
Please merge this set to master and backport it to thud as well. Thanks.
Denys Dmytriyenko (3):
external-arm-toolchain: basic cleanup
external-arm-toolchain: package up toolchain binaries
external-arm-toolchain: also package up extra libs, stubs and headers
.../external-arm-toolchain.bb | 45 ++++++++++++++++------
1 file changed, 33 insertions(+), 12 deletions(-)
--
2.7.4
From: Denys Dmytriyenko <denys(a)ti.com>
When backporting Arm toolchain from master to thud, several commits were missed,
as well as one addition of crosssdk-inital recipe was missing. This series
addresses those issues.
Denys Dmytriyenko (2):
gcc-crosssdk-initial: add missing arm-8.2 version
tcmode-external-arm: uncomment preference for
virtual/${TARGET_PREFIX}binutils
Koen Kooi (4):
tcmode-external-arm.inc: fix some ELT⇒ EAT conversions that were
missed previously
tcmode-external-arm.inc: prefer virtual/libc-locale =
external-arm-toolchain
tcmode-external-arm.inc: set glibc override
tcmode-external-arm.inc: add 'libc-locales libc-locale-code
libc-charsets' to DISTRO_FEATURES_LIBC
.../conf/distro/include/tcmode-external-arm.inc | 18 ++++++++++--------
.../gcc/gcc-crosssdk-initial_arm-8.2.bb | 3 +++
2 files changed, 13 insertions(+), 8 deletions(-)
create mode 100644 meta-linaro-toolchain/recipes-devtools/gcc/gcc-crosssdk-initial_arm-8.2.bb
--
2.7.4
On Fri, Mar 15, 2019 at 05:16:06PM -0600, Anibal Limon wrote:
> I sent a review request,
>
> https://review.linaro.org/c/openembedded/meta-linaro/+/30779
Any updates? I'm still getting a lot of warnings during parsing, e.g.:
WARNING: .../meta-linaro/meta-linaro-toolchain/recipes-core/glibc/glibc_linaro-2.20.bb: Unable to get checksum for glibc SRC_URI entry ld.so.conf: file could not be found
WARNING: .../meta-linaro/meta-linaro-toolchain/recipes-core/glibc/glibc_linaro-2.20.bb: Unable to get checksum for glibc SRC_URI entry 0022-Add-ILP32-to-makefiles.patch: file could not be found
Denys
> On Fri, 15 Mar 2019 at 14:46, Anibal Limon <anibal.limon(a)linaro.org> wrote:
>
> >
> >
> > On Fri, Mar 15, 2019, 1:54 PM Denys Dmytriyenko <denis(a)denix.org> wrote:
> >
> >> On Fri, Mar 15, 2019 at 09:55:21AM -0600, Anibal Limon wrote:
> >> > Hi Denys,
> >> >
> >> > I'm not see a PV set on glibc_linaro-2.20.bb, there is a PV set on gcc
> >> > recipes with linaro-2.20.
> >>
> >> As my previous email states - PV is set by the filename. Moreover, you
> >> are
> >> erroneously referrring to the recipe as "glibc_linaro", while it's
> >> "glibc"
> >> instead. And "linaro-2.20" is actually recipe's PV. The underscore in the
> >> filename separates recipe name from recipe version. From the manual:
> >>
> >>
> >> https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manu…
> >>
> >> | In this example, a recipe called "something_1.2.3.bb" sets PN to
> >> "something"
> >> | and PV to "1.2.3".
> >>
> >> Hence, in this case, glibc_linaro-2.20.bb used to set PN to "glibc" and
> >> PV to
> >> "linaro-2.20". And it used to work for years.
> >>
> >> Moreover, since ${FILESPATH} below expects ${FILE_DIRNAME}/glibc-${PV}
> >> and
> >> there's "glibc-linaro-2.20" directory with whole bunch of patches:
> >>
> >> https://git.linaro.org/openembedded/meta-linaro.git/tree/meta-linaro-toolch…
> >>
> >> So, with your change, it would instead try to look into "glibc-2.20" and
> >> fail
> >> to find any patches. Not even sure how it was tested...
> >>
> >
> > You are right, I not see the error because I'm using upstream glibc (2.29)
> > and the build didn't fail.
> >
> > I will update the PV in the common file.
> >
> > Regards,
> > Anibal
> >
> >
> >> --
> >> Denys
> >>
> >>
> >> > ...
> >> > $ git grep PV .
> >> > glibc-linaro-2.20/eglibc-ppc8xx-cache-line-workaround.patch:+ reads
> >> from
> >> > the PVR register. */
> >> > glibc-linaro-2.20/eglibc-ppc8xx-cache-line-workaround.patch:+
> >> emulates
> >> > PowerPC mfspr reads from the PVR register. */
> >> > glibc_linaro-2.20.bb:SRC_URI = "
> >> >
> >> http://releases.linaro.org/archive/${MMYY}/components/toolchain/glibc-linar…
> >> > \
> >> > glibc_linaro-2.20.bb:S = "${WORKDIR}/glibc-${PV}-${RELEASE}"
> >> > glibc_linaro-2.20.bb:FILESPATH = "${@base_set_filespath([
> >> > '${FILE_DIRNAME}/glibc-${PV}', '${FILE_DIRNAME}/glibc',
> >> > '${FILE_DIRNAME}/files', '${FILE_DIRNAME}' ], d)}"
> >> > glibc_linaro.inc:PV = "2.20"
> >> > ...
> >> >
> >> > What is the error that you have noticed?
> >> >
> >> > Regards,
> >> > Anibal
> >> >
> >> > On Fri, 8 Mar 2019 at 14:32, Denys Dmytriyenko <denis(a)denix.org> wrote:
> >> >
> >> > >
> >> > >
> >> https://git.linaro.org/openembedded/meta-linaro.git/commit/?id=768925270cc2…
> >> > >
> >> > > meta-linaro-toolchain: Set PV on glibc_linaro
> >> > > Recently a common file was introudced to set PV for glibc [1]
> >> > > in oe-core causing failures becuase glibc_linaro is trying
> >> > > to download the latest oe-core version (2.29).
> >> > >
> >> > > [1]
> >> https://git.openembedded.org/openembedded-core/commit/?id=41093cb6c6
> >> > >
> >> > > Change-Id: I5c99c25a953f00a64614046ba40e578795553bc1
> >> > > Signed-off-by: Aníbal Limón <anibal.limon(a)linaro.org>
> >> > >
> >> > >
> >> > > The problem is that all those modified recipes already had PV set in
> >> their
> >> > > filename and it was "linaro-2.20", not just "2.20".
> >
> > > >
> >> > > --
> >> > > Denys
> >> > >
> >>
> >
On Fri, Mar 15, 2019 at 09:55:21AM -0600, Anibal Limon wrote:
> Hi Denys,
>
> I'm not see a PV set on glibc_linaro-2.20.bb, there is a PV set on gcc
> recipes with linaro-2.20.
As my previous email states - PV is set by the filename. Moreover, you are
erroneously referrring to the recipe as "glibc_linaro", while it's "glibc"
instead. And "linaro-2.20" is actually recipe's PV. The underscore in the
filename separates recipe name from recipe version. From the manual:
https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manu…
| In this example, a recipe called "something_1.2.3.bb" sets PN to "something"
| and PV to "1.2.3".
Hence, in this case, glibc_linaro-2.20.bb used to set PN to "glibc" and PV to
"linaro-2.20". And it used to work for years.
Moreover, since ${FILESPATH} below expects ${FILE_DIRNAME}/glibc-${PV} and
there's "glibc-linaro-2.20" directory with whole bunch of patches:
https://git.linaro.org/openembedded/meta-linaro.git/tree/meta-linaro-toolch…
So, with your change, it would instead try to look into "glibc-2.20" and fail
to find any patches. Not even sure how it was tested...
--
Denys
> ...
> $ git grep PV .
> glibc-linaro-2.20/eglibc-ppc8xx-cache-line-workaround.patch:+ reads from
> the PVR register. */
> glibc-linaro-2.20/eglibc-ppc8xx-cache-line-workaround.patch:+ emulates
> PowerPC mfspr reads from the PVR register. */
> glibc_linaro-2.20.bb:SRC_URI = "
> http://releases.linaro.org/archive/${MMYY}/components/toolchain/glibc-linar…
> \
> glibc_linaro-2.20.bb:S = "${WORKDIR}/glibc-${PV}-${RELEASE}"
> glibc_linaro-2.20.bb:FILESPATH = "${@base_set_filespath([
> '${FILE_DIRNAME}/glibc-${PV}', '${FILE_DIRNAME}/glibc',
> '${FILE_DIRNAME}/files', '${FILE_DIRNAME}' ], d)}"
> glibc_linaro.inc:PV = "2.20"
> ...
>
> What is the error that you have noticed?
>
> Regards,
> Anibal
>
> On Fri, 8 Mar 2019 at 14:32, Denys Dmytriyenko <denis(a)denix.org> wrote:
>
> >
> > https://git.linaro.org/openembedded/meta-linaro.git/commit/?id=768925270cc2…
> >
> > meta-linaro-toolchain: Set PV on glibc_linaro
> > Recently a common file was introudced to set PV for glibc [1]
> > in oe-core causing failures becuase glibc_linaro is trying
> > to download the latest oe-core version (2.29).
> >
> > [1] https://git.openembedded.org/openembedded-core/commit/?id=41093cb6c6
> >
> > Change-Id: I5c99c25a953f00a64614046ba40e578795553bc1
> > Signed-off-by: Aníbal Limón <anibal.limon(a)linaro.org>
> >
> >
> > The problem is that all those modified recipes already had PV set in their
> > filename and it was "linaro-2.20", not just "2.20".
> >
> > --
> > Denys
> >
https://git.linaro.org/openembedded/meta-linaro.git/commit/?id=768925270cc2…
meta-linaro-toolchain: Set PV on glibc_linaro
Recently a common file was introudced to set PV for glibc [1]
in oe-core causing failures becuase glibc_linaro is trying
to download the latest oe-core version (2.29).
[1] https://git.openembedded.org/openembedded-core/commit/?id=41093cb6c6
Change-Id: I5c99c25a953f00a64614046ba40e578795553bc1
Signed-off-by: Aníbal Limón <anibal.limon(a)linaro.org>
The problem is that all those modified recipes already had PV set in their
filename and it was "linaro-2.20", not just "2.20".
--
Denys
Hi all,
I tried the new external-arm feature.
I had a problem in building gdb-7.8, attached the patch I used to
solve the problem,an in the following the patch for the layer, but
anyway why gdb-7.8 is still used in the master branch? why do not
upgrade to a newer version?
Regards,
d.
diff --git a/meta-linaro-toolchain/recipes-devtools/gdb/gdb_linaro-7.8.bb
b/meta-linaro-toolchain/recipes-devtools/gdb/gdb_linaro-7.8.bb
index 630d43c..841b1ed 100644
--- a/meta-linaro-toolchain/recipes-devtools/gdb/gdb_linaro-7.8.bb
+++ b/meta-linaro-toolchain/recipes-devtools/gdb/gdb_linaro-7.8.bb
@@ -6,6 +6,8 @@ inherit python-dir
PACKAGECONFIG ??= ""
PACKAGECONFIG[python] =
"--with-python=${WORKDIR}/python,--without-python,python"
+SRC_URI += "file://0001-Fix-compilation-external-gcc-arm-8.2-2018.11.patch"
+
do_configure_prepend() {
if [ -n "${(a)bb.utils.contains('PACKAGECONFIG', 'python',
'python', '', d)}" ]; then
cat > ${WORKDIR}/python << EOF
From: Denys Dmytriyenko <denys(a)ti.com>
Fixes for the recently introduced external ARM toolchain support.
Denys Dmytriyenko (15):
tcmode-external-arm: use correct EAT_ prefix instead of ELT_ for
TARGET_SYS
external-arm-toolchain: also support 32-bit arm toolchains
tcmode-external-arm: uncomment preference for
virtual/${TARGET_PREFIX}binutils
external-arm-toolchain: package header files into
linux-libc-headers-dev
external-arm-toolchain: libgcc_s.so in base_libdir is not a symlink,
but a linker script
external-arm-toolchain: package c++ headers
external-arm-toolchain: some packages rdepend on ldd, so allow
creating empty package
external-arm-toolchain: fix host contamination QA issue
external-arm-toolchain: switch from ${COREBASE}/LICENSE to
${COMMON_LICENSE_DIR}/MIT
external-arm-toolchain: libasan/libubsan bump major version number
external-arm-toolchain: libcidn is no longer packaged
external-arm-toolchain: libnsl was split off of glibc and is a
separate package now
external-arm-toolchain: rpcsvc/rquota.* headers are now provided by
separate quota package
external-arm-toolchain: also provide virtual/libc-locale
external-arm-toolchain: also set proper RPROVIDES for glibc-staticdev
.../include/external-arm-toolchain-versions.inc | 8 +--
.../conf/distro/include/tcmode-external-arm.inc | 17 +++--
.../external-arm-toolchain.bb | 76 ++++++++++++----------
3 files changed, 56 insertions(+), 45 deletions(-)
--
2.7.4
hi there,
as discussed recently, we are starting to put together the thud builds
for Linaro OE RPB.
* The oe-rpb-manifest now has the 'thud' branch, see [1]. Some layers
are still missing thud branch themselves, in which case we use master.
* we created thud branches for all Linaro layers (meta-linaro,
meta-backports, meta-rpb, meta-96boards, meta-qcom)
* A new build was created on ci.linaro, see [2] , and is now enabled
(which means it will trigger on any change on one of the thud branches
we track)
The first 2 builds failed during the weekend, but it was
infrastructure issues, however we just got a new failure that is a
valid failure.. see [3]. Looks like LTP fails to build.
Daniel: is that something you can check and fix?
cheers
nico
[1] https://github.com/96boards/oe-rpb-manifest/tree/thud
[2] https://review.linaro.org/#/c/ci/job/configs/+/29110/
[3] https://ci.linaro.org/job/96boards-reference-platform-openembedded-thud/
Adding the Linaro OE mailing list.
I am not familiar with the details of what you are doing, but it looks
like your layer needs to be updated. See
https://bugzilla.yoctoproject.org/show_bug.cgi?id=3314, the getVar()
function was updated and that requires updating your layer.
nico
On Thu, Oct 18, 2018 at 9:06 PM Park, Kyung Min
<kyung.min.park(a)intel.com> wrote:
>
> Copying Nicolas/Fathi here.
>
>
>
> Hi Nicolas/Fathi,
>
> Can you comment on this?
>
>
>
> Thanks,
>
> Kyung Min
>
>
>
> From: Dey, Megha
> Sent: Wednesday, October 17, 2018 4:40 PM
> To: Park, Kyung Min <kyung.min.park(a)intel.com>; koen.kooi(a)linaro.org
> Subject: RE: oe-rpb-manifest sumo branch?
>
>
>
> Hi Koen,
>
>
>
> We are trying to configure LUV (Linux UEFI Validation) using the OE-RPB model, as per our discussion at the Linaro connect.
>
>
>
> As a start, we tried to build the oe-rpb-manifest with the default morty branch and everything builds fine. However, if we switch to the sumo branch, we see the error below.
>
>
>
> We wanted to confirm if the sumo branch build fine on your end and if we are missing something on our end.
>
>
>
> Please let us know.
>
>
>
> Thanks,
>
> Megha
>
>
>
> From: Park, Kyung Min
> Sent: Tuesday, October 9, 2018 5:22 PM
> To: koen.kooi(a)linaro.org
> Cc: Dey, Megha <megha.dey(a)intel.com>
> Subject: oe-rpb-manifest sumo branch?
>
>
>
> Hi Koen,
>
>
>
> We’ve been trying to build the oe-rpb-manifest with ‘sumo’ branch. But, we’re getting an error in data_smart.py as below.
>
> Do you know if anybody tried sumo branch or validated? Everything went well with ‘morty’ branch.
>
>
>
> # git repo
>
> https://github.com/96boards/oe-rpb-manifest
>
>
>
> # error log when build
>
> ERROR: Unable to parse /home/km/Documents/rpb-yocto-tue/oe-rpb-manifest/bitbake/lib/bb/data_smart.py
>
> Traceback (most recent call last):
>
> File "/home/km/Documents/rpb-yocto-tue/oe-rpb-manifest/bitbake/lib/bb/data_smart.py", line 401, in DataSmart.ex pandWithRefs(s="${(a)os.path.dirname(bb.utils.which(d.getVar('PATH'),'bitbake'))}:${HOSTTOOLS_DIR}", varname='PATH[ :=]'):
>
> raise ExpansionError(varname, s, exc) from exc
>
>
>
> bb.data_smart.ExpansionError: Failure expanding variable PATH[:=], expression was ${(a)os.path.dirname(bb.utils.whi ch(d.getVar('PATH'),'bitbake'))}:${HOSTTOOLS_DIR} which triggered exception TypeError: getVar() missing 1 require d positional argument: 'expand'
>
>
>
> Thanks,
>
> Kyung Min
libcc1 is not included in gcc 4.9 so bad RPATHs fix not needed
in this version.
Signed-off-by: Daniel Gomez <daniel.gomez(a)silicon-gears.com>
---
meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb | 6 ---
---
1 file changed, 6 deletions(-)
diff --git a/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-
4.9.bb b/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
index 3e0f4bc..68d3d92 100644
--- a/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
+++ b/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
@@ -7,12 +7,6 @@ require recipes-devtools/gcc/gcc-target.inc
# | gcc-4.8.1-r0/gcc-4.8.1/gcc/cp/decl.c:7442:(.text.unlikely+0x318):
additional relocation overflows omitted from the output
ARM_INSTRUCTION_SET_armv4 = "arm"
-do_configure_prepend() {
- # Easiest way to stop bad RPATHs getting into the library
since we have a
- # broken libtool here
- sed -i -e 's/hardcode_into_libs=yes/hardcode_into_libs=no/'
${S}/libcc1/configure
-}
-
BBCLASSEXTEND = "nativesdk"
DEPENDS += "gmp-native"
--
2.7.4
libcc1 is not included in gcc 4.9 so bad RPATHs fix not needed
in this version.
Signed-off-by: Daniel Gomez <daniel.gomez(a)silicon-gears.com>
---
meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb | 6 ---
---
1 file changed, 6 deletions(-)
diff --git a/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-
4.9.bb b/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
index 3e0f4bc..68d3d92 100644
--- a/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
+++ b/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
@@ -7,12 +7,6 @@ require recipes-devtools/gcc/gcc-target.inc
# | gcc-4.8.1-r0/gcc-4.8.1/gcc/cp/decl.c:7442:(.text.unlikely+0x318):
additional relocation overflows omitted from the output
ARM_INSTRUCTION_SET_armv4 = "arm"
-do_configure_prepend() {
- # Easiest way to stop bad RPATHs getting into the library
since we have a
- # broken libtool here
- sed -i -e 's/hardcode_into_libs=yes/hardcode_into_libs=no/'
${S}/libcc1/configure
-}
-
BBCLASSEXTEND = "nativesdk"
DEPENDS += "gmp-native"
--
2.7.4
Hi,
I looked at https://github.com/96boards/meta-rpb/blame/rocko/recipes-overlayed/kselftes… today and noticed a common anti-pattern:
FOO += “bar”
FOO += “quix”
FOO += “something”
Please stop doing that and use this instead:
FOO = “bar \
quix \
something \
“
In OE += is a heavy operation that really slows down parsing due to the all the expansion and override roundtrips needed, so please stop abusing it as a way to do multiline variables. Thanks!
—
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
Signed-off-by: Daniel Gomez <daniel.gomez(a)silicon-gears.com>
---
meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb b/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
index 3e0f4bc..5a26fa2 100644
--- a/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
+++ b/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
@@ -10,7 +10,9 @@ ARM_INSTRUCTION_SET_armv4 = "arm"
do_configure_prepend() {
# Easiest way to stop bad RPATHs getting into the library since we have a
# broken libtool here
- sed -i -e 's/hardcode_into_libs=yes/hardcode_into_libs=no/' ${S}/libcc1/configure
+ if [ -d "${S}/libcc1" ]; then
+ sed -i -e 's/hardcode_into_libs=yes/hardcode_into_libs=no/' ${S}/libcc1/configure
+ fi
}
BBCLASSEXTEND = "nativesdk"
--
2.7.4
Check libcc1 directory before trying to fix it
Signed-off-by: Daniel Gomez <daniel.gomez(a)silicon-gears.com>
---
meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb b/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
index 3e0f4bc..5a26fa2 100644
--- a/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
+++ b/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
@@ -10,7 +10,9 @@ ARM_INSTRUCTION_SET_armv4 = "arm"
do_configure_prepend() {
# Easiest way to stop bad RPATHs getting into the library since we have a
# broken libtool here
- sed -i -e 's/hardcode_into_libs=yes/hardcode_into_libs=no/' ${S}/libcc1/configure
+ if [ -d "${S}/libcc1" ]; then
+ sed -i -e 's/hardcode_into_libs=yes/hardcode_into_libs=no/' ${S}/libcc1/configure
+ fi
}
BBCLASSEXTEND = "nativesdk"
--
2.7.4
Koen, Fathi,
Thanks for updating gcc recipe to 7.2 and merging it to rocko! I have some
matching fixes for the external toolchain recipe I'll try to submit soon...
I was wondering what are the plans for other toolchain components, like glibc,
gdb and binutils - there are recipes for glibc 2.20-2014.11, gdb 7.8-2014.09
and binutils 2.25/2.27 2016.10. All those correspond to when the last time a
tarball of that component was released by Linaro. I know these days all those
components are in git at https://git.linaro.org/toolchain/ - are there any
plans to provide corresponding recipes to build those components from sources?
--
Denys
Hello,
I am seeing this error in my build:
Configuring aCollected errors:
* check_data_file_clashes: Package linux-firmware-bcm43430 wants to
install file /linaro/mbl/workspace-arm/build-mbl/tmp-mbl-glibc/work/imx7s
_warp-oe-linux-gnueabi/mbl-console-image-test/1.0-r0/root
fs/lib/firmware/brcm/brcmfmac43430-sdio.bin
But that file is already provided by package * firmware-imx
* check_data_file_clashes: Package linux-firmware-bcm43430 wants to
install file /linaro/mbl/workspace-arm/build-mbl/tmp-mbl-glibc/work/imx7s
_warp-oe-linux-gnueabi/mbl-console-image-test/1.0-r0/root
fs/lib/firmware/brcm/brcmfmac43430-sdio.txt
But that file is already provided by package * firmware-imx
In my build, I'm including meta-raspberrypi and meta-freescale-3rdparty in
my manifest. These two meta layers include the following two files into the
rootfs in various ways:
/lib/firmware/brcm/brcmfmac43430-sdio.txt
/lib/firmware/brcm/brcmfmac43430-sdio.bin
For example, in the following files define a way of adding the firmware
into the rootfs (there will be more ways they get into the build, saying as
one is a .inc file):
meta-freescale-3rdparty/recipes-bsp/broadcom-nvram-config/
broadcom-nvram-config.inc
meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware_%.bbappend
openembedded-core/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
My meta-layer is included after meta-freescale* and meta-raspberrypi, but
before openembedded-core/meta in my BBLAYERS setup.
However, I want to provide a newer version of these two files in my build.
So we created this recipe in our meta layer:
file: recipes-bsp/firmware-imx/firmware-imx_%.bbappend
------------------------------------------------------------
--------------------------
SRCREV_linuxfirmware = "a61ac5cf8374edbfe692d12f805a1b194f7fead2"
SRCREV_recalboxbuildroot = "f648e4b54eb5e4be593746d6cc51375b22a7efbd"
SRC_URI += "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linu
x-firmware.git;branch=${SRCBRANCH};destsuffix=${S}/git1;name=linuxfirmware
<http://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;…>
\
git://github.com/recalbox/recalbox-buildroot.git;protocol=
https;branch=${SRCBRANCH};destsuffix=${S}/git2;name=recalboxbuildroot
<http://github.com/recalbox/recalbox-buildroot.git;protocol=https;branch=$%7…>
"
LIC_FILES_CHKSUM += "file://git1/LICENCE.broadcom_
bcm43xx;md5=3160c14df7228891b868060e1951dfbc \
file://git2/COPYING;md5=e4edbc78b8892db416b6a07e0d97309a
"
do_install_append() {
install -d ${D}${base_libdir}/firmware
install -d ${D}${base_libdir}/firmware/brcm
cp -rfv git1/brcm/brcmfmac43430-sdio.bin ${D}${base_libdir}/firmware/br
cm
cp -rfv git2/board/warp7/rootfs_overlay/lib/firmware/brcm/brcmfmac43430-sdio.txt
${D}${base_libdir}/firmware/brcm
}
FILES_${PN} += "${base_libdir}/firmware/brcm/brcmfmac43430*"
COMPATIBLE_MACHINE = "(imx7s-warp)"
------------------------------------------------------------
--------------------------
It builds fine in a "normal" configuration. However, in a "test" build,
where "dev-pkgs" is added to IMAGE_FEATURES, I get the error as above.
So how do I work around this issue? Am I doing the wrong thing by providing
a bbappend to overlay these files?
Any advice appreciated.
Regards,
Ryan.
Hi All,
I am new to the OpenEmbedded framework and kindly do let me know if this is not the right forum for such query.
I am using the Dragonboard410c with the Linaro OpenEmbedded Release (Steps to build the sources is: https://github.com/96boards/oe-rpb-manifest)
I want to do a clean build and incremental build of only the kernel sources.
I checked articles for the same and found the below commands:
bitbake -c cleansstate virtual/kernel
bitbake -c clean virtual/kernel
But the above commands are giving error like below:
******* Error Start *******
ERROR: Nothing PROVIDES 'linux-linaro-aarch64'
ERROR: linux-linaro-aarch64 was skipped: We shouldn't have multilib variants for the kernel
ERROR: linux-linaro-aarch64 was skipped: PREFERRED_PROVIDER_virtual/kernel set to linux-linaro-qcomlt, not linux-linaro-aarch64
******* Error End *******
I also tried the below:
bitbake -c cleansstate linux-linaro-qcomlt
bitbake -c cleansstate linux-linaro-aarch64
But that also does not work.
So can you please suggest from where can I know, how to build the kernel without triggering the whole build.
Thanks & Regards,
Sunny
************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *************************************************************************************************************************************************************
It can be slightly tricky to build a copy of python-wand that will also
function. A problem is that without additional logic (MAGICK_HOME), the
python code will not look outside of system paths for a copy of the
imagemagick library. However, even with this path added to the search
list, the code will still try a 'naked' load of the library it wants.
This can result in a visible failure if you have a new enough
imagemagic-6 installed (such as 6.9.7) as the date string checking logic
will fail. Work around these problems by setting MAGICK_HOME globally
to the correct location and patch the api code to look for the form of
imagemagick that we build first, rather than last, so that we are going
to first search for what we know we built.
Signed-off-by: Tom Rini <trini(a)konsulko.com>
---
This patch should be applied to at least master, pyro and rocko.
Arguably this should also be applied further back as without MAGICK_HOME
it will never be looking in our sysroot.
.../0001-wand-api.py-Change-search-order.patch | 32 ++++++++++++++++++++++
.../recipes-devtools/python/python-wand_0.4.4.bb | 7 ++++-
2 files changed, 38 insertions(+), 1 deletion(-)
create mode 100644 meta-optee/recipes-devtools/python/python-wand/0001-wand-api.py-Change-search-order.patch
diff --git a/meta-optee/recipes-devtools/python/python-wand/0001-wand-api.py-Change-search-order.patch b/meta-optee/recipes-devtools/python/python-wand/0001-wand-api.py-Change-search-order.patch
new file mode 100644
index 000000000000..ac2c0b0622c0
--- /dev/null
+++ b/meta-optee/recipes-devtools/python/python-wand/0001-wand-api.py-Change-search-order.patch
@@ -0,0 +1,32 @@
+From 7691ebcf38c59332eb819f909250a22ba5e8e50b Mon Sep 17 00:00:00 2001
+From: Tom Rini <trini(a)konsulko.com>
+Date: Tue, 24 Oct 2017 12:01:51 -0400
+Subject: [PATCH 1/1] wand/api.py: Change search order
+
+In addition to specifying MAGICK_HOME to ensure that we will even look
+within our desired paths, we need to also check for the type of library
+that we know we have. Otherwise we may find a different form of the
+library in one of the system paths before we try ours.
+
+Upstream-Status: Inappropriate [configuration]
+Signed-off-by: Tom Rini <trini(a)konsulko.com>
+---
+ wand/api.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/wand/api.py b/wand/api.py
+index 19cf6d2..dde9c5e 100644
+--- a/wand/api.py
++++ b/wand/api.py
+@@ -55,7 +55,7 @@ def library_paths():
+ """
+ libwand = None
+ libmagick = None
+- versions = '', '-6', '-Q16', '-Q8', '-6.Q16'
++ versions = '-6.Q16', '-6', '-Q16', '-Q8', ''
+ options = '', 'HDRI', 'HDRI-2'
+ system = platform.system()
+ magick_home = os.environ.get('MAGICK_HOME')
+--
+2.11.0
+
diff --git a/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb b/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb
index 9679b9c9f658..605bc59e2707 100644
--- a/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb
+++ b/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb
@@ -7,7 +7,8 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=170eafd687d4a2b950819cd5e067e6d5"
SRCNAME = "wand"
SRCREV = "c731c620c3c96c409a194dafab396ffbb97d6702"
-SRC_URI = "git://github.com/dahlia/wand.git"
+SRC_URI = "git://github.com/dahlia/wand.git \
+ file://0001-wand-api.py-Change-search-order.patch"
S = "${WORKDIR}/git"
inherit setuptools
@@ -33,6 +34,10 @@ inherit setuptools
DEPENDS += " imagemagick-native"
+# Tell python-wand where to look for our imagemagick and it must be
+# one level up from where 'lib' resides.
+export MAGICK_HOME="${STAGING_LIBDIR_NATIVE}/.."
+
BBCLASSEXTEND = "native"
FILES_${PN} += "${datadir}"
--
2.7.4
Hello all,
It seems that the external-linaro-toolchain recipe (in meta-linaro/meta-linaro-toolchain) doesn't work unless TI's meta-arago/meta-arago-extras layer is also present. That layer contains, among other things:
meta-arago-extras/recipes-devtools/meta/
* external-linaro-toolchain.bbappend - seems to fix a variety of packaging errors, and relaxes the requirement that external-linaro-toolchain itself provide libc Linux headers
* external-linaro-sdk-toolchain.bb - provides the cross-canadian toolchain, for building nativesdk packages. My understanding is that part is useable when the host machine is the same as the SDK machine (e.g. both x86_64-linux), since otherwise you would need two external toolchains.
* external-linaro-toolchain-cross.bb - seems to just provides some tweaks
* external-linaro-bfd-version.inc - populates ELT_VER_BFD with the detected version
meta-arago-extras/conf/distro/include/
* tclibc-external-linaro-toolchain.inc - the TCLIBC configuration that tells Yocto you're using the external Linaro glibc, instead of having Yocto built it.
Is my understanding correct? If so, I'd be curious to know why these files are in meta-arago, as opposed to just being moved into meta-linaro-toolchain itself. If it's just due to a lack of time, then I'd be more than willing to help out. As things currently exist, I find the 'external-linaro-toolchain' recipe in meta-linaro to be a bit of a "carrot on a stick" - it looks really promising and enticing, but you can't get it to work without lots of effort. That effort ultimately amounts to implementing the changes that are present in meta-arago-extras...
Thank you,
Chris Laplante
* use SRCREV instead of tag name, so that bitbake doesn't translate tag to SRCREV
every time it's parsing this recipe
* fix QA issue:
ERROR: QA Issue: python-wand: Files/directories were installed but not shipped in any package:
/usr/share
/usr/share/README.rst
* add comment about imagemagick version needed to use python-wand-native
otherwise it will use imagemagick from host
Signed-off-by: Martin Jansa <Martin.Jansa(a)gmail.com>
---
This is needed in all 3 branches: [morty][pyro][master]
But for pyro you'll need to first backport from master (or forward port from pyro) the upgrade to 0.4.4 from:
commit 7ed523b06bde259f99b21a15e8c936af4f18c752
Author: Fathi Boudra <fathi.boudra(a)linaro.org>
Date: Thu Oct 5 22:46:48 2017 +0300
meta-optee: python-wand: upgrade to latest release 0.4.4
Latest python-wand release is from October 2016.
Update to latest release: 0.4.4.
Change-Id: I23dc1fbb817bbb26357c3ab6dcc86b251eea36e6
Signed-off-by: Fathi Boudra <fathi.boudra(a)linaro.org>
.../recipes-devtools/python/python-wand_0.4.4.bb | 24 +++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb b/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb
index 1043987..9679b9c 100644
--- a/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb
+++ b/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb
@@ -6,11 +6,33 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=170eafd687d4a2b950819cd5e067e6d5"
SRCNAME = "wand"
-SRC_URI = "git://github.com/dahlia/wand.git;tag=${PV}"
+SRCREV = "c731c620c3c96c409a194dafab396ffbb97d6702"
+SRC_URI = "git://github.com/dahlia/wand.git"
S = "${WORKDIR}/git"
inherit setuptools
+# Requires imagemagick-6 while meta-oe morty and newer provides imagemagick-7 which isn't compatible with wand
+#
+# You can import imagemagick-5 from older meta-oe, before this upgrade:
+# commit ec660639ecea3fcb6e554b6f1bafc504e8f2fc78
+# Author: Randy MacLeod <randy.macleod(a)windriver.com>
+# Date: Mon Aug 8 17:41:34 2016 -0400
+# imagemagick: upgrade from 6.9.2 to 7.0.2
+# and add this commit on top of that:
+# commit dfcb67af35936a351789044039a55e3fad299c1a
+# Author: Andreas Müller <schnitzeltony(a)googlemail.com>
+# Date: Sun Sep 18 02:47:26 2016 +0200
+# imagemagick: depend on fftw not virtual/fftw
+#
+# We need this old version becase python-wand-native used here
+# depends on older imagemagick-native as discussed here:
+# https://stackoverflow.com/questions/37011291/python-wand-image-is-not-recog…
+# there still isn't newer python-wand supporting 7.* version:
+# https://github.com/dahlia/wand/blob/4fe2c6ba9cb0d4105361cea6e9e9e8311608047…
+
DEPENDS += " imagemagick-native"
BBCLASSEXTEND = "native"
+
+FILES_${PN} += "${datadir}"
--
2.7.4
Hi,
I am not sure if this is the right place to provide this info.
I came across an issue, which might be caused by a wrong entry in
meta-linaro. See
https://github.com/Angstrom-distribution/angstrom-manifest/issues/31
It seems that inheriting from image_types_uboot.bbclass is not required
anymore and causes a error with a newer openembedde-core.
The following seems to fix this little issue:
diff --git
a/meta-linaro/recipes-linaro/images/linaro-image-minimal-initramfs.bb
b/meta-linaro/recipes-linaro/images/linaro-image-minimal-initramfs.bb
index f928797..d83de70 100644
--- a/meta-linaro/recipes-linaro/images/linaro-image-minimal-initramfs.bb
+++ b/meta-linaro/recipes-linaro/images/linaro-image-minimal-initramfs.bb
@@ -36,4 +36,4 @@ IMAGE_LINGUAS = ""
IMAGE_ROOTFS_SIZE = "8192"
-inherit core-image image_types_uboot
+inherit core-image
Regards
Feddischson
Hello,
I tried to build my distro with meta-linaro/meta-linaro, I've found an
issue on "perf".
When I added "perf" to IMAGE_INSTALL, it causes an error as below;
----
NOTE: Running task 1452 of 2124
(/home/linaro/vsbu/openembedded-core/meta/recipes-kernel/perf/perf.bb:do_patch)
NOTE: Running task 1453 of 2124
(/home/linaro/vsbu/meta-uniphier/recipes-kernel/linux/linux-uniphier-arm64_4.4.bb:do_populate_lic)
NOTE: recipe linux-uniphier-arm64-4.4.8-AUTOINC+5f1a02e66c-r0: task
do_kernel_configme: Started
NOTE: recipe perf-4.2-r9: task do_patch: Started
NOTE: recipe linux-uniphier-arm64-4.4.8-AUTOINC+5f1a02e66c-r0: task
do_populate_lic: Started
NOTE: recipe perf-4.2-r9: task do_patch: Succeeded
NOTE: Running task 1454 of 2124
(/home/linaro/vsbu/openembedded-core/meta/recipes-kernel/perf/perf.bb:do_populate_lic)
NOTE: recipe linux-uniphier-arm64-4.4.8-AUTOINC+5f1a02e66c-r0: task
do_populate_lic: Succeeded
NOTE: recipe perf-4.2-r9: task do_populate_lic: Started
WARNING: perf-4.2-r9 do_populate_lic: Could not copy license file
/home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/linux-tools-4.2/COPYING
to /home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/license-destdir/perf/COPYING:
[Errno 2] No such file or directory:
'/home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/linux-tools-4.2/COPYING'
ERROR: perf-4.2-r9 do_populate_lic: QA Issue: perf: LIC_FILES_CHKSUM
points to an invalid file:
/home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/linux-tools-4.2/COPYING
[license-checksum]
NOTE: recipe perf-4.2-r9: task do_populate_lic: Succeeded
[...]
NOTE: Running task 2084 of 2124
(/home/linaro/vsbu/openembedded-core/meta/recipes-kernel/perf/perf.bb:do_prepare_recipe_sysroot)
NOTE: recipe perf-4.2-r9: task do_prepare_recipe_sysroot: Started
NOTE: recipe perf-4.2-r9: task do_prepare_recipe_sysroot: Succeeded
NOTE: Running task 2085 of 2124
(/home/linaro/vsbu/openembedded-core/meta/recipes-kernel/perf/perf.bb:do_configure)
NOTE: recipe perf-4.2-r9: task do_configure: Started
ERROR: perf-4.2-r9 do_configure: Function failed: do_configure (log
file is located at
/home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/temp/log.do_configure.4060)
ERROR: Logfile of failure stored in:
/home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/temp/log.do_configure.4060
NOTE: recipe perf-4.2-r9: task do_configure: Failed
ERROR: Task (/home/linaro/vsbu/openembedded-core/meta/recipes-kernel/perf/perf.bb:do_configure)
failed with exit code '1'
NOTE: recipe bind-9.10.3-P3-r0: task do_install: Succeeded
NOTE: recipe perl-5.24.1-r0: task do_package: Succeeded
NOTE: Tasks Summary: Attempted 2085 tasks of which 6 didn't need to be
rerun and 1 failed.
---
So it seems that it doesn't do do_fetch and just failed.
I've found you tried to re-enable do_fetch by d.delVarFlag() in
meta-linaro/meta-linaro/recipes-kernel/perf/perf.bbappend as below,
-----
LICENSE = "GPL-2"
LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
PV = "4.2"
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI = "http://snapshot.debian.org/archive/debian/20150926T032755Z/pool/main/l/linu…"
SRC_URI[md5sum] = "9a4a83c22368281b85e4ab12dcc3ec95"
SRC_URI[sha256sum] =
"78b336fca5e250f205fe5bc10cc77943dc95c2d66899f0bc95963b3aab8ef644"
S = "${WORKDIR}/linux-tools-${PV}"
B = "${WORKDIR}/linux-tools-${PV}-build"
do_compile_prepend() {
mkdir -p ${S}/include/generated
echo "#define UTS_RELEASE \"${PV}\"" > ${S}/include/generated/utsrelease.h
}
# Ensure the above tarball gets fetched, unpackaged and patched
python () {
d.delVarFlag("do_fetch", "noexec")
d.delVarFlag("do_unpack", "noexec")
d.delVarFlag("do_patch", "noexec")
}
-----
But it seems not work correctly.
Actually, when I just removed the perf.bbappend file from meta-linaro
(just for debugging) bitbake completed to build rootfs image with perf.
I actually would like to know below
- Is there any recommended configuration for perf?
- Was that tested with any configure before?
- Is that tested (built) in nightly test build?
If it is clear, I can dig deeper by comparing configurations by myself.
Thank you,
--
Masami Hiramatsu
I'm still trying to get the external-linaro-toolchain going in master after
all the recent changes...
First of all, I'm seeing these:
ERROR: external-linaro-toolchain-2017.02-r0.arago35 do_install: oe_multilib_header: Unable to find header bits/long-double.h.
ERROR: external-linaro-toolchain-2017.02-r0.arago35 do_install: oe_multilib_header: Unable to find header bits/fp-fast.h.
They are coming from these changes:
http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-core/gli…http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-core/gli…
I believe (please correct me) those are due to Linaro toolchain 6.3 still
using glibc 2.23...
But the real problem comes when I try to build gcc (either "linaro-6.3" from
meta-linaro-toolchain, or "6.3" from oe-core) for the target using
external-linaro-toolchain:
| g++: error: gengtype-lex.c: No such file or directory
| g++: fatal error: no input files
It seems to come from oe-core gcc-source.inc, which removes gengtype-lex.c in
order to re-generate it:
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/g…
Has anyone looked into fixing these issues? What's the status of
external-linaro-toolchain in master? Will this be looked at for 6.3 version,
or not until 7.x gets integrated? Thanks.
--
Denys
From: Denys Dmytriyenko <denys(a)ti.com>
When OE-Core updated binutils to version 2.28, many of the patches got updated
and renamed:
http://cgit.openembedded.org/openembedded-core/commit/?id=e9f839d5fe70a222c…
Most of those do not affect binutils recipes in meta-linaro-toolchain, as patches
are listed in version-specific .bb and .inc files for 2.25 and 2.27.
But binutils-cross.inc is one of the generic common .inc files in OE-Core, that
includes a patch that got renamed. Sync up this one patch with OE-Core to avoid
these warnings:
WARNING: /OE/master/sources/meta-linaro/meta-linaro-toolchain/recipes-devtools/binutils/binutils-crosssdk_linaro-2.25.bb: Unable to get checksum for binutils-crosssdk-x86_64-arago-linux SRC_URI entry 0002-binutils-cross-Do-not-generate-linker-script-directo.patch: file could not be found
WARNING: /OE/master/sources/meta-linaro/meta-linaro-toolchain/recipes-devtools/binutils/binutils-cross_linaro-2.25.bb: Unable to get checksum for binutils-cross-arm SRC_URI entry 0002-binutils-cross-Do-not-generate-linker-script-directo.patch: file could not be found
Signed-off-by: Denys Dmytriyenko <denys(a)ti.com>
---
...ss-Do-not-generate-linker-script-directo.patch} | 26 +++++++++++++++++-----
1 file changed, 20 insertions(+), 6 deletions(-)
rename meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25/{no-tooldirpaths.patch => 0002-binutils-cross-Do-not-generate-linker-script-directo.patch} (75%)
diff --git a/meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25/no-tooldirpaths.patch b/meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25/0002-binutils-cross-Do-not-generate-linker-script-directo.patch
similarity index 75%
rename from meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25/no-tooldirpaths.patch
rename to meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25/0002-binutils-cross-Do-not-generate-linker-script-directo.patch
index 2bfc8d4..14299fd 100644
--- a/meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25/no-tooldirpaths.patch
+++ b/meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25/0002-binutils-cross-Do-not-generate-linker-script-directo.patch
@@ -1,20 +1,31 @@
+From 7c7de107b4b0a507d2aeca3e3a86d01cb4b51360 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem(a)gmail.com>
+Date: Mon, 6 Mar 2017 23:37:05 -0800
+Subject: [PATCH 02/15] binutils-cross: Do not generate linker script
+ directories
+
We don't place target libraries within ${exec_prefix}, we'd always place these
within the target sysroot within the standard library directories. Worse, the
append_to_lib_path code prefixes these paths with the sysroot which makes even
less sense.
-These directories therefore don't make sense in our case and mean we have to
-relocate all the linker scripts if they're present. Dropping them
+These directories therefore don't make sense in our case and mean we have to
+relocate all the linker scripts if they're present. Dropping them
gives a reasonable performance improvement/simplification.
Upstream-Status: Inappropriate
RP 2017/01/30
-Index: git/ld/genscripts.sh
-===================================================================
---- git.orig/ld/genscripts.sh
-+++ git/ld/genscripts.sh
+Signed-off-by: Khem Raj <raj.khem(a)gmail.com>
+---
+ ld/genscripts.sh | 23 -----------------------
+ 1 file changed, 23 deletions(-)
+
+diff --git a/ld/genscripts.sh b/ld/genscripts.sh
+index a42c4d7a4b..d727b4d07e 100755
+--- a/ld/genscripts.sh
++++ b/ld/genscripts.sh
@@ -189,29 +189,6 @@ append_to_lib_path()
fi
}
@@ -45,3 +56,6 @@ Index: git/ld/genscripts.sh
if [ "x${LIB_PATH}" = "x" ] && [ "x${USE_LIBPATH}" = xyes ] ; then
libs=${NATIVE_LIB_DIRS}
if [ "x${NATIVE}" = "xyes" ] ; then
+--
+2.12.0
+
--
2.7.4
not sure if this is the right list to point out oddities in the
documentation, but i'm reading this:
https://www.96boards.org/db410c-getting-started/HardwareDocs/HWUserManual.m…
and in the ToC, under "Low Speed Expansion Connector", there is no
mention of I2S, but in the very next section, "Introduction", under
"I/O Interfaces", one reads:
One 40-pin Low Speed (LS) expansion connector
UART, SPI, I2S, I2C x2, GPIO x12, DC power
^^^
should I2S be added to the ToC for consistency? or am i misreading
something?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
still clawing my way through the previous replies to my admittedly
tedious questions, but since i want to get specific with this issue, i
thought a new thread would be in order.
i think my biggest obstacle with this DB410C is just getting used to
a new boot process that is clearly more sophisticated than what i'm
used to with other boards, like my BBB.
rather than ask numerous questions, is there a canonical explanation
of the boot procedure, like say the hardware reference manual, or
something like that? i think a lot of my confusion will evaporate as
soon as i can say, "ah, so *that's* how the boot process works."
to that end, i'm going to check out the actual flashing utility in
the debian install image; i figure reading the source is the best way
to get to the bottom of this.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
i don't currently have access to the DB410C (colleague has wandered
off with it), but what should be a couple simple questions.
i'm reading the Installation Guide here:
https://github.com/96boards/documentation/wiki/Dragonboard-410c-Installatio…
and the basic recipe for installing the latest debian image without
using fastboot is given in the section:
https://github.com/96boards/documentation/wiki/Dragonboard-410c-Installatio…
i notice that that section clearly instructs the user to hook up a
mouse, keyboard and monitor to do this graphically. can you not do
that same install without all that hardware, like through the console
port?
and if i read a bit further, i see that if one uses "fastboot", it
appears that that would solve the problem. so if i had the board and
only a power adapter and USB cable to support a terminal window, what
would be the proper approach?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
before i get to installing and/or booting the linux image i build
with openembedded, i'd like to boot simply to the appropriate u-boot
binary for this target board.
first, i've already bitbaked an absolutely stock
"core-image-minimal" image for this board without issue using the
meta-qcom layer at
git://git.yoctoproject.org/meta-qcom
although nicolas tells me that that layer is more generally maintained
on github at:
https://github.com/ndechesne/meta-qcom
but that's easy enough to change. haven't booted into that image yet,
just wanted to verify that the build worked with no problem and
produced all the artifacts i expect from an OE build. worked
flawlessly.
to add u-boot to the build process, i went back and added the
following lines to my local.conf:
EXTRA_IMAGEDEPENDS += "u-boot"
UBOOT_MACHINE = "dragonboard410c_config"
again, build appeared to work perfectly, and generated the new
artifact:
u-boot-dragonboard-410c-2017.01-r0.bin
so, again, looks good. at this point, it appears that the recipe for
booting to u-boot is in the readme.txt file in the appropriate
directory in the u-boot source:
http://git.denx.de/?p=u-boot.git;a=blob;f=board/qualcomm/dragonboard410c/re…
can anyone verify that that is still the correct set of instructions?
and as i read it, to get to "fastboot" mode, i don't need the FTDI
connection, just USB OTG should do it, is that correct?
is there a way to install the u-boot binary on the SD card and boot
directly from there?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
following up on a question i asked on the generic OE mailing list,
and nicolas dechesne's extensive reply:
http://lists.openembedded.org/pipermail/openembedded-core/2017-May/136547.h…
i figured i might as well move the discussion here since most of my
queries will be specific to that target board.
briefly, i unpacked my new dragonboard, cabled it up, plugged it in
and it popped into android as i expected it would, so i can at least
verify that that part works.
also, i have a fair bit of experience with ARM, openembedded and
u-boot, so i'll try not to ask idiotic questions. first question
coming shortly, might as well keep them modular and not try to ask
everything at once.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
BTW, are there plans to fix external-linaro-toolchain flow with recipe
specific sysroot in master? Let me know if you need logs or any other help.
--
Denys
Hello
While using Linaro 'meta-linaro-toolchain' layer with own definition
of AArch64 machine (not using Linaro's meta-aarch64) I have noticed
seemingly incorrect use of LINKER_HASH_STYLE variable.
In the current master and morty branches (I have not checked others
yet), all meta-linaro-toolchain/recipes-devtools/gcc/gcc-linaro-*.inc
files contain following lines:
EXTRA_OECONF_BASE = "\
--disable-bootstrap \
--disable-libmudflap \
--with-system-zlib \
--with-linker-hash-style=${LINKER_HASH_STYLE} \
--enable-linker-build-id \
--with-ppl=no \
--with-cloog=no \
In my case, during the build, meta/recipes-devtools/gcc/gcc-cross.inc
gets included and breaks the libgcc qa checks by incorrectly
redefining hash style to SysV (snippet below, this was introduced in
morty):
# While we want the 'gnu' hash style, we explicitly set it to sysv here to
# ensure that any recipe which doesn't obey our LDFLAGS (which also set it to
# gnu) will hit a QA failure.
LINKER_HASH_STYLE ?= "sysv"
So, per my understanding, instead of directly using LINKER_HASH_STYLE,
Linaro GCC build shall parse LDFLAGS and get correct hash style there.
Of course, it may be also hardcoded or otherwise avoided but from the
comment above it seems that Yocto engineers explicitly insist on
LDFLAGS checking :)
Would this approach (use of LDFLAGS instead of LINKER_HASH_STYLE) be
acceptable for meta-linaro?
Best regards,
Artem Mygaiev
Hi folks,
I have two CES blockers with the master branch of https://github.com/ndechesne/meta-qcom
1. The build it defaulting to uni-proc. What change is required to enable all the cores.
2. Issuing reboot in a terminal window will not cause the device to reboot. A power cycle is required after issuing "reboot" from console.
Regards,
Joel Winarske (prior QC Senior Staff Engineer)
Senior Embedded Software Engineer
INRIX
(206) 512-6779
> Op 6 sep. 2016, om 20:42 heeft Denys Dmytriyenko <denis(a)denix.org> het volgende geschreven:
>
> Koen, Fathi, et al,
>
> Any chance to get EXTRA_OEMAKE to not hardcode ARM64 flags?
>
> https://git.linaro.org/openembedded/meta-linaro.git/blob/HEAD:/meta-optee/r…
It’s not planned, but we wouldn’t say no to patches :)
--
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
Greetings,
Have to call it "v3" as I've sent a different patch with "v2" earlier.
This is a reworked version of "[PATCH] mali-userland-drm: add support for mali450 binaries for hikey":
- the __anonymous() function (inspired by mesa.inc) removed, as I doubt that it adds value in this case, and
am not sure it handles the package names correctly.
- recipe file name changed. Tried to minimize the use of non-default values where possible.
All in all, it now looks more similar to [1].
- using the mesa_%.bbappend looks unavoidable for me, and it should match the files included into the driver
tarball (from SRC_URI), so the mesa_%.bbappend has been added to this patch.
- more comments added.
Regarding the PACKAGE_ARCH = "${MACHINE_ARCH}", the driver is indeed specific for HiKey (would not fit
other boards with mali450), but I don't know the details.
Thanks,
Andrey
[1] https://github.com/ARM-software/meta-mali/blob/master/recipes-graphics/mali…
From: Andrey Konovalov <andrey.konovalov(a)linaro.org>
Date: Wed, 8 Jun 2016 00:07:21 +0300
Subject: [PATCH 1/4] Add public Mali450 driver for wayland
Signed-off-by: Andrey Konovalov <andrey.konovalov(a)linaro.org>
---
.../mali-userland/mali450-userland_r6p0_01rel0.bb | 55 ++++++++++++++++++++++
recipes-graphics/mesa/mesa_%.bbappend | 11 +++++
2 files changed, 66 insertions(+)
create mode 100644 recipes-graphics/mali-userland/mali450-userland_r6p0_01rel0.bb
create mode 100644 recipes-graphics/mesa/mesa_%.bbappend
diff --git a/recipes-graphics/mali-userland/mali450-userland_r6p0_01rel0.bb b/recipes-graphics/mali-userland/mali450-userland_r6p0_01rel0.bb
new file mode 100644
index 0000000..63bcf51
--- /dev/null
+++ b/recipes-graphics/mali-userland/mali450-userland_r6p0_01rel0.bb
@@ -0,0 +1,55 @@
+SUMMARY = "Mali450 libraries (drm backend)"
+
+LICENSE = "Proprietary"
+LIC_FILES_CHKSUM = "file://${WORKDIR}/END_USER_LICENCE_AGREEMENT.txt;md5=3918cc9836ad038c5a090a0280233eea"
+
+SRC_URI[md5sum] = "36f39e86ccfe5a6a4cb2090865c339ba"
+SRC_URI[sha256sum] = "dd136931cdbb309c0ce30297c06f7c6b0a48450f51acbbbc10529d341977f728"
+
+PROVIDES += "virtual/egl virtual/libgles1 virtual/libgles2 virtual/libdrm"
+
+DEPENDS = "virtual/mesa"
+
+BACKEND="drm"
+
+SRC_URI = " http://malideveloper.arm.com/downloads/drivers/binary/utgard/r6p0-01rel0/ma…"
+
+S = "${WORKDIR}/wayland-drm"
+
+# The SRC is just a set of binaries to install - nothing to configure and to
+# compile
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+
+do_install() {
+ install -m 755 -d ${D}/${libdir}
+ install ${S}/libMali.so ${D}/${libdir}
+ ln -sf libMali.so ${D}/${libdir}/libEGL.so.1.4
+ ln -sf libEGL.so.1.4 ${D}/${libdir}/libEGL.so.1
+ ln -sf libEGL.so.1 ${D}/${libdir}/libEGL.so
+ ln -sf libMali.so ${D}/${libdir}/libGLESv1_CM.so.1.1
+ ln -sf libGLESv1_CM.so.1.1 ${D}/${libdir}/libGLESv1_CM.so.1
+ ln -sf libGLESv1_CM.so.1 ${D}/${libdir}/libGLESv1_CM.so
+ ln -sf libMali.so ${D}/${libdir}/libGLESv2.so.2.0
+ ln -sf libGLESv2.so.2.0 ${D}/${libdir}/libGLESv2.so.2
+ ln -sf libGLESv2.so.2 ${D}/${libdir}/libGLESv2.so
+ ln -sf libMali.so ${D}/${libdir}/libgbm.so.1
+ ln -sf libgbm.so.1 ${D}/${libdir}/libgbm.so
+ ln -sf libMali.so ${D}/${libdir}/libwayland-egl.so
+}
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+# The mali-450 driver tarball has only *.so files, so all the packages
+# except the ${PN} one would be empty
+PACKAGES = "${PN}"
+FILES_${PN} += "${libdir}/*.so* "
+
+INSANE_SKIP_${PN} = "ldflags dev-so"
+
+# To get the egl/gles headers and the packageconfig files (missing from this
+# mali-450 driver tarball) we have to build mesa, and to handle the conflicts
+# due to both mali450-userland, and mesa providing the same libraries.
+RREPLACES_${PN} = "libegl libegl1 libgles1 libglesv1-cm1 libgles2 libglesv2-2 libgbm"
+RPROVIDES_${PN} = "libegl libegl1 libgles1 libglesv1-cm1 libgles2 libglesv2-2 libgbm"
+RCONFLICTS_${PN} = "libegl libegl1 libgles1 libglesv1-cm1 libgles2 libglesv2-2 libgbm"
diff --git a/recipes-graphics/mesa/mesa_%.bbappend b/recipes-graphics/mesa/mesa_%.bbappend
new file mode 100644
index 0000000..3020b2b
--- /dev/null
+++ b/recipes-graphics/mesa/mesa_%.bbappend
@@ -0,0 +1,11 @@
+# Remove the *.so libraries - the ones provided by mali-450 driver are to
+# be used for HiKey
+do_install_append() {
+ rm -f ${D}/${libdir}/libEGL.so*
+ rm -f ${D}/${libdir}/libGLESv1_CM.so*
+ rm -f ${D}/${libdir}/libGLESv2.so*
+ rm -f ${D}/${libdir}/libgbm.so*
+ rm -f ${D}/${libdir}/libwayland-egl.so*
+}
+
+PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/egl"
--
1.9.1
The base_contains function is deprecated and we ought to use
bb.utils.contains instead.
Signed-off-by: Max Krummenacher <max.krummenacher(a)toradex.com>
---
Hi
missed that one with my sed script in patch 9d228b1d2dc6e2e3f677c04cb83bbb6e04319e94
Sorry about that.
Max
.../external-linaro-toolchain/external-linaro-toolchain.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb b/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb
index 6a72ff7..eb82e96 100644
--- a/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb
+++ b/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb
@@ -93,7 +93,7 @@ do_install() {
fi
# fix up the copied symlinks (they are still pointing to the multiarch directory)
- linker_name="${(a)bb.utils.contains("TUNE_FEATURES", "aarch64", "ld-linux-aarch64.so.1", base_contains("TUNE_FEATURES", "callconvention-hard", "ld-linux-armhf.so.3", "ld-linux.so.3",d), d)}"
+ linker_name="${(a)bb.utils.contains("TUNE_FEATURES", "aarch64", "ld-linux-aarch64.so.1", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "ld-linux-armhf.so.3", "ld-linux.so.3",d), d)}"
ln -sf ld-${ELT_VER_LIBC}.so ${D}${base_libdir}/${linker_name}
ln -sf ../../lib/libnsl.so.1 ${D}${libdir}/libnsl.so
ln -sf ../../lib/librt.so.1 ${D}${libdir}/librt.so
--
2.6.6
Are the instructions here:
https://wiki.linaro.org/HowTo/ARMv8/OpenEmbedded
...still accurate? That wiki has not been updated in ~3 years.
I'm looking for steps to build a simple openembedded based aarch64
rootfs.
Anywhere else I should be looking?
Thanks,
Stuart Yoder
NXP Semiconductor
Added into gerrit:
https://review.linaro.org/11498https://review.linaro.org/11499
On 20 April 2016 at 19:53, Denys Dmytriyenko <denis(a)denix.org> wrote:
> From: Denys Dmytriyenko <denys(a)ti.com>
>
> With migration from crosstool-NG to ABE, libgcov.a changed path and is now
> available in ${libdir}. So, instead of being packaged into own libgcov-dev
> package, it gets picked up by "catchall" libc6-staticdev package. This mostly
> works, as long as nothing directly depends on libgcov-dev. Unfortunately,
> packagegroup-core-standalone-sdk-target does and is the one being used when
> building SDKs with -c populate_sdk. Correct path to generate libgcov-dev pkg.
>
> Signed-off-by: Denys Dmytriyenko <denys(a)ti.com>
> ---
> This is required for fido/jethro, but krogoth/master introduces single -dev
> package rule, so separate libgcov-dev package can be dropped entirely.
>
> .../external-linaro-toolchain/external-linaro-toolchain.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb b/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb
> index ea41179..531caf7 100644
> --- a/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb
> +++ b/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb
> @@ -301,7 +301,7 @@ PKGV_gdbserver = "${ELT_VER_GDBSERVER}"
> ALLOW_EMPTY_${PN}-mtrace = "1"
> FILES_${PN}-mtrace = "${bindir}/mtrace"
>
> -FILES_libgcov-dev = "${libdir}/${TARGET_SYS}/${BINV}/libgcov.a"
> +FILES_libgcov-dev = "${libdir}/libgcov.a"
>
> FILES_libsegfault = "${base_libdir}/libSegFault*"
>
> --
> 2.2.0
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev(a)lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-dev
--
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
Hi Koen,
I think you mentioned that issue already briefly at ELC, but I stumbled
upon it independently again:
We have issues with the versioning of the Linaro toolchain in Ångström.
While it happens with the Ångström package feed, I think it is actually
a problem of how the meta-linaro layer uses PV/PR.
It seems that the change to the 2015.11-2 release added yet another
hyphen, which gets interpreted wrong by opkg. When we build a new image,
and try to download something which just asks for linaro-5.2, we get the
following error:
Not downgrading libgcc1 from linaro-5.2-r2015.11-2 to
linaro-5.2-r2015.11.0 on root.
Downgrading? The "2015.11-2" release should be an upgrade...
This can be verified when checking the versions using the
compare-versions command:
$ opkg compare-versions "linaro-5.2-r2015.11-2" '>='
"linaro-5.2-r2015.11"; echo $?
1
Error code is set, hence the comparison is _not_ satisfied. Whether
there is another .0 at the end of r2015.11 does not matter (Btw, where
is that coming from?)
Things after the hyphen are interpreted by opkg as package revision...
This leads to the following akward situation (added some debug prints
into opkg's source):
$ ./src/opkg --offline-root . compare-versions linaro-5.2-r2015.11-2
'>=' linaro-5.2-r2015.11
parse_version, version linaro-5.2-r2015.11, revision 2
parse_version, version linaro-5.2, revision r2015.11
This change introduced the additional hyphen:
https://git.linaro.org/openembedded/meta-linaro.git/commitdiff/62333718e8f3…
I think everything should work if that additional -2 would be a .2...
However, hyphens in the main version number are actually quite frowned
upon, also the debian policy does not allow hyphens:
https://www.debian.org/doc/debian-policy/ch-binary.html#s-versions
So maybe even the hyphen in linaro-5.2 should be something else...
--
Stefan
On 19 April 2016 at 07:30, Koen Kooi <koen.kooi(a)linaro.org> wrote:
> On 18 April 2016 at 23:03, Denys Dmytriyenko <denis(a)denix.org> wrote:
>> On Fri, Apr 15, 2016 at 08:01:48AM +0200, Koen Kooi wrote:
>>> On 14 April 2016 at 18:27, Denys Dmytriyenko <denis(a)denix.org> wrote:
>>> > On Thu, Apr 14, 2016 at 10:04:18AM +0200, Koen Kooi wrote:
>>> >> On 14 April 2016 at 07:09, Fathi Boudra <fathi.boudra(a)linaro.org> wrote:
>>> >> > On 14 April 2016 at 00:05, Denys Dmytriyenko <denis(a)denix.org> wrote:
>>> >> >> Koen, et al,
>>> >> >>
>>> >> >> With the release of 5.3-2016.02 Linaro toolchain it is now possible to use the
>>> >> >> binary version with the external-linaro-toolchain recipe. Are there any
>>> >> >> immediate plans to provide corresponding recipes to build the same version of
>>> >> >> the toolchain from sources? Thanks.
>>> >> >
>>> >> > Yes, the recipes for 5.3-2016.02 will be added. It's targeted for next cycle.
>>> >>
>>> >> The test build is still running, but here's the gerrit:
>>> >>
>>> >> https://review.linaro.org/11376
>>> >
>>> > Thanks!
>>>
>>> It breaks grub, I'll sort that out with the toolchain folks later today.
>>>
>>> > What about glibc-2.21?
>>>
>>> Haven't looked at that one yet.
>>
>> Any updates on the above 2 items? It's not exactly blocking me currently, as I
>> have workarounds in place, but it would be nice to get these resolved in
>> krogoth/2.1... Thanks!
>
> For grub we need both a newer toolchain and a newer binutils. Still
> haven't looked at glibc 2.21 yet, sorry.
An update to the gcc situation: we've decided to move it to the next
cycle (2016.06) so we can use a newer gcc release with the fix
included. I've retracted https://review.linaro.org/#/c/11376/ to
reflect this.
--
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs