If the yocto host system has seccomp provisions, any packaging command will fail with the following (example): Command '['file', '-b', '/home/juro/yocto/poky/build-thud/tmp/work/armv5e-poky-linux-gnueabi/file/5.34-r0/package/usr/lib/libmagic.so.1.0.0']' died with <Signals.SIGSYS: 31>.: Traceback (most recent call last): File "/home/juro/yocto/poky/meta/lib/oe/utils.py", line 272, in run ret = self._target(*self._args, **self._kwargs) File "/home/juro/yocto/poky/meta/lib/oe/package.py", line 70, in is_elf result = subprocess.check_output(["file", "-b", path], stderr=subprocess.STDOUT).decode("utf-8") File "/usr/lib/python3.7/subprocess.py", line 395, in check_output **kwargs).stdout File "/usr/lib/python3.7/subprocess.py", line 487, in run output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['file', '-b', '/home/juro/yocto/poky/build-thud/tmp/work/armv5e-poky-linux-gnueabi/file/5.34-r0/package/usr/lib/libmagic.so.1.0.0']' died with <Signals.SIGSYS: 31>. ERROR: file-5.34-r0 do_package: Function failed: split_and_strip_files This patch fixes the problem: =================== diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py index efd36b3758..38afeb4244 100644 --- a/meta/lib/oe/package.py +++ b/meta/lib/oe/package.py @@ -67,7 +67,7 @@ def is_kernel_module_signed(path): # 16 - kernel module def is_elf(path): exec_type = 0 - result = subprocess.check_output(["file", "-b", path], stderr=subprocess.STDOUT).decode("utf-8") + result = subprocess.check_output(["file", "-bS", path], stderr=subprocess.STDOUT).decode("utf-8") if "ELF" in result: exec_type |= 1 ===================== (see man file "S" option)
Created attachment 4464 [details] patch fixing the reported problem
Interestingly my build of file-native from master doesn't have a -S option.
On my host: $ file --version file-5.36 magic file from /usr/share/file/magic
(In reply to comment #2) > Interestingly my build of file-native from master doesn't have a -S option. The "file" being used comes from HOSTTOOLS, I am not sure why we don't use our file-native.
What host distro was this? I'm guessing Clear Linux. Can you still replicate this? There's presumably some conflict between seccomp and pseudo. I wonder if it's possible to disable seccomp in file without passing an option so we don't need to detect if seccomp is enabled before every invocation of file.
Current thinking is "can we just mandate that seccomp isn't enabled"?
(In reply to comment #6) > Current thinking is "can we just mandate that seccomp isn't enabled"? The latest "file" allows the switch -S without seccomp being available. (Up until then -S was treated as an error in that case). But it will take some time for this to percolate to all distros. So the patch I posted will not work with the old "file" package.
Yes, I saw that. It landed in file five days ago and we still support Centos 7 which is based on Fedora 19, so I don't expect to be able to assume 'file -S' works for a good few years yet.
Interestingly LWN has an article about how Debian tried enabling seccomp for file, and had to turn it off because they use fakeroot (thus, LD_PRELOAD) during package building too: https://lwn.net/SubscriberLink/796108/95ab278a062b5838/
We expect that seccomp for file does now work in general and any distro trying to do so will eventually revet that feature.
Correction: seccomp for 'file' does *not* work in general
Clear agree that seccomp is stupid and are reverting this.
GNU file and seccomp and LD_PRELOAD (thus, pseudo) just don't get on. As per comment #9 this isn't specific to us, Debian has come to the same conclusion. Clear was the only distribution that enabled seccomp in file and as of this commit it doesn't do that any more: https://github.com/clearlinux-pkgs/file/commit/74624ebb5d803a9ce7cd8c956830983f54451d41 Closing as WONTFIX. I guess an alternative would be to remove file-native from ASSUME_PROVIDED on these platforms and ensure that file-native is marked as a dependency where it is used, but I don't know if this would actually be possible.