The autopkgtest failures on focal are expected, and not an issue.
422s Summary
422s
422s failures true time 3 Size 0.00MiB List plugins
422s failures true time 3 Size 0.00MiB List presets
422s failures true time 2 Size 0.00MiB List profiles
422s failures true time 3 Size 11.69KiB --no-report --label TEST -o hardware
422s failures true time 11 Size 3.15MiB --log-size 0 --no-env-vars -z gzip
422s failures true time 29 Size 2.31MiB --mask
422s
422s Tests Failed: 9
422s Failures within each test:
422s
422s run_expecting_success: test generated stderr output, see above
422s run_expecting_success: test generated stderr output, see above
422s run_expecting_success: test generated stderr output, see above
422s run_expecting_success: test generated stderr output, see above
422s run_expecting_success: test generated stderr output, see above
422s run_expecting_success: test generated stderr output, see above
422s run_expecting_success: test generated stderr output, see above
422s run_expecting_success: test generated stderr output, see above
422s run_expecting_success: test generated stderr output, see above
As an example,
343s !!! TEST FAILED: test generated stderr output, see above !!!
343s ### start stderr
343s
343s WARNING: Failed to load 'magic' module version >= 0.4.20 which sos aims
343s to use for detecting binary files. A less effective method will be used.
343s It is recommended to install proper python3-magic package with the
343s module.
343s
343s ### end stderr
These failures are expected, and are a result of https://github.com/sosreport/sos/pull/3025 which makes python3-magic optional. On focal we do not have the required python3-magic version, so we default back to the older way of detecting binaries in sosreport. Unfortunately this then spews that message on stderr.
in the d/tests/control file, the tests fail because the test returns 1 when it sees stderr output.
The simple.sh file which has the sosreport tests has the following code,
run_expecting_success () {
#$1 - is command options
#$2 - kind of check to do, so far only extract
FAIL=false
<snip>
if [ -s /dev/shm/stderr ]; then
add_failure "test generated stderr output, see above"
echo "### start stderr"
cat /dev/shm/stderr
echo "### end stderr"
fi
The autopkgtest failures on focal are expected, and not an issue.
422s Summary success: test generated stderr output, see above success: test generated stderr output, see above success: test generated stderr output, see above success: test generated stderr output, see above success: test generated stderr output, see above success: test generated stderr output, see above success: test generated stderr output, see above success: test generated stderr output, see above success: test generated stderr output, see above
422s
422s failures true time 3 Size 0.00MiB List plugins
422s failures true time 3 Size 0.00MiB List presets
422s failures true time 2 Size 0.00MiB List profiles
422s failures true time 3 Size 11.69KiB --no-report --label TEST -o hardware
422s failures true time 11 Size 3.15MiB --log-size 0 --no-env-vars -z gzip
422s failures true time 29 Size 2.31MiB --mask
422s
422s Tests Failed: 9
422s Failures within each test:
422s
422s run_expecting_
422s run_expecting_
422s run_expecting_
422s run_expecting_
422s run_expecting_
422s run_expecting_
422s run_expecting_
422s run_expecting_
422s run_expecting_
As an example,
343s !!! TEST FAILED: test generated stderr output, see above !!!
343s ### start stderr
343s
343s WARNING: Failed to load 'magic' module version >= 0.4.20 which sos aims
343s to use for detecting binary files. A less effective method will be used.
343s It is recommended to install proper python3-magic package with the
343s module.
343s
343s ### end stderr
These failures are expected, and are a result of https:/ /github. com/sosreport/ sos/pull/ 3025 which makes python3-magic optional. On focal we do not have the required python3-magic version, so we default back to the older way of detecting binaries in sosreport. Unfortunately this then spews that message on stderr.
Even though we have
Restrictions: needs-root, allow-stderr, isolation-machine
in the d/tests/control file, the tests fail because the test returns 1 when it sees stderr output.
The simple.sh file which has the sosreport tests has the following code,
run_expecting_ success () {
#$1 - is command options
#$2 - kind of check to do, so far only extract
FAIL=false
<snip>
if [ -s /dev/shm/stderr ]; then
add_failure "test generated stderr output, see above"
echo "### start stderr"
cat /dev/shm/stderr
echo "### end stderr"
fi
The add_failure then does
add_failure () { LIST="$ {FAIL_LIST} \n \t ${FUNCNAME[1]}: \t\t ${1}"
FAIL=true <--
echo "!!! TEST FAILED: $1 !!!"
FAIL_
}
So the test returns 1 not the expected 0,
if $FAIL; then URES=$( ($NUMOFFAILURES + 1))
NUMOFFAIL
return 1 <---
else
return 0
fi