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 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'
