Bug 13605 - [master-next] LockedSignatures.test_locked_signatures fails
Summary: [master-next] LockedSignatures.test_locked_signatures fails
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: 3.0
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 3.1 M3
Assignee: Richard Purdie
QA Contact:
URL: https://errors.yoctoproject.org/Erro...
Whiteboard:
Depends on:
Blocks:
 
Reported: 2019-10-20 15:53 UTC by Armin Kuster
Modified: 2020-03-24 22:05 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.