apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2023-10-18T08:51:56Zhttps://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/10902`apk add --virtual` conflicts with tagged repositories2023-07-09T13:03:57ZDaniel Rudolf`apk add --virtual` conflicts with tagged repositoriesCurrently it's not possible to install a package from a tagged repository (`package@repository`) with a virtual package (`--virtual`/`-t`):
```
$ apk add --virtual .fetch-deps py3-pip@testing
ERROR: 'py3-pip@testing' is not a valid chil...Currently it's not possible to install a package from a tagged repository (`package@repository`) with a virtual package (`--virtual`/`-t`):
```
$ apk add --virtual .fetch-deps py3-pip@testing
ERROR: 'py3-pip@testing' is not a valid child dependency, format is name([<>~=]version)
```
It would be great if we can combine these two features.https://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.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10899apk list -u with pinned repository2024-03-26T14:04:03ZMatt Adamsapk list -u with pinned repositoryWith `@edge https://dl-cdn.alpinelinux.org/alpine/edge/main`
`apk list -u` lists **all** packages which have a newer edge version, not just packages in world with the `@edge` tag as I would expect.With `@edge https://dl-cdn.alpinelinux.org/alpine/edge/main`
`apk list -u` lists **all** packages which have a newer edge version, not just packages in world with the `@edge` tag as I would expect.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10898Core dump during "apk del package -r"2023-10-12T10:08:45ZJohn PfuntnerCore dump during "apk del package -r"I'm using the public alpine:latest image and am seeing a core dump if I do a `apk del package -r`:
```
$ docker run -it --rm alpine:latest
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
8a49fdb3b6a5: Pu...I'm using the public alpine:latest image and am seeing a core dump if I do a `apk del package -r`:
```
$ docker run -it --rm alpine:latest
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
8a49fdb3b6a5: Pull complete
Digest: sha256:02bb6f428431fbc2809c5d1b41eab5a68350194fb508869a33cb1af4444c9b11
Status: Downloaded newer image for alpine:latest
/ # grep PRETTY /etc/os-release
PRETTY_NAME="Alpine Linux v3.18"
/ # apk --version
apk-tools 2.14.0, compiled for x86_64.
/ # apk add python3
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/17) Installing libbz2 (1.0.8-r5)
(2/17) Installing libexpat (2.5.0-r1)
(3/17) Installing libffi (3.4.4-r2)
(4/17) Installing gdbm (1.23-r1)
(5/17) Installing xz-libs (5.4.3-r0)
(6/17) Installing libgcc (12.2.1_git20220924-r10)
(7/17) Installing libstdc++ (12.2.1_git20220924-r10)
(8/17) Installing mpdecimal (2.5.1-r2)
(9/17) Installing ncurses-terminfo-base (6.4_p20230506-r0)
(10/17) Installing libncursesw (6.4_p20230506-r0)
(11/17) Installing libpanelw (6.4_p20230506-r0)
(12/17) Installing readline (8.2.1-r1)
(13/17) Installing sqlite-libs (3.41.2-r2)
(14/17) Installing python3 (3.11.3-r10)
(15/17) Installing python3-pycache-pyc0 (3.11.3-r10)
(16/17) Installing pyc (0.1-r0)
(17/17) Installing python3-pyc (3.11.3-r10)
Executing busybox-1.36.0-r9.trigger
OK: 51 MiB in 32 packages
/ # apk del python3 -r
Segmentation fault (core dumped)
/ #
```
I don't have the problem if I don't use `-r` or when using alpine:3.17 (apkt-tools 2.12.10).https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10897Core dump during "apk del package -r"2023-05-10T12:06:35ZJohn PfuntnerCore dump during "apk del package -r"I'm using the public alpine:latest image and am seeing a core dump if I do a `apk del package -r`:
```
$ docker run -it --rm alpine:latest
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
8a49fdb3b6a5: Pu...I'm using the public alpine:latest image and am seeing a core dump if I do a `apk del package -r`:
```
$ docker run -it --rm alpine:latest
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
8a49fdb3b6a5: Pull complete
Digest: sha256:02bb6f428431fbc2809c5d1b41eab5a68350194fb508869a33cb1af4444c9b11
Status: Downloaded newer image for alpine:latest
/ # grep PRETTY /etc/os-release
PRETTY_NAME="Alpine Linux v3.18"
/ # apk --version
apk-tools 2.14.0, compiled for x86_64.
/ # apk add python3
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/17) Installing libbz2 (1.0.8-r5)
(2/17) Installing libexpat (2.5.0-r1)
(3/17) Installing libffi (3.4.4-r2)
(4/17) Installing gdbm (1.23-r1)
(5/17) Installing xz-libs (5.4.3-r0)
(6/17) Installing libgcc (12.2.1_git20220924-r10)
(7/17) Installing libstdc++ (12.2.1_git20220924-r10)
(8/17) Installing mpdecimal (2.5.1-r2)
(9/17) Installing ncurses-terminfo-base (6.4_p20230506-r0)
(10/17) Installing libncursesw (6.4_p20230506-r0)
(11/17) Installing libpanelw (6.4_p20230506-r0)
(12/17) Installing readline (8.2.1-r1)
(13/17) Installing sqlite-libs (3.41.2-r2)
(14/17) Installing python3 (3.11.3-r10)
(15/17) Installing python3-pycache-pyc0 (3.11.3-r10)
(16/17) Installing pyc (0.1-r0)
(17/17) Installing python3-pyc (3.11.3-r10)
Executing busybox-1.36.0-r9.trigger
OK: 51 MiB in 32 packages
/ # apk del python3 -r
Segmentation fault (core dumped)
/ #
```
I don't have the problem if I don't use `-r` or when using alpine:3.17 (apkt-tools 2.12.10).https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10896apk3: apk search no longer shows reverse dependencies of non-existent packages2023-10-12T10:08:45ZDaniel Kolesaapk3: apk search no longer shows reverse dependencies of non-existent packagesEver since some point (not exactly sure when, probably when the `--from` stuff was added), `apk search` will no longer find reverse dependencies of a package that was dropped from index.
That means:
1) Given a (possibly only virtual) p...Ever since some point (not exactly sure when, probably when the `--from` stuff was added), `apk search` will no longer find reverse dependencies of a package that was dropped from index.
That means:
1) Given a (possibly only virtual) package `foo` which is no longer present in index
2) And package `bar` depending on it
3) Running `apk search -r -e foo` will no longer list `bar` like it did before
This does not apply to packages that *are* present in index. Example:
```
root@cbuild: ~$ apk search -r -e so:libLLVM-16.so
libllvm-16.0.2-r0 is required by:
llvm-runtime-16.0.2-r0
lld-16.0.2-r0
clang-16.0.2-r0
llvm-16.0.2-r0
clang-tools-extra-16.0.2-r0
libclang-cpp-16.0.2-r0
libllvm-dbg-16.0.2-r0
libclang-16.0.2-r0
llvm-linker-tools-16.0.2-r0
llvm-devel-16.0.2-r0
libomp-16.0.2-r0
lldb-16.0.2-r0
spirv-llvm-translator-16.0.0-r0
root@cbuild: ~$ apk search -r -e so:libLLVM-15.so
root@cbuild: ~$ apk info -R rust
rust-1.69.0-r0 depends on:
clang
musl-devel
rust-std=1.69.0-r0
so:libLLVM-15.so
so:libc++.so.1
so:libc.so
so:libunwind.so.1
```
Note how `rust` depends on `so:libLLVM-15.so` but it is seemingly impossible to look it up in reverse. The `apk info` command is identically affected. I noticed this when my package staging system seemingly stopped working.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10895ERROR: script exited with error 02024-03-08T16:21:40ZPatrycja Rosaalpine@ptrcnull.meERROR: script exited with error 0in some weird cases, like running an arm64v8 container on x86_64 with qemu-user, apk can return `script exited with error 0`:
```console
$ podman run --rm -it arm64v8/alpine:3.15
WARNING: image platform (linux/arm64/v8) does not match t...in some weird cases, like running an arm64v8 container on x86_64 with qemu-user, apk can return `script exited with error 0`:
```console
$ podman run --rm -it arm64v8/alpine:3.15
WARNING: image platform (linux/arm64/v8) does not match the expected platform (linux/amd64)
/ # sed -i 's/3.15/3.12/' /etc/apk/repositories
/ # apk upgrade -a
fetch https://dl-cdn.alpinelinux.org/alpine/v3.12/main/aarch64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.12/community/aarch64/APKINDEX.tar.gz
(1/15) Downgrading musl (1.2.2-r8 -> 1.1.24-r10)
(2/15) Downgrading busybox (1.34.1-r7 -> 1.31.1-r22)
Executing busybox-1.31.1-r22.post-upgrade
(3/15) Downgrading alpine-baselayout (3.2.0-r18 -> 3.2.0-r7)
Executing alpine-baselayout-3.2.0-r7.pre-upgrade
ERROR: alpine-baselayout-3.2.0-r7.pre-upgrade: script exited with error 0
Executing alpine-baselayout-3.2.0-r7.post-upgrade
(4/15) Downgrading alpine-keys (2.4-r1 -> 2.4-r0)
```
i narrowed it down to this line:
https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/v2.12.7/src/database.c#L1979
but couldn't find in which cases `WIFEXITED` would return a zero valuehttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/108942.14_rc1: fetch -L not recognised2023-10-12T10:08:45ZGhost User2.14_rc1: fetch -L not recognised```console
$ apk fetch -L musl
apk: unrecognized option: L
$ apk fetch --link musl # works
```
`apk fetch --help`:
```
-L, --link Create hard links if possible
``````console
$ apk fetch -L musl
apk: unrecognized option: L
$ apk fetch --link musl # works
```
`apk fetch --help`:
```
-L, --link Create hard links if possible
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10893apk dot exiting with code 1 and without any output2023-04-26T10:28:11ZPatrycja Rosaalpine@ptrcnull.meapk dot exiting with code 1 and without any outputsorry, this is a bit of a vague issue.
i still have no idea how to reproduce it, must be something broken with my world / installed dbsorry, this is a bit of a vague issue.
i still have no idea how to reproduce it, must be something broken with my world / installed db