Re: [OE-core] [PATCH v2 1/5] systemd: update 246 -> 247

["Luca Bocassi" <luca.boccassi@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4182 bytes --]

On Thu, 2020-12-17 at 17:46 +0000, Richard Purdie wrote:
> On Thu, 2020-12-17 at 17:25 +0000, Luca Boccassi wrote:
> > On Wed, 2020-12-16 at 18:07 +0000, Richard Purdie wrote:
> > > On Mon, 2020-12-14 at 12:34 +0000, Luca Bocassi wrote:
> > > > From: Luca Boccassi <luca.boccassi@microsoft.com>
> > > > 
> > > > Update systemd to v247.1.
> > > > Add rule for new oomd dbus conf and for new pam.d
> > > > conf directory in /usr/lib.
> > > > Drop selinux-hook-handling-to-enumerate-nexthop.patch,
> > > > merged upstream.
> > > > Backport 0001-meson-set-cxx-variable-before-using-it.patch
> > > > from v247-stable to fix builds without C++.
> > > > Refresh musl patches.
> > > > 
> > > > Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > > > ---
> > > > NOTE: the musl build has only been build-tested, and only on x86_64.
> > > > The glibc build has been built and runtime-tested on x86_64 and
> > > > arm64.
> > > 
> > > [sorry, hit send early when writing]
> > > 
> > > Unfortunately there is still something not quite right in this patchset
> > > as it failed again during testing. There are a few different problems:
> > > 
> > > meta-intel in systemd-boot:
> > > 
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/100/builds/1016
> > 
> > Looking into this, thanks

Looks like it was an issue in meta-intel, which was fixed there as per
email from Anuj

> > > a reproducibility issue in oe-selftest:
> > > 
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/1651
> > > (which did happen last time as well on centos but I don't think was
> > > reported on the list, sorry)
> > > 
> > > These urls may help understand why its not reproducible:
> > > 
> > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20201215-mhq8wl33/packages/diff-html/
> > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20201215-mhq8wl33/
> > > 
> > > (looks like the uid of messagebus is changing at a really quick glance)
> > 
> > Given your follow-up message about host contamination, is there
> > anything I can do here to fix it/mitigate it, or is it a CI issue?
> 
> We'll have to look into why building it on a centos system seems to
> result in a different binary from building it on other distros. Its not
> a CI problem, our multi distro setup is just exposing the problem (as
> its intended to).

I'm afraid this is a bit beyond my capabilities at the moment - I don't
have a CentOS system available, nor the time to set it up right now.
As far as I can see there should be nothing in the changes I'm doing to
the recipe causing this - if the root cause is in the package, it must
be from the upstream sources.

> > > and a build issue in world-lsb:
> > > 
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/108/builds/1189
> > > 
> > > At the top of the logs you can see the configuration that is being used
> > > for a given build, so for example in the last one, the key difference
> > > to some of the other builds might be any one of:
> > > 
> > > DISTRO = "poky-altcfg"
> > > DISTRO_FEATURES_append = ' api-documentation'
> > > require conf/multilib.conf
> > > MULTILIBS = 'multilib:lib32'
> > > DEFAULTTUNE_virtclass-multilib-lib32 = 'x86'
> > > QEMU_USE_KVM = 'True'
> > > INHERIT += 'testimage'
> > > SDK_EXT_TYPE = 'minimal'
> > > SDK_INCLUDE_TOOLCHAIN = '1'
> > > 
> > > but given its a pam error, I'd strongly suspect the DISTRO = "poky-
> > > altcfg" would be the likely trigger.
> > 
> > ERROR: systemd-1_247.1-r0 do_package: QA Issue: systemd: Files/directories were installed but not shipped in any packa
> > ge:
> >   /usr/lib/pam.d
> >   /usr/lib/pam.d/systemd-user
> > 
> > But the recipe has:
> > 
> > FILES_${PN} = " ${base_bindir}/* \
> >                <...>
> >                ${libdir}/pam.d/ \
> > 
> > Shouldn't that match? Did I use the wrong variable?
> 
> I think the trailing slash may make it match the directory only? I'm
> going from memory though...

Paul figured this one out: we need to also match
${nonarch_libdir}/pam.d - fixed in v3

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 499 bytes --]