The Eoan Ermine has reached end of life, so this bug will not be fixed
for that release
** Changed in: libseccomp (Ubuntu Eoan)
Status: Fix Committed => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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.
** Tags removed: server-next
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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
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):
-
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
--
You received this bug notification
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/375429
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1849785
Title:
FTBFS on
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
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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
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]:
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:
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'
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
The full 2.4.2 release also fails with:
Traceback (most recent call last):
File "./setup.py", line 28, in
from Cython.Distutils import build_ext
File "/usr/lib/python3/dist-packages/Cython/Distutils/__init__.py", line 1,
in
from Cython.Distutils.build_ext import build_ext
File
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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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 "", line 20, in
File "/usr/lib/python3.8/sysconfig.py", line 512, in get_path
return get_paths(scheme, vars,
Continues to FTFBS in LP infra today :-/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1849785
Title:
FTBFS on i386/ppc64/s390x (Eoan+Focal)
To manage notifications about this bug go to:
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
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
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)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
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
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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
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
--
You
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 },
--
You received this bug
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/375205
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1849785
Title:
FTBFS on
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
** Tags added: server-next
--
You received this bug notification because you are a member of
** Changed in: libseccomp
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1849785
Title:
FTBFS on i386/ppc64/s390x (Eoan+Focal)
To manage notifications about this
blocking the intro of python3.8
** Tags added: rls-ff-incoming
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1849785
Title:
FTBFS on i386/ppc64/s390x (Eoan+Focal)
To manage notifications about
** Changed in: libseccomp
Status: Unknown => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1849785
Title:
FTBFS on i386/ppc64/s390x (Eoan+Focal)
To manage notifications about this bug
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.
** Changed in: libseccomp (Ubuntu)
Importance: Undecided => Medium
** Changed in: libseccomp (Ubuntu
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
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
And as usual once you know what you search:
=> https://github.com/seccomp/libseccomp/issues/166
** Bug watch added: github.com/seccomp/libseccomp/issues #166
https://github.com/seccomp/libseccomp/issues/166
** Also affects: libseccomp via
https://github.com/seccomp/libseccomp/issues/166
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
->
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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1849785
Title:
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
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
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
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,
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
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
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-1 result: SUCCESS
...
Test 36-sim-ipc_syscalls%%025-1 result: SKIPPED (only
39 matches
Mail list logo
