On Mon, Jan 20, 2020 at 4:53 AM Martin Hundebøll <mar...@geanix.com> wrote: > > On 18/10/2019 23.28, Richard Purdie wrote: > > On Fri, 2019-10-18 at 18:03 +0530, Khem Raj wrote: > >> > >> > >> On Fri, Oct 18, 2019 at 4:58 PM Ross Burton <ross.bur...@intel.com> > >> wrote: > >>> file will automatically enable seccomp if the seccomp headers are > >>> available, but > >>> the build will fail on Opensuse Tumbleweed because the include > >>> paths are wrong. > >>> > >>> Enabling seccomp is a bad idea because it interacts badly with > >>> pseudo (causing > >>> build failures), so explicitly and globally disable seccomp. > >>> > >>> Signed-off-by: Ross Burton <ross.bur...@intel.com> > >>> --- > >>> meta/recipes-devtools/file/file_5.37.bb | 2 ++ > >>> 1 file changed, 2 insertions(+) > >>> > >>> diff --git a/meta/recipes-devtools/file/file_5.37.bb > >>> b/meta/recipes-devtools/file/file_5.37.bb > >>> index a840dbc012b..c53a120b840 100644 > >>> --- a/meta/recipes-devtools/file/file_5.37.bb > >>> +++ b/meta/recipes-devtools/file/file_5.37.bb > >>> @@ -21,6 +21,8 @@ S = "${WORKDIR}/git" > >>> > >>> inherit autotools update-alternatives > >>> > >>> +EXTRA_OECONF += "--disable-libseccomp" > >>> + > >> > >> On host it makes sense but how about for target recipe ? We do have > >> libseccomp support > >> Perhaps it’s best to disable it for native and native sdk alone ? > > > > Given the problem reports in the media and the decisions made by most > > other distros I think disabling this is probably safest until its been > > make more usable (no other distro is shipping this enabled now). > > Arch Linux enabled libseccomp as of today: > > https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/file&id=a52fa0a37bad1f4ab67a934a4e0025e70aa1fd0e > > This breaks the use of `file` in do_package(): > > ERROR: base-files-3.0.14-r89 do_package: Fatal errors occurred in > subprocesses: > > Command '['file', '-b', > '/home/martin/clients/connectedcars/yocto/build/tmp-glibc/work/iwg26-oe-linux-gnueabi/base-files/3.0.14-r89/package/etc/skel/.profile']' > died with <Signals.SIGSYS: 31>.: Traceback (most recent call last): > > File > "/home/martin/clients/connectedcars/yocto/poky/meta/lib/oe/utils.py", > line 272, in run > > ret = self._target(*self._args, **self._kwargs) > > File > "/home/martin/clients/connectedcars/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.8/subprocess.py", line 411, in check_output > > return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, > > File "/usr/lib/python3.8/subprocess.py", line 512, in run > > > raise CalledProcessError(retcode, process.args, > > subprocess.CalledProcessError: Command '['file', '-b', > '/home/martin/clients/connectedcars/yocto/build/tmp-glibc/work/iwg26-oe-linux-gnueabi/base-files/3.0.14-r89/package/etc/skel/.profile']' > died with <Signals.SIGSYS: 31>. > > Disabling libseccomp sandboxing at runtime fixes it for me: > > diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py > > index efd36b3758..bc46d7c27c 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", "-S", "-b", path], > stderr=subprocess.STDOUT).decode("utf-8") >
pseudo needs some love since it alters syscalls which go out of bounds what is allowed by libseccomp until then pin your file version to 5.37 in arch till a supported distro is affected by same problem. It wont be long better option is to fix pseudo > > > if "ELF" in result: > > exec_type |= 1 > > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core