| Message ID | 20230810133450.237127-1-richard.purdie@linuxfoundation.org |
|---|---|
| State | Accepted, archived |
| Commit | 7b7411788e805fa067dd672c9771dcaf2af918a0 |
| Headers | show |
| Series | selftest/reproducible: Update config to match ongoing changes | expand |
I don’t follow i am afraid. How would having separate usr expose issues that merged usr would hide? Alex On Thu 10. Aug 2023 at 15.34, Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > We can't have systemd here any longer without usrmerge. We don't really > want to enable the latter since having separate usr will likely result in > a class of reproducibility and host contamination issues that enabling it > might hide. > > Also drop INHIBIT_PACKAGE_STRIP since we generally don't build with that > and the debug binaries should be generated regardless. I suspect this > is legacy from older issues. > > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> > --- > meta/lib/oeqa/selftest/cases/reproducible.py | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/meta/lib/oeqa/selftest/cases/reproducible.py > b/meta/lib/oeqa/selftest/cases/reproducible.py > index 0f7e6eb376e..4c6ed4e4a50 100644 > --- a/meta/lib/oeqa/selftest/cases/reproducible.py > +++ b/meta/lib/oeqa/selftest/cases/reproducible.py > @@ -212,10 +212,9 @@ class ReproducibleTests(OESelftestTestCase): > > config = textwrap.dedent('''\ > PACKAGE_CLASSES = "{package_classes}" > - INHIBIT_PACKAGE_STRIP = "1" > TMPDIR = "{tmpdir}" > LICENSE_FLAGS_ACCEPTED = "commercial" > - DISTRO_FEATURES:append = ' systemd pam' > + DISTRO_FEATURES:append = ' pam' > USERADDEXTENSION = "useradd-staticids" > USERADD_ERROR_DYNAMIC = "skip" > USERADD_UID_TABLES += "files/static-passwd" > -- > 2.39.2 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#185747): > https://lists.openembedded.org/g/openembedded-core/message/185747 > Mute This Topic: https://lists.openembedded.org/mt/100663206/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
On Thu, 2023-08-10 at 16:57 +0200, Alexander Kanavin wrote: > I don’t follow i am afraid. How would having separate usr expose > issues that merged usr would hide? Most host systems are moving over to merged usr. If host paths to a binary were to creep in (e.g. the path to a tool, /usr/bin/xxx), our non usrmerge config would be more likely to generate a reproducibility mismatch than one with usrmerge enabled. Cheers, Richard
On Thu 10. Aug 2023 at 17.10, Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Thu, 2023-08-10 at 16:57 +0200, Alexander Kanavin wrote: > > I don’t follow i am afraid. How would having separate usr expose > > issues that merged usr would hide? > > Most host systems are moving over to merged usr. If host paths to a > binary were to creep in (e.g. the path to a tool, /usr/bin/xxx), our > non usrmerge config would be more likely to generate a reproducibility > mismatch than one with usrmerge enabled. But then it would creep into both build A and build B since both would come from the same host or two hosts both with usrmerge, and there would be no mismatch. No? Alex > >
On Thu, 2023-08-10 at 17:27 +0200, Alexander Kanavin wrote: > On Thu 10. Aug 2023 at 17.10, Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > On Thu, 2023-08-10 at 16:57 +0200, Alexander Kanavin wrote: > > > I don’t follow i am afraid. How would having separate usr expose > > > issues that merged usr would hide? > > > > Most host systems are moving over to merged usr. If host paths to a > > binary were to creep in (e.g. the path to a tool, /usr/bin/xxx), > > our > > non usrmerge config would be more likely to generate a > > reproducibility > > mismatch than one with usrmerge enabled. > > But then it would creep into both build A and build B since both > would come from the same host or two hosts both with usrmerge, and > there would be no mismatch. No? True, I'm thinking of something slightly different. I'm thinking having usrmerge disabled makes it more likely we'd notice a "bad" tool path creeping into builds rather than the case where the host and target share the same paths. That isn't a reproducibility case, more a general one. Cheers, Richard
On Thu, 10 Aug 2023 at 18:24, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > I'm thinking having usrmerge disabled makes it more likely we'd notice > a "bad" tool path creeping into builds rather than the case where the > host and target share the same paths. That isn't a reproducibility > case, more a general one. But then should we really drop usrmerge/systemd from reproducibility as the bad path wouldn't be noticed until runtime (or maybe in package_qa), and that is tested elsewhere? FWIW, I'm not particularly happy that systemd is nowadays de facto dictating filesystem layouts. Or that you can use any libc you like, as long as it's glibc. And that all/most key developers are employed by Microsoft. Monocultures are not good, even if source code is available. Alex
On Thu, 2023-08-10 at 18:32 +0200, Alexander Kanavin wrote: > On Thu, 10 Aug 2023 at 18:24, Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > I'm thinking having usrmerge disabled makes it more likely we'd notice > > a "bad" tool path creeping into builds rather than the case where the > > host and target share the same paths. That isn't a reproducibility > > case, more a general one. > > But then should we really drop usrmerge/systemd from reproducibility > as the bad path wouldn't be noticed until runtime (or maybe in > package_qa), and that is tested elsewhere? We do build systemd configurations in multiple places and package_qa checks are run. > FWIW, I'm not particularly happy that systemd is nowadays de facto > dictating filesystem layouts. Or that you can use any libc you like, > as long as it's glibc. And that all/most key developers are employed > by Microsoft. Monocultures are not good, even if source code is > available. I am also a bit worried about that and I don't really want to tie ourselves to that in our test matrix. Whilst removing systemd from there looks fairly drastic, it isn't as bad as it seems. From the reproducibility work, we've now much tighter QA checks in general so the reprodcubility issues appearing now are much reduced and usually toolchain level rather than random path issues which the QA checks now find much earlier. As such, I doubt overall reproducibility will suffer regressions. Cheers, Richard
diff --git a/meta/lib/oeqa/selftest/cases/reproducible.py b/meta/lib/oeqa/selftest/cases/reproducible.py index 0f7e6eb376e..4c6ed4e4a50 100644 --- a/meta/lib/oeqa/selftest/cases/reproducible.py +++ b/meta/lib/oeqa/selftest/cases/reproducible.py @@ -212,10 +212,9 @@ class ReproducibleTests(OESelftestTestCase): config = textwrap.dedent('''\ PACKAGE_CLASSES = "{package_classes}" - INHIBIT_PACKAGE_STRIP = "1" TMPDIR = "{tmpdir}" LICENSE_FLAGS_ACCEPTED = "commercial" - DISTRO_FEATURES:append = ' systemd pam' + DISTRO_FEATURES:append = ' pam' USERADDEXTENSION = "useradd-staticids" USERADD_ERROR_DYNAMIC = "skip" USERADD_UID_TABLES += "files/static-passwd"
We can't have systemd here any longer without usrmerge. We don't really want to enable the latter since having separate usr will likely result in a class of reproducibility and host contamination issues that enabling it might hide. Also drop INHIBIT_PACKAGE_STRIP since we generally don't build with that and the debug binaries should be generated regardless. I suspect this is legacy from older issues. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> --- meta/lib/oeqa/selftest/cases/reproducible.py | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)