On Thu, May 7, 2020 at 2:15 PM Steve Sakoman <[email protected]> wrote: > > From the discussion to this point it seems that these patches aren't > quite ready for dunfell. Let me know if/when that changes, or if I'm > mistaken in that assumption!
Richard merged 3 of the 4 kernel updates (up to v5.4.34), so they are ok for dunfell. There's just a reproducible issue that we have to look into more (there's no runtime issues with any of them). Bruce > > Steve > > On Mon, May 4, 2020 at 3:34 AM Bruce Ashfield <[email protected]> > wrote: > > > > On Mon, May 4, 2020 at 9:24 AM Richard Purdie > > <[email protected]> wrote: > > > > > > On Mon, 2020-05-04 at 09:06 -0400, Bruce Ashfield wrote: > > > > On Mon, May 4, 2020 at 8:56 AM Bruce Ashfield via > > > > lists.openembedded.org > > > > <[email protected]> wrote: > > > > > On Mon, May 4, 2020 at 4:31 AM Richard Purdie > > > > > <[email protected]> wrote: > > > > > > Hi Bruce, > > > > > > > > > > > > On Sun, 2020-05-03 at 11:44 -0400, [email protected] wrote: > > > > > > > From: Bruce Ashfield <[email protected]> > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > Here are the -stable updates I've collected since m3 of dunfell. I > > > > > > > ran things through the autobuilder, and no new kernel issues were > > > > > > > picked up. > > > > > > > > > > > > > > The -dev bump is good for master, while all of the 5.4-stable > > > > > > > bumps > > > > > > > are good for both master and dunfell. > > > > > > > > > > > > I pulled these into master-next and saw reproducibility issues. I > > > > > > wondered why your test build didn't show it, turns out it also did: > > > > > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/1024 > > > > > > > > > > > > 2020-05-04 05:18:46,863 - oe-selftest - INFO - > > > > > > ====================================================================== > > > > > > 2020-05-04 05:18:46,863 - oe-selftest - INFO - FAIL: > > > > > > reproducible.ReproducibleTests.test_reproducible_builds > > > > > > (subunit.RemotedTestCase) > > > > > > 2020-05-04 05:18:46,863 - oe-selftest - INFO - > > > > > > ---------------------------------------------------------------------- > > > > > > 2020-05-04 05:18:46,864 - oe-selftest - INFO - > > > > > > testtools.testresult.real._StringException: > > > > > > > > > > > > AssertionError: The following deb packages are missing or > > > > > > different: > > > > > > /home/pokybuild/yocto-worker/oe-selftest-centos/build/build-st-36044/reproducibleB/tmp/deploy/deb/./qemux86_64/kernel-module-kheaders-5.4.38-yocto-standard_5.4.38+git0+f405543442_6cb5b11e83-r0_amd64.deb > > > > > > The following ipk packages are missing or different: > > > > > > /home/pokybuild/yocto-worker/oe-selftest-centos/build/build-st-36044/reproducibleB/tmp/deploy/ipk/./qemux86_64/kernel-module-kheaders-5.4.38-yocto-standard_5.4.38+git0+f405543442_6cb5b11e83-r0_qemux86_64.ipk > > > > > > > > > > > > > > > > I don't see any changes in the kernels that would have triggered it, > > > > > but they never are obvious. > > > > > > > > I am working on some kernel reproducibility changes that were > > > > discussed about three weeks ago. > > > > > > > > Is the default for reproducible builds in master-next different from > > > > what it was before dunfell was releases ? If so, that might explain > > > > why I'm not seeing a change that would have triggered it (i.e. this is > > > > unrelated to my -stable changes). > > > > > > There are no reproducibility changes between master-next and dunfell. > > > > interesting. I'll take a closer look at the changes again and see what > > might pop up as a culprit. > > > > > > > > > Like I was mentioning before, if there's a document or pastebin of > > > > steps I can follow, I can run the tests against my pending changes and > > > > finish them for master. They of course would not necessarily be > > > > suitable for dunfell. > > > > > > The good news is the autobuilder has some debugging built in for this > > > kind of problem. You can see the diffoscope output here: > > > > > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200504-vhr0o_t9/packages/diff-html/ > > > > > > which tells us its kheaders.ko in .rodata by the looks of it. Some > > > changes are cause, some are effect, e.g. the build ID is different as > > > the sections are different so that isn't the issue but an effect of it. > > > It looks like diffoscope doesn't know how to decode the .rodata which > > > could be compressed? > > > > > > The raw data is also there (the packages that differ), e.g.: > > > > > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200504-vhr0o_t9/packages/reproducibleA/tmp/deploy/deb/qemux86_64/kernel-module-kheaders-5.4.38-yocto-standard_5.4.38%2Bgit0%2Bf405543442_6cb5b11e83-r0_amd64.deb > > > > > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200504-vhr0o_t9/packages/reproducibleB/tmp/deploy/deb/qemux86_64/kernel-module-kheaders-5.4.38-yocto-standard_5.4.38%2Bgit0%2Bf405543442_6cb5b11e83-r0_amd64.debe > > > > > > > cool. That's definitely useful, I'll have a look. > > > > At the same time, I'll try and clean up the documented kernel > > reproducible changes and trigger another run to see if they help. > > > > > which would allow you to look further at them by hand. > > > > > > You can manually run this test locally with: > > > > > > oe-selftest -r reproducible.ReproducibleTests.test_reproducible_builds > > > > > > but it will take a while to run as it has to run two builds and compare > > > them and only uses sstate for one of them. To make it faster since you > > > know where the issue is, edit > > > meta/lib/oeqa/selftest/cases/reproducible.py to change images (core- > > > image-sato, core-image-minimal and friends to simply "virtual/kernel". > > > > I'll do that cut down of the tests and see if I can trigger it here .. > > With those full builds, I'd be at about an 8 hour cycle to see the > > results! > > > > Bruce > > > > > > > > Cheers, > > > > > > Richard > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138033): https://lists.openembedded.org/g/openembedded-core/message/138033 Mute This Topic: https://lists.openembedded.org/mt/73956229/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
