mbox series

[v5,0/5] Add bblock helper scripts

Message ID 20230925080452.803540-1-jstephan@baylibre.com
Headers show
Series Add bblock helper scripts | expand

Message

Julien Stephan Sept. 25, 2023, 8:04 a.m. UTC
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

Comments

Alexandre Belloni Sept. 27, 2023, 10:16 a.m. UTC | #1
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]
> -=-=-=-=-=-=-=-=-=-=-=-
>
Julien Stephan Sept. 27, 2023, 12:47 p.m. UTC | #2
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
Alexandre Belloni Sept. 27, 2023, 12:58 p.m. UTC | #3
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
Alexander Kanavin Sept. 27, 2023, 12:59 p.m. UTC | #4
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]
> -=-=-=-=-=-=-=-=-=-=-=-
>
Julien Stephan Sept. 27, 2023, 1:02 p.m. UTC | #5
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]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >
Alexandre Belloni Sept. 27, 2023, 1:04 p.m. UTC | #6
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]
> > > -=-=-=-=-=-=-=-=-=-=-=-
> > >
Richard Purdie Sept. 27, 2023, 9:17 p.m. UTC | #7
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
Julien Stephan Sept. 30, 2023, 2:13 p.m. UTC | #8
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
Jose Quaresma Oct. 2, 2023, 10:24 a.m. UTC | #9
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]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
Julien Stephan Oct. 5, 2023, 8:02 a.m. UTC | #10
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
Alexandre Belloni Oct. 6, 2023, 10:56 a.m. UTC | #11
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]
> -=-=-=-=-=-=-=-=-=-=-=-
>
Richard Purdie Oct. 6, 2023, 10:59 a.m. UTC | #12
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
Julien Stephan Oct. 6, 2023, 12:37 p.m. UTC | #13
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