Otherwise the default hardcoded in abuild-fetch (var/cache/distfiles) is
used.
(in the same vein as 6864df03aa)
Fixes: 1582617 ("abuild-rootbld: clear environment for bwrap container")
the '@' characted serves as a repository separator (eg. pkg@repo) so we
should not add a cmd: provides for binaries having this character.
This avoids conflicts with for example `who` from coreutils and `who@`
from ucspi-tpc6.
fixes https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10074
This is mainly needed for alpine-baselayout which creates all
directories, and most of them are empty. The code in question
would remove directories we explicitly want alpine-baselayout
to create and own.
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.
strictly speaking, it is possible for an x86_64 cpu to run 32-bit
userspace binaries without qemu emulation. it is also possible for an
aarch64 cpu to run armhf/armv7 binaries (as long as the cpu implements
it, most do). rather than check for every possible combination of when
this is allowed (host cpu + emulated target, does cpu support it, ...),
just downgrade this case to a warning, to permit non-emulated use.
ref https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/117#note_255174
otherwise every package prints
>>> gotosocial-openrc*: Running postcheck for gotosocial-openrc
find: /builds/raspbeguy/aports/testing/gotosocial/pkg/gotosocial-openrc/usr/lib/python*: No such file or directory
the other postchecks already conditionalise on if [ -d, but we use a wildcard here
no actual package change
Sertonix
Dimitri John Ledkov
Piraty
Natanael Copa
Timo Teräs
Jingyun Hua
ptrcnull
psykose
Sören Tempel
Jakub Panek
Dimitry Andric
Haelwenn (lanodan) Monnier
Sören Tempel