apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2024-03-26T14:04:03Zhttps://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 dbhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10890[Question] Order of installation/upgrades for "install_if" packages2023-04-24T15:05:20ZPablo Correa Gomez[Question] Order of installation/upgrades for "install_if" packagesI asked in IRC, and I was redirected here. I apologize if this is not the right place to ask.
Regarding some problem in pmOS, I have some question about whether there is a warrantied order during both installations and upgrades. The mai...I asked in IRC, and I was redirected here. I apologize if this is not the right place to ask.
Regarding some problem in pmOS, I have some question about whether there is a warrantied order during both installations and upgrades. The main reason, is that we currently enable some system services of dependent packages on the `post-upgrade` scripts of some meta-packages. I have built apk-tools with `DEBUG_PRINT` and read some of the solver code, but I am still a bit confused about quite some of the solver bits, so I thought asking would be smart. I hope it's not too annoying. I am interested in the following circumstances:
* Install: if "a" -> depends -> "b" -> depends -> "c", is there a warranty that "c" will be installed before "b", before "a"? They way I understand the solver, and some debugging, this is the only one that I'm partially sure is like this.
* Upgrade of packages (assuming all of them upgraded): if "a" -> depends -> "b" -> depends -> "c", is there a warranty that "c" will be upgraded before "b", before "a"?
In a sense, these two situations are the ones we need so we can keep the `post-upgrade` scripts and can avoid using "triggers" instead. The ones below just influence how we should do the packaging:
* Install: if "a" -> depends -> "b", and "c" -> install_if -> "a"=ver, "b", is there any warranty regarding the installation order of "c"? So for example, that it will be installed before any package that depends on "a"? By experience I assume no, but just checking.
* Upgrade of packages (assuming all of them upgraded): if "a" -> depends -> "b", and "c" -> install_if -> "a"=ver, "b", is there any warranty regarding the upgrade order of "c"? So for example, that it will be upgraded before any package that depends on "a"? Again, by experience I guess no, but also just checking.
Thank you very much for your time :)https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10889FIFO handling and embedded checksums2023-10-12T10:08:44ZAlex DenesFIFO handling and embedded checksums`abuild` creates no checksums for FIFO files that are packaged and `apk-tools` <= 2.14.0 complains about the FIFO files having no embedded checksum.
Minimal APKBUILD to replicate:
```
pkgname=fifo-test
pkgver=0.0.0
pkgrel=0
pkgdesc="F...`abuild` creates no checksums for FIFO files that are packaged and `apk-tools` <= 2.14.0 complains about the FIFO files having no embedded checksum.
Minimal APKBUILD to replicate:
```
pkgname=fifo-test
pkgver=0.0.0
pkgrel=0
pkgdesc="FIFO problem showcase"
url="null"
arch="noarch"
license="null"
makedepends="busybox"
source=""
builddir="$srcdir/"
options="!check"
package() {
mkdir -p "$pkgdir"
mkfifo "$pkgdir"/test
}
```
This can cause problems in cases such as pre-built s6-linux-init databases which contain service FIFOs.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10888prismlauncher : enable aarch642023-04-15T19:30:56Zexkcprismlauncher : enable aarch64Pls enable aarch64 in the prismlauncher's apk build.Btw There are a flatpka version of prismlauncher for aarch64.Pls enable aarch64 in the prismlauncher's apk build.Btw There are a flatpka version of prismlauncher for aarch64.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10886apk index --incremental2023-10-12T10:08:44ZNatanael Copaapk index --incrementalIt would be nice to be able to update the index without having all the repository locally so builders don't need to have the entire repository locally.It would be nice to be able to update the index without having all the repository locally so builders don't need to have the entire repository locally.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10885libboost_context.so required for nix2023-03-22T15:11:24ZGhost Userlibboost_context.so required for nixI tried to install nix. I turned off the comment for the edge repository in /etc/apk/repositories to get nix then:
doas apk add nix
ERROR: unable to select packages:
so:libboost_context.so.1.81.0 (no such package):
required by: n...I tried to install nix. I turned off the comment for the edge repository in /etc/apk/repositories to get nix then:
doas apk add nix
ERROR: unable to select packages:
so:libboost_context.so.1.81.0 (no such package):
required by: nix-2.13.2-r0[so:libboost_context.so.1.81.0]https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10884apk3: provider priority is not respected2023-10-12T10:08:44ZDaniel Kolesaapk3: provider priority is not respectedI created two packages, `testpkg-a` and `testpkg-b`. They both provide `testfoo` with an identical version, with `testpkg-a` having priority of 1 and `testpkg-b` having priority of 100.
adbdump for `testpkg-a`, showing it has the correc...I created two packages, `testpkg-a` and `testpkg-b`. They both provide `testfoo` with an identical version, with `testpkg-a` having priority of 1 and `testpkg-b` having priority of 100.
adbdump for `testpkg-a`, showing it has the correct priority and provides:
```
#%SCHEMA: 676B6370
# ADB block, size: 292, compat: 0, ver: 0
info:
name: testpkg-a
version: 0.1-r0
unique-id: c1be6a801cc49e691a96f5f12117ac300f13d0eb
description: Test package
arch: x86_64
license: custom:meta
origin: testpkg-a
maintainer: q66 <q66@chimera-linux.org>
url: https://chimera-linux.org
build-time: 1679187819
installed-size: 4096 B
priority: 1
provides: # 1 items
- testfoo=0.1-r0
paths: # 1 items
- acl:
mode: 755
user: root
group: root
# sig v00 h04 8d10a60e37e6ce5ec1ccec8752206cb61e14f90b5e8dbe823c794e6bc078a93235cfca9df149f3792061b4d595cb60c259cfe8522d99..: UNTRUSTED signature
```
adbdump for `testpkg-b`, showing the same:
```
#%SCHEMA: 676B6370
# ADB block, size: 304, compat: 0, ver: 0
info:
name: testpkg-b
version: 0.1-r0
unique-id: 8ce10ac4c5ef480b149024358d9908bce206e708
description: Test package
arch: x86_64
license: custom:meta
origin: testpkg-a
maintainer: q66 <q66@chimera-linux.org>
url: https://chimera-linux.org
build-time: 1679187819
installed-size: 4096 B
priority: 100
provides: # 1 items
- testfoo=0.1-r0
paths: # 1 items
- acl:
mode: 755
user: root
group: root
# sig v00 h04 8d10a60e37e6ce5ec1ccec8752206cb67ecd102f70341aee0ffba8f5162e0cc2c6b8e8255b98fcb58d45efcd9a3c18b75a50945b0825..: UNTRUSTED signature
```
since they have the same version, apk should use the priority as a tie-breaker, and install `testpkg-b` when requesting a `testfoo`. However, this is not the case:
```
$ apk add testfoo
(1/1) Installing testpkg-a (0.1-r0)
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10883apk3: strange output behavior with install_if packages when trying to "add" a...2024-03-22T20:14:48ZDaniel Kolesaapk3: strange output behavior with install_if packages when trying to "add" a non-existent packageMy distribution makes heavy use of install_if, and it generally works well. This is just a harmless but annoying issue with invalid output, with the practical behavior with correct inputs being good.
Since it's hard to explain what's ac...My distribution makes heavy use of install_if, and it generally works well. This is just a harmless but annoying issue with invalid output, with the practical behavior with correct inputs being good.
Since it's hard to explain what's actually going on, here is a way to reproduce it:
```
$ mkdir testroot
$ apk --root testroot --repository "https://repo.chimera-linux.org/current/main" --allow-untrusted --initdb add chimerautils
fetch https://repo.chimera-linux.org/current/main/x86_64/APKINDEX.tar.gz
(1/16) Installing base-files (0.1-r0)
(2/16) Installing iana-etc (20230313-r0)
(3/16) Installing musl (1.2.3-r0)
(4/16) Installing libbz2 (1.0.8-r0)
(5/16) Installing libcxx (15.0.7-r0)
(6/16) Installing libcrypto3 (3.1.0-r0)
(7/16) Installing ncurses-libs (6.4-r0)
(8/16) Installing ncurses-base (6.4-r0)
(9/16) Installing ncurses (6.4-r0)
(10/16) Installing libedit (20220411-r0)
(11/16) Installing musl-fts (1.2.7-r0)
(12/16) Installing liblzma (5.4.1-r0)
(13/16) Installing musl-rpmatch (1.0-r0)
(14/16) Installing libxo (1.6.0-r0)
(15/16) Installing zlib (1.2.13-r0)
(16/16) Installing chimerautils (13.1.2-r0)
OK: 13 MiB in 16 packages
$ mount --bind /proc testroot/proc
$ mount --bind /sys testroot/sys
$ mount --bind /dev testroot/dev
$ cp /etc/resolv.conf testroot/etc
$ apk --root testroot --repository "https://repo.chimera-linux.org/current/main" --allow-untrusted add base-bootstrap
(1/7) Installing debianutils (5.7-r0)
(2/7) Installing libssl3 (3.1.0-r0)
(3/7) Installing openssl (3.1.0-r0)
(4/7) Installing ca-certificates (20230311-r0)
(5/7) Installing apk-tools (3.0.0_pre0-r0)
(6/7) Installing chimera-repo-main (0.1-r0)
(7/7) Installing base-bootstrap (0.1-r0)
Executing ca-certificates-20230311-r0.trigger
Clearing symlinks in /etc/ssl/certs...
done.
Updating certificates in /etc/ssl/certs...
157 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
OK: 16 MiB in 23 packages
$ chroot testroot /bin/sh
# apk update
fetch https://repo.chimera-linux.org/current/main/x86_64/APKINDEX.tar.gz
[https://repo.chimera-linux.org/current/main]
OK: 3315 distinct packages available
# apk add foobar
ERROR: unable to select packages:
foobar (no such package):
required by: world[foobar]
# apk add dinit-chimera
(1/17) Installing awk (20220303-r0)
(2/17) Installing libblkid (2.38.1-r0)
(3/17) Installing libmount (2.38.1-r0)
(4/17) Installing libsmartcols (2.38.1-r0)
(5/17) Installing util-linux-common (2.38.1-r0)
(6/17) Installing mount (2.38.1-r0)
(7/17) Installing kmod (30-r0)
(8/17) Installing procps (4.0.3-r0)
(9/17) Installing libcap (2.67-r0)
(10/17) Installing libkmod (30-r0)
(11/17) Installing udev (253-r0)
(12/17) Installing base-udev (253-r0)
(13/17) Installing udev-dinit (253-r0)
(14/17) Installing udev-dinit-links (253-r0)
(15/17) Installing dinit (0.16.1-r0)
(16/17) Installing tzdata (2022g-r0)
(17/17) Installing dinit-chimera (0.11-r0)
Executing udev-253-r0.trigger
Updating udev hwdb...
OK: 36 MiB in 40 packages
# apk add foobar
ERROR: unable to select packages:
foobar (no such package):
required by: world[foobar]
udev-dinit (virtual):
note: please select one of the 'provided by' packages explicitly
provided by: udev-dinit
required by: udev-dinit-links-253-r0[udev-dinit=253-r0]
# apk add base-man
(1/21) Installing less (608-r0)
(2/21) Installing less-man (608-r0)
(3/21) Installing mandoc (1.14.6-r0)
(4/21) Installing mandoc-man (1.14.6-r0)
(5/21) Installing base-man (1.14.6-r0)
(6/21) Installing debianutils-man (5.7-r0)
(7/21) Installing openssl-man (3.1.0-r0)
(8/21) Installing libedit-man (20220411-r0)
(9/21) Installing chimerautils-man (13.1.2-r0)
(10/21) Installing apk-tools-man (3.0.0_pre0-r0)
(11/21) Installing ncurses-man (6.4-r0)
(12/21) Installing ca-certificates-man (20230311-r0)
(13/21) Installing musl-man (1.2.3-r0)
(14/21) Installing libxo-man (1.6.0-r0)
(15/21) Installing awk-man (20220303-r0)
(16/21) Installing mount-man (2.38.1-r0)
(17/21) Installing kmod-man (30-r0)
(18/21) Installing procps-man (4.0.3-r0)
(19/21) Installing udev-man (253-r0)
(20/21) Installing dinit-man (0.16.1-r0)
(21/21) Installing dinit-chimera-man (0.11-r0)
Executing mandoc-1.14.6-r0.trigger
Regenerating man db...
OK: 44 MiB in 61 packages
# apk add foobar
ERROR: unable to select packages:
foobar (no such package):
required by: world[foobar]
ncurses (virtual):
note: please select one of the 'provided by' packages explicitly
provided by: ncurses
required by: ncurses-man-6.4-r0[ncurses=6.4-r0]
udev-dinit (virtual):
note: please select one of the 'provided by' packages explicitly
provided by: udev-dinit
required by: udev-dinit-links-253-r0[udev-dinit=253-r0]
```
In this case, you can see the issue with the `ncurses` and `udev-dinit` packages. Both packages are real (non-virtual) but are automatically installed. Adding them into world makes them disappear from the list. The `udev-dinit` is also automatically installed by `install_if`, but `ncurses` is not. However, `ncurses-man` is automatically installed by `install_if`, as is `udev-dinit-links`, so the shared thing is that both are implicitly-installed packages treated as dependencies of automatically installed `install_if` packages (though in this case, `ncurses` would be installed by other things even if not a dependency of an `install_if` package).
In larger, more practical systems, this list can get massive, spamming the terminal output when a user makes a typo in package name they are installing. Technically it does not do any other harm, but it's still a UX problem.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10882apk-version: 8.2.0 > 8.2.0012024-03-12T18:00:18ZValery Ushakovapk-version: 8.2.0 > 8.2.001readline package was recently upgraded to patchlevel 1, from `pkgver=8.2.0` to `pkgver=8.2.001`. However apk doesn't consider it to be an upgrade, b/c:
```
$ apk version -t 8.2.0 8.2.001
>
```
The apk sources say that "Leading zero digi...readline package was recently upgraded to patchlevel 1, from `pkgver=8.2.0` to `pkgver=8.2.001`. However apk doesn't consider it to be an upgrade, b/c:
```
$ apk version -t 8.2.0 8.2.001
>
```
The apk sources say that "Leading zero digits get a special treatment", but don't elaborate.
As the result the last component gets token value -1 for single zero in "0" and -2 for two zeroes in "001" (with "1" left over as `TOKEN_DIGIT`).
(xref: initially reported as alpine/aports#14668)https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10880apk-version: x.0_preY is considered newer than x.02023-10-12T10:08:44ZPatrycja Rosaalpine@ptrcnull.meapk-version: x.0_preY is considered newer than x.0```
$ apk3 version -t '6.0_pre1' '6.0'
>
$ apk3 version -t '6.1_pre1' '6.1'
<
```
same happens on apk-tools 2.12.11```
$ apk3 version -t '6.0_pre1' '6.0'
>
$ apk3 version -t '6.1_pre1' '6.1'
<
```
same happens on apk-tools 2.12.11https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10879APK prints warnings and errors to STDOUT not STDERR (re-opened)2023-03-03T11:02:01ZMartin BraunAPK prints warnings and errors to STDOUT not STDERR (re-opened)Continuing with #7107. Right now, it is impossible to run `apk` and only show success messages as warnings and errors are all send to stdout. Sure, I can pipe everything, check the exit code and print only on error, but this is less eleg...Continuing with #7107. Right now, it is impossible to run `apk` and only show success messages as warnings and errors are all send to stdout. Sure, I can pipe everything, check the exit code and print only on error, but this is less elegant. A custom flag that tells `apk` to be quite only on failed operations would also be insufficient, because `apk` shall be part of a wrapper function, so it should really send warnings and errors to the right output, so they can be handled properly higher up.
The original fix was reverted, because a user reported:
> If I run apk and get an error, the message is printed on the current
> line of my terminal and it disappears when I start typing.
I think this is a different issue that should be fixed properly, instead of just sending all output to stdout.
In addition to that, diagnostic infos should be send to stderr, as well, since they result of an error.
`apk add unknown-pkg-foo-baz 2>/dev/null` should be silent.
cc @fabledv3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10878apk's lib/apk/db/scripts.tar is date/time-dependent2023-02-23T09:35:23ZPetr Tomanapk's lib/apk/db/scripts.tar is date/time-dependentThe **```apk```** command writes into the ```/lib/apk/db/scripts.tar``` file. The way ```tar``` works is that the resulting .tar archive takes into account not only the contents of the files packed but also their timestamps (and their or...The **```apk```** command writes into the ```/lib/apk/db/scripts.tar``` file. The way ```tar``` works is that the resulting .tar archive takes into account not only the contents of the files packed but also their timestamps (and their order).
Why could this be a problem? If you run a build that produces e.g. a Docker image on top of the alpine image where you simply do ```RUN apk add curl``` in the source Dockerfile, you get a different resulting image even though the ```curl``` apk is the same and the base alpine image (```FROM alpine:<tag>```) is the same. So, on the very same machine, with the same dependencies, but in a different moment in time, you get a different result.
This effectively means that apk doesn't act in a repeatable way (which may or may not be an intention from the creators of apk/alpine) but it is an issue when trying to make your builds **reproducible**. Please see https://reproducible-builds.org/docs/source-date-epoch/ (SOURCE_DATE_EPOCH) for some attempts how to address this. See also https://stackoverflow.com/questions/32997526/how-to-create-a-tar-file-that-omits-timestamps-for-its-contents how to avoid the time-sensitivity in the ```tar``` tool.
**Possible solutions**:
* instruct tar not to take file timestamps into account (i.e. globally)
* add a cmdline argument to apk that will do the trick above (i.e. only when the user needs so)
* perhaps use the epoch env var mentioned above
For more details how to reproduce, please assume the below Dockerfile:
```
FROM alpine:<fixed_tag>
RUN apk update && apk add --no-cache curl
```
and see the resulting images/containers, and the differences:
```
# build the images
docker build -t tmp_alpine:1 .
docker build -t tmp_alpine:2 .
# create containers but don't run them
docker create --name="tmp_1" tmp_alpine:1
docker create --name="tmp_2" tmp_alpine:2
# export to a tar
docker export tmp_1 -o export_1.tar
docker export tmp_2 -o export_2.tar
# extract
mkdir tmp_1
mkdir tmp_2
tar -xvf export_1.tar -C tmp_1
tar -xvf export_2.tar -C tmp_2
# diff (btw this doesn't work on a Mac cmdline)
diff -r --no-dereference tmp_1 tmp_2
```
The difference will be in the ```scripts.tar``` file - even though the files inside have the same contents, the .tar file itself has a different checksum:
```
~ tar -tvf tmp_1/layer/lib/apk/db/scripts.tar
-rwxr-xr-x 0 root root 131 Nov 24 19:06 busybox-1.33.1-r6.Q1dgtiXUOjvBmrjmjNI1P/d9kQxBw=.post-install
-rwxr-xr-x 0 root root 1056 Nov 24 19:06 busybox-1.33.1-r6.Q1dgtiXUOjvBmrjmjNI1P/d9kQxBw=.post-upgrade
-rwxr-xr-x 0 root root 546 Nov 24 19:06 busybox-1.33.1-r6.Q1dgtiXUOjvBmrjmjNI1P/d9kQxBw=.trigger
-rwxr-xr-x 0 root root 56 Nov 24 19:06 alpine-baselayout-3.2.0-r16.Q1UJtB9cNV4r+/VbxySkEei++qbho=.pre-install
-rwxr-xr-x 0 root root 983 Nov 24 19:06 alpine-baselayout-3.2.0-r16.Q1UJtB9cNV4r+/VbxySkEei++qbho=.post-install
-rwxr-xr-x 0 root root 706 Nov 24 19:06 alpine-baselayout-3.2.0-r16.Q1UJtB9cNV4r+/VbxySkEei++qbho=.pre-upgrade
-rwxr-xr-x 0 root root 983 Nov 24 19:06 alpine-baselayout-3.2.0-r16.Q1UJtB9cNV4r+/VbxySkEei++qbho=.post-upgrade
-rwxr-xr-x 0 root root 42 Nov 24 19:06 glibc-bin-2.33-r0.Q1nxKJj3cqOPuthsgXHKenUAGLhEM=.trigger
-rwxr-xr-x 0 root root 137 Nov 24 19:06 ca-certificates-20191127-r5.Q1+3SNr5R52GfBxkXj9gkEr6QAWZw=.post-deinstall
-rwxr-xr-x 0 root root 72 Nov 24 19:06 ca-certificates-20191127-r5.Q1+3SNr5R52GfBxkXj9gkEr6QAWZw=.trigger
~ tar -tvf tmp_2/layer/lib/apk/db/scripts.tar
-rwxr-xr-x 0 root root 131 Nov 24 19:10 busybox-1.33.1-r6.Q1dgtiXUOjvBmrjmjNI1P/d9kQxBw=.post-install
-rwxr-xr-x 0 root root 1056 Nov 24 19:10 busybox-1.33.1-r6.Q1dgtiXUOjvBmrjmjNI1P/d9kQxBw=.post-upgrade
-rwxr-xr-x 0 root root 546 Nov 24 19:10 busybox-1.33.1-r6.Q1dgtiXUOjvBmrjmjNI1P/d9kQxBw=.trigger
-rwxr-xr-x 0 root root 56 Nov 24 19:10 alpine-baselayout-3.2.0-r16.Q1UJtB9cNV4r+/VbxySkEei++qbho=.pre-install
-rwxr-xr-x 0 root root 983 Nov 24 19:10 alpine-baselayout-3.2.0-r16.Q1UJtB9cNV4r+/VbxySkEei++qbho=.post-install
-rwxr-xr-x 0 root root 706 Nov 24 19:10 alpine-baselayout-3.2.0-r16.Q1UJtB9cNV4r+/VbxySkEei++qbho=.pre-upgrade
-rwxr-xr-x 0 root root 983 Nov 24 19:10 alpine-baselayout-3.2.0-r16.Q1UJtB9cNV4r+/VbxySkEei++qbho=.post-upgrade
-rwxr-xr-x 0 root root 42 Nov 24 19:10 glibc-bin-2.33-r0.Q1nxKJj3cqOPuthsgXHKenUAGLhEM=.trigger
-rwxr-xr-x 0 root root 137 Nov 24 19:10 ca-certificates-20191127-r5.Q1+3SNr5R52GfBxkXj9gkEr6QAWZw=.post-deinstall
-rwxr-xr-x 0 root root 72 Nov 24 19:10 ca-certificates-20191127-r5.Q1+3SNr5R52GfBxkXj9gkEr6QAWZw=.trigger
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10877"sh: out of range" error message when installing certain packages.2023-02-22T09:49:57ZShyam Sunder"sh: out of range" error message when installing certain packages.I've been noticing a strange error message pop up when adding certain packages (namely `postgresql14-client`, but there might be others) inside a docker container.
Command:
```
apk --no-cache add postgresql14-client
```
Response:
```s...I've been noticing a strange error message pop up when adding certain packages (namely `postgresql14-client`, but there might be others) inside a docker container.
Command:
```
apk --no-cache add postgresql14-client
```
Response:
```shell
fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/community/x86_64/APKINDEX.tar.gz
(1/6) Installing postgresql-common (1.1-r3)
Executing postgresql-common-1.1-r3.pre-install
(2/6) Installing libpq (15.2-r0)
(3/6) Installing ncurses-terminfo-base (6.3_p20221119-r0)
(4/6) Installing ncurses-libs (6.3_p20221119-r0)
(5/6) Installing readline (8.2.0-r0)
(6/6) Installing postgresql14-client (14.7-r0)
Executing busybox-1.35.0-r29.trigger
Executing postgresql-common-1.1-r3.trigger
* Setting postgresql14 as the default version
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.17/main: No such file or directory
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.17/community: No such file or directory
sh: out of range
OK: 11 MiB in 21 packages
```
Note that despite the error message, the package does install fine, and I'm able to run its installed binaries (namely `pg_dump`) just fine.
I have confirmed that this issue can be reproduced on the `v3.15`, `v3.16`, `v3.17`, `edge`, and `latest` tags of the official Alpine Linux Docker images. Note that other packages, such as `apk --no-cache add bash` don't seem to generate this message.
Judging by the nature of the error, I'm suspecting that this is an error in APK, but let me know if this should bug be opened on the postgres package instead.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10876apk.static: --initdb without adding a package?2023-02-28T10:19:45ZKasper Kapk.static: --initdb without adding a package?unlike `apk add`, there is no `--initdb` option in `apk search`, `apk fetch`, `apk cache` etc. to initialize the db and directory structure in a fresh environment (different `--root` or running apk.static on e.g. debian). not even `apk f...unlike `apk add`, there is no `--initdb` option in `apk search`, `apk fetch`, `apk cache` etc. to initialize the db and directory structure in a fresh environment (different `--root` or running apk.static on e.g. debian). not even `apk fix`, `apk update` or `apk upgrade` help in this case. there is no top-level command to "(re-)initialize the apk environment idempotently" either.
so if we wanted to use `search`, `fetch`, `cache` or any other command _before_ the first `add`, it is simply not possible(!?). the workaround is wasteful: `add` some random package with `--initdb`, then perform the desired action. otherwise, depending on the command, we are either greeted with:
```
ERROR: Unable to lock database: No such file or directory
ERROR: Failed to open apk database: No such file or directory
```
or
```
WARNING: opening from cache http://dl-cdn.alpinelinux.org/alpine/edge/main: cache not available
WARNING: opening from cache http://dl-cdn.alpinelinux.org/alpine/edge/community: cache not available
```