Without this patch install would cause:
* Bad lib64 usage detected:
drwxr-xr-x 3 root root 4.0K Jan 4 06:31 /build/target/tmp/portage/dev-libs/libbpf-1.0.1/image/usr/lib64
lrwxrwxrwx 1 root root 11 Jan 4 06:31 /build/target/tmp/portage/dev-libs/libbpf-1.0.1/image/usr/lib64/libbpf.so -> libbpf.so.1
lrwxrwxrwx 1 root root 15 Jan 4 06:31 /build/target/tmp/portage/dev-libs/libbpf-1.0.1/image/usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
-rwxr-xr-x 1 root root 889K Jan 4 06:31 /build/target/tmp/portage/dev-libs/libbpf-1.0.1/image/usr/lib64/libbpf.so.1.0.1
drwxr-xr-x 2 root root 4.0K Jan 4 06:31 /build/target/tmp/portage/dev-libs/libbpf-1.0.1/image/usr/lib64/pkgconfig
-rw-r--r-- 1 root root 294 Jan 4 06:31 /build/target/tmp/portage/dev-libs/libbpf-1.0.1/image/usr/lib64/pkgconfig/libbpf.pc
* This arch (arm) should never use 'lib64'.
PR #28323 commit bd8d3b7a7f (dev-libs/libbpf: Fix install in prefix")
removed declaration of LIBDIR because it is default-initialized to:
LIBDIR ?= $(PREFIX)/$(LIBSUBDIR)
However this causes regression because while we do set:
export LIBSUBDIR="$(get_libdir)"
This does not take effect in the Makefile, because it does either one of:
LIBSUBDIR := lib64
LIBSUBDIR := lib
Environment variables don't take precedence over variables from makefiles
unless -e is given. To minimize other possible regressions I'm explicitly
whitelisting LIBSUBDIR for precedence over that from makefile.
Reported-by: Aashay Shringarpure <aashay@google.com>
Signed-off-by: YiFei Zhu <zhuyifei@google.com>
Closes: https://github.com/gentoo/gentoo/pull/28962
Signed-off-by: Sam James <sam@gentoo.org>
Set the correct appid so that wayland compositors (like Plasma and Gnome
Shell) can correctly associate blender with its .desktop file.
Signed-off-by: Sebastian Parborg <darkdefende@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Files being installed by Portage are generally trusted but also the
syscalls allowed by file are quite broad anyway.
With e.g. new libc or sandbox version (or any number of things...), the
syscalls used by file can change which leads to its seccomp filter killing
the process. This is an acceptable tradeoff when users are calling file(1),
but it makes less sense with trusted input within Portage, especially
where it may lead to confusing errors (swallowed within pipes, subshells,
etc).
Indeed, it might even be the case that file(1) is broken, but the user
needs to complete a world upgrade to get a newer file/portage/???, but
can't because of various ebuilds (like ones using this eclass) failing.
Disable seccomp for these calls to keep working.
Bug: https://bugs.gentoo.org/811462
Bug: https://bugs.gentoo.org/815877
Bug: https://bugs.gentoo.org/889046
Signed-off-by: Sam James <sam@gentoo.org>
Files being installed by Portage are generally trusted but also the
syscalls allowed by file are quite broad anyway.
With e.g. new libc or sandbox version (or any number of things...), the
syscalls used by file can change which leads to its seccomp filter killing
the process. This is an acceptable tradeoff when users are calling file(1),
but it makes less sense with trusted input within Portage, especially
where it may lead to confusing errors (swallowed within pipes, subshells,
etc).
Indeed, it might even be the case that file(1) is broken, but the user
needs to complete a world upgrade to get a newer file/portage/???, but
can't because of various ebuilds (like ones using this eclass) failing.
Disable seccomp for these calls to keep working.
Bug: https://bugs.gentoo.org/811462
Bug: https://bugs.gentoo.org/815877
Bug: https://bugs.gentoo.org/889046
Signed-off-by: Sam James <sam@gentoo.org>
Files being installed by Portage are generally trusted but also the
syscalls allowed by file are quite broad anyway.
With e.g. new libc or sandbox version (or any number of things...), the
syscalls used by file can change which leads to its seccomp filter killing
the process. This is an acceptable tradeoff when users are calling file(1),
but it makes less sense with trusted input within Portage, especially
where it may lead to confusing errors (swallowed within pipes, subshells,
etc).
Indeed, it might even be the case that file(1) is broken, but the user
needs to complete a world upgrade to get a newer file/portage/???, but
can't because of various ebuilds (like ones using this eclass) failing.
Disable seccomp for these calls to keep working.
Bug: https://bugs.gentoo.org/811462
Bug: https://bugs.gentoo.org/815877
Bug: https://bugs.gentoo.org/889046
Signed-off-by: Sam James <sam@gentoo.org>
Dennis Lamm
William Hubbs
listout
Mario Haustein
Philippe Chaintreuil
Alexander Kurakin
YiFei Zhu
Sebastian Parborg
Volkmar W. Pogatzki
Sam James
Ionen Wolkens
Sebastian Pipping
Maciej Barć