On Sun, 2020-03-08 at 13:18 +0000, Richard Purdie wrote: > On Sun, 2020-03-08 at 14:08 +0100, Alexander Kanavin wrote: > > On Sun, 8 Mar 2020 at 09:15, Richard Purdie < > > richard.pur...@linuxfoundation.org> wrote: > > > This is now closer. Alex fixed the libmodule-build-perl and > > > gettext > > > reproducibility issues (thanks!), I tracked down a glibc issue > > > and > > > procps one I saw locally. On a fresh autobuilder run we saw: > > > > > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200307-mk0v6ljq/packages/diff-html/ > > > and > > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200307-5pvgdd3a/packages/diff-html/ > > > > > > which I believe is the remaining blocking issue on coreutils- > > > ptest. > > > > Not quite. The coreutils-ptest itself seems to persistently fail > > here: > > > > AssertionError: Failed ptests: > > {'coreutils': ['tests/tail-2/assert.sh']} > > > > so I'd like to have that fixed before it goes in. We have a 100% > > ptest pass rate now (except for random timing fluctuations), which > > I > > don't want to see regressed :) > > I agree that would be nice and something we need to do before > release, > I may let us sort that one test in M4 to enable the M3 build, I have > to > take a pragmatic approach to this. > > That said, there is a more pressing issue: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/1686 > > which is somehow seemingly related to the coreutils change, I just > can't see how as yet :/ > > (as well as the gcc-plugin reproducibility issues)
Caused by the new libmodule-build-perl which depends upon build- essential and hence gcc which isn't target multilib 'safe'. If we could stop the -ptest package dependencies leaking to -dev we'd avoid this. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core