FTBFS on i386/ppc64/s390x (Eoan+Focal)

[Christian Ehrhardt ]

Due to the python 3.8 transition in focal this was rebuilt but fails atm.
=> https://launchpadlibrarian.net/448119198/buildlog_ubuntu-focal-s390x.libseccomp_2.4.1-0ubuntu0.19.10.4_BUILDING.txt.gz

The simulations fail in this case:
 batch name: 36-sim-ipc_syscalls
 test mode: c
 test type: bpf-sim
Test 36-sim-ipc_syscalls%%001-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%002-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%003-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%004-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%005-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%006-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%007-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%008-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%009-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%010-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%011-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%012-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%013-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%014-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%015-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%016-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%017-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%018-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%019-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%020-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%021-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%022-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%023-00001 result: ERROR 36-sim-ipc_syscalls rc=14
Test 36-sim-ipc_syscalls%%024-00001 result: ERROR 36-sim-ipc_syscalls rc=14
 test mode: c
 test type: bpf-valgrind
Test 36-sim-ipc_syscalls%%025-00001 result: FAILURE 36-sim-ipc_syscalls rc=14
 batch name: 37-sim-ipc_syscalls_be
 test mode: c
 test type: bpf-sim
 test arch: s390

 batch name: 37-sim-ipc_syscalls_be
 test mode: c
 test type: bpf-sim
 test arch: s390
Test 37-sim-ipc_syscalls_be%%001-00001 result: ERROR 37-sim-ipc_syscalls_be rc=14
 test arch: s390
Test 37-sim-ipc_syscalls_be%%002-00001 result: ERROR 37-sim-ipc_syscalls_be rc=14
 test arch: s390
Test 37-sim-ipc_syscalls_be%%003-00001 result: ERROR 37-sim-ipc_syscalls_be rc=14
 test arch: s390
Test 37-sim-ipc_syscalls_be%%004-00001 result: ERROR 37-sim-ipc_syscalls_be rc=14
 test arch: s390
Test 37-sim-ipc_syscalls_be%%005-00001 result: ERROR 37-sim-ipc_syscalls_be rc=14
 test arch: s390
Test 37-sim-ipc_syscalls_be%%006-00001 result: ERROR 37-sim-ipc_syscalls_be rc=14
 test arch: s390
Test 37-sim-ipc_syscalls_be%%007-00001 result: ERROR 37-sim-ipc_syscalls_be rc=14
 test arch: s390
Test 37-sim-ipc_syscalls_be%%008-00001 result: ERROR 37-sim-ipc_syscalls_be rc=14
 test arch: s390
Test 37-sim-ipc_syscalls_be%%009-00001 result: ERROR 37-sim-ipc_syscalls_be rc=14
 test arch: s390
Test 37-sim-ipc_syscalls_be%%010-00001 result: ERROR 37-sim-ipc_syscalls_be rc=14
 test arch: s390
Test 37-sim-ipc_syscalls_be%%011-00001 result: ERROR 37-sim-ipc_syscalls_be rc=14
 test arch: s390
Test 37-sim-ipc_syscalls_be%%012-00001 result: ERROR 37-sim-ipc_syscalls_be rc=14
 test mode: c
 test type: bpf-valgrind
Test 37-sim-ipc_syscalls_be%%013-00001 result: FAILURE 37-sim-ipc_syscalls_be rc=14

It is always the s390x test - even when running on i386/ppc64
On x86_64 this test succeeds:

Test 36-sim-ipc_syscalls%%025-00001 result: SUCCESS
 batch name: 37-sim-ipc_syscalls_be
 test mode: c
 test type: bpf-sim
 test arch: s390

[Christian Ehrhardt  (paelzer)]

Interestingly this is already FTBFS in Eoan.
I have created LXD environments doing rebuilds of the same source and they fail the same way in Eoan and Focal.

The last successful build in Launchpad if from 4th of May, so something else going into Eoan already broke this.

[Christian Ehrhardt  (paelzer)]

I wanted to have a good case for comparison, so I also spawned Disco and there the same passes.
The subtests are reporting "SUCCESS" and overall it is skipped for non native.
Test 36-sim-ipc_syscalls%%023-00001 result: SUCCESS
...
Test 36-sim-ipc_syscalls%%025-00001 result: SKIPPED (only valid in native/c mode)

[Christian Ehrhardt  (paelzer)]

Note: the debug needs nothing very special
$ apt build-dep libseccomp
$ pull-lp-source libseccomp
$ cd libseccomp-2.4.1/
$ ./debian/rules build

Is enough to trigger the failing build.
To then afterwards re-iterate on the failing code run:

$ cd tests
$ ./36-sim-ipc_syscalls

Good: some output and RC=0
Bad: no output, RC=14

[Christian Ehrhardt  (paelzer)]

This is non stripped and only 112 lines of C

./36-sim-ipc_syscalls: ELF 64-bit MSB pie executable, IBM S/390, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1, BuildID[sha1]=15c4946540be396acecc4273529e252eceff398f, for GNU/Linux 3.2.0, with debug_info, not stripped

wc -l 36-sim-ipc_syscalls.c
112 36-sim-ipc_syscalls.c

That should be debuggable I guess ...

Re-Build without optimization:
# gcc -DHAVE_CONFIG_H -I. -I.. -I../include -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -g -O0 -fdebug-prefix-map=/root/libseccomp-2.4.1=. -fstack-protector-strong -Wformat -Werror=format-security -c -o 36-sim-ipc_syscalls.o 36-sim-ipc_syscalls.c
# gcc -Wall -g -O0 -fdebug-prefix-map=/root/libseccomp-2.4.1=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-Bsymbolic-functions -Wl,-z -Wl,relro -o 36-sim-ipc_syscalls 36-sim-ipc_syscalls.o -lpthread ./.libs/util.a ../src/.libs/libseccomp.a

Install gdb and check what might be going on ...

[Christian Ehrhardt  (paelzer)]

Note: it became a PIE executable in Eoan, but haven't we had pie as default much longer?

The difference is in:
  rc = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(semtimedop), 0);

In the bad case it returns -14

Good:
Breakpoint 2, seccomp_rule_add (ctx=0x2aa00049260, action=2147418112, syscall=-204, arg_cnt=0) at api.c:429
Bad:
Breakpoint 2, seccomp_rule_add (ctx=0x2aa000492a0, action=2147418112, syscall=392, arg_cnt=0) at api.c:429

Look at the syscall number it is very different.
In the good case all are -2xx (also all following ones)

So maybe "SCMP_SYS(semtimedop)" for s390x no more works well?

[Christian Ehrhardt  (paelzer)]

include/seccomp.h
#define __PNR_semtimedop -204
#ifndef __NR_semtimedop
#define __NR_semtimedop __PNR_semtimedop
#endif /* __NR_semtime */

So if __NR_semtimedop is 392 then it would not set -204 and we'd get this result.

Turns out that all but SCMP_SYS(semop) have changed on this s390x build.
A build with -E shows that.

Good:
 rc = seccomp_rule_add(ctx, 0x7fff0000U, (-201), 0);
 if (rc != 0)
  goto out;
 rc = seccomp_rule_add(ctx, 0x7fff0000U, (-204), 0);
 if (rc != 0)
  goto out;
 rc = seccomp_rule_add(ctx, 0x7fff0000U, (-202), 0);
 if (rc != 0)
  goto out;

Bad:
 rc = seccomp_rule_add(ctx, 0x7fff0000U, (-201), 0);
 if (rc != 0)
  goto out;
 rc = seccomp_rule_add(ctx, 0x7fff0000U, (
# 61 "36-sim-ipc_syscalls.c" 3 4
                                           392
# 61 "36-sim-ipc_syscalls.c"
                                           ), 0);
 if (rc != 0)
  goto out;
 rc = seccomp_rule_add(ctx, 0x7fff0000U, (
# 65 "36-sim-ipc_syscalls.c" 3 4
                                           393
# 65 "36-sim-ipc_syscalls.c"
                                           ), 0);
 if (rc != 0)
  goto out;

[Christian Ehrhardt  (paelzer)]

The difference is in the includes:

Good:
grep -Hrn __NR_semtimedop *
asm-generic/unistd.h:539:#define __NR_semtimedop 192
asm-generic/unistd.h:540:__SC_COMP(__NR_semtimedop, sys_semtimedop, compat_sys_semtimedop)
s390x-linux-gnu/bits/syscall.h:1782:#ifdef __NR_semtimedop
s390x-linux-gnu/bits/syscall.h:1783:# define SYS_semtimedop __NR_semtimedop

Bad:
# grep -Hrn __NR_semtimedop *
asm-generic/unistd.h:571:#define __NR_semtimedop 192
asm-generic/unistd.h:572:__SC_3264(__NR_semtimedop, sys_semtimedop_time32, sys_semtimedop)
>>> s390x-linux-gnu/asm/unistd_64.h:336:#define __NR_semtimedop 392
s390x-linux-gnu/bits/syscall.h:1894:#ifdef __NR_semtimedop
s390x-linux-gnu/bits/syscall.h:1895:# define SYS_semtimedop __NR_semtimedop

That is from Package: linux-libc-dev:s390x
Which is from source "linux" so the kernel I'd think then.

Good: 5.0.0-32.34
Bad: 5.3.0-19.20

Hmm, a kernel change then?

[Christian Ehrhardt  (paelzer)]

I think this comes from [1] which is in since 5.3.
This will be generated into s390x-linux-gnu/asm/unistd_64.h and such.

on x86-64 it was 220 all along, no change there.
/usr/include/x86_64-linux-gnu/asm/unistd_64.h:#define __NR_semtimedop 220

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0d6040d4

[Christian Ehrhardt  (paelzer)]

Well this change made the ID 392 "known" to all architectures (in a try to sync numbers across everywhere) but it fails on those it isn't implemented (32bit, ppc, s390x + sparc which we don't have).

The path registering these calls goes
seccomp_rule_add
 -> seccomp_rule_add_array
     -> db_col_valid
     -> _syscall_valid
     -> db_col_rule_add <- still -204/392
         -> _db_rule_new
         -> db_col_transaction_start <- dups old rule (-201) ITERATES
            -> arch_filter_rule_add
                -> arch_syscall_translate
                    -> arch_syscall_resolve_num <- returns "semop" for -201
                    -> arch_syscall_resolve_name <- returns -201 for "semop"
            Returns RC=0 (db_col_transaction_start)
            The above defined the transaction start
         -> arch_filter_rule_add <- this adds the new rule -204/392
             -> arch_syscall_translate
                 -> arch_syscall_resolve_num
                      Good case returns "semtimedop" for
                      Bad case returns 0x0 for 392
                  From here it now returns -EFAULT (=> -14) and things break

So we enter:
Good: Breakpoint 14, s390x_syscall_resolve_num (num=-204) at arch-s390x-syscalls.c:533
Bad: Breakpoint 13, s390x_syscall_resolve_num (num=392) at arch-s390x-syscalls.c:533

This searches the table s390x_syscall_table and fails to find 392, from there things break.
The worst is, that "semtimedop" is there, but with __PNR_semtimedop as number.
As it used to have no number yet when last time generated.
If it would use __NR_semtimedop instead of __PNR_semtimedop it might even work as-is.
I'm not sure if src/arch-s390x-syscalls.c is allowed to use include/seccomp.h (where these compat defines are).
I need to suggest that upstream (or check if a change exists)

Summary of the above:
- kernel change defined numbers for all calls (implemented or not)
- due to that no more the fallback "#define __PNR_semtimedop -204" but provided 392 is used
- arch_syscall_translate tries to translate 392 in the context of the native architecure to the provided architecture and fails
- src/arch-s390x-syscalls.c contains syscall tables derived from 4.15-rc7 which need to be updated
- Definitions in this table should use __NR_ instead of __PNR_ to get the kernel value once it is defined (will be ==__PNR when not defined)
- Even if not using __NR it needs a redefine for newer kernels

[Christian Ehrhardt  (paelzer)]

Upstream/master branch still is on 4.15-rc7 AND still uses __PNR_* for the definitions.
I'll open an issue to further discuss it there.

[Christian Ehrhardt  (paelzer)]

And as usual once you know what you search:
=> https://github.com/seccomp/libseccomp/issues/166

[Christian Ehrhardt  (paelzer)]

TODO:
a) wait for 2.4.2 and 2.5.0 to be released and pick those
b) if urgent pick and backport [1]

[1]: https://github.com/seccomp/libseccomp/pull/176/commits/e4d38dcfd44743a55728b336d008ec8e37c1b344

[Christian Ehrhardt  (paelzer)]

Subscribing ubuntu-security to monitor this together with us as often enough they do libseccomp.
IMHO We don't have any urgency to go ahead of upstream, unless a fast re-build is needed.

[Matthias Klose (doko)]

blocking the intro of python3.8

[Christian Ehrhardt  (paelzer)]

Code is on https://github.com/seccomp/libseccomp/tree/release-2.4 now.
But an official release would need 2.4.2 to be tagged by upstream.

But now fixes can be cherry-picked to fix the FTBFS in E+F

[Christian Ehrhardt  (paelzer)]

I have tried quickly to just backport [1] but it still fails in a full cross arch PPA build
OTOH adding those worked in the sbuild env when modifying things manually.
There must be more to it.

[1]: https://github.com/seccomp/libseccomp/commit/be65b26b67099be2b2b4890d736dbd1ad15adf36

[Christian Ehrhardt  (paelzer)]

Oh it now became a real build issue (not on unit tests) by breaking very early with things like:
arch-x86_64-syscalls.c:63:27: error: ‘__PNR_clock_getres_time64’ undeclared here (not in a function)
   63 | { "clock_getres_time64", __PNR_clock_getres_time64 },

[Christian Ehrhardt  (paelzer)]

Well the answer to the new fails is that we are now "too new" in my tests I used kernel 5.3 and this is what Focal has. But the final fix used 5.4-rc levels which brought in all the time64 things.

linux-libc-dev:amd64 5.3.0-21.22

5.3 already has the NR definitions like
/usr/include/x86_64-linux-gnu/bits/syscall.h:182:#ifdef __NR_clock_gettime64

But the updated seccomp code added things like:
src/arch-mips64-syscalls.c
 626 +»··{ "clock_settime64", __PNR_clock_settime64 },

Usually there are compat defines inside seccomp include/seccomp.h
But the timers are not there.

So without the timers defined => tests fail re-resolving those
with them defined => build fails missing some other part of the definition.

What we overall need seems instead to be the slightly bigger set of:
44113f30 arch: add support for io-uring related system calls in kernel 5.1
0db8babb api: stop defining __NR_x values for syscalls that don't exist
80177ff2 build: ship seccomp-syscalls.h
be65b26b arch: update the internal syscall tables to Linux v5.4-rc4

[Christian Ehrhardt  (paelzer)]

Offline build worked much better with these, but I still see some arches fail (see PPA)

PPA: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1849785-libseccomp-ftbfs/+packages

[Christian Ehrhardt  (paelzer)]

Only fails on arm64 now (all others good):
15-basic-resolver.c:58:46: error: ‘__NR_open’ undeclared (first use in this function)
   58 | if (seccomp_syscall_resolve_name("open") != __NR_open)

[Christian Ehrhardt  (paelzer)]

Build issue is reproducible on arm64 LP infrastructure builds.

I spawned a canonistack arm64 system to check if it is reproducible there as well for some debugging how we could fix it.

Interestingly, it does NOT FAIL on focal as-is when building on aarch64.

But as LP builds are against -proposed I Then switched to focal-proposed which upgraded this list of things:
apport/focal-proposed 2.20.11-0ubuntu11 all [upgradable from: 2.20.11-0ubuntu9]
fwupd-signed/focal-proposed 1.12+1.3.3-2 arm64 [upgradable from: 1.10+1.2.10-1ubuntu2]
fwupd/focal-proposed 1.3.3-2 arm64 [upgradable from: 1.2.10-1ubuntu2]
gawk/focal-proposed 1:5.0.1+dfsg-1 arm64 [upgradable from: 1:4.2.1+dfsg-1.1build1]
libcap2-bin/focal-proposed 1:2.27-1 arm64 [upgradable from: 1:2.25-2]
libcap2/focal-proposed 1:2.27-1 arm64 [upgradable from: 1:2.25-2]
libdebconfclient0/focal-proposed 0.250ubuntu1 arm64 [upgradable from: 0.249ubuntu1]
libfwupd2/focal-proposed 1.3.3-2 arm64 [upgradable from: 1.2.10-1ubuntu2]
libglib2.0-0/focal-proposed 2.63.1-1 arm64 [upgradable from: 2.62.1-1]
libglib2.0-bin/focal-proposed 2.63.1-1 arm64 [upgradable from: 2.62.1-1]
libglib2.0-data/focal-proposed 2.63.1-1 all [upgradable from: 2.62.1-1]
liblz4-1/focal-proposed 1.9.2-1 arm64 [upgradable from: 1.9.1-2]
libpam-cap/focal-proposed 1:2.27-1 arm64 [upgradable from: 1:2.25-2]
libpython3-all-dev/focal-proposed 3.7.5-1ubuntu1 arm64 [upgradable from: 3.7.5-1]
libpython3-dev/focal-proposed 3.7.5-1ubuntu1 arm64 [upgradable from: 3.7.5-1]
libpython3-stdlib/focal-proposed 3.7.5-1ubuntu1 arm64 [upgradable from: 3.7.5-1]
libseccomp2/focal-proposed 2.4.1-0ubuntu0.19.10.4 arm64 [upgradable from: 2.4.1-0ubuntu0.19.10.3]
linux-headers-generic/focal-proposed 5.3.0.21.24 arm64 [upgradable from: 5.3.0.19.22]
linux-headers-virtual/focal-proposed 5.3.0.21.24 arm64 [upgradable from: 5.3.0.19.22]
linux-image-virtual/focal-proposed 5.3.0.21.24 arm64 [upgradable from: 5.3.0.19.22]
linux-libc-dev/focal-proposed 5.3.0-21.22 arm64 [upgradable from: 5.3.0-19.20]
linux-virtual/focal-proposed 5.3.0.21.24 arm64 [upgradable from: 5.3.0.19.22]
lz4/focal-proposed 1.9.2-1 arm64 [upgradable from: 1.9.1-2]
python3-all-dev/focal-proposed 3.7.5-1ubuntu1 arm64 [upgradable from: 3.7.5-1]
python3-all/focal-proposed 3.7.5-1ubuntu1 arm64 [upgradable from: 3.7.5-1]
python3-apport/focal-proposed 2.20.11-0ubuntu11 all [upgradable from: 2.20.11-0ubuntu9]
python3-colorama/focal-proposed 0.4.1-1 all [upgradable from: 0.3.7-1]
python3-dev/focal-proposed 3.7.5-1ubuntu1 arm64 [upgradable from: 3.7.5-1]
python3-distupgrade/focal-proposed 1:20.04.4 all [upgradable from: 1:20.04.2]
python3-jwt/focal-proposed 1.7.1-2 all [upgradable from: 1.7.1-1]
python3-launchpadlib/focal-proposed 1.10.7-2 all [upgradable from: 1.10.7-1]
python3-lazr.restfulclient/focal-proposed 0.14.2-2 all [upgradable from: 0.14.2-1]
python3-lazr.uri/focal-proposed 1.0.3-4 all [upgradable from: 1.0.3-3]
python3-minimal/focal-proposed 3.7.5-1ubuntu1 arm64 [upgradable from: 3.7.5-1]
python3-oauthlib/focal-proposed 3.1.0-1 all [upgradable from: 2.1.0-1]
python3-pkg-resources/focal-proposed 41.4.0-1 all [upgradable from: 41.1.0-1]
python3-problem-report/focal-proposed 2.20.11-0ubuntu11 all [up...

[Christian Ehrhardt  (paelzer)]

Arm64:
$ grep NR_open $(dpkg -L linux-libc-dev | xargs) 2>/dev/null
/usr/include/asm-generic/unistd.h:#define __NR_openat 56
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_openat, sys_openat)
/usr/include/asm-generic/unistd.h:#define __NR_open_by_handle_at 265
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_open_by_handle_at, sys_open_by_handle_at)
/usr/include/asm-generic/unistd.h:#define __NR_open_tree 428
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_open_tree, sys_open_tree)

Amd64:
$ grep NR_open $(dpkg -L linux-libc-dev | xargs) 2>/dev/null
/usr/include/asm-generic/unistd.h:#define __NR_openat 56
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_openat, sys_openat)
/usr/include/asm-generic/unistd.h:#define __NR_open_by_handle_at 265
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_open_by_handle_at, sys_open_by_handle_at)
/usr/include/asm-generic/unistd.h:#define __NR_open_tree 428
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_open_tree, sys_open_tree)
/usr/include/x86_64-linux-gnu/asm/unistd_32.h:#define __NR_open 5
/usr/include/x86_64-linux-gnu/asm/unistd_32.h:#define __NR_openat 295
/usr/include/x86_64-linux-gnu/asm/unistd_32.h:#define __NR_open_by_handle_at 342
/usr/include/x86_64-linux-gnu/asm/unistd_32.h:#define __NR_open_tree 428
/usr/include/x86_64-linux-gnu/asm/unistd_64.h:#define __NR_open 2
/usr/include/x86_64-linux-gnu/asm/unistd_64.h:#define __NR_openat 257
/usr/include/x86_64-linux-gnu/asm/unistd_64.h:#define __NR_open_by_handle_at 304
/usr/include/x86_64-linux-gnu/asm/unistd_64.h:#define __NR_open_tree 428
/usr/include/x86_64-linux-gnu/asm/unistd_x32.h:#define __NR_open (__X32_SYSCALL_BIT + 2)
/usr/include/x86_64-linux-gnu/asm/unistd_x32.h:#define __NR_openat (__X32_SYSCALL_BIT + 257)
/usr/include/x86_64-linux-gnu/asm/unistd_x32.h:#define __NR_open_by_handle_at (__X32_SYSCALL_BIT + 304)
/usr/include/x86_64-linux-gnu/asm/unistd_x32.h:#define __NR_open_tree (__X32_SYSCALL_BIT + 428)

So this really might be different on arm, not sure what to do about it yet.
Might be related to https://github.com/seccomp/libseccomp/commit/0db8babb27eed3ce202d54ec1cd99f23367631cf

[Christian Ehrhardt  (paelzer)]

Continues to FTFBS in LP infra today :-/

[Christian Ehrhardt  (paelzer)]

Note: I ensured that the ppa uses focal-proposed, now there are even more issues.

x86:
checking for python extension module directory... Traceback (most recent call last):
  File "<string>", line 20, in <module>
  File "/usr/lib/python3.8/sysconfig.py", line 512, in get_path
    return get_paths(scheme, vars, expand)[name]
  File "/usr/lib/python3.8/sysconfig.py", line 502, in get_paths
    return _expand_vars(scheme, vars)
  File "/usr/lib/python3.8/sysconfig.py", line 172, in _expand_vars
    _extend_dict(vars, get_config_vars())
  File "/usr/lib/python3.8/sysconfig.py", line 550, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/usr/lib/python3.8/sysconfig.py", line 421, in _init_posix
    _temp = __import__(name, globals(), locals(), ['build_time_vars'], 0)
ModuleNotFoundError: No module named '_sysconfigdata_m_linux_x86_64-linux-gnu'

And Arm continues to be affected by:
Only fails on arm64 now (all others good):
15-basic-resolver.c:58:46: error: ‘__NR_open’ undeclared (first use in this function)
   58 | if (seccomp_syscall_resolve_name("open") != __NR_open)

As I said on a local build on arm64 it just works fine :-/

[Christian Ehrhardt  (paelzer)]

2.4.2 was released by upstream now on the weekend wrapping up all the changes I experimented with.
We might try packaging this instead and be better off.

[Christian Ehrhardt  (paelzer)]

The full 2.4.2 release also fails with:
Traceback (most recent call last):
  File "./setup.py", line 28, in <module>
    from Cython.Distutils import build_ext
  File "/usr/lib/python3/dist-packages/Cython/Distutils/__init__.py", line 1, in <module>
    from Cython.Distutils.build_ext import build_ext
  File "/usr/lib/python3/dist-packages/Cython/Distutils/build_ext.py", line 25, in <module>
    from .old_build_ext import old_build_ext as build_ext
  File "/usr/lib/python3/dist-packages/Cython/Distutils/old_build_ext.py", line 79, in <module>
    optimization = Optimization()
  File "/usr/lib/python3/dist-packages/Cython/Distutils/old_build_ext.py", line 59, in __init__
    self.state = sysconfig.get_config_vars(*self.flags)
  File "/usr/lib/python3.8/distutils/sysconfig.py", line 506, in get_config_vars
    func()
  File "/usr/lib/python3.8/distutils/sysconfig.py", line 466, in _init_posix
    _temp = __import__(name, globals(), locals(), ['build_time_vars'], 0)
ModuleNotFoundError: No module named '_sysconfigdata_m_linux_s390x-linux-gnu'

[Christian Ehrhardt  (paelzer)]

Architectures with the fail above: all

Happens after build and self tests on dh_auto_install for python 3.8
On x86 that would be:
ModuleNotFoundError: No module named '_sysconfigdata_m_linux_x86_64-linux-gnu'

[Christian Ehrhardt  (paelzer)]

This moved in python:
3.7:
libpython3.7-minimal:amd64: /usr/lib/python3.7/_sysconfigdata_m_linux_x86_64-linux-gnu.py
3.8:
libpython3.8-stdlib:amd64: /usr/lib/python3.8/_sysconfigdata__linux_x86_64-linux-gnu.py

Build depends is: libpython3-all-dev
The file is present - Build-env:
/usr/lib/python3.8/__pycache__/_sysconfigdata__linux_x86_64-linux-gnu.cpython-38.pyc
/usr/lib/python3.8/__pycache__/_sysconfigdata__x86_64-linux-gnu.cpython-38.pyc
/usr/lib/python3.8/_sysconfigdata__linux_x86_64-linux-gnu.py
/usr/lib/python3.8/_sysconfigdata__x86_64-linux-gnu.py

This is explicit in
override_dh_auto_install:
        dh_auto_install
        set -e; export _PYTHON_SYSCONFIGDATA_NAME='_sysconfigdata_m_${DEB_HOST_ARCH_OS}_${DEB_HOST_MULTIARCH}'; \
        for pyver in `py3versions -s`; do \
                dh_auto_configure -- --enable-python PYTHON=$$pyver; \
                dh_auto_install --sourcedirectory=src/python -- PYTHON=$$pyver; \
        done

So it turns out this lost the "m" in python 3.8
Which probably would autoresolve in other cases, but since here the d/rules has it listed explicitly it fails.

Error reproducible with:
$ set -e; export _PYTHON_SYSCONFIGDATA_NAME='_sysconfigdata_m_linux_x86_64_linux-gnu'
$ dh_auto_install --sourcedirectory=src/python -- PYTHON=python3.8

works with:
set -e; export _PYTHON_SYSCONFIGDATA_NAME='_sysconfigdata__linux_x86_64-linux-gnu'
dh_auto_install --sourcedirectory=src/python -- PYTHON=python3.8

Note that it also works WITHOUT the set at all.
Per the commit that added it this is for an FTCBFS => https://salsa.debian.org/debian/libseccomp/commit/3e16ede54bbcce6238e542d043821cabcc6a343e#8756c63497c8dc39f7773438edf53b220c773f67_31_29

I now wonder, does python 3.8 need to be fixed or the d/rules of libseccomp or both.

[Christian Ehrhardt  (paelzer)]

Lol, after completing the python 3.8 fight I'm back at step #2
Arm fails the build still missing __NR_open

15-basic-resolver.c:58:46: error: ‘__NR_open’ undeclared (first use in this function)
   58 | if (seccomp_syscall_resolve_name("open") != __NR_open)

Interim state of the branch pushed to https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+ref/fix-ftbfs-1849785-focal
Discussion along the same at the MP
https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/375205

[Christian Ehrhardt  (paelzer)]

The new issue was discussed upstream already [1] and has a PR [2] this is targetted at v2.5, but we might pick just the fix [3] for now.

[1]: https://github.com/seccomp/libseccomp/issues/184
[2]: https://github.com/seccomp/libseccomp/pull/182
[3]: https://github.com/seccomp/libseccomp/pull/182/commits/35803ceb43c453762a3ab5177c5f8d5dbb813478

[Christian Ehrhardt  (paelzer)]

MP for Ubuntu: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/375205
PR for Debian: https://salsa.debian.org/debian/libseccomp/merge_requests/1

[Christian Ehrhardt  (paelzer)]

Debian accepted my MR and 2.4.2 is there.
Unfortunately due to bug 1852389 I had to realize that I can't make it a sync yet.
I prepared a MP for a proper merge in https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/375472

[Launchpad Janitor (janitor)]

This bug was fixed in the package libseccomp - 2.4.2-2ubuntu1

---------------
libseccomp (2.4.2-2ubuntu1) focal; urgency=medium

  * Merge with Debian unstable (LP: 1849785). Remaining changes:
    * Add autopkgtests
  * Dropped changes (in upstream now):
    - db-properly-reset-attribute-state.patch
    - Updated to new upstream 2.4.1 version to fix security issue.
    - add-log-action.patch: Minimal backport to support the
      SECCOMP_RET_LOG action that was released in Linux kernel version
      4.14.
  * Dropped changes (in Debian now):
    - debian/tests/testsuite-live:
      - build utils with -pthread
      - build tools/scmp_api_level
    - debian/control: add valgrind to Build-Depends to get more unit tests.
    - debian/*.install: change python paths.
    - debian/libseccomp2.symbols: added new symbols.
    - debian/rules: add dh_auto_configure before dh_auto_install to pick up
      all the python versions.
    - debian/patches/*: removed, all included in new version.

libseccomp (2.4.2-2) unstable; urgency=medium

  [ Christian Ehrhardt ]
  * d/rules: fix potential FTFBS after full python3 switch
  * d/t/control: drop python2 test following the removal of the package

  [ Felix Geyer ]
  * Remove build-dependency on valgrind for mips64el as it's broken there.
  * Backport patch to define __SNR_ppoll again.
    - Add api_define__SNR_ppoll_again.patch
  * Replace custom patch for cython3 with the upstream fix.

libseccomp (2.4.2-1) unstable; urgency=medium

  [ Christian Ehrhardt ]
  * New upstream release 2.4.2 for compatibility with newer kernels and
    fixing FTBFS (LP: #1849785).
    - drop d/p/python_install_dir.patch (now upstream)
    - d/rules: adapt to python 3.8 lacking the m modifier on includes
      see https://wiki.debian.org/Python/Python3.8
    - d/p/tests-rely-on-__SNR_xxx-instead-of-__NR_xxx-for-sysc.patch: fix
      build time test on arm64

  [ Felix Geyer ]
  * Drop Python 2 bindings. (Closes: #936917)
    - Add cython3.patch to use the Python 3 cython variant.

libseccomp (2.4.1-2) unstable; urgency=medium

  * Remove build-dependency on valgrind for mipsel and x32 as it's broken
    on those archs.
  * Set Rules-Requires-Root: no.

libseccomp (2.4.1-1) unstable; urgency=medium

  * New upstream release.
    - Addresses CVE-2019-9893 (Closes: #924646)
  * Drop all patches for parisc arch support, merged upstream.
  * Build-depend on valgrind to run more unit tests.
  * Run dh_auto_configure for every python 3 version to install the extension
    in the correct path.
  * Update the symbols file.
  * Adapt autopkgtest to new upstream version:
    - Build against pthread
    - Build scmp_api_level tool
  * Upgrade to debhelper compat level 12.
    - Add d/not-installed file
  * Fix install path of the python module.
    - Add python_install_dir.patch
  * Add autopkgtest for python packages.

 -- Christian Ehrhardt <email address hidden> Wed, 13 Nov 2019 08:41:54 +0100

[Christian Ehrhardt  (paelzer)]

An SRU for just a FTBFS seems wrong.
Even keeping it forever in block-proposed seems wrong.

The fixes are known and ready for whoever does a real upload.
The most likely upload is a full backport of the new version which already includes the fixes.

For whoever does an upload to Eoan what you need is at:
Git: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+ref/fix-ftbfs-1849785-eoan
PPA: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3875

[Robie Basak (racb)]

FWIW, I don't see an issue leaving an FTBFS fix in block-proposed-eoan here.

Removing server-next as that tag is no longer relevant to this bug.

[Brian Murray (brian-murray)]

The Eoan Ermine has reached end of life, so this bug will not be fixed for that release