due to the revbump of sys-apps/file-5.40-r1, my ~ARCH systems tried to rebuild sys-apps/file and some of them have failed reproducibly. specifically affected are: ~x86 and ~arm ~arm64 is not affected and emerges just fine. however, setting USE="-seccomp" let both ~arm and ~x86 also succeed. It does not seem to be sys-apps/file version dependent, as also trying older package versions of it, all fail merging at the very same point > .. > Making all in magic > make[2]: Entering directory '/var/tmp/portage/sys-apps/file-5.40-r1/work/file-5.40-abi_x86_32.x86/magic' > ../src/file -C -m magic > make[2]: *** [Makefile:843: magic.mgc] Bad system call > make[2]: Leaving directory '/var/tmp/portage/sys-apps/file-5.40-r1/work/file-5.40-abi_x86_32.x86/magic' > make[1]: *** [Makefile:459: all-recursive] Error 1 > .. respectively: > .. > Making all in magic > make[2]: Entering directory '/var/tmp/portage/sys-apps/file-5.40-r1/work/file-5.40-.arm/magic' > ../src/file -C -m magic > make[2]: *** [Makefile:843: magic.mgc] Bad system call > make[2]: Leaving directory '/var/tmp/portage/sys-apps/file-5.40-r1/work/file-5.40-.arm/magic' > make[1]: *** [Makefile:459: all-recursive] Error 1 > .. though, interactively enter /var/tmp/portage/sys-apps/file-5.40-r1/work/file-5.40-*/magic afterwards and calling `make` there, does not lead to any error. there seems to be some mismatch in seccomp'ing within the build sandbox and the real system. Also two points that hint to seccomp: * merging it with: # USE="-seccomp" emerge sys-apps/file -> succeeds * merging it with: # USE="seccomp" emerge sys-apps/file -> fails, and writes to kmesg: > [1772755.646078] audit: type=1326 audit(1619035681.197:9): auid=0 uid=250 gid=250 ses=5 pid=11965 comm="lt-file" exe="/var/tmp/portage/sys-apps/file-5.40-r1/work/file-5.40-.arm/src/.libs/lt-file" sig=31 arch=40000028 syscall=327 compat=0 ip=0x76e56160 code=0x0 respectively: > [199683.827731] audit: type=1326 audit(1619035756.502:7): auid=0 uid=250 gid=250 ses=5 subj=kernel pid=19440 comm="file" exe="/var/tmp/portage/sys-apps/file-5.40-r1/work/file-5.40-abi_x86_32.x86/src/.libs/file" sig=31 arch=40000003 syscall=300 compat=0 ip=0xb7f15549 code=0x0 Reproducible: Always
*** Bug 784860 has been marked as a duplicate of this bug. ***
1) if you can, please strace the failing file invocation during build 2) please post emerge —-info from failing and successful builds (make clear which) 3) post build.logs too 4) please try this patch which I’ve been meaning to file a bug to include: https://github.com/file/file/commit/abcd583135bb0762e6bfd0f2e06c50bea1fb3cd0 (put it in /etc/portage/patches/sys-apps/file)
(I’m on mobile so can’t check easily but that dmesg snippet may be enough. Please tell us which arch it is from though because syscall numbers vary. So, to reiterate, please make clear which output is from which system.)
first is from ~arm - second from ~x86 (also identifiable from the exe=/var/tmp/portage/..)
(In reply to Christian Bricart from comment #4) > first is from ~arm - second from ~x86 (also identifiable from the > exe=/var/tmp/portage/..) I did mention I’m on mobile :) Anyway, the information is still needed to figure out which syscall table to check (kernel version)
no hurry on mobile :) ~x86 is:1 > Linux version 5.11.15-gentoo-eeebox-4 (root@eeebox) (i686-pc-linux-gnu-gcc-10.3.0 (Gentoo 10.3.0 p1) 10.3.0, GNU ld (Gentoo 2.35.2 p1) 2.35.2) #1 SMP Mon Apr 19 11:22:16 CEST 2021 ~arm uses upstream git checkout from github.com/raspberrypi/linux - rpi-5.10.y branch: > Linux version 5.10.25-v7+ (root@pi) (armv7a-unknown-linux-gnueabihf-gcc (Gentoo 10.2.0-r5 p6) 10.2.0, GNU ld (Gentoo 2.35.2 p1) 2.35.2) #7 SMP Thu Apr 1 03:25:52 CEST 2021
meanwhile, I've tried your patch from 4) - no change, still does not merge on both arches. actually, the patch mentiones "ARM64" - though, these failing arches are "armv7l" and "x86". sorry- I do not have an arm64 on hand.
manged to patch strace into the failing invocation. uploading both failing build.log
Created attachment 701556 [details] strace'ed build log from ~arm
Created attachment 701559 [details] strace'ed build.log from ~x86
Created attachment 701565 [details] successful strace'ed build.log from x86 tried re-merging (with strace) on a stable x86 host -> success
Created attachment 701568 [details] successful strace'ed build.log from x86 re-merged with LC_ALL=C ..
I would like to confirm this exact same bug on my x86 gentoo system USE="-seccomp" emerge sys-apps/file indeed compiles fine
It would be really helpful to have emerge --info from a failing system. I am especially interested in the glibc version.
Created attachment 702021 [details] emerge --info
Created attachment 702024 [details] file-5.40-r1 build.log build.log
It looks like the fstatat64 syscall is coming from sys-apps/sandbox.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0813d843cb2a43c748fdf6c9d5ac6dc882104dcf commit 0813d843cb2a43c748fdf6c9d5ac6dc882104dcf Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2021-04-23 19:10:09 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2021-04-23 19:10:09 +0000 sys-apps/file: allow faccessat and fstatat64 syscalls Closes: https://bugs.gentoo.org/784857 Signed-off-by: Mike Gilbert <floppym@gentoo.org> .../{file-5.40-r1.ebuild => file-5.40-r2.ebuild} | 2 ++ .../file/files/file-5.40-seccomp-faccessat.patch | 34 ++++++++++++++++++++++ .../file/files/file-5.40-seccomp-fstatat64.patch | 29 ++++++++++++++++++ 3 files changed, 65 insertions(+)
thank you Mike, the patches indeed fixed emerging with =sys-apps/file-5.40-r2 both on ~arm and ~x86 However, you will also have to backport this to (stable) =sys-apps/file-5.39-r4 which still fails to merge. thank you
(In reply to Christian Bricart from comment #19) I was unable to reproduce the issue on a stale x86 system. I suspect it only happens when sys-apps/sandbox has been compiled against glibc-2.33.
you are correct for a fully stable system. Though I've just also tried to explicitly emerge =sys-apps/file-5.39-r4 on a otherwise fully ~arm and also otherwise fully ~x86 system. And that obviously fails too. So I've thought it should be functional in any combination one may think of
it should not require a revbump for the stable package though
We do not require that stable packages function correctly with unstable dependencies. Regardless, I opened bug 785292 to stabilize the new version of sys-apps/file.
