apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2024-03-21T18:09:41Zhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10978wrong progress bar after critical system upgrade2024-03-21T18:09:41ZSertonixwrong progress bar after critical system upgradeI noticed that the progress bar after a critical system upgrade used `#` even though apk should have used the unicode characters.
My guess is that when apk calls itself without passing variables that haven't been exported.I noticed that the progress bar after a critical system upgrade used `#` even though apk should have used the unicode characters.
My guess is that when apk calls itself without passing variables that haven't been exported.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10977`apk add` tries to set directory permissions when running as non-root user2024-03-11T13:54:53Zleso-kn`apk add` tries to set directory permissions when running as non-root userFrom the apk-tools documentation:
> ```
> --no-chown
> Do not change file owner or group. By default apk will manage the file
> ownership when running as root. However, this option is turned on when
> running as non-root user, a...From the apk-tools documentation:
> ```
> --no-chown
> Do not change file owner or group. By default apk will manage the file
> ownership when running as root. However, this option is turned on when
> running as non-root user, as changing file ownership is not permitted
> by the system then.
> ```
#### Reproducing the error
```bash
# as a non-root user
$ mkdir -p test-sysroot/etc/apk/keys
$ uname -m > test-sysroot/etc/apk/arch
$ cp /etc/apk/repositories test-sysroot/etc/apk
# let's try to install vim
$ apk --root=$PWD/test-sysroot add --initdb --allow-untrusted vim
(1/6) Installing vim-common (9.1.0-r1)
(2/6) Installing musl (1.2.5-r0)
(3/6) Installing xxd (9.1.0-r1)
(4/6) Installing ncurses-terminfo-base (6.4_p20231125-r0)
(5/6) Installing libncursesw (6.4_p20231125-r0)
(6/6) Installing vim (9.1.0-r1)
ERROR: 71 errors updating directory permissions
OK: 32 MiB in 6 packages
```
#### Expected behaviour
After vim is installed `apk` should not try to set any permissions, as `--no-chown` is implicitly passed by running as a non-root user.
**Note:** Passing `--no-chown` explicitly results in the same behaviour.
#### Actual behaviour
`apk` tries to set to set directory permissions despite the `--no-chown` flag in [database.c:2101](https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/6cd7f31d9bde79bb6361f2d2cbe37bfbafa342ea/src/database.c#L2101).https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10975Remove .keep_* special case2024-02-19T13:53:29ZSertonixRemove .keep_* special caseapk includes a special case when installed directories have a name starting with `.keep_`.
[`src/database.c#L2623-L2624`](https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/c15eb020ffcbdac6a0c658100ec2e41da2d6e15f/src/database.c#L26...apk includes a special case when installed directories have a name starting with `.keep_`.
[`src/database.c#L2623-L2624`](https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/c15eb020ffcbdac6a0c658100ec2e41da2d6e15f/src/database.c#L2623-L2624)
```c
if (bfile.len > 6 && memcmp(bfile.ptr, ".keep_", 6) == 0)
return 0;
```
The code was there since the initial commit. I don't think it provides any purpose.
I would suggest removing that code or documenting it.
CC @fabled since you committed that codehttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10971mkpkg -f flag conflicts with global -f, --force flag2024-02-14T12:10:29ZWesley Mooremkpkg -f flag conflicts with global -f, --force flagSimilar to #10822 `mkpkg` has a short flag for `--files` of `-f` but this conflicts with the global `-f, --force` flag. If `-f` is passed then `mkpkg` does not include any files in the package.Similar to #10822 `mkpkg` has a short flag for `--files` of `-f` but this conflicts with the global `-f, --force` flag. If `-f` is passed then `mkpkg` does not include any files in the package.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10970Segfault when writing database on `apk fix`2024-01-14T07:32:13ZPatrycja Rosaalpine@ptrcnull.meSegfault when writing database on `apk fix`i'm not quite sure how to debug this...
version: 2.14.0-r5, running on Alpine edge
```
$ doas nano /etc/apk/world
$ doas apk fix
fetch https://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
fetc...i'm not quite sure how to debug this...
version: 2.14.0-r5, running on Alpine edge
```
$ doas nano /etc/apk/world
$ doas apk fix
fetch https://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/edge/community/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/edge/testing/x86_64/APKINDEX.tar.gz
fetch https://repo.ptrc.gay/ptrcports/x86_64/APKINDEX.tar.gz
fetch https://mirror.postmarketos.org/postmarketos/master/x86_64/APKINDEX.tar.gz
(1/36) Purging .makedepends-bcachefs-tools (20231128.033928)
(2/36) Purging clang17-dev (17.0.5-r0)
(3/36) Purging libaio-dev (0.3.113-r2)
(4/36) Purging libsodium-dev (1.0.19-r0)
(5/36) Purging keyutils-dev (1.6.3-r3)
(6/36) Purging lz4-dev (1.9.4-r5)
(7/36) Purging userspace-rcu-dev (0.14.0-r2)
(8/36) Purging .makedepends-firefox (20231210.205110)
(9/36) Purging hunspell-dev (1.7.2-r4)
(10/36) Purging libevent-dev (2.1.12-r7)
(11/36) Purging libtheora-dev (1.1.1-r18)
(12/36) Purging libvpx-dev (1.13.1-r0)
(13/36) Purging libxt-dev (1.3.0-r4)
(14/36) Purging lld-doc (17.0.5-r0)
(15/36) Purging lld (17.0.5-r0)
(16/36) Purging llvm17-dev (17.0.5-r0)
(17/36) Purging llvm17-test-utils-pyc (17.0.5-r0)
(18/36) Purging llvm17-test-utils (17.0.5-r0)
(19/36) Purging nasm-doc (2.16.01-r2)
(20/36) Purging nasm (2.16.01-r2)
(21/36) Purging nss-dev (3.94-r0)
(22/36) Purging pipewire-dev (1.0.0-r0)
(23/36) Purging wasi-sdk (20-r3)
(24/36) Purging wasi-libc (0.20231012-r0)
(25/36) Purging wasi-libcxx (17.0.5-r0)
(26/36) Purging wireless-tools-dev (30_pre9-r4)
(27/36) Purging .makedepends-hledger-stockquotes (20231119.055847)
(28/36) Purging .makedepends-pandoc-cli (20231107.221958)
(29/36) Purging cabal-doc (3.10.2.1-r0)
(30/36) Purging cabal (3.10.2.1-r0)
(31/36) Purging ghc-doc (9.4.8-r0)
(32/36) Purging ghc (9.4.8-r0)
(33/36) Purging llvm14 (14.0.6-r17)
(34/36) Purging lld-libs (17.0.5-r0)
(35/36) Purging llvm14-libs (14.0.6-r17)
(36/36) Purging nspr-dev (4.35-r4)
Executing busybox-1.36.1-r16.trigger
zsh: segmentation fault (core dumped) doas apk fix
```
<details>
<summary>gdb backtrace</summary>
```
$ gdb -q /sbin/apk core-apk-11-0-0-8265-1705133663
Reading symbols from /sbin/apk...
Reading symbols from /usr/lib/debug//sbin/apk.debug...
[New LWP 8265]
Core was generated by `apk fix'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 apk_db_write_fdb (db=db@entry=0x555f5abde880 <db>, os=os@entry=0x7f7774c2df30) at src/database.c:962
warning: 962 src/database.c: No such file or directory
(gdb) bt full
#0 apk_db_write_fdb (db=db@entry=0x555f5abde880 <db>, os=os@entry=0x7f7774c2df30) at src/database.c:962
ipkg = 0x0
pkg = <optimized out>
ppkg = 0x7f7776b132c8
pkgs = 0x7f7776b132c0
diri = <optimized out>
file = <optimized out>
c1 = <optimized out>
c2 = <optimized out>
buf = "r\230~zw\177\000\000\000\350\227m\375\177\000\000\a\000\000\0001/Teh\346\227m\375\177\000\000\a\000\000\000ict/\a\000\000\000\000\000\000\000\200\346\227m\375\177\000\000\000\347\227m\375\177\000\000\362\"\203zw\177\000\000\a\000\000\000w\177\000\000\000\000\000\000\a\000\000\000\037\000\000\000\000\000\000\000\272`7zw\177\000\000=\372vzw\177\000\000\231\2606zw\177\000\000\220\022\354tw\177\000\000\001\000\000\000\000\000\000\000\037\000\000\000\000\000\000\000]\245{zw\177\000\000H<\213[_U\000\000\\\303~zw\177\000\000\000\350\227m\375\177\000\000\000\000\000\000\000\000\000\000\356\347\227m\375\177\000\000h\346\227m\375\177\000\000"...
bbuf = {len = 5120, ptr = 0x7ffd6d97e578 "r\230~zw\177"}
r = 0
__mptr = <optimized out>
__mptr = <optimized out>
#1 0x00007f777a75cf63 in apk_db_write_config (db=db@entry=0x555f5abde880 <db>) at src/database.c:1763
os = 0x7f7774c2df30
r = <optimized out>
#2 0x00007f777a760b7a in apk_solver_commit_changeset (db=db@entry=0x555f5abde880 <db>, changeset=changeset@entry=0x7ffd6d97fb30, world=world@entry=0x7f777a05d4a0) at src/commit.c:374
prog = {done = {changes = 36, bytes = 0, packages = 36}, total = {changes = 36, bytes = 0, packages = 36}, pkg = 0x0}
change = <optimized out>
buf = "(37/36)", '\000' <repeats 13 times>, "\376\017\000\000\000\000\000\000\000\000\000"
size_unit = <optimized out>
humanized = 0
size_diff = <optimized out>
download_size = <optimized out>
r = <optimized out>
errors = 0
__func__ = "apk_solver_commit_changeset"
#3 0x00007f777a7610f6 in apk_solver_commit (db=0x555f5abde880 <db>, solver_flags=<optimized out>, world=0x7f777a05d4a0) at src/commit.c:785
changeset = {num_install = 0, num_remove = 36, num_adjust = 0, num_total_changes = 36, changes = 0x7f77744b9030}
r = 0
#4 0x0000555f5abd1db2 in main (argc=0, argv=<optimized out>) at src/apk.c:621
ctx = 0x7f777a74bcd0
dbopts = {lock_wait = 0, cache_max_age = 0, open_flags = 2, root = 0x0, arch = 0x0, keys_dir = 0x0, cache_dir = 0x7f777a76f627 "etc/apk/cache", repositories_file = 0x0,
protected_paths = {len = 0, ptr = 0x0}, repository_list = {next = 0x7ffd6d97fbd8, prev = 0x7ffd6d97fbd8}}
args = 0x7f777a77a7a0 <dummy_array>
applet = <optimized out>
r = 0
```
</details>https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10969document files/dirs used by apk in man page2024-03-27T10:47:33ZSertonixdocument files/dirs used by apk in man pageapk uses files spread across the system. To find these it is needed to dig through the source code.
For example I wasn't able to find info about `/etc/apk/repositories.d/` and `/etc/apk/commit_hooks.d/` without looking at the source.
I...apk uses files spread across the system. To find these it is needed to dig through the source code.
For example I wasn't able to find info about `/etc/apk/repositories.d/` and `/etc/apk/commit_hooks.d/` without looking at the source.
I have seen other man pages listing the relevant files so it would be nice to have that for apk too.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10968Pass interactive flag to triggers2024-01-29T08:43:50ZSertonixPass interactive flag to triggersIt would be nice for triggers to know if apk is run interactively. That would allow triggers to provide some user choice if they want to do something or not. eg. grub trigger.
I think an environmental variable would be the best way. `AP...It would be nice for triggers to know if apk is run interactively. That would allow triggers to provide some user choice if they want to do something or not. eg. grub trigger.
I think an environmental variable would be the best way. `APK_IS_INTERACTIVE=1` maybe. I think that the name makes clear that this is not a variable to make apk interactive.
This doesn't work with parallel triggers (#10760). So if they are added that would need to be disabled in interactive mode.
Idea comes from aports#15653 since it would benefit from interactivity when possible.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10967add compilation option for --ignore-busybox-symlinks2024-03-22T13:36:14ZSertonixadd compilation option for --ignore-busybox-symlinksThe `--ignore-busybox-symlinks` only (needs to) exist cause of the way busybox is packaged on alpine. Since other distros using apk don't need the option it would be nice to disable it at compile time. Maybe disabled by default and enabl...The `--ignore-busybox-symlinks` only (needs to) exist cause of the way busybox is packaged on alpine. Since other distros using apk don't need the option it would be nice to disable it at compile time. Maybe disabled by default and enabled for alpine.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10966apk3: apk fix --no-chown2024-02-05T12:35:47ZSertonixapk3: apk fix --no-chown`apk add` has the `--no-chown` flag. Since `apk fix` (and maybe others) can also trigger file creation it would make sense to add the flag there too.
I think it would fit under the commit options.`apk add` has the `--no-chown` flag. Since `apk fix` (and maybe others) can also trigger file creation it would make sense to add the flag there too.
I think it would fit under the commit options.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10965APK --force-broken-world shouldn't default to a soluton where the package I'm...2024-03-26T14:04:03ZEllieAPK --force-broken-world shouldn't default to a soluton where the package I'm targeting is simply uninstalledThis concerns apk, packaged as apk-tools 2.14.0 on current stable postmarketOS 23.06 as of 2023-12-28.
Let me demonstrate, steps to reproduce **(this breaks your packages!!!** Reasoning however is explained below):
1. Install postmarke...This concerns apk, packaged as apk-tools 2.14.0 on current stable postmarketOS 23.06 as of 2023-12-28.
Let me demonstrate, steps to reproduce **(this breaks your packages!!!** Reasoning however is explained below):
1. Install postmarketOS 23.06 stable, **not** edge, as found today 2023-12-28 with no later service packs or updates.
2. In a terminal, run: `wget https://gitlab.gnome.org/GNOME/gnome-system-monitor/uploads/d3d43f1845d021eee2b1217cc7776607/gnome-system-monitor-45.0.2_p1-r1.apk` (for what it's worth, info about the package source: https://gitlab.gnome.org/GNOME/gnome-system-monitor/-/merge_requests/112#note_1955032 )
3. In a terminal run **(super unsafe, at your own risk):** `sudo apk add --allow-untrusted gnome-system-monitor-45.0.2_p1-r1.apk` which shouldn't work, but rather give you a dependency error: `ERROR: unable to select packages: so:libc.musl-x86_64.so.1 (no such package)`
4. In a terminal run **(extremely unsafe and breaks your system):** `sudo apk add --allow-broken-world --allow-untrusted gnome-system-monitor-45.0.2_p1-r1.apk`
Now what happens, why is that unexpected, and what did I expect instead:
As a result of the last command, apk simply removed gnome-system-monitor as a program entirely from the system. This doesn't seem like a useful or expected behavior to me for this command. To explain my reasoning, I made a risky guess that maybe despite the dependency on the newer musl libc, the given package would maybe manage to run fine with the older one. I was willing to accept crashes and issues due to this, so my intention here was "please proceed even if the dependencies can't be fully satisfied". That seems to be what `--force-broken-world` suggests it would do.
The current behavior however doesn't seem useful in any scenario I can think of since it seems to be the equivalent of `apk del --purge gnome-system-monitor` which I could have just run instead, and effectively it doesn't even seem to touch or use the apk file I pointed it to. That seems kind of nonsensical, since if I want to convince it to do something with the given package on disk, an operation that ends up not using it doesn't really seem to be what a user would be after.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10962Use parallelism optimally2024-02-23T12:34:58ZSander MaijersUse parallelism optimallyThis is a meta-issue for:
- [ ] #5977
- [ ] #10760
- [ ] #10963This is a meta-issue for:
- [ ] #5977
- [ ] #10760
- [ ] #10963https://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.