- _LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS: This macro is used to enable -Wthread-safety annotations on libc++’s std::mutex and std::lock_guard.
- _LIBCPP_ENABLE_HARDENED_MODE to enable the hardened mode.
the previous implementation had a bug that + chars needed escaping
(which was fixed), and now has another discovered but that pkgnames
could start with a number, so the /^pkg/ match matches the pkgname again
and a size comparison gives you:
>>> Size difference for 7zip: 7zip-22.01-r5 installed size: -> 7zip-23.01-r0 installed size:
using grep -F avoids any magic character expansion and works correctly
in all cases.
prior to the recent reworks, this error handling path was never
triggered, because the script is ran without pipefail, and it was at
the end of a | pipe | line | sort, so all it did was be ignored for 'new
apks', when the old one would fail to fetch and be missing.
since we now do hit this path on fetch failure however, it aborts the
script when a new subpackage/package is added (since the 'old apk' won't
exist), and doesn't output a diff. since before we always ignored this,
ignore the 'old apk' perhaps not existing, which gives the currently
intended behaviour.
when apk fetch fails (a new package is added) these just say 'gzip invalid magic' or similar, as there is no old apk to compare to.
the || die is also never triggered, as it only triggers when the sort fails, since it won't trigger on earlier pipeline steps
this needs more cleaning up, but i'll leave that for the future when i write some tests.
We can't run mkusers inside the chroot because of bwrap peculiarities.
Presently, rootbld does therefore not work at all for APKBUILDs which
use $pkggroups/$pkguser. While not polluting the host is a noble goal
it isn't really useful if it causes rootbld to be incapable of building
certain packages (i.e. those using $pkggroups/$pkguser with groups
not existent on the host).
This commit therefore restores the original behavior for now. While at
it, I also added a comment to the mkusers invocation.
See: https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10094
This reverts commit 84d7b7693d.
In abuild's getopts loop, option variables such as "keep", "verbose",
etc are only set if the corresponding option is found. If such an option
is *not* found, any environment variable with the same name will leak
in, instead. Prevent this by explicitly unsetting almost all of them.
the previous implementation used -regex, which is subtly different between busybox and findutils
[0-9]\+ matches on busybox, but doesn't match with gnu findutils
[0-9]+ matches with findutils, but doesn't match on busybox
this means python deps were subtly broken when findutils was installed
(sometimes pulled via makedeps) vs not
Similar to suid binaries, abuild will now error out if the package
includes binaries with setcap(8) capabilities but doesn't have `setcap`
in `$options`. This eases identifying package which ship binaries
with extra capabilities.
Furthermore, if these binaries are executable by others a warning is
emitted. This warning could be changed to an error in the future.
The recommendation is to make such binaries only executable by owner
and group, thereby requiring the system administrator to explicitly
add users to a specific group in order to give them accesses to these
capabilities.
See: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/45
Discussion: This change requires abuild to depend on the `libcap`
package for the `getcap` binary. It does not seem to be possible
at the moment to use scanelf(1) to identify these binaries.
jvoisin
sudotac
psykose
Iztok Fister Jr
Sören Tempel
Cowington Post
Rodrigo Lourenço
Jakub Panek
Dimitry Andric
ptrcnull
Jakub Jirutka
Timo Teräs