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
these have a slight runtime hit (like fortify-source), but help find
bugs early, by making programs crash on invariants that would corrupt
memory and lead to hard to debug crashes/bugs later.
these are mostly useless and redundant given the other flags. all they
do is spam more flags onto every invocation line- things don't "only"
pass cppflags for anything in the general case.
There's some extra indentation on the first sections that doesn't match
other man pages and just looks misaligned with the rest of the page.
Example from man:
```
NAME
man – display manual pages
SYNOPSIS
man [-acfhklw] [-C file] [-M path] [-m path] [-S subsection]
[[-s] section] name ...
DESCRIPTION
```
Example from newapkbuild before this patch:
```
NAME
newapkbuild - generate a new APKBUILD
SYNOPSIS
newapkbuild options... [pkgname[-pkgver] | source_url]
DESCRIPTION
```
Example for newapkbuild after this patch:
```
NAME
newapkbuild - generate a new APKBUILD
SYNOPSIS
newapkbuild options... [pkgname[-pkgver] | source_url]
DESCRIPTION
```
this fetches only things for the target triple, so it usually skips e.g.
all the windows crates.
we do this in aports already, in places where it doesn't work we just
unset it.
- -G Ninja because that is always preferred
- remove inferred trailing dot
- use =ON as that is what we usually use most of the time for true/false
- add samurai to makedeps for -G Ninja
- use flatter ctest invocation
this is a good thing to have and we should reinstate it after 3.18,
however it requires fixing a million things, which is a bit too much for
a sudden release build.
i forgot the implications of this aside from fixing strerror_r and how
much work it was, so put this back after 3.18 branch.
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