Message ID | 20230925080452.803540-1-jstephan@baylibre.com |
---|---|
Headers | show |
Series | Add bblock helper scripts | expand |
Hello, I had a build were all the tests passed, then I had this failure: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio On 25/09/2023 10:04:47+0200, Julien Stephan wrote: > Hi all, > > This is v5 for bblock script. > > Improvement from v4: > * Fix self test error reported by autobuilder > * Allow to specify task with/without the "do_" prefix: > example: bblock bc -t compile,do_install > * Fix test_lock_single_recipe_all_tasks > * Fix getTaskSignatures: now retrieve all tasks and filter out the > * setscene and nostamps ones > > Limitations: > * Silently does nothing if given task doesn't exist > * Silently does nothing when resetting a recipe that doesn't exist > > Improvement from v3: > * Add self test > * Add a new "info" level for SIGGEN_LOCKEDSIGS_TASKSIG_CHECK: this allows to > display a Note when recipe contains locked task(s) > > Improvement from v2: > * Add a function in bb.cooker to compute task signatures > * Replace the findSigInfo function by the new created one. This has the > following advantages: > * findSigInfo needs the task to be already built to get the siginfo > file, meaning we cannot lock a recipe on a fresh build > * we can now generate the signatures for all available task of a given > recipe > * Check if a given task is already locked. If so, don't duplicate > entry in bblock.conf > > Limitations: > * Needs to taint tasks that are locked, to display a warning > * I may be still missing some checks on user input > * Silently does nothing if given task doesn't exist > * Silently does nothing when resetting a recipe that doesn't exist > > I did some tests using qemux86-64 and qemuarm but I may be missing some > corner cases. > > Improvement from V1: > * Signatures are now package architecture specific meaning that if you > switch MACHINE, the lock sig will not be taken into account > * I added the -r option to unlock recipes > * I added a -d option to display the current bblock.conf > * Added an include directive for conf/bblock.conf inside bitbake.conf > * Added -t option to specify the tasks to lock/unlock > > Limitations: > * I may be still missing some checks on user input > * I need to find a way to get the list of tasks ( by default still lock > only the do_compile for now, unless -t is specified) > * Do not check if a particular recipe/task is already locked when trying > to add lock. So entries may appear multiple times > * We still need the signature of the tasks to be already computed before > locking. Need to find a way to generate it if missing > > V3: https://lists.openembedded.org/g/openembedded-core/message/184932 > V2: https://lists.openembedded.org/g/openembedded-core/message/184697 > V1: https://lists.openembedded.org/g/openembedded-core/message/184584 > > My branch is available here [1] > > Cheers > Julien > > [1]: https://git.yoctoproject.org/poky-contrib/commit/?h=jstephan/bblock > > Julien Stephan (5): > bitbake.conf: include bblock.conf > bitbake: cooker: add a new function to retrieve task signatures > sstatesig: add a new info level for SIGGEN_LOCKEDSIGS_TASKSIG_CHECK > scripts/bblock: add a script to lock/unlock recipes > oeqa/selftest/bblock: add self test for bblock tool > > bitbake/lib/bb/command.py | 6 + > bitbake/lib/bb/cooker.py | 31 ++++ > bitbake/lib/bb/event.py | 8 + > meta/conf/bitbake.conf | 1 + > meta/lib/oe/sstatesig.py | 18 ++- > meta/lib/oeqa/selftest/cases/bblock.py | 201 +++++++++++++++++++++++++ > scripts/bblock | 184 ++++++++++++++++++++++ > 7 files changed, 448 insertions(+), 1 deletion(-) > create mode 100644 meta/lib/oeqa/selftest/cases/bblock.py > create mode 100755 scripts/bblock > > -- > 2.41.0 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#188174): https://lists.openembedded.org/g/openembedded-core/message/188174 > Mute This Topic: https://lists.openembedded.org/mt/101570279/3617179 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alexandre.belloni@bootlin.com] > -=-=-=-=-=-=-=-=-=-=-=- >
Le mer. 27 sept. 2023 à 12:16, Alexandre Belloni <alexandre.belloni@bootlin.com> a écrit : > > Hello, > > I had a build were all the tests passed, then I had this failure: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio > Hi Alexandre, I only see bblock.BBLock.test_lock_single_recipe_all_tasks: FAILED but I can't see the actual error :( Is it possible to have it somewhere? Cheers Julien > > > -- > Alexandre Belloni, co-owner and COO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
On 27/09/2023 14:47:57+0200, Julien Stephan wrote: > Le mer. 27 sept. 2023 � 12:16, Alexandre Belloni > <alexandre.belloni@bootlin.com> a �crit : > > > > Hello, > > > > I had a build were all the tests passed, then I had this failure: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio > > > > Hi Alexandre, > I only see > > bblock.BBLock.test_lock_single_recipe_all_tasks: FAILED > > but I can't see the actual error :( Is it possible to have it somewhere? > You can scroll up or click on the looking glass on the top right. Alternatively, you can download the log here: https://autobuilder.yoctoproject.org/typhoon/api/v2/logs/8276762/raw (the button is also on the top right) The assertion error is fairly large, that's why I didn't copy it. > Cheers > Julien > > > > > > > -- > > Alexandre Belloni, co-owner and COO, Bootlin > > Embedded Linux and Kernel engineering > > https://bootlin.com
You need to scroll up. The failure is in lines 557 to 609. Alex On Wed, 27 Sept 2023 at 14:48, Julien Stephan <jstephan@baylibre.com> wrote: > > Le mer. 27 sept. 2023 à 12:16, Alexandre Belloni > <alexandre.belloni@bootlin.com> a écrit : > > > > Hello, > > > > I had a build were all the tests passed, then I had this failure: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio > > > > Hi Alexandre, > I only see > > bblock.BBLock.test_lock_single_recipe_all_tasks: FAILED > > but I can't see the actual error :( Is it possible to have it somewhere? > > Cheers > Julien > > > > > > > -- > > Alexandre Belloni, co-owner and COO, Bootlin > > Embedded Linux and Kernel engineering > > https://bootlin.com > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#188313): https://lists.openembedded.org/g/openembedded-core/message/188313 > Mute This Topic: https://lists.openembedded.org/mt/101570279/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
Le mer. 27 sept. 2023 à 14:59, Alexander Kanavin <alex.kanavin@gmail.com> a écrit : > > You need to scroll up. The failure is in lines 557 to 609. Hmm stange ctrl-f didn't work. I can see it now. Thank you, I'll look at it Julien > > Alex > > > On Wed, 27 Sept 2023 at 14:48, Julien Stephan <jstephan@baylibre.com> wrote: > > > > Le mer. 27 sept. 2023 à 12:16, Alexandre Belloni > > <alexandre.belloni@bootlin.com> a écrit : > > > > > > Hello, > > > > > > I had a build were all the tests passed, then I had this failure: > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio > > > > > > > Hi Alexandre, > > I only see > > > > bblock.BBLock.test_lock_single_recipe_all_tasks: FAILED > > > > but I can't see the actual error :( Is it possible to have it somewhere? > > > > Cheers > > Julien > > > > > > > > > > > -- > > > Alexandre Belloni, co-owner and COO, Bootlin > > > Embedded Linux and Kernel engineering > > > https://bootlin.com > > > > -=-=-=-=-=-=-=-=-=-=-=- > > Links: You receive all messages sent to this group. > > View/Reply Online (#188313): https://lists.openembedded.org/g/openembedded-core/message/188313 > > Mute This Topic: https://lists.openembedded.org/mt/101570279/1686489 > > Group Owner: openembedded-core+owner@lists.openembedded.org > > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] > > -=-=-=-=-=-=-=-=-=-=-=- > >
On 27/09/2023 15:02:00+0200, Julien Stephan wrote: > Le mer. 27 sept. 2023 � 14:59, Alexander Kanavin > <alex.kanavin@gmail.com> a �crit : > > > > You need to scroll up. The failure is in lines 557 to 609. > > Hmm stange ctrl-f didn't work. I can see it now. Thank you, I'll look at it > By default the log is not fully downloaded, you have to click on the looking glass before ctrl-f. > Julien > > > > Alex > > > > > > On Wed, 27 Sept 2023 at 14:48, Julien Stephan <jstephan@baylibre.com> wrote: > > > > > > Le mer. 27 sept. 2023 � 12:16, Alexandre Belloni > > > <alexandre.belloni@bootlin.com> a �crit : > > > > > > > > Hello, > > > > > > > > I had a build were all the tests passed, then I had this failure: > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio > > > > > > > > > > Hi Alexandre, > > > I only see > > > > > > bblock.BBLock.test_lock_single_recipe_all_tasks: FAILED > > > > > > but I can't see the actual error :( Is it possible to have it somewhere? > > > > > > Cheers > > > Julien > > > > > > > > > > > > > > > -- > > > > Alexandre Belloni, co-owner and COO, Bootlin > > > > Embedded Linux and Kernel engineering > > > > https://bootlin.com > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > > > Links: You receive all messages sent to this group. > > > View/Reply Online (#188313): https://lists.openembedded.org/g/openembedded-core/message/188313 > > > Mute This Topic: https://lists.openembedded.org/mt/101570279/1686489 > > > Group Owner: openembedded-core+owner@lists.openembedded.org > > > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] > > > -=-=-=-=-=-=-=-=-=-=-=- > > >
On Wed, 2023-09-27 at 14:47 +0200, Julien Stephan wrote: > Le mer. 27 sept. 2023 à 12:16, Alexandre Belloni > <alexandre.belloni@bootlin.com> a écrit : > > > > Hello, > > > > I had a build were all the tests passed, then I had this failure: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio > > > > Hi Alexandre, > I only see > > bblock.BBLock.test_lock_single_recipe_all_tasks: FAILED > > but I can't see the actual error :( Is it possible to have it somewhere? I am a bit worried this will be hard to reproduce/debug so I had a look at things as I do really want to get things resolved. The error log says: WARNING: The quilt:do_build sig is computed to be 255536826e64d835fcc6b5a277e9a3dacaae75318e608fa2df289bdfa23df40e, but the sig is locked to 0f48875f011499948d53edc6abbe9e4efd617d5ef9233055e4b61411cf01cb87 in SIGGEN_LOCKEDSIGS_core2-64 and I couldn't reproduce those stamps in a local build or on the builder where it failed (once I got access which took a while). The "while" is important as I think in the meantime things changed which effected the results. On the autobuilder, "bitbake quilt -S none" generated stamp files for quilt. I did this for "build" and "build-st-3046552", the latter being the one where the test failed. There were two different do_build stamps generated. The diff: bitbake-diffsigs tmp/stamps/core2-64-poky-linux/quilt/0.67.do_build.sigdata.b502a759bb6bceb6c8ccd76b57db2612501bb66bd9c46ece5f99f8bf16d7ac4a ../build/tmp/stamps/core2-64-poky-linux/quilt/0.67.do_build.sigdata.7cf16a1f87d5058e134f3f6fc02612515e28784625413c87d3545e93ae0ab407 NOTE: Reconnecting to bitbake server... Hash for task dependency diffstat:do_package_write_rpm changed from 41171f7938a2ddbe244372c1cc4300d91b7dca425eb8b214c19262e4949a7f18 to 2211ac20553e9dddc710970cf1a663412ece5b5a2071e47c5471b3ee01efa2ce Hash for task dependency diffstat:do_package changed from f3fe486831eede23d2ebbc1efe2e2510f49f5df6d5d8a8ceb7aa2ddc6e11b1ec to e5ff0ed8a81d8022b0981162e9b4e286886d9e281adee81175725072c3d413ec Unable to find matching sigdata for diffstat:do_package with hash e5ff0ed8a81d8022b0981162e9b4e286886d9e281adee81175725072c3d413ec i.e. a couple of dependencies were different. bitbake-diffsigs tmp/stamps/core2-64-poky-linux/diffstat/1.65.do_package.sigdata.f3fe486831eede23d2ebbc1efe2e2510f49f5df6d5d8a8ceb7aa2ddc6e11b1ec ../build/tmp/stamps/core2-64-poky-linux/diffstat/1.65.do_package.sigdata.af8ebe96c5cf424e1094c1599400a56096302e16d0f691daaeec380b963f37b2 showed no output, i.e. they appear to be the same but different. My best guess at what is going on here is hash equivalence causing problems. So in summary, I think the best solution will be to disable hash equivalence for these tests. Cheers, Richard
Le mer. 27 sept. 2023 à 23:17, Richard Purdie <richard.purdie@linuxfoundation.org> a écrit : > > On Wed, 2023-09-27 at 14:47 +0200, Julien Stephan wrote: > > Le mer. 27 sept. 2023 à 12:16, Alexandre Belloni > > <alexandre.belloni@bootlin.com> a écrit : > > > > > > Hello, > > > > > > I had a build were all the tests passed, then I had this failure: > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio > > > > > > > Hi Alexandre, > > I only see > > > > bblock.BBLock.test_lock_single_recipe_all_tasks: FAILED > > > > but I can't see the actual error :( Is it possible to have it somewhere? > > I am a bit worried this will be hard to reproduce/debug so I had a look > at things as I do really want to get things resolved. > > The error log says: > > WARNING: The quilt:do_build sig is computed to be 255536826e64d835fcc6b5a277e9a3dacaae75318e608fa2df289bdfa23df40e, but the sig is locked to 0f48875f011499948d53edc6abbe9e4efd617d5ef9233055e4b61411cf01cb87 in SIGGEN_LOCKEDSIGS_core2-64 > > and I couldn't reproduce those stamps in a local build or on the > builder where it failed (once I got access which took a while). > > The "while" is important as I think in the meantime things changed > which effected the results. > > On the autobuilder, "bitbake quilt -S none" generated stamp files for > quilt. I did this for "build" and "build-st-3046552", the latter being > the one where the test failed. There were two different do_build stamps > generated. The diff: > > bitbake-diffsigs tmp/stamps/core2-64-poky-linux/quilt/0.67.do_build.sigdata.b502a759bb6bceb6c8ccd76b57db2612501bb66bd9c46ece5f99f8bf16d7ac4a ../build/tmp/stamps/core2-64-poky-linux/quilt/0.67.do_build.sigdata.7cf16a1f87d5058e134f3f6fc02612515e28784625413c87d3545e93ae0ab407 > NOTE: Reconnecting to bitbake server... > Hash for task dependency diffstat:do_package_write_rpm changed from 41171f7938a2ddbe244372c1cc4300d91b7dca425eb8b214c19262e4949a7f18 to 2211ac20553e9dddc710970cf1a663412ece5b5a2071e47c5471b3ee01efa2ce > Hash for task dependency diffstat:do_package changed from f3fe486831eede23d2ebbc1efe2e2510f49f5df6d5d8a8ceb7aa2ddc6e11b1ec to e5ff0ed8a81d8022b0981162e9b4e286886d9e281adee81175725072c3d413ec > Unable to find matching sigdata for diffstat:do_package with hash e5ff0ed8a81d8022b0981162e9b4e286886d9e281adee81175725072c3d413ec > > i.e. a couple of dependencies were different. > > bitbake-diffsigs tmp/stamps/core2-64-poky-linux/diffstat/1.65.do_package.sigdata.f3fe486831eede23d2ebbc1efe2e2510f49f5df6d5d8a8ceb7aa2ddc6e11b1ec ../build/tmp/stamps/core2-64-poky-linux/diffstat/1.65.do_package.sigdata.af8ebe96c5cf424e1094c1599400a56096302e16d0f691daaeec380b963f37b2 > > showed no output, i.e. they appear to be the same but different. > > My best guess at what is going on here is hash equivalence causing > problems. > > So in summary, I think the best solution will be to disable hash > equivalence for these tests. > > Hi Richard, Thank you a lot for digging into this! How can I disable the hash equivalence for these tests? Should I use BB_BASEHASH_IGNORE_VARS for that? I tried the following: self.write_config("BB_BASEHASH_IGNORE_VARS += \"TOPDIR\"") But this doesn't work, I get a lot of errors like the following: ERROR: When reparsing /home/jstephan/upstream/yocto/poky/meta/recipes-devtools/quilt/quilt_0.67.bb:do_packagedata, the basehash value changed from 8b6adb69d1f05eddb3e86143bf9a51060f4fac153742964bb4a3d53bee93d377 to 9dee5dada20d7f8ccfc89ed3114c428af8c96d665234fead22c25fb118f9f62b. The metadata is not deterministic and this needs to be fixed. ERROR: The following commands may help: ERROR: $ bitbake quilt -cdo_packagedata -Snone ERROR: Then: ERROR: $ bitbake quilt -cdo_packagedata -Sprintdiff Cheers Julien > Cheers, > > Richard
Hi Julien, Julien Stephan <jstephan@baylibre.com> escreveu no dia sábado, 30/09/2023 à(s) 15:13: > Le mer. 27 sept. 2023 à 23:17, Richard Purdie > <richard.purdie@linuxfoundation.org> a écrit : > > > > On Wed, 2023-09-27 at 14:47 +0200, Julien Stephan wrote: > > > Le mer. 27 sept. 2023 à 12:16, Alexandre Belloni > > > <alexandre.belloni@bootlin.com> a écrit : > > > > > > > > Hello, > > > > > > > > I had a build were all the tests passed, then I had this failure: > > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio > > > > > > > > > > Hi Alexandre, > > > I only see > > > > > > bblock.BBLock.test_lock_single_recipe_all_tasks: FAILED > > > > > > but I can't see the actual error :( Is it possible to have it > somewhere? > > > > I am a bit worried this will be hard to reproduce/debug so I had a look > > at things as I do really want to get things resolved. > > > > The error log says: > > > > WARNING: The quilt:do_build sig is computed to be > 255536826e64d835fcc6b5a277e9a3dacaae75318e608fa2df289bdfa23df40e, but the > sig is locked to > 0f48875f011499948d53edc6abbe9e4efd617d5ef9233055e4b61411cf01cb87 in > SIGGEN_LOCKEDSIGS_core2-64 > > > > and I couldn't reproduce those stamps in a local build or on the > > builder where it failed (once I got access which took a while). > > > > The "while" is important as I think in the meantime things changed > > which effected the results. > > > > On the autobuilder, "bitbake quilt -S none" generated stamp files for > > quilt. I did this for "build" and "build-st-3046552", the latter being > > the one where the test failed. There were two different do_build stamps > > generated. The diff: > > > > bitbake-diffsigs > tmp/stamps/core2-64-poky-linux/quilt/0.67.do_build.sigdata.b502a759bb6bceb6c8ccd76b57db2612501bb66bd9c46ece5f99f8bf16d7ac4a > ../build/tmp/stamps/core2-64-poky-linux/quilt/0.67.do_build.sigdata.7cf16a1f87d5058e134f3f6fc02612515e28784625413c87d3545e93ae0ab407 > > NOTE: Reconnecting to bitbake server... > > Hash for task dependency diffstat:do_package_write_rpm changed from > 41171f7938a2ddbe244372c1cc4300d91b7dca425eb8b214c19262e4949a7f18 to > 2211ac20553e9dddc710970cf1a663412ece5b5a2071e47c5471b3ee01efa2ce > > Hash for task dependency diffstat:do_package changed from > f3fe486831eede23d2ebbc1efe2e2510f49f5df6d5d8a8ceb7aa2ddc6e11b1ec to > e5ff0ed8a81d8022b0981162e9b4e286886d9e281adee81175725072c3d413ec > > Unable to find matching sigdata for diffstat:do_package with hash > e5ff0ed8a81d8022b0981162e9b4e286886d9e281adee81175725072c3d413ec > > > > i.e. a couple of dependencies were different. > > > > bitbake-diffsigs > tmp/stamps/core2-64-poky-linux/diffstat/1.65.do_package.sigdata.f3fe486831eede23d2ebbc1efe2e2510f49f5df6d5d8a8ceb7aa2ddc6e11b1ec > ../build/tmp/stamps/core2-64-poky-linux/diffstat/1.65.do_package.sigdata.af8ebe96c5cf424e1094c1599400a56096302e16d0f691daaeec380b963f37b2 > > > > showed no output, i.e. they appear to be the same but different. > > > > My best guess at what is going on here is hash equivalence causing > > problems. > > > > So in summary, I think the best solution will be to disable hash > > equivalence for these tests. > > > > > > Hi Richard, > > Thank you a lot for digging into this! > How can I disable the hash equivalence for these tests? > Can you try with BB_SIGNATURE_HANDLER using the bibake default config self.write_config('BB_SIGNATURE_HANDLER = "OEBasicHash"') Jose > Should I use BB_BASEHASH_IGNORE_VARS for that? > > I tried the following: > self.write_config("BB_BASEHASH_IGNORE_VARS += \"TOPDIR\"") > > But this doesn't work, I get a lot of errors like the following: > ERROR: When reparsing > > /home/jstephan/upstream/yocto/poky/meta/recipes-devtools/quilt/quilt_0.67.bb: > do_packagedata, > the basehash value changed from > 8b6adb69d1f05eddb3e86143bf9a51060f4fac153742964bb4a3d53bee93d377 to > 9dee5dada20d7f8ccfc89ed3114c428af8c96d665234fead22c25fb118f9f62b. The > metadata is not deterministic and this needs to be fixed. > ERROR: The following commands may help: > ERROR: $ bitbake quilt -cdo_packagedata -Snone > ERROR: Then: > ERROR: $ bitbake quilt -cdo_packagedata -Sprintdiff > > > > Cheers > Julien > > > Cheers, > > > > > Richard > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#188459): > https://lists.openembedded.org/g/openembedded-core/message/188459 > Mute This Topic: https://lists.openembedded.org/mt/101570279/5052612 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > quaresma.jose@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
Hi Jose, I just pushed my branch on poky-contrib (https://git.yoctoproject.org/poky-contrib/log/?h=jstephan/bblock) with the fix you just suggested. I do not reproduce the issue locally, so I am not sure this fix the problem.. Richard, Alexandre what do you think? Can you restart a build on autobuidler? Cheers Julien Le lun. 2 oct. 2023 à 12:25, Jose Quaresma <quaresma.jose@gmail.com> a écrit : > > Hi Julien, > > Julien Stephan <jstephan@baylibre.com> escreveu no dia sábado, 30/09/2023 à(s) 15:13: >> >> Le mer. 27 sept. 2023 à 23:17, Richard Purdie >> <richard.purdie@linuxfoundation.org> a écrit : >> > >> > On Wed, 2023-09-27 at 14:47 +0200, Julien Stephan wrote: >> > > Le mer. 27 sept. 2023 à 12:16, Alexandre Belloni >> > > <alexandre.belloni@bootlin.com> a écrit : >> > > > >> > > > Hello, >> > > > >> > > > I had a build were all the tests passed, then I had this failure: >> > > > >> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio >> > > > >> > > >> > > Hi Alexandre, >> > > I only see >> > > >> > > bblock.BBLock.test_lock_single_recipe_all_tasks: FAILED >> > > >> > > but I can't see the actual error :( Is it possible to have it somewhere? >> > >> > I am a bit worried this will be hard to reproduce/debug so I had a look >> > at things as I do really want to get things resolved. >> > >> > The error log says: >> > >> > WARNING: The quilt:do_build sig is computed to be 255536826e64d835fcc6b5a277e9a3dacaae75318e608fa2df289bdfa23df40e, but the sig is locked to 0f48875f011499948d53edc6abbe9e4efd617d5ef9233055e4b61411cf01cb87 in SIGGEN_LOCKEDSIGS_core2-64 >> > >> > and I couldn't reproduce those stamps in a local build or on the >> > builder where it failed (once I got access which took a while). >> > >> > The "while" is important as I think in the meantime things changed >> > which effected the results. >> > >> > On the autobuilder, "bitbake quilt -S none" generated stamp files for >> > quilt. I did this for "build" and "build-st-3046552", the latter being >> > the one where the test failed. There were two different do_build stamps >> > generated. The diff: >> > >> > bitbake-diffsigs tmp/stamps/core2-64-poky-linux/quilt/0.67.do_build.sigdata.b502a759bb6bceb6c8ccd76b57db2612501bb66bd9c46ece5f99f8bf16d7ac4a ../build/tmp/stamps/core2-64-poky-linux/quilt/0.67.do_build.sigdata.7cf16a1f87d5058e134f3f6fc02612515e28784625413c87d3545e93ae0ab407 >> > NOTE: Reconnecting to bitbake server... >> > Hash for task dependency diffstat:do_package_write_rpm changed from 41171f7938a2ddbe244372c1cc4300d91b7dca425eb8b214c19262e4949a7f18 to 2211ac20553e9dddc710970cf1a663412ece5b5a2071e47c5471b3ee01efa2ce >> > Hash for task dependency diffstat:do_package changed from f3fe486831eede23d2ebbc1efe2e2510f49f5df6d5d8a8ceb7aa2ddc6e11b1ec to e5ff0ed8a81d8022b0981162e9b4e286886d9e281adee81175725072c3d413ec >> > Unable to find matching sigdata for diffstat:do_package with hash e5ff0ed8a81d8022b0981162e9b4e286886d9e281adee81175725072c3d413ec >> > >> > i.e. a couple of dependencies were different. >> > >> > bitbake-diffsigs tmp/stamps/core2-64-poky-linux/diffstat/1.65.do_package.sigdata.f3fe486831eede23d2ebbc1efe2e2510f49f5df6d5d8a8ceb7aa2ddc6e11b1ec ../build/tmp/stamps/core2-64-poky-linux/diffstat/1.65.do_package.sigdata.af8ebe96c5cf424e1094c1599400a56096302e16d0f691daaeec380b963f37b2 >> > >> > showed no output, i.e. they appear to be the same but different. >> > >> > My best guess at what is going on here is hash equivalence causing >> > problems. >> > >> > So in summary, I think the best solution will be to disable hash >> > equivalence for these tests. >> > >> > >> >> Hi Richard, >> >> Thank you a lot for digging into this! >> How can I disable the hash equivalence for these tests? > > > Can you try with BB_SIGNATURE_HANDLER using the bibake default config > > self.write_config('BB_SIGNATURE_HANDLER = "OEBasicHash"') > > Jose > >> >> Should I use BB_BASEHASH_IGNORE_VARS for that? >> >> I tried the following: >> self.write_config("BB_BASEHASH_IGNORE_VARS += \"TOPDIR\"") >> >> But this doesn't work, I get a lot of errors like the following: >> ERROR: When reparsing >> /home/jstephan/upstream/yocto/poky/meta/recipes-devtools/quilt/quilt_0.67.bb:do_packagedata, >> the basehash value changed from >> 8b6adb69d1f05eddb3e86143bf9a51060f4fac153742964bb4a3d53bee93d377 to >> 9dee5dada20d7f8ccfc89ed3114c428af8c96d665234fead22c25fb118f9f62b. The >> metadata is not deterministic and this needs to be fixed. >> ERROR: The following commands may help: >> ERROR: $ bitbake quilt -cdo_packagedata -Snone >> ERROR: Then: >> ERROR: $ bitbake quilt -cdo_packagedata -Sprintdiff >> >> >> >> Cheers >> Julien >> >> > Cheers, >> > >> >> > Richard >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#188459): https://lists.openembedded.org/g/openembedded-core/message/188459 >> Mute This Topic: https://lists.openembedded.org/mt/101570279/5052612 >> Group Owner: openembedded-core+owner@lists.openembedded.org >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [quaresma.jose@gmail.com] >> -=-=-=-=-=-=-=-=-=-=-=- >> > > > -- > Best regards, > > José Quaresma
I started an oe-selftest that passed, I'm going to carry that in my branch to see whether there are other issues. On 05/10/2023 10:02:22+0200, Julien Stephan wrote: > Hi Jose, > > I just pushed my branch on poky-contrib > (https://git.yoctoproject.org/poky-contrib/log/?h=jstephan/bblock) > with the fix you just suggested. > > I do not reproduce the issue locally, so I am not sure this fix the problem.. > Richard, Alexandre what do you think? Can you restart a build on autobuidler? > > Cheers > Julien > > Le lun. 2 oct. 2023 � 12:25, Jose Quaresma <quaresma.jose@gmail.com> a �crit : > > > > Hi Julien, > > > > Julien Stephan <jstephan@baylibre.com> escreveu no dia s�bado, 30/09/2023 �(s) 15:13: > >> > >> Le mer. 27 sept. 2023 � 23:17, Richard Purdie > >> <richard.purdie@linuxfoundation.org> a �crit : > >> > > >> > On Wed, 2023-09-27 at 14:47 +0200, Julien Stephan wrote: > >> > > Le mer. 27 sept. 2023 � 12:16, Alexandre Belloni > >> > > <alexandre.belloni@bootlin.com> a �crit : > >> > > > > >> > > > Hello, > >> > > > > >> > > > I had a build were all the tests passed, then I had this failure: > >> > > > > >> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio > >> > > > > >> > > > >> > > Hi Alexandre, > >> > > I only see > >> > > > >> > > bblock.BBLock.test_lock_single_recipe_all_tasks: FAILED > >> > > > >> > > but I can't see the actual error :( Is it possible to have it somewhere? > >> > > >> > I am a bit worried this will be hard to reproduce/debug so I had a look > >> > at things as I do really want to get things resolved. > >> > > >> > The error log says: > >> > > >> > WARNING: The quilt:do_build sig is computed to be 255536826e64d835fcc6b5a277e9a3dacaae75318e608fa2df289bdfa23df40e, but the sig is locked to 0f48875f011499948d53edc6abbe9e4efd617d5ef9233055e4b61411cf01cb87 in SIGGEN_LOCKEDSIGS_core2-64 > >> > > >> > and I couldn't reproduce those stamps in a local build or on the > >> > builder where it failed (once I got access which took a while). > >> > > >> > The "while" is important as I think in the meantime things changed > >> > which effected the results. > >> > > >> > On the autobuilder, "bitbake quilt -S none" generated stamp files for > >> > quilt. I did this for "build" and "build-st-3046552", the latter being > >> > the one where the test failed. There were two different do_build stamps > >> > generated. The diff: > >> > > >> > bitbake-diffsigs tmp/stamps/core2-64-poky-linux/quilt/0.67.do_build.sigdata.b502a759bb6bceb6c8ccd76b57db2612501bb66bd9c46ece5f99f8bf16d7ac4a ../build/tmp/stamps/core2-64-poky-linux/quilt/0.67.do_build.sigdata.7cf16a1f87d5058e134f3f6fc02612515e28784625413c87d3545e93ae0ab407 > >> > NOTE: Reconnecting to bitbake server... > >> > Hash for task dependency diffstat:do_package_write_rpm changed from 41171f7938a2ddbe244372c1cc4300d91b7dca425eb8b214c19262e4949a7f18 to 2211ac20553e9dddc710970cf1a663412ece5b5a2071e47c5471b3ee01efa2ce > >> > Hash for task dependency diffstat:do_package changed from f3fe486831eede23d2ebbc1efe2e2510f49f5df6d5d8a8ceb7aa2ddc6e11b1ec to e5ff0ed8a81d8022b0981162e9b4e286886d9e281adee81175725072c3d413ec > >> > Unable to find matching sigdata for diffstat:do_package with hash e5ff0ed8a81d8022b0981162e9b4e286886d9e281adee81175725072c3d413ec > >> > > >> > i.e. a couple of dependencies were different. > >> > > >> > bitbake-diffsigs tmp/stamps/core2-64-poky-linux/diffstat/1.65.do_package.sigdata.f3fe486831eede23d2ebbc1efe2e2510f49f5df6d5d8a8ceb7aa2ddc6e11b1ec ../build/tmp/stamps/core2-64-poky-linux/diffstat/1.65.do_package.sigdata.af8ebe96c5cf424e1094c1599400a56096302e16d0f691daaeec380b963f37b2 > >> > > >> > showed no output, i.e. they appear to be the same but different. > >> > > >> > My best guess at what is going on here is hash equivalence causing > >> > problems. > >> > > >> > So in summary, I think the best solution will be to disable hash > >> > equivalence for these tests. > >> > > >> > > >> > >> Hi Richard, > >> > >> Thank you a lot for digging into this! > >> How can I disable the hash equivalence for these tests? > > > > > > Can you try with BB_SIGNATURE_HANDLER using the bibake default config > > > > self.write_config('BB_SIGNATURE_HANDLER = "OEBasicHash"') > > > > Jose > > > >> > >> Should I use BB_BASEHASH_IGNORE_VARS for that? > >> > >> I tried the following: > >> self.write_config("BB_BASEHASH_IGNORE_VARS += \"TOPDIR\"") > >> > >> But this doesn't work, I get a lot of errors like the following: > >> ERROR: When reparsing > >> /home/jstephan/upstream/yocto/poky/meta/recipes-devtools/quilt/quilt_0.67.bb:do_packagedata, > >> the basehash value changed from > >> 8b6adb69d1f05eddb3e86143bf9a51060f4fac153742964bb4a3d53bee93d377 to > >> 9dee5dada20d7f8ccfc89ed3114c428af8c96d665234fead22c25fb118f9f62b. The > >> metadata is not deterministic and this needs to be fixed. > >> ERROR: The following commands may help: > >> ERROR: $ bitbake quilt -cdo_packagedata -Snone > >> ERROR: Then: > >> ERROR: $ bitbake quilt -cdo_packagedata -Sprintdiff > >> > >> > >> > >> Cheers > >> Julien > >> > >> > Cheers, > >> > > >> > >> > Richard > >> > >> > >> > > > > > > -- > > Best regards, > > > > Jos� Quaresma > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#188705): https://lists.openembedded.org/g/openembedded-core/message/188705 > Mute This Topic: https://lists.openembedded.org/mt/101570279/3617179 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alexandre.belloni@bootlin.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Fri, 2023-10-06 at 12:56 +0200, Alexandre Belloni wrote: > I started an oe-selftest that passed, I'm going to carry that in my > branch to see whether there are other issues. I've had a couple of runs in my branch and not seen any issue from that as yet FWIW. I am leaning towards merging this at this point. Cheers, Richard
Le ven. 6 oct. 2023 à 12:59, Richard Purdie <richard.purdie@linuxfoundation.org> a écrit : > > On Fri, 2023-10-06 at 12:56 +0200, Alexandre Belloni wrote: > > I started an oe-selftest that passed, I'm going to carry that in my > > branch to see whether there are other issues. > > I've had a couple of runs in my branch and not seen any issue from that > as yet FWIW. > > I am leaning towards merging this at this point. > > Cheers, > > Richard Hi Richard and Alexandre, That is very good news :) Cheers Julien