On Mon, Mar 15, 2021 at 12:21:37PM +0000, Richard Purdie wrote: > On Mon, 2021-03-15 at 11:50 +0000, Luca Boccassi wrote: > > On Mon, 2021-03-15 at 10:49 +0000, Richard Purdie wrote: > > > On Mon, 2021-03-15 at 10:44 +0000, Luca Boccassi wrote: > > > > On Sun, 2021-03-14 at 22:10 +0000, Richard Purdie wrote: > > > > > On Thu, 2021-03-11 at 15:09 +0000, luca.bocca...@gmail.com wrote: > > > > > > From: Luca Boccassi <luca.bocca...@microsoft.com> > > > > > > > > > > > > Recently util-linux gained an (optional) build dependency on > > > > > > libcryptsetup. > > > > > > But libcryptsetup build-depends on util-linux for blkid (optional, > > > > > > can be disabled) > > > > > > and uuid (mandatory). > > > > > > Split out util-linux-uuid in a different recipe to break the cycle. > > > > > > > > > > > > https://github.com/karelzak/util-linux/pull/898 > > > > > > > > > > > > Signed-off-by: Luca Boccassi <luca.bocca...@microsoft.com> > > > > > > > > > > Unfortunately I noticed we had a performance regression in buildtimes > > > > > in > > > > > recent changes. The closest I have this narrowed down to so far: > > > > > > > > > > https://autobuilder.yocto.io/pub/non-release/20210314-14/testresults/buildperf-ubuntu1604/perf-ubuntu1604_master_20210314181831_d42487bf52.html > > > > > > > > > > suggests it may be this change. I have more tests queued to confirm > > > > > that definitively, if so we'll have to figure out why as this > > > > > shouldn't > > > > > really happen, its an 8% regression :(. > > > > > > > > Very strange that a single recipe could do that - is there something > > > > wrong in the new .bb that I missed and could cause this? > > > > > > I'm wondering if it is because we're building util-linux twice now and > > > there is some key choke point in the dependency chain. I have no evidence > > > for that yet, it is just speculation though. > > > > With the autoconf options I've set, on my laptop it takes 32s to do > > configure + make -j2. Most of that is autoconf - make -j2 takes 8s. > > > > Only 3 libraries are built with this combination: libcommon.a, > > libtcolors.a, and libuuid.a/so. No executables or anything else is > > built. It doesn't look like libtcolors is actually needed, I'll see if > > I can prepare a patch to skip it, but I don't think it will buy more > > than 1s, it's just two object files. > > > > The good news is that meson support is about to land upstream, which > > should be significantly faster than autoconf + make: > > > > https://github.com/karelzak/util-linux/commits/topic/meson > > Meson definitely improves the speed! I was wondering if it was from > configure for example. > > I now have more performance test results in (takes time to interleave > them with testing of master): > > https://autobuilder.yocto.io/pub/non-release/20210315-1/testresults/buildperf-ubuntu1604/perf-ubuntu1604_master_20210315005048_6bb1621815.html > > and I think this means it isn't from the util-linux change but one of > another three. I'm not entirely convinced those changes could do this > but it is what the data says. > > I've queued more bisection to narrow it down from there...
BTW: this split also needs manual cleanup in the TMPDIR, right?
Incremental build fails with:
ERROR: util-linux-uuid-2.36.2-r0 do_packagedata: The recipe util-linux-uuid is
trying to install files into a shared area when those files already exist.
Those files and their manifest location are:
/OE/build/oe-core/tmp-glibc/pkgdata/qemux86-64/shlibs2/util-linux-libuuid.list
(matched in manifest-qemux86_64-util-linux.packagedata)
/OE/build/oe-core/tmp-glibc/pkgdata/qemux86-64/runtime/util-linux-libuuid.packaged
(matched in manifest-qemux86_64-util-linux.packagedata)
/OE/build/oe-core/tmp-glibc/pkgdata/qemux86-64/runtime/util-linux-libuuid
(matched in manifest-qemux86_64-util-linux.packagedata)
Please verify which recipe should provide the above files.
The build has stopped, as continuing in this scenario WILL break things - if
not now, possibly in the future (we've seen builds fail several months later).
If the system knew how to recover from this automatically it would, however
there are several different scenarios which can result in this and we don't
know which one this is. It may be you have switched providers of something like
virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in that case you
need to execute the clean task for both recipes and it will resolve this error.
It may be you changed DISTRO_FEATURES from systemd to udev or vice versa.
Cleaning those recipes should again resolve this error, however switching
DISTRO_FEATURES on an existing build directory is not supported - you should
really clean out tmp and rebuild (reusing sstate should be safe). It could be
the overlapping files detected are harmless in which case adding them to
SSTATE_DUPWHITELIST may be the correct solution. It could also be your build is
including two different conflicting versions of things (e.g. bluez 4 and bluez
5 and the correct solution for that would be to resolve the conflict. If in
doubt, please ask on the mailing list, sharing the error and filelist above.
ERROR: util-linux-uuid-2.36.2-r0 do_packagedata: If the above message is too
much, the simpler version is you're advised to wipe out tmp and rebuild
(reusing sstate is fine). That will likely fix things in most (but not all)
cases.
ERROR: Logfile of failure stored in:
/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/util-linux-uuid/2.36.2-r0/temp/log.do_packagedata.2055738
NOTE: recipe util-linux-uuid-2.36.2-r0: task do_packagedata: Failed
ERROR: Task
(/OE/build/oe-core/openembedded-core/meta/recipes-core/util-linux/util-linux-uuid_2.36.2.bb:do_packagedata)
failed with exit code '1'
as util-linux-uuid doesn't depend on util-linux (and even cannot depend on it),
then
nothing ensures that older util-linux (including libuuid) is removed from
sstate-control
before this new separate util-linux-uuid is running packagedata.
Not sure if there is something we can do in cases like this and
bumping OELAYOUT_ABI because of this 1 recipe seems a bit overkill.
"bitbake -c clean util-linux" should be enough to unblock util-linux-uuid, but
it
needs to be executed for every MACHINE (or at least every TUNE_PKGARCH) in given
TMPDIR.
Cheers,
signature.asc
Description: PGP signature
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149461): https://lists.openembedded.org/g/openembedded-core/message/149461 Mute This Topic: https://lists.openembedded.org/mt/81254724/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
