Bug 13605

Summary: [master-next] LockedSignatures.test_locked_signatures fails
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Armin Kuster <akuster>
Component: coreAssignee: Richard Purdie <richard.purdie>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium+ CC: meta.mr.watcher, meta.watcher, randy.macleod
Version: 3.0   
Target Milestone: 3.1 M3   
Hardware: x86   
OS: Multiple   
URL: https://errors.yoctoproject.org/Errors/Build/91473/
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know

Description Armin Kuster 2019-10-20 15:53:40 UTC
2019-10-19 10:10:56,740 - oe-selftest - INFO -  ... FAIL
2019-10-19 10:10:56,741 - oe-selftest - INFO - 2: 35/35 188/366 (51.74s) (signing.LockedSignatures.test_locked_signatures)
2019-10-19 10:10:56,741 - oe-selftest - INFO - testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/home/pokybuild/yocto-worker/oe-selftest-centos/build/meta/lib/oeqa/selftest/cases/signing.py", line 219, in test_locked_signatures
    self.assertIsNotNone(found_warn, "Didn't find the expected warning message. Output: %s" % ret.output)
  File "/usr/lib64/python3.6/unittest/case.py", line 1256, in assertIsNotNone
    self.fail(self._formatMessage(msg, standardMsg))
  File "/usr/lib64/python3.6/unittest/case.py", line 687, in fail
    raise self.failureException(msg)
AssertionError: unexpectedly None : Didn't find the expected warning message. Output: Loading cache...done.
Comment 1 Richard Purdie 2019-12-03 22:04:55 UTC
Happened again https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/526
Comment 2 Richard Purdie 2019-12-04 13:04:22 UTC
Also seen in https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/844
Comment 3 Richard Purdie 2020-03-06 08:51:53 UTC
I've tried for months to try and debug this. I've been unable to replicate locally.

What was really revealing was adding in debug code into siggen where the warnings are stored in a string. Those warnings are later printed by code in sstate.bbclass calling the checkhashes() method.

What was happening is that checkhashes() never appeared to run, hence the expected warnings were never shown, hence the test fails. The underlying locked sigs code appeared to be working correctly and it was a message logging issue.

Later log messages are shown so its unlikely to be a client disconnection issue.

The most likely way I believe that possible is that the checkhashes function was only called with one hash to check and there is an early return in there that could trigger. I was unable to figure out how to replicate such a scenario but its possible.

We now have the summary parameter, so I've sent a patch to drop this other older piece of code.