abuild issueshttps://gitlab.alpinelinux.org/alpine/abuild/-/issues2024-03-24T16:17:48Zhttps://gitlab.alpinelinux.org/alpine/abuild/-/issues/9016Support GnuPG public keys as an alternative to checksums2024-03-24T16:17:48ZalgitbotSupport GnuPG public keys as an alternative to checksumsSigned packages provide more security than checksums, e.g. in the case
of corrupt mirrors or download sites.
The private key is only owned by the devs or release managers. All users
can use the well known public key to verify their dow...Signed packages provide more security than checksums, e.g. in the case
of corrupt mirrors or download sites.
The private key is only owned by the devs or release managers. All users
can use the well known public key to verify their downloads. As an
additional feature, the key can be fetched from keyservers, so
corrupt/revoked keys will throw an error.
e.g. in the case of nginx:
Fetch B0F4253373F8F6F510D42178520A9993A1C052F8 in the APKBUILD and fetch
the \*.asc together with the tarball/signed git tag.
*(from redmine: issue id 9016, created on 2018-06-16)*https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10111CBUILD= abuild rootbld requires its own separate apk cache2024-03-11T10:34:28ZGhost UserCBUILD= abuild rootbld requires its own separate apk cachethe installed binaries in the root are still the 'host' binaries if an apk cache exists for them.
maybe this is an issue of apk itself?
```
$SUDO_APK add --initdb --update \
--arch $CBUILD_ARCH \
--root "$BUILD_ROOT" \
--cache-d...the installed binaries in the root are still the 'host' binaries if an apk cache exists for them.
maybe this is an issue of apk itself?
```
$SUDO_APK add --initdb --update \
--arch $CBUILD_ARCH \
--root "$BUILD_ROOT" \
--cache-dir /etc/apk/cache \
abuild alpine-base build-base git $hostdeps $builddeps \
${USE_CCACHE:+ccache}
```
this should probably not install non- --arch binaries just because they are already in the cache-dirhttps://gitlab.alpinelinux.org/alpine/abuild/-/issues/10088Versions not complying with the rules in APKBUILD2024-03-06T11:55:52ZRex PVersions not complying with the rules in APKBUILDThere are multiple packages with versions that seem to be invalid according to the APKBUILD.5.scd documentation.
For example
- `libretls` on Alpine v3.14 has a pkgver=3.3.3p1
- `sudo` on Alpine v3.12 - v3.15 has a pkgver=1.9.5p2
- `open...There are multiple packages with versions that seem to be invalid according to the APKBUILD.5.scd documentation.
For example
- `libretls` on Alpine v3.14 has a pkgver=3.3.3p1
- `sudo` on Alpine v3.12 - v3.15 has a pkgver=1.9.5p2
- `opensmtpd` on Alpine v3.11 - v3.16 has pkgver=6.6.2p1
They all seem to be missing the `_` between `p` and the number before it. Is the APKBUILD.5.scd documentation outdated and these version should be allowed, or are these all typos and invalid versions?https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10119No validation on metadata fields can break packages2024-03-06T10:42:58ZKevin DaudtNo validation on metadata fields can break packagesIt's possible to provide random data via `install_if` (and potentially other metadata fields), that are fed directly to the package control data, which in turn will break the index (package file format error).
Should we add validation t...It's possible to provide random data via `install_if` (and potentially other metadata fields), that are fed directly to the package control data, which in turn will break the index (package file format error).
Should we add validation to those fields so that we know it's not garbage?
[This commit](https://gitlab.alpinelinux.org/alpine/aports/-/commit/f369e4491da4?page=3#e911b71f2354d6e19257e8f730e5328e955f4e0f_66_68) for example set `install_if` to:
```
install_if="$
# The group tag is just to easily find this APKBUILD by some scripts for automation
# group=kde-applications
```
which was fed directly into the apk .PKGINFO file:
```
install_if = $ # The group tag is just to easily find this APKBUILD by some scripts for automation # group=kde-applications pkgname=23.04.3-r1 nftables
```
and the package was successfully added to the index. But afterwards, any attempt to add new packages to the index failed with:
```
>>> kdeconnect: Updating the community/s390x repository index...
ERROR: kdeconnect-nftables-23.04.3-r1.apk: package file format error
>>> ERROR: kdeconnect: Failed to create index
```
After fixing the packages, this was fixed by removing the old package from the index with `abuild cleanoldpkg; abuild cleanpkg` and building it again.https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10121checkapk: false positive in soname rebuild detection2024-03-04T18:32:21ZJ0WIcheckapk: false positive in soname rebuild detection!223 reports that packages need to get rebuild, even if they only depend on the major version in the soname and only the exact version changed. See example below.
https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1165098
```log
--- ...!223 reports that packages need to get rebuild, even if they only depend on the major version in the soname and only the exact version changed. See example below.
https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1165098
```log
--- filelist-armadillo-old
+++ filelist-armadillo-new
@@ -2,4 +2,4 @@
usr/
usr/lib/
usr/lib/libarmadillo.so.12
-usr/lib/libarmadillo.so.12.6.5
+usr/lib/libarmadillo.so.12.6.6
SODIFF:
-usr/lib/libarmadillo.so.12.6.5: SONAME libarmadillo.so.12
+usr/lib/libarmadillo.so.12.6.6: SONAME libarmadillo.so.12
REBUILDS:
*** 2 packages linked against libarmadillo.so.12 need to be rebuild!
```
```sh
$ apk search -r --origin --exact -q so:libarmadillo.so.12.6.5
$ apk search -r --origin --exact -q so:libarmadillo.so.12.6
$ apk search -r --origin --exact -q so:libarmadillo.so.12
armadillo
gdal
```https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10127apk2 includes uid/gid from build system2024-02-13T11:02:37ZSertonixapk2 includes uid/gid from build systemThe apk archive includes uid/gid from the system it was build on. This is system dependent and differs if rootbld is used or not.
It would be nice to exclude that information to increase consistency. Especially for reproducible builds t...The apk archive includes uid/gid from the system it was build on. This is system dependent and differs if rootbld is used or not.
It would be nice to exclude that information to increase consistency. Especially for reproducible builds this needs to be consistent.
Tar has the options `--owner=0 --group=0` which do standardize the uid/gid. The problem is that they also reset the username and groupname in the tar archive. These are needed by apk.
The issue could probably be fixed with the `--owner-map` and `--group-map` options but I haven't figured out how.https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10131`default_static()` does not add `-dev` to `depends`2024-02-13T10:21:09ZCeleste`default_static()` does not add `-dev` to `depends`[`default_static()` from abuild](https://gitlab.alpinelinux.org/alpine/abuild/-/blob/3.12.0/abuild.in#L2077-L2103) has some code to add a `depends=` on the `-dev` subpackage (which contains header files), but that doesn't work, resulting...[`default_static()` from abuild](https://gitlab.alpinelinux.org/alpine/abuild/-/blob/3.12.0/abuild.in#L2077-L2103) has some code to add a `depends=` on the `-dev` subpackage (which contains header files), but that doesn't work, resulting in all `-static` subpackages not depending on the corresponding `-dev`.
I looked into this issue, and found that it's caused by [`subpackages_has()` checking `$subpackages`](https://gitlab.alpinelinux.org/alpine/abuild/-/blob/3.12.0/abuild.in#L2688) which is [empty while handling subpackages](https://gitlab.alpinelinux.org/alpine/abuild/-/blob/3.12.0/abuild.in#L2981).
This issue would also affect everything that calls `subpackages_has` during the handling of subpackages, but i haven't investigated this further.https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10094rootbld cannot create groups from pkggroups=2023-12-27T09:15:30ZGhost Userrootbld cannot create groups from pkggroups=with a `pkggroups=pipewire`
```
>>> pipewire: Unpacking /var/cache/distfiles/pipewire-0.3.66.tar.gz...
>>> pipewire: Creating group pipewire
abuild-addgroup: User demon is not a member of group abuild
>>> ERROR: pipewire: mkusers faile...with a `pkggroups=pipewire`
```
>>> pipewire: Unpacking /var/cache/distfiles/pipewire-0.3.66.tar.gz...
>>> pipewire: Creating group pipewire
abuild-addgroup: User demon is not a member of group abuild
>>> ERROR: pipewire: mkusers failed
>>> ERROR: pipewire: rootbld failed
```
the actual (host) user is in `abuild`https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10123rootless abuild2023-12-12T22:15:38ZSertonixrootless abuildIs there a way to run abuild without requiring root privileges (including no setuid)? Maybe with proot or fakeroot/fakechroot?
I thought rootbld would do that but now I found that I kind of backdoored my system with setuid binaries.
ap...Is there a way to run abuild without requiring root privileges (including no setuid)? Maybe with proot or fakeroot/fakechroot?
I thought rootbld would do that but now I found that I kind of backdoored my system with setuid binaries.
apk-tools#10779, is related. #10094 also a bit.https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10107amove cannot handle paths with spaces2023-12-12T21:39:40ZGhost Useramove cannot handle paths with spaces```
amove "usr/share/Folder Name/abc"
```
^ fails```
amove "usr/share/Folder Name/abc"
```
^ failshttps://gitlab.alpinelinux.org/alpine/abuild/-/issues/10124Feature suggestion: make default snapshot() do a recursive git checkout2023-11-16T10:03:30ZDaniel FancsaliFeature suggestion: make default snapshot() do a recursive git checkoutIt would be nice, if the default snapshot() implementation would consider the git submodules too.It would be nice, if the default snapshot() implementation would consider the git submodules too.https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10122sanitycheck contributor email formatting2023-11-08T23:54:09ZJacob Ludvigsensanitycheck contributor email formattingMaintainer email address is checked, and a malformed address triggers a sanitycheck error.
This is not the case with a malformed contributor email address.Maintainer email address is checked, and a malformed address triggers a sanitycheck error.
This is not the case with a malformed contributor email address.https://gitlab.alpinelinux.org/alpine/abuild/-/issues/9997Follow XDG Base Directory specifications2023-10-24T01:52:52ZBart RibbersFollow XDG Base Directory specificationsCurrently abuild write it's config file and build keys to `~/.abuild`, and puts generated packages in `~/packages`. It would be nice if it would use [the XDG Base Directory specification](https://specifications.freedesktop.org/basedir-sp...Currently abuild write it's config file and build keys to `~/.abuild`, and puts generated packages in `~/packages`. It would be nice if it would use [the XDG Base Directory specification](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) instead so it doesn't clutter the `$HOME` directory.
The config file would go to `~/.config/abuild/abuild.conf` (if `$XDG_CONFIG_DIR` isn't set) and the keys and packages to `~/.local/share/abuild` (if `$XDG_DATA_DIRS` isn't set).https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10117Tool to resign packages2023-10-21T01:10:24ZCarl ChaveTool to resign packagesFrom IRC:
```
2023-06-29 02:44:47 <smcavoy> is there a quick way to re-sign a package? I'd rather that then rebuild (2hr build time) with the new key...
...
2023-06-29 08:52:35 <ncopa> i think we need a tool to resign packages
```From IRC:
```
2023-06-29 02:44:47 <smcavoy> is there a quick way to re-sign a package? I'd rather that then rebuild (2hr build time) with the new key...
...
2023-06-29 08:52:35 <ncopa> i think we need a tool to resign packages
```https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10069functions.sh: APORTSDIR has subpar defaults and does not detect in a lot of c...2023-10-17T14:02:20ZGhost Userfunctions.sh: APORTSDIR has subpar defaults and does not detect in a lot of cases.rootbld_repositories (used in rootbld or during bootstrapping), is set from `$repo_template`, and that is sourced from:
```
repo_template=$aportsgit/$repo/.rootbld-repositories
```
where `$aportsgit` is:
```sh
APORTSDIR=${_APORT....rootbld_repositories (used in rootbld or during bootstrapping), is set from `$repo_template`, and that is sourced from:
```
repo_template=$aportsgit/$repo/.rootbld-repositories
```
where `$aportsgit` is:
```sh
APORTSDIR=${_APORTSDIR-$APORTSDIR}
gitbase=$(git rev-parse --show-toplevel 2>/dev/null) || true # already is -P
if [ -d "$APORTSDIR" ]; then
APORTSDIR=$(cd "$APORTSDIR"; pwd -P)
elif [ -z "$APORTSDIR" ] && [ -d "$HOME/aports" ]; then
APORTSDIR=$(cd "$HOME/aports"; pwd -P)
else
if [ -n "$gitbase" ]; then
case $(git remote get-url origin) in
# '.git' for SSH URLs, and no suffix for HTTPS URLs
*/aports|*/aports.git) APORTSDIR=$gitbase ;;
*) APORTSDIR= ;;
esac
else
APORTSDIR=
fi
fi
```
this fails to detect anything that has a trailing slash (for instance a url such as `https://gitlab.alpinelinux.org/
alpine/aports.git/`).
since we already check for a manual setting, and for `$HOME/aports`, etc.. perhaps it makes sense to simply set it to $gitbase as a fallback instead of checking the remotes at all? this also prevents it from working in custom third party repos, because those usually don't have 'aports' in their urls, and it's annoying to need to export APORTSDIR all the time.https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10114abuild-sign: support remote signing2023-06-11T09:37:38ZNatanael Copaabuild-sign: support remote signingIt would be nice if we could have a remote signing service so we don't need to have the private key available on each builder.
The service could be a simple https server, which uses client certificates.
The client (abuild-sign) would P...It would be nice if we could have a remote signing service so we don't need to have the private key available on each builder.
The service could be a simple https server, which uses client certificates.
The client (abuild-sign) would POST the `control.tar.gz` file (using curl?) and get a signature in return.Kevin DaudtKevin Daudthttps://gitlab.alpinelinux.org/alpine/abuild/-/issues/10113debug appended twice in rootbld2023-06-05T06:19:20ZGhost Userdebug appended twice in rootbldthis is top-level:
```
# if we want build debug package
if [ -n "$DEBUG" ] || subpackage_types_has "dbg"; then
CFLAGS="$CFLAGS -g"
CXXFLAGS="$CXXFLAGS -g"
DFLAGS="$DFLAGS -g"
options="$options !strip"
fi
```
so when rootbld is u...this is top-level:
```
# if we want build debug package
if [ -n "$DEBUG" ] || subpackage_types_has "dbg"; then
CFLAGS="$CFLAGS -g"
CXXFLAGS="$CXXFLAGS -g"
DFLAGS="$DFLAGS -g"
options="$options !strip"
fi
```
so when rootbld is used, it executes, then again on rootbld re-exec (-g -g)
this breaks an assumption in aports that e.g. `${CFLAGS/-g/-g1}` works (only replaces first), but should probably not append twicehttps://gitlab.alpinelinux.org/alpine/abuild/-/issues/10097PIE check2023-06-03T12:37:08ZGhost UserPIE checkcurrently, non-PIE binaries are not flagged/detected. perhaps they should be?
either a warning or a failure with options="!pie" would workcurrently, non-PIE binaries are not flagged/detected. perhaps they should be?
either a warning or a failure with options="!pie" would workhttps://gitlab.alpinelinux.org/alpine/abuild/-/issues/10083abuild: check version format when generating pc: depends2023-06-03T10:47:45ZPatrycja Rosaalpine@ptrcnull.meabuild: check version format when generating pc: dependssince https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/a6126a6f2362ee47e91acb25083e1b112a57640a, packages with invalid depends versions fail `apk index`; this is an issue, because some pkgconfig versions are not valid apk version...since https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/a6126a6f2362ee47e91acb25083e1b112a57640a, packages with invalid depends versions fail `apk index`; this is an issue, because some pkgconfig versions are not valid apk versions, like so:
```
depend = pc:gsettings-desktop-schemas>=40.alpha
```https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10095package() step getting corrumpted file2023-06-03T04:00:59ZFabricio Silvahi@fabricio.devpackage() step getting corrumpted fileConsider this APKBUILD https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/44628/diffs#929507b7288ff63088918552e2a55a9ff5a2e0e6
When I do `abuild -r` or `abuild rootpkg` its generating/copying a corrupted file from my build() ...Consider this APKBUILD https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/44628/diffs#929507b7288ff63088918552e2a55a9ff5a2e0e6
When I do `abuild -r` or `abuild rootpkg` its generating/copying a corrupted file from my build() step.
```bash
alpine:~/aports/testing/recyclarr$ abuild rootpkg
>>> recyclarr: Entering fakeroot...
>>> recyclarr*: Running postcheck for recyclarr
>>> recyclarr*: Preparing package recyclarr...
>>> recyclarr*: Stripping binaries
>>> recyclarr*: Scanning shared objects
>>> recyclarr*: Tracing dependencies...
dotnet7-runtime
so:libc.musl-x86_64.so.1
so:libgcc_s.so.1
so:libstdc++.so.6
>>> recyclarr*: Package size: 2.0 KB
>>> recyclarr*: Compressing data...
>>> recyclarr*: Create checksum...
>>> recyclarr*: Create recyclarr-4.3.0-r0.apk
alpine:~/aports/testing/recyclarr$ ls -la pkg/recyclarr/usr/sbin/
total 58
drwxr-xr-x 2 fabricio fabricio 3 Feb 28 09:25 .
drwxr-sr-x 3 fabricio fabricio 3 Feb 28 09:25 ..
-rwxr-xr-x 1 fabricio fabricio 78320 Feb 28 09:25 recyclarr
```
(look to the file size 78320)
But If you do the manually steps, I can see that until the `abuild build` step, my binary is right there and has correct size (and it works if I execute it)
```bash
alpine:~/aports/testing/recyclarr$ abuild unpack
>>> recyclarr: Fetching recyclarr-4.3.0.tar.gz::https://github.com/recyclarr/recyclarr/archive/refs/tags/v4.3.0.tar.gz
>>> recyclarr: Checking sha512sums...
recyclarr-4.3.0.tar.gz: OK
0001-disable-gitversion.patch: OK
>>> recyclarr: Unpacking /var/cache/distfiles/recyclarr-4.3.0.tar.gz...
alpine:~/aports/testing/recyclarr$ abuild prepare
>>> recyclarr: 0001-disable-gitversion.patch
patching file src/Directory.Build.props
patching file src/Recyclarr.Cli/Program.cs
Hunk #1 succeeded at 81 (offset -1 lines).
alpine:~/aports/testing/recyclarr$ abuild build
MSBuild version 17.4.1+fedecea9d for .NET
Determining projects to restore...
All projects are up-to-date for restore.
Recyclarr.Common -> /home/fabricio/aports/testing/recyclarr/src/recyclarr-4.3.0/src/Recyclarr.Common/bin/Release/net7.0/Recyclarr.Common.dll
Recyclarr.TrashLib -> /home/fabricio/aports/testing/recyclarr/src/recyclarr-4.3.0/src/Recyclarr.TrashLib/bin/Release/net7.0/Recyclarr.TrashLib.dll
Recyclarr.Cli -> /home/fabricio/aports/testing/recyclarr/src/recyclarr-4.3.0/src/Recyclarr.Cli/bin/Release/net7.0/linux-musl-x64/recyclarr.dll
Recyclarr.Cli -> /home/fabricio/aports/testing/recyclarr/src/recyclarr-4.3.0/publish/
alpine:~/aports/testing/recyclarr$ ls -la src/recyclarr-4.3.0/publish/
total 3734
drwxr-sr-x 2 fabricio fabricio 3 Feb 28 09:13 .
drwxr-sr-x 10 fabricio fabricio 23 Jan 22 20:51 ..
-rwxr-xr-x 1 fabricio fabricio 6561208 Feb 28 09:36 recyclarr
```
(look to the file size 6561208)
If I run the `abuild rootpkg` now it returns the first statement I show with wrong binary.
I have tried to touch the package() instructions, nothing have work yet. Any advise in what could Im doing wrong?