apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2019-07-14T07:29:02Zhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/1069apk info -e should exit with err when package is not installed2019-07-14T07:29:02ZNatanael Copaapk info -e should exit with err when package is not installedapk info -e says libiconv-dev is installed when it is not.
ncdev:~/aports/main/cryptsetup$ apk --version
apk-tools 2.3.0, compiled for x86.
ncdev:~/aports/main/cryptsetup$ abuild -r
>>> cryptsetup: Checking sanity of /ho...apk info -e says libiconv-dev is installed when it is not.
ncdev:~/aports/main/cryptsetup$ apk --version
apk-tools 2.3.0, compiled for x86.
ncdev:~/aports/main/cryptsetup$ abuild -r
>>> cryptsetup: Checking sanity of /home/ncopa/aports/main/cryptsetup/APKBUILD...
>>> cryptsetup: Analyzing dependencies...
>>> ERROR: cryptsetup: Conflicting package(s) installed: libiconv-dev
>>> ERROR: cryptsetup: all failed
ncdev:~/aports/main/cryptsetup$ sudo apk del libiconv-dev
OK: 428 MiB in 172 packages
ncdev:~/aports/main/cryptsetup$ apk info -e libiconv-dev; echo $?
0
ncdev:~/aports/main/cryptsetup$ grep libiconv-dev /lib/apk/db/installed
ncdev:~/aports/main/cryptsetup$
*(from redmine: issue id 1069, created on 2012-03-29, closed on 2012-04-26)*
* Changesets:
* Revision ebaf8305b5c9cc5bdc5d640f4cb25e058f7a2c26 by Timo Teräs on 2012-03-30T06:20:21Z:
```
info: fix exit code for -e
fixes #1069
```Timo TeräsTimo Teräs2012-04-30https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10688APK re-inserts basic auth info across domains when following redirects2021-04-11T11:27:49ZMorgan HeinAPK re-inserts basic auth info across domains when following redirectsThe code related to this bug:
https://github.com/alpinelinux/apk-tools/blob/master/libfetch/http.c\#L1081
Summary:
- add basic auth info to a repository in /etc/apk/repositories
- request an apk update
- server handling request r...The code related to this bug:
https://github.com/alpinelinux/apk-tools/blob/master/libfetch/http.c\#L1081
Summary:
- add basic auth info to a repository in /etc/apk/repositories
- request an apk update
- server handling request returns a 302 redirect to provide the
APKINDEX.tar.gz file
- apk follows redirect, re-injects basic auth, and makes request
This is done regardless of domain boundaries. In our case, this is
non-standard behavior that is causing issues. This ticket is not meant
as a judgement call that the current behavior is wrong, but that it
would, at the very least, be nice to be able to disable this behavior.
Furthermore, DNF, YUM, and APT do not have this behavior, so APK is
special in this case. This may be a feature request, if not considered a
bug.
Here’s a cleaned up excerpt of a conversation from the irc channel that
explains this bug in more detail:
<johnnyfive> my issue is this: I have a private repo stored on S3, which
is served behind a gateway with basic auth. The gateway creates signed
S3 urls, and redirects them to apk. apk handles the redirection just
fine, but the issue is it ‘re-issues’ or re-injects the original basic
auth info into the redirect, which causes s3 to break.
<johnnyfive> \[to further\] let me explain. So we have an s3 bucket that
we don’t want direct access to (the logging on s3 natively is not
granular enough to give us the information we need)
<johnnyfive> so, instead we have a mildly altered http gateway, that
restricts access via basic auth
<johnnyfive> which, when a file is requested, creates a signed url to
the s3 bucket, and returns a redirect to that file
<AinNero> actually, if gateway and s3 url are on different domain, and
the auth data is passed, its an bug in apk
<johnnyfive> it is a different domain
<johnnyfive> the redirect is a 302
<AinNero> johnnyfive:
https://github.com/alpinelinux/apk-tools/blob/master/libfetch/http.c\#L1081
<AinNero> apk is passing the auth data when following redirects, so the
question is, if thats valid or not
<johnnyfive> yep, no idea what the ‘correct’ behavior is, but I will
mention that yum+dnf+apt do not have this behavior
*(from redmine: issue id 9490, created on 2018-09-28)*Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10674apk refuses to install seamonkey along with firefox-esr2020-02-21T14:21:36Zalgitbotapk refuses to install seamonkey along with firefox-esrIt seems that apk refuses to install packages that have libraries with
same name even if they are going to install different paths.
```
ERROR: unsatisfiable constraints:
firefox-esr-52.6.0-r1:
conflicts: seamonkey-2.48-r1[so:liblg...It seems that apk refuses to install packages that have libraries with
same name even if they are going to install different paths.
```
ERROR: unsatisfiable constraints:
firefox-esr-52.6.0-r1:
conflicts: seamonkey-2.48-r1[so:liblgpllibs.so=0] seamonkey-2.48-r1[so:libxul.so=0]
satisfies: world[firefox-esr]
seamonkey-2.48-r1:
conflicts: firefox-esr-52.6.0-r1[so:liblgpllibs.so=0] firefox-esr-52.6.0-r1[so:libxul.so=0]
satisfies: world[seamonkey]
```
*(from redmine: issue id 8648, created on 2018-03-15)*https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10652apk doesn't handle upgrades correctly when old dep versions are still availab...2019-07-22T19:06:24ZA. Wilcoxapk doesn't handle upgrades correctly when old dep versions are still available in repositoryWe’ve just released Adélie 1.0-BETA3, and due to that, we have lots of
people upgrading their computers… we’ve had at least three cases so far
today where there’s been the same error:
ERROR: unsatisfiable constraints:
harfbuzz...We’ve just released Adélie 1.0-BETA3, and due to that, we have lots of
people upgrading their computers… we’ve had at least three cases so far
today where there’s been the same error:
ERROR: unsatisfiable constraints:
harfbuzz-icu-1.8.8-r1:
breaks: harfbuzz-dev-2.4.0-r0[harfbuzz-icu=2.4.0-r0]
libpcrecpp-8.42-r1:
breaks: pcre-dev-8.43-r0[libpcrecpp=8.43-r0]
All of these cases are when qt5-qtbase-dev (or another Qt 5 development
package) is installed. This helpfully included our primary web server,
which has only adelie-base, apache-httpd, and qt5-qtbase-dev installed.
I enabled DEBUG\_PRINT in apk/solver.c, rebuilt, and tried again with
this custom apk-tools build. Output is included in the attached 1.33 MB
log file.
In the middle you find this chunk:
select_package: harfbuzz-icu (requirers=1, iif=0)
consider harfbuzz-icu-1.8.8-r1 iif_triggered=0, tag_ok=1, selectable=1, provider_priority=0, installed=1
consider harfbuzz-icu-2.3.1-r0 iif_triggered=0, tag_ok=1, selectable=1, provider_priority=0, installed=0
consider harfbuzz-icu-2.4.0-r0 iif_triggered=0, tag_ok=1, selectable=1, provider_priority=0, installed=0
selecting: harfbuzz-icu-1.8.8-r1, available: 1
assign harfbuzz-icu to harfbuzz-icu-1.8.8-r1
disqualify_package: harfbuzz-icu-2.3.1-r0 (conflicting provides)
queue_dirty: pc:harfbuzz
disqualify_package: harfbuzz-icu-2.4.0-r0 (conflicting provides)
assign so:libharfbuzz-icu.so.0 to harfbuzz-icu-1.8.8-r1
This seems to be a small issue in the solver:
https://git.alpinelinux.org/apk-tools/tree/src/solver.c\#n514 - it
“Prefer\[s\] existing package\[s\]”, even during a system upgrade.
Anything in world is considered for upgrade, but **dependencies** of
world are only considered for upgrade if the existing package versions
are no longer present/available. I’m aware that the Alpine policy is to
run the equivalent of cleanoldpkg on every build, but it isn’t our
policy at Adélie - once a package is published to our mirrors, it is
never removed for any reason other than if there is a license error
My personal opinion is that there should perhaps be another flag to
upgrade, maybe -d/—deep for “deep upgrades” which will upgrade **every**
package, not just world.
*(from redmine: issue id 10532, created on 2019-06-01)*Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10648APK Randomly failing when using virtual packages2019-07-14T07:53:04ZAlex ViscreanuAPK Randomly failing when using virtual packagesWe have randomly experienced errors while using apk to install packages
using the \`—virtual\` fiag. As there was no apparent logic behind the
issues we decided to run the same command multiple times, and we
realized that the errors seem...We have randomly experienced errors while using apk to install packages
using the \`—virtual\` fiag. As there was no apparent logic behind the
issues we decided to run the same command multiple times, and we
realized that the errors seem to be randomly succeeding. We performed
the tests using alpine 3.9 and it never raises any error.
The command that allows as to trigger the error is
apk add --no-cache --virtual=.build-deps curl build-base postgresql-dev && apk add --no-cache --virtual=.run-deps libpq && apk add --no-cache --virtual=.webpack-deps nodejs nodejs-npm
I’ve set up a GitLab repository, with parallel pipelines so there can be
easily replicated. As you can see, the only jobs that are failing are
the ones running alpine 3.10, and the number of failing jobs is totally
random
https://gitlab.com/alexviscreanu/test-alpine-build/pipelines/68980751/builds
https://gitlab.com/alexviscreanu/test-alpine-build/pipelines/68980779/builds
https://gitlab.com/alexviscreanu/test-alpine-build/pipelines/68980829/builds
And the error trace always seem to be the same
$ apk add --no-cache --virtual=.build-deps curl build-base postgresql-dev && apk add --no-cache --virtual=.run-deps libpq && apk add --no-cache --virtual=.webpack-deps nodejs nodejs-npm
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
(1/31) Installing ca-certificates (20190108-r0)
(2/31) Installing nghttp2-libs (1.38.0-r0)
(3/31) Installing libcurl (7.65.1-r0)
(4/31) Installing curl (7.65.1-r0)
(5/31) Installing binutils (2.32-r0)
(6/31) Installing libmagic (5.37-r0)
(7/31) Installing file (5.37-r0)
(8/31) Installing gmp (6.1.2-r1)
(9/31) Installing isl (0.18-r0)
(10/31) Installing libgomp (8.3.0-r0)
(11/31) Installing libatomic (8.3.0-r0)
(12/31) Installing libgcc (8.3.0-r0)
(13/31) Installing mpfr3 (3.1.5-r1)
(14/31) Installing mpc1 (1.1.0-r0)
(15/31) Installing libstdc++ (8.3.0-r0)
(16/31) Installing gcc (8.3.0-r0)
(17/31) Installing musl-dev (1.1.22-r2)
(18/31) Installing libc-dev (0.7.1-r0)
(19/31) Installing g++ (8.3.0-r0)
(20/31) Installing make (4.2.1-r2)
(21/31) Installing fortify-headers (1.1-r0)
(22/31) Installing build-base (0.5-r1)
(23/31) Installing pkgconf (1.6.1-r1)
(24/31) Installing openssl-dev (1.1.1c-r0)
(25/31) Installing db (5.3.28-r1)
(26/31) Installing libsasl (2.1.27-r3)
(27/31) Installing libldap (2.4.47-r2)
(28/31) Installing libpq (11.4-r0)
(29/31) Installing postgresql-libs (11.4-r0)
(30/31) Installing postgresql-dev (11.4-r0)
(31/31) Installing .build-deps (20190702.104055)
Executing busybox-1.30.1-r2.trigger
Executing ca-certificates-20190108-r0.trigger
OK: 196 MiB in 45 packages
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
(1/1) Installing .run-deps (20190702.104058)
OK: 196 MiB in 46 packages
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
ERROR: unsatisfiable constraints:
.webpack-deps (missing):
required by: world[.webpack-deps=20190702.104058]
If we remove the virtual packages everything works fine, but we never
had any issue until now. Are we doing something wrong? How can it be
explained that it only fails sometimes?
*(from redmine: issue id 10648, created on 2019-07-02)*
* Changesets:
* Revision b45415b1096e76f40b32326d2798123f81fe5976 by Timo Teräs on 2019-07-02T12:27:57Z:
```
add: fix virtual package id generation
Fixes 37fbafcd by adding more input to the hash than just second
grained time stamp - collisions would happen when running apk
scripted.
For virtual package the hash works only as unique identifier, so
try to add elements that should make it unique in most cases.
Fixes #10648
```
* Revision 1b98a2fa98c5af24a6a55cc61a4ff1ba1fa1f34f by Timo Teräs on 2019-07-08T07:56:52Z:
```
main/apk-tools: cherry-pick fix for #10648
ref #10648
(cherry picked from commit 129e1119ed93b1be7d0c168567a3cd8d3a970978)
```Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10533Support "epoch" in APKBUILD, like it works in PKGBUILD2024-03-14T14:25:39ZOliver SmithSupport "epoch" in APKBUILD, like it works in PKGBUILDSometimes software needs to follow a new versioning scheme, which would
make newer releases appear to have a smaller version than older
releases.
Arch Linux has the “epoch” field in their PKGBUILDs:
https://wiki.archlinux.org/index.ph...Sometimes software needs to follow a new versioning scheme, which would
make newer releases appear to have a smaller version than older
releases.
Arch Linux has the “epoch” field in their PKGBUILDs:
https://wiki.archlinux.org/index.php/PKGBUILD#epoch
It would be nice to have this in Alpine too (abuild is makepkg light
after all ;)).
(This does not have any priority to me right now, otherwise I would work
towards implementing this in apk-tools, if it is desired.)
*(from redmine: issue id 10533, created on 2019-06-01)*backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10219apk add --quiet is not quiet2020-01-17T01:54:18Zalgitbotapk add --quiet is not quiet-q/—quiet is supposed to make apk quite
script
docker run —rm -it python:3.7.3-alpine3.9 apk add —quiet bash
Results in following output captured in typescript:
\`\`\`
<sup>\[8</sup>\[\[0K<sup>\[7\ 62%\ ██████████████████████████...-q/—quiet is supposed to make apk quite
script
docker run —rm -it python:3.7.3-alpine3.9 apk add —quiet bash
Results in following output captured in typescript:
\`\`\`
<sup>\[8</sup>\[\[0K<sup>\[7\ 62%\ █████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████</sup>\[8<sup>\[\[0K</sup>\[7
63%
██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████
<sup>\[8</sup>\[\[0K<sup>\[7\ 65%\ ████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████</sup>\[8<sup>\[\[0K</sup>\[7
66%
█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████
<sup>\[8</sup>\[\[0K<sup>\[7\ 68%\ ██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████</sup>\[8<sup>\[\[0K</sup>\[7
69%
███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████
<sup>\[8</sup>\[\[0K<sup>\[7\ 70%\ █████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████</sup>\[8<sup>\[\[0K</sup>\[7
72%
██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████
<sup>\[8</sup>\[\[0K<sup>\[7\ 73%\ ███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████</sup>\[8<sup>\[\[0K</sup>\[7
75%
████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████
<sup>\[8</sup>\[\[0K<sup>\[7\ 76%\ ██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████</sup>\[8<sup>\[\[0K</sup>\[7
78%
███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████
<sup>\[8</sup>\[\[0K<sup>\[7\ 79%\ ████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████</sup>\[8<sup>\[\[0K</sup>\[7
81%
██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████
<sup>\[8</sup>\[\[0K<sup>\[7\ 82%\ ███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████</sup>\[8<sup>\[\[0K</sup>\[7
83%
████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████
<sup>\[8</sup>\[\[0K<sup>\[7\ 85%\ █████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████</sup>\[8<sup>\[\[0K</sup>\[7
86%
███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████
<sup>\[8</sup>\[\[0K<sup>\[7\ 88%\ ████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████</sup>\[8<sup>\[\[0K</sup>\[7
89%
█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████
<sup>\[8</sup>\[\[0K<sup>\[7\ 91%\ ███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████</sup>\[8<sup>\[\[0K</sup>\[7
92%
████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████
<sup>\[8</sup>\[\[0K<sup>\[7\ 93%\ █████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████</sup>\[8<sup>\[\[0K</sup>\[7
95%
██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████
<sup>\[8</sup>\[\[0K<sup>\[7\ 96%\ ████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████</sup>\[8<sup>\[\[0K</sup>\[7100%
████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████<sup>\[8</sup>\[\[0K
\`\`\`
Tested with:
apk-tools 2.10.3, compiled for x86\_64.
*(from redmine: issue id 10219, created on 2019-04-09)*https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10201renameat fails in apk-tools when upgrading a package where V1 has a directory...2019-12-27T14:48:55ZArchis Gorerenameat fails in apk-tools when upgrading a package where V1 has a directory and V2 has a fileWe noticed the issue due to this bug:
https://github.com/netdata/netdata/issues/5713
I can explain the use-case in detail if you’d like, but quite simply
there’s an issue that we surfaced when upgrading packages.
Specifically at this l...We noticed the issue due to this bug:
https://github.com/netdata/netdata/issues/5713
I can explain the use-case in detail if you’d like, but quite simply
there’s an issue that we surfaced when upgrading packages.
Specifically at this line:
https://git.alpinelinux.org/apk-tools/tree/src/database.c\#n2740 (and
presumably at other places where renameat is called), when name is a
directory, but tmpname is a file it fails with EISDIR.
I instrumented the line with this:
\`\`\`
if (renameat(db->root\_fd, tmpname,
db->root\_fd, name) != 0) {
apk\_error(PKG\_VER\_FMT“: failed to rename %s to %s (errno=%d,
strerror=%s EISDIR: %d).”,
PKG\_VER\_PRINTF(ipkg->pkg),
tmpname, name,
errno, strerror(errno), EISDIR);
ipkg->broken\_files = 1;
}
\`\`\`
And got this output:
\`\`\`
ERROR: py2-psycopg2-2.7.5-r0: failed to rename
usr/lib/python2.7/site-packages/.apk.e6a4129270b3b99b221d1dbc3289eb2ec9dd67d2f0113746
to usr/lib/python2.7/site-packages/psycopg2-2.7.5-py2.7.egg-info
(errno=21, strerror=Is a directory EISDIR: 21).
\`\`\`
A google search confirms this isn’t an isolated issue
(https://www.google.com/search?source=hp&ei=tFOoXM-KFN6-0PEP9dKXgAY&q=alpine<span
class="underline">“failed+to+rename”&btnK=Google+Search&oq=alpine</span>“failed+to+rename”&gs\_l=psy-ab.3..33i22i29i30l10.852.2458..3285…0.0..0.83.614.11……0….1j2..gws-wiz…..0..0i131j0.DbDWol4S26w)
I’m a long-time Alpine user but new here, and I’ve read contributor
guidelines. I’d be happy to submit patches and help in any way I can if
you think this is a fix worth accepting.
I’d like to propose two changes. The first of which is to simply print
\`errno\` and \`strerror(errno)\` as part of the error message - since
the information is available at the failure site, it would really help
everyone just see what the error was.
Secondly, I’d love guidance on what the expected semantics should be
when V1 has a directory called Foo, but V2 makes it a file called Foo,
and then I can submit patches to fix that.
Happy to hear thoughts, suggestions, comments.
*(from redmine: issue id 10201, created on 2019-04-06)*
* Uploads:
* [0001-Add-more-diagnostic-error-details-to-renameat-failur.patch](/uploads/31a6452a4fa8764f7e41c23b9afea49f/0001-Add-more-diagnostic-error-details-to-renameat-failur.patch) The proposed patch for better debugging informationTimo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10157apk exits with 0 when given invalid flags2019-12-27T14:54:46ZChristopher Croneapk exits with 0 when given invalid flagsIt appears that apk exits with a 0 exit code even when an invalid option
is passed. A case follows below:
$ docker run --rm -it alpine:3.9.2
# apk add --invalid-option git
apk: unrecognized option: invalid-option
fetch h...It appears that apk exits with a 0 exit code even when an invalid option
is passed. A case follows below:
$ docker run --rm -it alpine:3.9.2
# apk add --invalid-option git
apk: unrecognized option: invalid-option
fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/x86_64/APKINDEX.tar.gz
(1/7) Installing ca-certificates (20190108-r0)
(2/7) Installing nghttp2-libs (1.35.1-r0)
(3/7) Installing libssh2 (1.8.1-r0)
(4/7) Installing libcurl (7.64.0-r1)
(5/7) Installing expat (2.2.6-r0)
(6/7) Installing pcre2 (10.32-r1)
(7/7) Installing git (2.20.1-r0)
Executing busybox-1.29.3-r10.trigger
Executing ca-certificates-20190108-r0.trigger
OK: 20 MiB in 21 packages
/ # echo $?
0
*(from redmine: issue id 10157, created on 2019-03-26)*
* Uploads:
* [0001-Fix-show-help-when-invalid-option-is-passed-to-apk.patch](/uploads/4f456a804bb9a8687d930562c01b8c92/0001-Fix-show-help-when-invalid-option-is-passed-to-apk.patch)https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/9957"abuild deps" is no more updates dependency list2019-12-27T14:16:19ZTaner Tas"abuild deps" is no more updates dependency listDuring package development, abuild was able to install each newly added
dependency when consecutively running “abuild deps” each time.
But it seems this useful feature broken at some point. Now, we have to
do “abuild undeps” and then “...During package development, abuild was able to install each newly added
dependency when consecutively running “abuild deps” each time.
But it seems this useful feature broken at some point. Now, we have to
do “abuild undeps” and then “abuild deps” to install newly added
dependencies.
Please revert it previous behavior otherwise package development process
will be unnecessarily painful.
*(from redmine: issue id 9957, created on 2019-02-03)*
* Relations:
* duplicates #9651
* Changesets:
* Revision 37fbafcd928c466c82c892a7868d686d710e5d07 by Timo Teräs on 2019-06-03T06:33:43Z:
```
add: make virtual packages upgradeable (ref #9957)
Originally the virtual packages could have dependencies added to it.
However, commit b06e3b99 broke this behaviour to fix error reporting.
The root cause however was that the virtual depedency package was not
properly versioned.
This fixes to use current date/time as the package version, and
constructs the "faked" package hash from it. This effectively makes
"add -t virtpkg deps.." replace the dependencies which should be the
desired behaviour for "abuild deps".
'world' dependency to the generated virtual package is also now
versioned to make sure it get's upgraded.
```Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/9634apk symbolic link handling2022-12-21T20:00:16ZTony Garnock-Jonesapk symbolic link handlingI suspect there is a bug in \`apk add\`’s handling of symlinks when
using \`—root\` pointing to an area of the file system not on the same
mount as the running root directory, when the symlink is to end up in
the root directory.
I...I suspect there is a bug in \`apk add\`’s handling of symlinks when
using \`—root\` pointing to an area of the file system not on the same
mount as the running root directory, when the symlink is to end up in
the root directory.
I had an APKBUILD with with a \`package()\` routine that included:
…
ln -s /media/data “$pkgdir”/data
ln -s /etc/crontabs “$pkgdir”/var/spool/cron/crontabs
ln -s /proc/mounts “$pkgdir”/etc/mtab
…
When installing the package using
apk —root targetroot —initdb add …(many packages)…
where \`targetroot\` was a **mount point** for the file system under
construction, it produced an error in apk’s \`src/database.c\`
\[here\](https://github.com/alpinelinux/apk-tools/blob/8fa193ecda2a71de3ff5f826205351b185d15054/src/database.c\#L2731-L2736),
/\* Overwrite the old file \*/
if (renameat(db->root\_fd, tmpname,
db->root\_fd, name) != 0) {
apk\_error(PKG\_VER\_FMT“: failed to rename %s to %s.”,
PKG\_VER\_PRINTF(ipkg->pkg), tmpname, name);
ipkg->broken\_files = 1;
}
Adding a \`perror(“renameat”)\` before the \`apk\_error\` showed that
the
cause of the failure was \`EXDEV\`:
EXDEV oldpath and newpath are not on the same mounted filesystem.
(Linux permits a filesystem to be mounted at multiple points,
but rename() does not work across different mount points, even
if the same filesystem is mounted on both.)
Changing the APKBUILD to omit the **first** symlink (\`/data\`),
leaving
the other two alone (\`/var/spool/cron/crontabs\` and \`/etc/mtab\`),
let
the installation complete successfully!
I suspect that the problem is in \`format\_tmpname\` in
\`src/database.c\`.
Specifically, I think that the tmpname is built like
the/target/directory + /.apk. + somerandomstuff
So for examples like the \`/etc/mtab\` symlink, the tmpname will be
etc + /.apk. + somerandomstuff
i.e. a relative path, BUT in the case where the target directory is
the ROOT directory, the tmpname will be
/.apk. + somerandomstuff
i.e. it will be an ABSOLUTE path.
Now, renameat(2) ignores \`db->root\_fd\` if \`tmpname\` is an
absolute
path, and so it will attempt to move a file from the actual root to
somewhere in the \`—root\` folder, leading to EXDEV.
I believe the fix COULD involve changing \`format\_tmpname\` to treat
an
empty \`f<s><span
style="text-align:right;">diri</span></s>>dir->name\` specially,
resulting in a relative tmpname,
but I am not 100% certain.
For now, I am working around the issue by removing the
ln -s /media/data “$pkgdir”/data
line from APKBUILD’s \`package()\`, and instead adding \`ln -s
/media/data /data\` to the \`pre-install\` script.
*(from redmine: issue id 9634, created on 2018-11-09)*https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/9621Fix compilation on PLD Linux2020-01-03T11:25:30ZElan RuusamäeFix compilation on PLD LinuxI’ve made some compile fixes, now I want to publish them.
So, attaching as git format match.
To apply:
```
git am 0001-fix-strncpy-bounds-errors.patch
git am 0002-include-sys-sysmacros.h-for-makedev-definition.patch
```
*(from r...I’ve made some compile fixes, now I want to publish them.
So, attaching as git format match.
To apply:
```
git am 0001-fix-strncpy-bounds-errors.patch
git am 0002-include-sys-sysmacros.h-for-makedev-definition.patch
```
*(from redmine: issue id 9621, created on 2018-11-03, closed on 2019-05-03)*
* Uploads:
* [0001-fix-strncpy-bounds-errors.patch](/uploads/5cbde551a5f6d6bbe8d50b1dd54cf3c7/0001-fix-strncpy-bounds-errors.patch) fix strncpy bounds errors
* [0002-include-sys-sysmacros.h-for-makedev-definition.patch](/uploads/4dc71e8a0e7d357bfc8201b555e7f985/0002-include-sys-sysmacros.h-for-makedev-definition.patch) include sys/sysmacros.h for makedev definitionhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/8792Add new option --exclude for apk upgrade2019-12-27T14:50:58ZJakub JirutkaAdd new option --exclude for apk upgradeAllow user to exclude specific packages from upgrading (e.g. kernel)
without modifying `/etc/apk/world` or using workaround as
`apk upgrade -s` and `apk add -u` for each package except the ones I
want to exclude.
*(from redmine: issue ...Allow user to exclude specific packages from upgrading (e.g. kernel)
without modifying `/etc/apk/world` or using workaround as
`apk upgrade -s` and `apk add -u` for each package except the ones I
want to exclude.
*(from redmine: issue id 8792, created on 2018-04-12)*https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/8360Update for Lua 5.32020-01-29T17:55:01ZJakub JirutkaUpdate for Lua 5.3apk’s Lua module is currently built for Lua 5.2.
I think that it doesn’t make much sense to keep maintaining Lua 5.2, I’d
like to remove it and keep just Lua 5.3 and LuaJIT.
*(from redmine: issue id 8360, created on 2017-12-29)*apk’s Lua module is currently built for Lua 5.2.
I think that it doesn’t make much sense to keep maintaining Lua 5.2, I’d
like to remove it and keep just Lua 5.3 and LuaJIT.
*(from redmine: issue id 8360, created on 2017-12-29)*https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/8161Don't use cached items if --no-cache is specified and proxy is used2019-07-14T07:53:03ZAntoni DabekDon't use cached items if --no-cache is specified and proxy is usedCurrently apk would use cached in proxy copy of item it is fetching from
repository because it does not indicate that it would prefer to use
newest version. It would be useful if when —no-cache or other new option
is used, apk would add ...Currently apk would use cached in proxy copy of item it is fetching from
repository because it does not indicate that it would prefer to use
newest version. It would be useful if when —no-cache or other new option
is used, apk would add “Cache-Control” HTTP header with value “no-cache”
to ensure that newest copy of index and/or package is being downloaded.
*(from redmine: issue id 8161, created on 2017-11-16, closed on 2019-05-03)*
* Relations:
* relates #5980
* Changesets:
* Revision f90af35e9c563bd4f865d8d47a7ae357191494db by Timo Teräs on 2018-01-03T12:25:07Z:
```
libfetch: add option to set "Cache-Control: no-cache"
ref #8161
```
* Revision 2da67940d50865d206f6a79165ce7b3de5a90de3 by Timo Teräs on 2018-01-03T14:00:38Z:
```
url: add "Cache-Control: no-cache" header with --force-refresh
fixes #8161
```
* Revision b7f70c067c035493cdfbf08fa78a0befbbfde3ea by Timo Teräs on 2018-01-09T07:56:05Z:
```
libfetch: add option to set "Cache-Control: no-cache"
ref #8161
(cherry picked from commit f90af35e9c563bd4f865d8d47a7ae357191494db)
```
* Revision ecc6d60e64cb6bc9cb76a4e22d4113a76cd75bdb by Timo Teräs on 2018-01-09T07:56:15Z:
```
url: add "Cache-Control: no-cache" header with --force-refresh
fixes #8161
(cherry picked from commit 2da67940d50865d206f6a79165ce7b3de5a90de3)
```Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/8160apk-tool/fetchlib could use https_proxy environmental variable to access https2019-07-14T07:53:03ZAntoni Dabekapk-tool/fetchlib could use https_proxy environmental variable to access httpsIt would be useful feature if apk would handle HTTP and HTTPS protocols
in same way and use proxy taken from https\_proxy environmental variable
for accessing repositories that are using HTTPS protocol.
*(from redmine: issue id 8160, c...It would be useful feature if apk would handle HTTP and HTTPS protocols
in same way and use proxy taken from https\_proxy environmental variable
for accessing repositories that are using HTTPS protocol.
*(from redmine: issue id 8160, created on 2017-11-16, closed on 2019-05-03)*
* Changesets:
* Revision 99e7bb93dfff2f43987b81ce7600ad8fbd0ce64c by Timo Teräs on 2018-01-03T08:43:31Z:
```
libfetch: honor https_proxy variable for https
fixes #8160
```
* Revision c051f6f10ff08fd68a091cd236c3606027952db3 by Timo Teräs on 2018-01-09T07:55:26Z:
```
libfetch: honor https_proxy variable for https
fixes #8160
(cherry picked from commit 99e7bb93dfff2f43987b81ce7600ad8fbd0ce64c)
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/7531APK add --upgrade flag non-transient2022-12-25T13:01:38ZTed TraskAPK add --upgrade flag non-transientWhen ‘apk add —upgrade’ is run, the ‘—repository’ option is ignored. I
would think this is a logical operation to attempt - “I would like to
upgrade this package from this particular repository”. Instead, the
upgrade does not happen.
Pr...When ‘apk add —upgrade’ is run, the ‘—repository’ option is ignored. I
would think this is a logical operation to attempt - “I would like to
upgrade this package from this particular repository”. Instead, the
upgrade does not happen.
Preliminary steps:
1) Boot alpine-standard-3.6.2-x86\_64.iso
2) Run setup-alpine to get network access, but do not add a web
repository
localhost:~\# cat /etc/apk/repositories
/media/cdrom/apks
localhost:~\# apk add —upgrade —repository
http://dl-3.alpinelinux.org/alpine/v3.6/main musl
OK: 11 MiB in 23 packages
localhost:~\# cat >>/etc/apk/repositories
http://dl-3.alpinelinux.org/alpine/v3.6/main
^C
localhost:~\# cat /etc/apk/repositories
/media/cdrom/apks
http://dl-3.alpinelinux.org/alpine/v3.6/main
localhost:~\# apk upgrade -U
fetch
http://dl-3.alpinelinux.org/alpine/v3.6/main/x86\_64/APKINDEX.tar.gz
Upgrading critical system libraries and apk-tools:
(1/1) Upgrading apk-tools (2.7.1-r1 ->2.7.2-r0)
Executing busybox-1.26.2-r5.trigger
Continuing the upgrade transaction with new apk-tools:
fetch
http://dl-3.alpinelinux.org/alpine/v3.6/main/x86\_64/APKINDEX.tar.gz
(1/2) Upgrading musl (1.1.16-r9 ->1.1.16-r13)
(2/2) Upgrading musl-utils (1.1.16-r9 ->1.1.16-r13)
Executing busybox-1.26.2-r5.trigger
OK: 11 MiB in 23 packages
localhost:~\#
*(from redmine: issue id 7531, created on 2017-07-16)*Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/7162`apk update` attempts mount/umount2 when run with rkt2019-07-14T07:53:02ZTim Dettrick`apk update` attempts mount/umount2 when run with rkt[rkt](https://github.com/rkt/rkt) is a container engine similar to
Docker, and capable of running Docker images. Like Docker, it enforces
seccomp and capability restrictions on system calls.
Alpine Edge has recently broken \`apk update\...[rkt](https://github.com/rkt/rkt) is a container engine similar to
Docker, and capable of running Docker images. Like Docker, it enforces
seccomp and capability restrictions on system calls.
Alpine Edge has recently broken \`apk update\` functionality with rkt,
as it is issuing (unnecessary) mount/umount2 syscalls which are blocked
by seccomp.
$ sudo rkt run --dns 8.8.8.8 --insecure-options image docker://alpine:3.5 --exec /bin/sh -- -c "apk --version && apk update"
[ 5844.906525] alpine[5]: apk-tools 2.6.8, compiled for x86_64.
[ 5844.908101] alpine[5]: fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/main/x86_64/APKINDEX.tar.gz
[ 5846.799587] alpine[5]: fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/community/x86_64/APKINDEX.tar.gz
[ 5847.041904] alpine[5]: v3.5.2-46-gdf4d97eba7 [http://dl-cdn.alpinelinux.org/alpine/v3.5/main]
[ 5847.042149] alpine[5]: v3.5.2-47-ga46d5990dc [http://dl-cdn.alpinelinux.org/alpine/v3.5/community]
[ 5847.042290] alpine[5]: OK: 7959 distinct packages available
$ sudo rkt run --dns 8.8.8.8 --insecure-options image docker://alpine:edge --exec /bin/sh -- -c "apk --version && apk update"
[ 5851.405934] alpine[5]: apk-tools 2.7.0, compiled for x86_64.
[ 5851.407383] alpine[5]: Bad system call
Please see [rkt/rkt\#3642](https://github.com/rkt/rkt/issues/3642) for
more detail.
I believe the most likely cause is the revised /proc setup logic.
*(from redmine: issue id 7162, created on 2017-04-18, closed on 2019-05-03)*
* Changesets:
* Revision 7ee47c808bdda24a658b325f229a2a8b84fe3790 by Timo Teräs on 2017-10-10T08:38:52Z:
```
db: handle default root correctly for /proc
dbopts->root may be null; use db->root instead
fixes #7162
```
* Revision 97e4d0531f2633b54996fc08447bb46449f4a45a by Timo Teräs on 2017-10-10T08:39:38Z:
```
db: handle default root correctly for /proc
dbopts->root may be null; use db->root instead
fixes #7162
```
* Revision 0e504ac58e35f837c468884de7bd4d5d005acd66 by Timo Teräs on 2017-10-10T10:41:21Z:
```
main/apk-tools: fix mounting proc (fixes #7162)
```Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/7104[subset of #7103] Extract manifest of pax checksum headers vs. files for apks...2022-12-21T19:47:14ZChris Giorgi[subset of #7103] Extract manifest of pax checksum headers vs. files for apks to stdout.This particular portion of Feature \#7103 is needed immediately to
improve user experience in upcoming Alpine 3.6 release.
In order to verify integrity of files extracted from apks and uniquely
identify specific versions of a file, the ...This particular portion of Feature \#7103 is needed immediately to
improve user experience in upcoming Alpine 3.6 release.
In order to verify integrity of files extracted from apks and uniquely
identify specific versions of a file, the checksum stored in the pax
header
68 APK-TOOLS.checksum.SHA1=
needs to be retrieved for each file in the apk tar archive. No standard
tar tool can extract this information, and using an awk script results
in unreasonably long runtimes for large packages such as ‘linux-grsec’,
‘linux-firmware’, etc.
apk already reads these headers, but there is currently no way to expose
that information.
Proposed functionality is export of a manifest to stdout (or optionally
file) containing one line per file (with optional comments), and each
line having information to uniquely identify a file by arch, package
name, and full package version.
Format currently in use in kerneltool/mkimage project is
printf 'apk:%s/%s-%s\t%s:$s\t%s' $arch $pkgname $pkgver $sumtype $sum $filename
where $sumtype is the lowercase name of the checksum function, such as
‘sha1’, ‘sha512’, or ‘md5’, which, when prepended to ‘sum’, yields the
appropriate command to verify the sum (i.e. ‘sha1’ ->sha1sum)
*(from redmine: issue id 7104, created on 2017-04-08)*https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/6795segmentation fault in apk.static from Alpine 3.5 blocks build on armhf2019-07-14T07:41:23ZTianon Gravisegmentation fault in apk.static from Alpine 3.5 blocks build on armhfThis appears to be very similar to
https://bugs.alpinelinux.org/issues/6372 on the surface, although
underlying cause might not be (there’s less output from `apk.static`
before the segfault here than there is there).
Here’s the script o...This appears to be very similar to
https://bugs.alpinelinux.org/issues/6372 on the surface, although
underlying cause might not be (there’s less output from `apk.static`
before the segfault here than there is there).
Here’s the script output: (note that `apk` referenced here is actually a
copy of `apk.static` from the `apk-tools-static-2.6.8-r1` package, and
`/home/ubuntu/jenkins-slave/workspace/docker-armhf-alpine/apk-tools-v3.5/etc/apk/keys`
comes from the `alpine-keys-1.3-r0` package)
$ sudo PATH="$PATH" ./mkimage-alpine.bash "${BUILD_OPTIONS[@]}"
fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/main/armhf/APKINDEX.tar.gz
./mkimage-alpine.bash: line 21: 14229 Segmentation fault (core dumped) apk --root "$rootfs" --update-cache --keys-dir /home/ubuntu/jenkins-slave/workspace/docker-armhf-alpine/apk-tools-v3.5/etc/apk/keys add --initdb ${packages[*]//,/ }
A `gdb` backtrace was requested in
https://bugs.alpinelinux.org/issues/6372\#note-24, but I can’t seem to
find where the core file was dumped, and running `apk` directly via
`gdb` is giving me the following:
Reading symbols from /home/ubuntu/jenkins-slave/workspace/docker-armhf-alpine/apk-tools-v3.5/sbin/apk.static...(no debugging symbols found)...done.
(gdb) r
Starting program: /home/ubuntu/jenkins-slave/workspace/docker-armhf-alpine/apk-tools-v3.5/sbin/apk.static --root /var/tmp/alpine-docker-rootfs-9n21sOwkbI --update-cache --keys-dir /home/ubuntu/jenkins-slave/workspace/docker-armhf-alpine/apk-tools-v3.5/etc/apk/keys add --initdb alpine-baselayout alpine-keys apk-tools libc-utils
fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/main/armhf/APKINDEX.tar.gz
Program received signal SIGSEGV, Segmentation fault.
0xaab02e1c in ?? ()
(gdb) bt
#0 0xaab02e1c in ?? ()
#1 0xaab03008 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
I’m happy to do more to help debug further — just need some pointers. :)
It might also be notable that 3.2, 3.3, 3.4, and edge all work fine in
the same environment.
*(from redmine: issue id 6795, created on 2017-02-01, closed on 2017-05-22)*
* Changesets:
* Revision 0eb056df5f4e6fb5af12c3f3f8eef81100066b02 by Natanael Copa on 2017-02-02T06:41:14Z:
```
main/apk-tools: fix error message short read
also triggers rebuild which might fix apk.static (ref #6795)
(cherry picked from commit 5ef7a332f8186986761c3280b8b2c2bf1c02f230)
```
* Revision 3a1f5351fc414b87eed5250b25df8e35f3973ddc by Natanael Copa on 2017-05-09T19:39:25Z:
```
main/apk-tools: fix error message short read
also triggers rebuild which might fix apk.static (ref #6795)
(cherry picked from commit 5ef7a332f8186986761c3280b8b2c2bf1c02f230)
```Timo TeräsTimo Teräs