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…
