apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2024-03-11T17:53:38Zhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10961apk audit ignoring owners in /etc/apk2024-03-11T17:53:38ZSertonixapk audit ignoring owners in /etc/apk`apk audit` seems to list all files in `/etc/apk` as added even though some are packaged.
All of these shouldn't be listed:
```
A etc/apk/protected_paths.d/ca-certificates.list
A etc/apk/keys/alpine-devel@lists.alpinelinux.org-5261cecb....`apk audit` seems to list all files in `/etc/apk` as added even though some are packaged.
All of these shouldn't be listed:
```
A etc/apk/protected_paths.d/ca-certificates.list
A etc/apk/keys/alpine-devel@lists.alpinelinux.org-5261cecb.rsa.pub
A etc/apk/keys/alpine-devel@lists.alpinelinux.org-5243ef4b.rsa.pub
A etc/apk/keys/alpine-devel@lists.alpinelinux.org-4a6a0840.rsa.pub
A etc/apk/keys/alpine-devel@lists.alpinelinux.org-61666e3f.rsa.pub
A etc/apk/keys/alpine-devel@lists.alpinelinux.org-6165ee59.rsa.pub
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10957Unable to read database state. Failed to open apk database2023-12-13T10:00:28ZAlexander ZhirovUnable to read database state. Failed to open apk databaseAlpine Release: 3.18.4
It is not possible to perform any manipulations with the package manager:
```
raspberry:/# apk update
ERROR: Unable to read database state: No such file or directory
ERROR: Failed to open apk database: No such fi...Alpine Release: 3.18.4
It is not possible to perform any manipulations with the package manager:
```
raspberry:/# apk update
ERROR: Unable to read database state: No such file or directory
ERROR: Failed to open apk database: No such file or directory
```
I moved the `/var` directory to a separate device. `rsync` has transferred all the necessary data. Everything works, it is mounted in `rw` mode:
```
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=10240k,nr_inodes=476386,mode=755)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)
/dev/sda2 on / type ext4 (rw,relatime,stripe=8191)
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=776824k,nr_inodes=819200,mode=755)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
/dev/sda1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
/dev/sdd1 on /var type ext4 (rw,relatime)
```
Can you tell me what the problem may be related to? I can't find any information on this issue.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10955apk version -v can not cope with longer package names2024-03-26T20:21:57ZHenrik Riomarapk version -v can not cope with longer package namesThe output from `apk version -v` does not cope with the longer package names now used in Alpine
Log
```
$ apk version -v | head -20
Installed: Available:
abseil-cpp-base-20230802.1-r0 = 20230802....The output from `apk version -v` does not cope with the longer package names now used in Alpine
Log
```
$ apk version -v | head -20
Installed: Available:
abseil-cpp-base-20230802.1-r0 = 20230802.1-r0
abseil-cpp-city-20230802.1-r0 = 20230802.1-r0
abseil-cpp-civil-time-20230802.1-r0 = 20230802.1-r0
abseil-cpp-cord-20230802.1-r0 = 20230802.1-r0
abseil-cpp-cord-internal-20230802.1-r0 = 20230802.1-r0
abseil-cpp-cordz-functions-20230802.1-r0= 20230802.1-r0
abseil-cpp-cordz-handle-20230802.1-r0 = 20230802.1-r0
abseil-cpp-cordz-info-20230802.1-r0 = 20230802.1-r0
abseil-cpp-crc-cord-state-20230802.1-r0 = 20230802.1-r0
abseil-cpp-crc-internal-20230802.1-r0 = 20230802.1-r0
abseil-cpp-crc32c-20230802.1-r0 = 20230802.1-r0
abseil-cpp-debugging-internal-20230802.1= 20230802.1-r0
abseil-cpp-die-if-null-20230802.1-r0 = 20230802.1-r0
abseil-cpp-examine-stack-20230802.1-r0 = 20230802.1-r0
abseil-cpp-exponential-biased-20230802.1= 20230802.1-r0
abseil-cpp-hash-20230802.1-r0 = 20230802.1-r0
abseil-cpp-int128-20230802.1-r0 = 20230802.1-r0
abseil-cpp-kernel-timeout-internal-20230= 20230802.1-r0
abseil-cpp-log-globals-20230802.1-r0 = 20230802.1-r0
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10954inaccurate return code / broken error propagation2024-03-11T13:54:53ZZach van Rijninaccurate return code / broken error propagation**example: broken error propagation**
Trigger exit codes do not appear to bubble up to calling applications, even if internally the `broken_script` [flag is set](https://git.adelielinux.org/adelie/apk-tools/-/blob/3890035c21e40aca7d5360...**example: broken error propagation**
Trigger exit codes do not appear to bubble up to calling applications, even if internally the `broken_script` [flag is set](https://git.adelielinux.org/adelie/apk-tools/-/blob/3890035c21e40aca7d5360bfc40e4b7ab9f10c50/src/package.c#L1036-1047).
In this example, we run one command that does not require elevated permissions, and one that does.
```
/ # adduser -D foo && cd /home/foo && su foo
~ $ mkdir x && apk add --root x --initdb && cp /etc/apk/repositories x/etc/apk
OK: 0 MiB in 0 packages
~ $ apk add --root x musl --allow-untrusted; echo $?
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/x86_64/APKINDEX.tar.gz
(1/1) Installing musl (1.2.4-r2)
OK: 0 MiB in 1 packages
0
~ $ apk add --root x mandoc --allow-untrusted; echo $?
(1/2) Installing zlib (1.2.13-r1)
(2/2) Installing mandoc (1.14.6-r8)
ERROR: 4 errors updating directory permissions
OK: 1 MiB in 3 packages
0
```
**example: inaccurate return code**
The `apk` return code may be inaccurate under certain circumstances, as it appears to rely on a combination of application runtime state as well as database state.
In this example, we run the same (problematic) command twice in a row. Under some circumstances, zero may be returned the first time, and a nonzero value on subsequent invocations.
```
/ # adduser -D foo && cd /home/foo && su foo
~ $ mkdir x && apk add --root x --initdb && cp /etc/apk/repositories x/etc/apk
OK: 0 MiB in 0 packages
~ $ apk add --root x ca-certificates --allow-untrusted; echo $?
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/x86_64/APKINDEX.tar.gz
(1/5) Installing musl (1.2.4-r2)
(2/5) Installing busybox (1.36.1-r5)
Executing busybox-1.36.1-r5.post-install
ERROR: busybox-1.36.1-r5.post-install: chroot: Operation not permitted
ERROR: busybox-1.36.1-r5.post-install: script exited with error 127
(3/5) Installing busybox-binsh (1.36.1-r5)
(4/5) Installing libcrypto3 (3.1.4-r1)
(5/5) Installing ca-certificates (20230506-r0)
ERROR: 33 errors updating directory permissions
Executing busybox-1.36.1-r5.trigger
ERROR: busybox-1.36.1-r5.trigger: chroot: Operation not permitted
ERROR: busybox-1.36.1-r5.trigger: script exited with error 127
Executing ca-certificates-20230506-r0.trigger
ERROR: ca-certificates-20230506-r0.trigger: chroot: Operation not permitted
ERROR: ca-certificates-20230506-r0.trigger: script exited with error 127
1 error; 6 MiB in 5 packages
1
~ $ apk add --root x ca-certificates --allow-untrusted; echo $?
2 errors; 6 MiB in 5 packages
2
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10952apk3 may create entries with 000 permissions2024-02-19T15:10:33ZDaniel Kolesaapk3 may create entries with 000 permissionsThere are some users who have reported to me that apk very rarely creates directories with zero permissions. This is usually not reproducible upon subsequent (re)installation, the packages themselves have correct ones. I have no idea how...There are some users who have reported to me that apk very rarely creates directories with zero permissions. This is usually not reproducible upon subsequent (re)installation, the packages themselves have correct ones. I have no idea how to reproduce this properly.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10951repository-tag pinning is sometimes ignored2024-03-24T14:23:02ZAriadne Conillariadne@ariadne.spacerepository-tag pinning is sometimes ignoredI found a weird edge case where the solver will ignore a repository tag pinning. Naturally, this came up while trying to illustrate why making a "frankenstein" environment combining Alpine and Wolfi components is generally disallowed.
...I found a weird edge case where the solver will ignore a repository tag pinning. Naturally, this came up while trying to illustrate why making a "frankenstein" environment combining Alpine and Wolfi components is generally disallowed.
For context, Wolfi's glibc package has an explicit conflict declared against musl. This is intended to prevent users from combining Alpine and Wolfi packages since obviously that will create stability problems.
Both Wolfi and Alpine have packages which satisfy the `librdkafka` name. So, if we start from a Wolfi environment:
```
8d94d6bb5b51:/# apk add alpine-keys
(1/1) Installing alpine-keys (2.4-r2)
OK: 17 MiB in 19 packages
```
And we trust the Alpine x86_64 signing keys:
```
8d94d6bb5b51:/# cp /usr/share/apk/keys/x86_64/alpine-devel@lists.alpinelinux.org-* /etc/apk/keys/
```
And we add `@alpine https://dl-cdn.alpinelinux.org/alpine/edge/community` to `/etc/apk/repositories`, then installing packages which are only in Alpine fails as we would expect:
```
8d94d6bb5b51:/# apk add stargazer-gmi@alpine
ERROR: unable to select packages:
so:libc.musl-x86_64.so.1 (no such package):
required by: stargazer-gmi-1.0.5-r2[so:libc.musl-x86_64.so.1]
```
But as previously mentioned, `librdkafka` is in both distributions, so what happens when we install `librdkafka@alpine`?
```
8d94d6bb5b51:/# apk add librdkafka@alpine
(1/5) Installing libgcc (13.2.0-r3)
(2/5) Installing liblz4-1 (1.9.4-r3)
(3/5) Installing libstdc++ (13.2.0-r3)
(4/5) Installing libzstd1 (1.5.5-r1)
(5/5) Installing librdkafka (2.3.0-r0)
OK: 23 MiB in 24 packages
```
This is the wrong `librdkafka` as should be obvious since the installing line does not describe the installed package as `librdkafka@alpine`. We can verify this by checking the shared libraries it depends on:
```
8d94d6bb5b51:/# /lib/ld-linux-x86-64.so.2 --list /usr/lib/librdkafka.so.1
(0x00007fc54e54d000)
linux-vdso.so.1 (0x00007fff17dd0000)
libm.so.6 => /lib/libm.so.6 (0x00007fc54e46d000)
libz.so.1 => /lib/libz.so.1 (0x00007fc54e453000)
libzstd.so.1 => /usr/lib/libzstd.so.1 (0x00007fc54e394000)
libssl.so.3 => /usr/lib/libssl.so.3 (0x00007fc54e2ef000)
libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x00007fc54de30000)
liblz4.so.1 => /usr/lib/liblz4.so.1 (0x00007fc54de09000)
libc.so.6 => /lib/libc.so.6 (0x00007fc54dbd2000)
/lib/ld-linux-x86-64.so.2 (0x00007fc54e759000)
```
I would expect the solver to reject this solution since it does not keep the `@alpine` tag, like it rejects installing `stargazer-gmi@alpine`.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10949apk fails to install a zero-dependency package, according to the error due to...2023-10-16T09:22:59ZBart Ribbersapk fails to install a zero-dependency package, according to the error due to dependency conflictsAs part of a repository I'm setting up to build nightly git versions of KDE packages I've been trying to build an updated version (compared to aports) of plasma-workspace. It builds fine but afterwards can not be installed:
```
/ # apk ...As part of a repository I'm setting up to build nightly git versions of KDE packages I've been trying to build an updated version (compared to aports) of plasma-workspace. It builds fine but afterwards can not be installed:
```
/ # apk add plasma-workspace
ERROR: unable to select packages:
polkit-qt-1-0.114.0-r2:
conflicts: polkit-qt-1-9999_git20220918-r0
satisfies: kauth5-5.110.0-r1[so:libpolkit-qt5-core-1.so.1]
kguiaddons5-5.110.0-r1:
conflicts: kguiaddons-9999_git20231006-r0[cmd:kde-geo-uri-handler=5.110.0-r1]
satisfies: kio5-5.110.0-r1[so:libKF5GuiAddons.so.5] kdeclarative5-5.110.0-r1[so:libKF5GuiAddons.so.5]
kconfigwidgets5-5.110.0-r1[so:libKF5GuiAddons.so.5] kxmlgui5-5.110.0-r1[so:libKF5GuiAddons.so.5]
kcmutils5-5.110.0-r1[so:libKF5GuiAddons.so.5]
polkit-qt-1-9999_git20220918-r0:
conflicts: polkit-qt-1-0.114.0-r2
satisfies: kauth-9999_git20231011-r0[so:libpolkit-qt6-core-1.so.1]
kguiaddons-9999_git20231006-r0:
conflicts: kguiaddons5-5.110.0-r1[cmd:kde-geo-uri-handler=9999_git20231006-r0]
satisfies: kio-9999_git20231012-r0[so:libKF6GuiAddons.so.6] kcolorscheme-9999_git20231011-r0[so:libKF6GuiAddons.so.6]
```
I can however install any of it's subpackages (most notably plasma-workspace-libs, which depends on tons of KDE Frameworks packages) just fine.
While debugging this problem I brought the package back to zero dependencies, currently the following `.PKGINFO` comes out of it:
```
# Generated by abuild 3.11.21-r0
# using fakeroot version 1.32.1
# Mon Oct 16 08:15:34 UTC 2023
pkgname = plasma-workspace
pkgver = 9999_git20231012-r0
pkgdesc = KDE Plasma Workspace
url = https://kde.org/plasma-desktop/
builddate = 1697444134
packager = Unknown
size = 14958592
arch = aarch64
origin = plasma-workspace
commit = 0a04689a1eea03dc0b60de73fb9426d6c14dd008-dirty
maintainer = team/kde <bribbers@disroot.org>
license = (GPL-2.0-only OR GPL-3.0-only) AND LGPL-2.1-or-later AND GPL-2.0-or-later AND MIT AND LGPL-2.1-only AND LGPL-2.0-or-later AND (LGPL-2.1-only OR LGPL-3.0-only) AND LGPL-2.0-only
# automatically detected:
datahash = 06228dd3f68affbcbef33a9327fff662855a526fda117f4c1b82fe57b3277f3b
```
`apk info -R` output (omitting the dependency list for plasma-workspace=5.27.8-r1 from aports):
```
/ # apk info -R plasma-workspace
plasma-workspace-9999_git20231012-r0 depends on:
```
However, still the same error. I don't understand how there can be dependency conflicts when the packages has literally 0 dependencies.
The APK of the package for aarch64 can be found [plasma-workspace-9999_git20231012-r0.apk](/uploads/f373bc76becadfdc9d821d84a8e9deb7/plasma-workspace-9999_git20231012-r0.apk).https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10948apk fetch creates empty files2023-12-13T08:32:54ZDaniel Kolesaapk fetch creates empty filesAttempting to use `apk fetch pkgname` will say something like "Downloading pkgname-pkgver" but it will create an empty file.Attempting to use `apk fetch pkgname` will say something like "Downloading pkgname-pkgver" but it will create an empty file.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10947apk hangs on lossy network2023-10-18T08:51:56ZNatanael Copaapk hangs on lossy networkWe are having some serious issue with our s390x CI. The Ci jobs relatively often hangs "forever", til they time out. (example: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1141094)
I have tried to troubleshoot it on the machine i...We are having some serious issue with our s390x CI. The Ci jobs relatively often hangs "forever", til they time out. (example: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1141094)
I have tried to troubleshoot it on the machine itself (alpine 3.15), and I have been able to reproduce it, both with `apk update` and with `apk fetch`. It appears to be a delay of around 3 seconds in the beginning of the session. If it passes that, it continues. If it fails there, it never recovers. It appears to happen more often with https than http (but I can not confirm that).
The network seems to be lossy:
```
gitlab-runner-s390x [~]# netstat -s | grep segments
Problem while parsing /proc/net/netstat
1332786 segments received
1631016 segments send out
23286 segments retransmited
2533 bad segments received.
```
Here is a section of strace where it passes. Note the `read` that takes 3 seconds:
```
...
14:07:44.802523 access("/etc/apk/cert.pem", R_OK) = -1 ENOENT (No such file or directory)
14:07:44.802585 mmap(NULL, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3ff9c807000
14:07:44.802623 mmap(NULL, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3ff9c802000
14:07:44.802663 mmap(NULL, 57344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3ff9c7f4000
14:07:44.802707 clock_gettime(CLOCK_REALTIME, {tv_sec=1697119664, tv_nsec=802717867}) = 0
14:07:44.802739 getpid() = 50721
14:07:44.802765 getpid() = 50721
14:07:44.802793 clock_gettime(CLOCK_REALTIME, {tv_sec=1697119664, tv_nsec=802798963}) = 0
14:07:44.802824 getpid() = 50721
14:07:44.802849 getpid() = 50721
14:07:44.802877 clock_gettime(CLOCK_REALTIME, {tv_sec=1697119664, tv_nsec=802882220}) = 0
14:07:44.802930 getpid() = 50721
14:07:44.802959 getpid() = 50721
14:07:44.802977 clock_gettime(CLOCK_REALTIME, {tv_sec=1697119664, tv_nsec=802989280}) = 0
14:07:44.803107 write(7, "\26\3\1\1?\1\0\1;\3\3\230{#M^\313t\374\307V\232\373\t\303\341\371\242\205\234L\367"..., 324) = 324
14:07:44.803157 read(7, "\26\3\3\0z", 5) = 5
14:07:48.267258 read(7, "\2\0\0v\3\3\n\2;\7\ra\263\322\322 \213Y\360\230\5\314C\v\267\266\375\355\244W+\321"..., 122) = 122
14:07:48.267513 read(7, "\24\3\3\0\1", 5) = 5
14:07:48.267534 read(7, "\1", 1) = 1
14:07:48.267555 read(7, "\27\3\3\0\33", 5) = 5
14:07:48.267576 read(7, "aB\220Y\354|\4\30\336\302\36jI\27\265\261\354(\320L\252\4\235\235\230\215/", 27) = 27
14:07:48.267603 read(7, "\27\3\3\17\244", 5) = 5
14:07:48.267624 read(7, "\35Fp9\315\370\300D\352\266\320\336g\177\325Ki\241\265\17\21\330L\0\n\266|\232\21\322\r\212"..., 4004) = 1274
14:07:48.267649 read(7, "4q\t\374\314\360\220#V\366\375)\t\t\276\276\r\371\362Smj\266\37\305\205\7\200\313\202^W"..., 2730) = 1444
14:07:48.270345 read(7, "{\314\332\373\224\217?\342\352D\20*\240n\0~\326$\245C\334\2278~d3\256l-O\354)"..., 1286) = 1286
14:07:48.272149 mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3ff9c7ec000
14:07:48.272218 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3ff9c7ea000
14:07:48.272405 stat("/etc/ssl1.1/certs/8d33f237.0", 0x3ffea1fc6c8) = -1 ENOENT (No such file or directory)
14:07:48.272500 clock_gettime(CLOCK_REALTIME, {tv_sec=1697119668, tv_nsec=272509352}) = 0
...
```
Here is a section of strace where it hangs:
```
14:07:50.145845 access("/etc/apk/cert.pem", R_OK) = -1 ENOENT (No such file or directory)
14:07:50.145903 mmap(NULL, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3ffa0887000
14:07:50.145938 mmap(NULL, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3ffa0882000
14:07:50.145967 mmap(NULL, 57344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3ffa0874000
14:07:50.146005 clock_gettime(CLOCK_REALTIME, {tv_sec=1697119670, tv_nsec=146010306}) = 0
14:07:50.146031 getpid() = 50726
14:07:50.146055 getpid() = 50726
14:07:50.146077 clock_gettime(CLOCK_REALTIME, {tv_sec=1697119670, tv_nsec=146081838}) = 0
14:07:50.146105 getpid() = 50726
14:07:50.146128 getpid() = 50726
14:07:50.146150 clock_gettime(CLOCK_REALTIME, {tv_sec=1697119670, tv_nsec=146154779}) = 0
14:07:50.146198 getpid() = 50726
14:07:50.146220 getpid() = 50726
14:07:50.146243 clock_gettime(CLOCK_REALTIME, {tv_sec=1697119670, tv_nsec=146248268}) = 0
14:07:50.146366 write(7, "\26\3\1\1?\1\0\1;\3\3\36\216%\354y\37\363\32\37\214\"\262\373\332\216\201\264\233I\301\214"..., 324) = 324
14:07:50.146414 read(7,
```
(It is now Thu Oct 12 14:42:06 UTC 2023 so it has been more than 15 mins.)
I believe this is related: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10869
I was able to reproduce it with curl, which exits after 5 mins with:
```
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:05:00 --:--:-- 0
curl: (28) SSL connection timeout
```
I wonder if it would make sense to have something like curl's [`--connect-timeout`](https://everything.curl.dev/usingcurl/timeouts) and [`--retry`](https://everything.curl.dev/usingcurl/downloads/retry) options? Then we could time out early if the initial/SSL connection takes longer than expected, and we could make apk retry a few times before giving up from abuild and CI.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10946who owns directory2024-03-19T12:58:43ZSertonixwho owns directoryThe who-owns functionality of apk doesn't seem to work with directories.
eg.
```sh
apk info -W /var/mail
```
results in
```
ERROR: /var/mail: Could not find owner package
```
but should result in
```
/var/mail is owned by alpine-baselay...The who-owns functionality of apk doesn't seem to work with directories.
eg.
```sh
apk info -W /var/mail
```
results in
```
ERROR: /var/mail: Could not find owner package
```
but should result in
```
/var/mail is owned by alpine-baselayout-3.4.3-r2
```
instead.
It does work for symlinks thought (see `/var/run`).https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10945php82-imagick not recognized by nextcloud2023-10-04T16:51:54Znicedevil007php82-imagick not recognized by nextcloudHey there, I'm using the alpine edge repositories to have the ability to install nextcloud 27. On the prior version 26 it was using php81 instead of the newer php82. I was able to get php-imagick working on the old release with the insta...Hey there, I'm using the alpine edge repositories to have the ability to install nextcloud 27. On the prior version 26 it was using php81 instead of the newer php82. I was able to get php-imagick working on the old release with the installation of:
```shellscript
apk add php81-pecl-imagick
```
Unfortunately this seems not to work after I added it with:
```shellscript
apk add php82-pecl-imagick
```
The nextcloud installation still says:
* Module php-imagick in this instance has no SVG support. For better compatibility it is recommended to install it.
I hope someone can help out here.
Thank you in advance.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10944[Feature request] Add ability to disable apk compression2024-02-14T12:41:20Zandrew-aladjev[Feature request] Add ability to disable apk compressionHello everyone, I want to introduce zstd compression in terms of storing multiple packages in binary form.
```sh
mkdir node
cd node
wget https://nodejs.org/download/release/v18.18.0/node-v18.18.0-linux-x64.tar.gz
wget https://nodejs.org...Hello everyone, I want to introduce zstd compression in terms of storing multiple packages in binary form.
```sh
mkdir node
cd node
wget https://nodejs.org/download/release/v18.18.0/node-v18.18.0-linux-x64.tar.gz
wget https://nodejs.org/download/release/v18.17.1/node-v18.17.1-linux-x64.tar.gz
wget https://nodejs.org/download/release/v18.17.0/node-v18.17.0-linux-x64.tar.gz
wget https://nodejs.org/download/release/v18.16.1/node-v18.16.1-linux-x64.tar.gz
wget https://nodejs.org/download/release/v18.16.0/node-v18.16.0-linux-x64.tar.gz
tar -cvf node.tar node-* && zstd -f --ultra -22 node.tar
> ( 169 MiB => 148 MiB, node.tar.zst)
```
Here we have downloaded similar binary node releases. But actually gunzip compression is a problem, zstd can't use binary similarity as it should be.
```sh
gzip -d node-*
gzip -5 node-*
tar -cvf node.tar node-* && zstd -f --ultra -22 node.tar
( 172 MiB => 149 MiB, node.tar.zst)
gzip -d node-*
gzip -1 node-*
tar -cvf node.tar node-* && zstd -f --ultra -22 node.tar
( 196 MiB => 162 MiB, node.tar.zst)
gzip -d node-*
tar -cvf node.tar node-* && zstd -f --ultra -22 node.tar
( 612 MiB => 96.4 MiB, node.tar.zst)
```
Changing gunzip level won't help a lot. But after removing compression zstd finds binary similarity and provided excellent results. Similar things are related to zstd with dictionary: you can train dictionary for similar binary packages and store all package versions very efficiently in zstd archive.
The only one issue is gunzip compression. Can you please add an ability for apk user for remove it? Thank you.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10943odd/dangerous behavior with replaces= when reverting to previous package2024-03-22T20:14:48ZDaniel Kolesaodd/dangerous behavior with replaces= when reverting to previous packageif package A replaces B and they provide the same virtual package and B is installed by default, installing A works fine (it will replace B and B will get purged)
however, when trying to switch back to B, you need to go through somethin...if package A replaces B and they provide the same virtual package and B is installed by default, installing A works fine (it will replace B and B will get purged)
however, when trying to switch back to B, you need to go through something like, delete A from world first (that by itself will not do anything) and then install B again; apk will do that, but it will erase the files that were replaced in the process (because B will be installed, then A will be purged which will remove the replaced files, and then you have to manually fix B afterwards)
the most notable case in my case is multiple providers for libc; installing a secondary libc provider will be fine, but you can't restore the original libc without static apk or external system, as restoring the previous libc will erase your libc.so, and everything will stop workingv3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10908`apk fetch --update-cache` does not update cache2023-12-13T08:35:03ZPatrycja Rosaalpine@ptrcnull.me`apk fetch --update-cache` does not update cacheas in the title; quick reproduction: `docker run --rm -it apk fetch --update-cache musl`as in the title; quick reproduction: `docker run --rm -it apk fetch --update-cache musl`https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10907apk policy listing packages in wrong order2024-03-08T16:21:40ZEdward Peekapk policy listing packages in wrong orderPer `apk policy --help` packages are supposed to be listed "in order of installation preference".
In Alpine 3.18 with `apk-tools-2.14.0-r2` I am instead observing multiple versions of the same package from a single custom repo being lis...Per `apk policy --help` packages are supposed to be listed "in order of installation preference".
In Alpine 3.18 with `apk-tools-2.14.0-r2` I am instead observing multiple versions of the same package from a single custom repo being listed unsorted in whatever order they are defined in the repo index. The first result is not what is installed:
```
# apk policy libuuid
libuuid policy:
2.38.1-r7:
https://.../v3.18/main
2.38.1-r8:
https://.../v3.18/main
/ # apk add libuuid
WARNING: This apk-tools is OLD! Some packages might not function properly.
(1/1) Installing libuuid (2.38.1-r8)
OK: 7 MiB in 16 packages
```
The repo `APKINDEX` contains:
```
P:libuuid
V:2.38.1-r7
A:x86_64
S:13571
I:40960
T:DCE compatible Universally Unique Identifier library
U:https://git.kernel.org/cgit/utils/util-linux/util-linux.git
L:BSD-3-Clause
o:util-linux
m:Natanael Copa <ncopa@alpinelinux.org>
t:1681557467
c:25bd220db5fce58966f17cf7719f9c73a5c5295e
D:so:libc.musl-x86_64.so.1
p:so:libuuid.so.1=1.3.0
z:v3.18/main/x86_64/libuuid-2.38.1-r7.apk
y:fbcdcb907098b719a1a7dd21aa48ddce83e8b62c
P:libuuid
V:2.38.1-r8
A:x86_64
S:13567
I:40960
T:DCE compatible Universally Unique Identifier library
U:https://git.kernel.org/cgit/utils/util-linux/util-linux.git
L:BSD-3-Clause
o:util-linux
m:Natanael Copa <ncopa@alpinelinux.org>
t:1686107202
c:c7de7fac9ae57f268781a733984e74a36f867d1c
D:so:libc.musl-x86_64.so.1
p:so:libuuid.so.1=1.3.0
```v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10905improve output for serial number2023-09-22T08:53:04Zqaqlandimprove output for serial numberWhen number <= 9, it looks so tidy. But when number of items > 9, will get:
```
(7/17) Upgrading busybox-suid (1.36.1-r1 -> 1.36.1-r2)
(8/17) Upgrading musl-utils (1.2.4-r0 -> 1.2.4-r1)
(9/17) Upgrading libmagic (5.44-r4 -> 5.45-r0)
(10...When number <= 9, it looks so tidy. But when number of items > 9, will get:
```
(7/17) Upgrading busybox-suid (1.36.1-r1 -> 1.36.1-r2)
(8/17) Upgrading musl-utils (1.2.4-r0 -> 1.2.4-r1)
(9/17) Upgrading libmagic (5.44-r4 -> 5.45-r0)
(10/17) Upgrading file (5.44-r4 -> 5.45-r0)
(11/17) Upgrading musl-dev (1.2.4-r0 -> 1.2.4-r1)
(12/17) Upgrading busybox-doc (1.36.1-r1 -> 1.36.1-r2)
```
It would be pretty if output like below:
```
( 7/17) Upgrading busybox-suid (1.36.1-r1 -> 1.36.1-r2)
( 8/17) Upgrading musl-utils (1.2.4-r0 -> 1.2.4-r1)
( 9/17) Upgrading libmagic (5.44-r4 -> 5.45-r0)
(10/17) Upgrading file (5.44-r4 -> 5.45-r0)
(11/17) Upgrading musl-dev (1.2.4-r0 -> 1.2.4-r1)
(12/17) Upgrading busybox-doc (1.36.1-r1 -> 1.36.1-r2)
```
So does number of items >= 100 or more.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10904reinstalls are somewhat broken if original directories are missing2024-03-22T14:06:35ZDaniel Kolesareinstalls are somewhat broken if original directories are missingThe current behavior of `apk fix` is somewhat broken. When you delete a package's directory tree and then `apk fix` it, you will get messages like:
```
ERROR: Failed to create /path/to/some/file: No such file or directory
```
This is b...The current behavior of `apk fix` is somewhat broken. When you delete a package's directory tree and then `apk fix` it, you will get messages like:
```
ERROR: Failed to create /path/to/some/file: No such file or directory
```
This is because apk does not re-create the directory structure to put the file in, and then tries to put the file in there, which causes the errors. This makes e.g. reinstalling packages on broken systems where stuff got deleted rather inconvenient.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10903apk3: broken adb with files over 1073741811 bytes2023-10-15T16:40:28ZDaniel Kolesaapk3: broken adb with files over 1073741811 bytesThe following code:
```
struct adb_block blk = adb_block_init(ADB_BLOCK_DATA, size + hdr.len);
size_t padding = adb_block_padding(&blk);
int r;
```
Using files of sizes larger than 1073741811 bytes will result in a block of type `AD...The following code:
```
struct adb_block blk = adb_block_init(ADB_BLOCK_DATA, size + hdr.len);
size_t padding = adb_block_padding(&blk);
int r;
```
Using files of sizes larger than 1073741811 bytes will result in a block of type `ADB_BLOCK_DATAX`, as the file will have spilled into the block's type bits. That will result in errors about bad ADB block when trying to check or extract the files.
It should be very easy to reproduce, the solution should probably using some kind of chunked approach for files whose size including the header does not fit in 30 bits.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10901Enhancement: Simplify the Makefile, don't delete it2024-03-20T19:41:57ZBharatvaj HemanthEnhancement: Simplify the Makefile, don't delete itHi I've been trying to build apk-tools on mac osx but couldn't using the recommended meson build tools. Had an issue with finding the openssl while compiling libfetch. Then I tried with `make` and it didn't work either.
I then wrote a M...Hi I've been trying to build apk-tools on mac osx but couldn't using the recommended meson build tools. Had an issue with finding the openssl while compiling libfetch. Then I tried with `make` and it didn't work either.
I then wrote a Makefile based on the meson.build file and finally I was able to build it for mac.
[Makefile](/uploads/8e594233fa5231bf07cd70bf868009a2/Makefile)
[config.mk](/uploads/4a973489f47456117c30512ff14b9d17/config.mk)
Since `apk` is such a fundamental part of the base system, and as meson requires a separate package of it's own and python. I suggest to keep the Makefile around instead of deleting in the 3.0.0 version. I would like to work on it and maintain it, if the core maintainers agree on this.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10900apk3: lots of endianness issues2023-07-09T13:26:26ZDaniel Kolesaapk3: lots of endianness issuesAttempting to use apk3 packages on a big endian system will end in failure because of many places; these are the ones I could find so far:
adb.c:
* `.magic = ADB_FORMAT_MAGIC,` -> `.magic = htole32(ADB_FORMAT_MAGIC),`
app_mkpkg.c:
``...Attempting to use apk3 packages on a big endian system will end in failure because of many places; these are the ones I could find so far:
adb.c:
* `.magic = ADB_FORMAT_MAGIC,` -> `.magic = htole32(ADB_FORMAT_MAGIC),`
app_mkpkg.c:
```
@@ -195,12 +195,12 @@ static int mkpkg_process_dirent(void *pctx, int dirfd, const char *entry)
case S_IFBLK:
case S_IFCHR:
case S_IFIFO:
- ft.dev.mode = fi.mode & S_IFMT;
- ft.dev.dev = fi.device;
+ ft.dev.mode = htole16(fi.mode & S_IFMT);
+ ft.dev.dev = htole64(fi.device);
target = APK_BLOB_STRUCT(ft.dev);
break;
case S_IFLNK:
- ft.symlink.mode = fi.mode & S_IFMT;
+ ft.symlink.mode = htole16(fi.mode & S_IFMT);
r = readlinkat(dirfd, entry, ft.symlink.target, sizeof ft.symlink.target);
if (r < 0) return r;
target = APK_BLOB_PTR_LEN((void*)&ft.symlink, sizeof(ft.symlink.mode) + r);
@@ -385,8 +385,8 @@ static int mkpkg_main(void *pctx, struct apk_ctx *ac, struct apk_string_array *a
if (!APK_BLOB_IS_NULL(target)) continue;
if (!sz) continue;
struct adb_data_package hdr = {
- .path_idx = i,
- .file_idx = j,
+ .path_idx = htole32(i),
+ .file_idx = htole32(j),
};
int n = apk_pathbuilder_pushb(&ctx->pb, filename);
adb_c_block_data(
```
extract_v3.c:
* `mode = *(uint16_t*)target.ptr;` -> `mode = le16toh(*(uint16_t*)target.ptr);`
* `fi.device = ((struct unaligned64 *)target.ptr)->value;` -> `fi.device = le64toh(((struct unaligned64 *)target.ptr)->value);`
* `hdr->path_idx != ctx->cur_path` -> `le32toh(hdr->path_idx) != ctx->cur_path`
* `hdr->file_idx != ctx->cur_file` -> `le32toh(hdr->file_idx) != ctx->cur_file`
After this, I could get packages to extract (but the changes may not be exhaustive). However, signature verification still fails, and I have no idea why. Big endian-created packages will pass verification (and fail it on LE) while little-endian-created packages will fail verification (and pass on LE). However, the message digest and stuff appears to be identical whether running on LE or on BE.
Also, `mkpkg` will still create packages whose data differ when run on systems of different endianness.