In the ubuntu armhf DEP8 infrastructure, this is what /proc/self/status looks like when that failing test starts (I added a "cat /proc/self/status" to debug):
Name: cat Umask: 0002 State: R (running) Tgid: 1105 Ngid: 0 Pid: 1105 PPid: 1102 TracerPid: 0 Uid: 1000 1000 1000 1000 Gid: 1000 1000 1000 1000 FDSize: 64 Groups: 4 24 27 30 115 1000 NStgid: 1105 NSpid: 1105 NSpgid: 1092 NSsid: 1092 VmPeak: 4164 kB VmSize: 4164 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 644 kB VmRSS: 644 kB RssAnon: 64 kB RssFile: 580 kB RssShmem: 0 kB VmData: 328 kB VmStk: 132 kB VmExe: 24 kB VmLib: 1188 kB VmPTE: 36 kB VmSwap: 0 kB HugetlbPages: 0 kB CoreDumping: 0 THP_enabled: 1 Threads: 1 SigQ: 0/63405 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000000000000 SigCgt: 0000000000000000 CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 0000003fffffffff CapAmb: 0000000000000000 NoNewPrivs: 0 Seccomp: 0 Speculation_Store_Bypass: unknown Cpus_allowed: ff Cpus_allowed_list: 0-7 Mems_allowed: 00000000,00000001 Mems_allowed_list: 0 voluntary_ctxt_switches: 0 nonvoluntary_ctxt_switches: 0 Seccomp: 0 Specifically, "Seccomp: 0" tells us that there is no seccomp filtering applied. Therefore, the test runs. When I launch an armhf container on my pi4, even a privileged one, I get "Seccomp: 2" and "Seccomp_filters: 1", so there is some filtering applied and the test is skipped. In the debian armhf DEP8 infrastructure, "Seccomp: 0" is not present in /proc/self/status (I don't know the full contents) when the test starts, so the "grep" check makes it exit with status 77 and the test is skipped. I don't know how to further troubleshoot this, since it only happens in the ubuntu DEP8 infrastructure, and using it for step by step debugging will take a long time. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/2051118 Title: DEP8 error on armhf Status in libseccomp package in Ubuntu: In Progress Bug description: Version 2.5.4-2 introduced this change in d/t/control: libseccomp (2.5.4-2) unstable; urgency=medium * Fix watch file. (Closes: #1050659) * Dynamically skip autopkgtests when the test runner already applies seccomp restrictions. - Drop isolation-machine restriction. -Restrictions: isolation-machine, allow-stderr +Restrictions: skippable, allow-stderr This made the test run in Ubuntu again on armhf, where we use a lxd container (it wasn't running previously). This change is relying on this check in d/t/common: if ! grep -q -E '^Seccomp:[[:blank:]]+0$' /proc/self/status; then echo "Skipping autpkgptest as the test environment already applies a seccomp filter" exit 77 fi In Debian, where they also use containers, the testsuite-live-python3 test is skipped correctly, but in Ubuntu, it is run and fails[1] with timeout limit: 541s live 541s ./regression: line 253: cd: /tmp/autopkgtest.X55y55/autopkgtest_tmp/tests/../src/python/build/lib.*: No such file or directory 10468s autopkgtest [01:49:37]: kill with SIGTERM did not work sending SIGKILL 1. https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/armhf/libs/libseccomp/20231225_015646_12139@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/2051118/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
