apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2020-10-03T10:59:56Zhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/106832.11.0 [was 2.10.6] release2020-10-03T10:59:56ZRasmus Thomsenoss@cogitri.dev2.11.0 [was 2.10.6] releaseHello,
it'd be nice if a 2.10.6 release of apk-tools could be made soon so we can have a shared libapk for 3.12Hello,
it'd be nice if a 2.10.6 release of apk-tools could be made soon so we can have a shared libapk for 3.12Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10686Conditional jump or move depends on uninitialised value in apk_db_triggers_read2021-04-11T11:27:48ZRasmus Thomsenoss@cogitri.devConditional jump or move depends on uninitialised value in apk_db_triggers_read```
==8634== Conditional jump or move depends on uninitialised value(s)
==8634== at 0x507EE23: csum_hash (database.c:131)
==8634== by 0x507E8D3: apk_hash_from_key (apk_hash.h:58)
==8634== by 0x507E973: apk_hash_get (apk_hash.h:7...```
==8634== Conditional jump or move depends on uninitialised value(s)
==8634== at 0x507EE23: csum_hash (database.c:131)
==8634== by 0x507E8D3: apk_hash_from_key (apk_hash.h:58)
==8634== by 0x507E973: apk_hash_get (apk_hash.h:70)
==8634== by 0x5085B8F: apk_db_get_pkg (database.c:2076)
==8634== by 0x50828F0: apk_db_triggers_read (database.c:1134)
==8634== by 0x5082B19: apk_db_read_state (database.c:1172)
==8634== by 0x5084517: apk_db_open (database.c:1668)
==8634== by 0x5051C88: _D4apkd11ApkDataBaseQn12openDatabaseMFxbZv (ApkDataBase.d:691)
==8634== by 0x5051E64: _D4apkd11ApkDataBaseQn6__ctorMFNcxAyaxQexbZSQBqQBoQBr (ApkDataBase.d:118)
==8634== by 0x1322D1: _D5tests4apkd7install5_mainFAAyaZi (install.d:45)
==8634== by 0x566C9AB: _D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZv (in /usr/lib/libdruntime-ldc-shared.so.2.0.90)
==8634== by 0x566C789: _d_run_main2 (in /usr/lib/libdruntime-ldc-shared.so.2.0.90)
==8634== Uninitialised value was created by a stack allocation
==8634== at 0x5082875: apk_db_triggers_read (database.c:1122)
```
Noticed this one while running apk-polkit's test suite in valgrind. I don't really see how it'd be uninitialized since it should be initialized in `apk_blob_pull_csum` on line 1131, but I figured it'd be best to report it either way since I don't know C that well :)https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10687musl-nscd package: nsswitch.conf not working with Samba 4 winbind nss entries2020-05-04T07:30:59Zgeorglizzardmusl-nscd package: nsswitch.conf not working with Samba 4 winbind nss entriesI added winbind nss config lines to /etc/nsswitch.conf as follows
`hosts: files dns
passwd: files winbind
group: files winbind`
When having only the first line the service starts OK.
When trying to start nscd daemon with added two ...I added winbind nss config lines to /etc/nsswitch.conf as follows
`hosts: files dns
passwd: files winbind
group: files winbind`
When having only the first line the service starts OK.
When trying to start nscd daemon with added two nss lines it fails with this error:
`nscd: libnss_files.so: Error loading shared library libnss_files.so: No such file or directory`
Tried to examine with
`strace nscd`
`execve("/usr/sbin/nscd", ["nscd"], 0x7ffc879baa50 /* 11 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x7fe061f6bd48) = 0
set_tid_address(0x7fe061f6c31c) = 10783
mprotect(0x7fe061f68000, 4096, PROT_READ) = 0
mprotect(0x55e07d209000, 4096, PROT_READ) = 0
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER|SA_R ESTART, sa_restorer=0x7fe061f1c27d}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0 }, 8) = 0
open("/etc/nsswitch.conf", O_RDONLY) = 3
brk(NULL) = 0x55e07d341000
brk(0x55e07d346000) = 0x55e07d346000
ioctl(3, TIOCGWINSZ, 0x7ffe68553958) = -1 ENOTTY (Not a tty)
readv(3, [{iov_base="hosts: files dns\npasswd: files w"..., iov_len=8191}, {iov_ base="", iov_len=1024}], 2) = 61
readv(3, [{iov_base="", iov_len=8130}, {iov_base="", iov_len=1024}], 2) = 0
ioctl(3, TIOCGWINSZ, 0x7ffe68553958) = -1 ENOTTY (Not a tty)
open("/etc/ld-musl-x86_64.path", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file o r directory)
open("/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No suc h file or directory)
open("/usr/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/libnss_files.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or di rectory)
open("/usr/local/lib/libnss_files.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libnss_files.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file o r directory)
writev(2, [{iov_base="nscd: ", iov_len=6}, {iov_base=NULL, iov_len=0}], 2nscd: ) = 6
writev(2, [{iov_base="libnss_files.so: ", iov_len=17}, {iov_base="Error loading shared library lib"..., iov_len=71}], 2libnss_files.so: Error loading shared lib rary libnss_files.so: No such file or directory) = 88
writev(2, [{iov_base="", iov_len=0}, {iov_base=NULL, iov_len=0}], 2) = 0
writev(2, [{iov_base="", iov_len=0}, {iov_base="\n", iov_len=1}], 2
) = 1
exit_group(1) = ?
+++ exited with 1 +++`
Alpinelinux Samba 4 is not functional as a fileserver with Windows ACL without NSS support, so it is practically useless...
I hope that musl-nscd is an workaround to have functional NSS for samba winbind.
Thanks!https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10689Making apk_package friendlier to bind to other languages2020-05-04T14:31:07ZRasmus Thomsenoss@cogitri.devMaking apk_package friendlier to bind to other languagesHello,
I know that apkv3 is probably going to rework this anyway, but it'd be very nice if it were possible to make apk_package nicer to bind to in the meantime, e.g. by making the bitflags in apk_package 4bit aligned (e.g. by adding a ...Hello,
I know that apkv3 is probably going to rework this anyway, but it'd be very nice if it were possible to make apk_package nicer to bind to in the meantime, e.g. by making the bitflags in apk_package 4bit aligned (e.g. by adding a padding of 29 bits).https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10691Provide releases of static builds of apk-tools2021-12-14T16:39:50ZKevin DaudtProvide releases of static builds of apk-toolsOn github, each release would contain a static build of apk, used by several other projects. Provide the same on gitlab CI.
See: https://github.com/alpinelinux/apk-tools/commit/8fc403c582a725b667d0211f9ccd8a217d25c2fcOn github, each release would contain a static build of apk, used by several other projects. Provide the same on gitlab CI.
See: https://github.com/alpinelinux/apk-tools/commit/8fc403c582a725b667d0211f9ccd8a217d25c2fcKevin DaudtKevin Daudthttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10693Alpine repo drops packages. This prevents package version pinning, and makes...2020-05-08T20:12:37ZP. CowlinatorAlpine repo drops packages. This prevents package version pinning, and makes apk non-deterministic.Alpine Linux has gained popularity as a Linux distribution that is especially good for Docker images.
What’s one of the biggest benefits of Docker? Reproducibility, including deterministic, reproducible Dockerfile builds.
You should...Alpine Linux has gained popularity as a Linux distribution that is especially good for Docker images.
What’s one of the biggest benefits of Docker? Reproducibility, including deterministic, reproducible Dockerfile builds.
You should be able to make a Dockerfile deterministic by pinning package version numbers, so that your image is not dependent on the point in time when it was built.
Unfortunately, the Alpine package repo drops packages, even packages on "stable" branches.
Example: on 2020 March 10th, I found gcc 9.2.0-r3 on the Alpine package repository (web UI) under branch 3.11. On 2020 March 23rd, just 13 days later, my Dockerfile failed to run because the package gcc 9.2.0-r3 had been revoked from the branch 3.11 of the package repository, and was replaced with gcc 9.2.0-r4.
This makes Alpine Linux unsuitable for use in Docker images. Either your Dockerfile with pinning will "expire", or you are forced to avoid pinning package versions, which may cause unexpected behavior. When package maintainers decide to release a new version, this unexpected version will be automatically installed as soon as you rebuild your image the next time.
Compare this to PyPI or npm: No version is dropped, so version pinning works perfectly fine, no matter when you build or use your stuff.
There is a similar thread, https://gitlab.alpinelinux.org/alpine/apk-tools/issues/10661 , which Timo Teräs (@fabled) closed, based on the unconfirmed assumption that the OP was mixing an Alpine image with Alpine packages from 2 different branches.
However, in my example, both the Alpine version and the package version were on the 3.11 branch. There is no mixing.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10694ImageMagick number of supported formats: 02020-05-11T10:31:00ZjuliemarsImageMagick number of supported formats: 0Hi
I hope this is the right place, I discovered this issue in the linuxserver letsencrypt docker image (https://github.com/linuxserver/docker-letsencrypt/issues/445) and they suggested I post it to you.
Expected Behavior
The ImageMagi...Hi
I hope this is the right place, I discovered this issue in the linuxserver letsencrypt docker image (https://github.com/linuxserver/docker-letsencrypt/issues/445) and they suggested I post it to you.
Expected Behavior
The ImageMagick module is not working, in phpinfo I can see that it says "ImageMagick number of supported formats: 0" this is preventing some functions needing this library from working.
If I disable the ImageMagick.ini file the system falls back to GD and works fine.
Nothing is logged in the docker or NGINX/php log for this error either.
I have deleted and recreated the container and image and tried on 2 different docker installs and issue remains on both.
Current Behavior
Images do not load generating a 500 error.
![image](/uploads/f7e52c575ae55a50b3b642cf6eb28fcb/image.png)
Steps to Reproduce
Setup new image
Use ImageMagick module (webtress uses this)
See 500 error/no image (webtress logs Cannot create thumbnail NoDecodeDelegateForThisImageFormat `PNG'"
they have advised the following:
"We have this php module installed: https://pkgs.alpinelinux.org/package/v3.11/community/x86_64/php7-pecl-imagick
It pulls in the imagemagick-libs: https://pkgs.alpinelinux.org/package/v3.11/community/x86_64/imagemagick-libs
That's why php is listing the imagemagick library version. But no idea why it's not finding any supported formats."
Any ideas?https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10696Option to disable building of docs during bootstrap for apk-tools2020-08-25T13:59:18ZRahul AtluryOption to disable building of docs during bootstrap for apk-toolsDuring the recent versions of apk-tools a new way, i.e to generate help with the help of lua was added.
https://github.com/alpinelinux/apk-tools/blob/master/src/genhelp.lua
Now there is also additional dependencies on lua5.3-lzlib as...During the recent versions of apk-tools a new way, i.e to generate help with the help of lua was added.
https://github.com/alpinelinux/apk-tools/blob/master/src/genhelp.lua
Now there is also additional dependencies on lua5.3-lzlib as well.
It would be nice if there was an option to disable it though at least for bootstrapping.
apk-tools and abuild are the heart of porting work, if they can compile easily with minimal dependencies it would help.
Thank you
Edit: Added different runs and their outputs log filehttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10697Leaking memory in apk_atom_init2020-08-25T13:59:19ZRasmus Thomsenoss@cogitri.devLeaking memory in apk_atom_initHello,
in my D bindings for apk-tools I'm currently doing the following to open the database:
```
apk_atom_init();
apk_db_init(&this.db);
```
And the following to close the db:
```
if (this.db.open_complete)
{
apk_db_close(&this....Hello,
in my D bindings for apk-tools I'm currently doing the following to open the database:
```
apk_atom_init();
apk_db_init(&this.db);
```
And the following to close the db:
```
if (this.db.open_complete)
{
apk_db_close(&this.db);
}
```
This will happen a lot of times during the lifetime of my DBus server, since I try to avoid holding the lock on the database for too long, so users aren't blocked from using the `apk` CLI tool when the server isn't doing an operation. The problem is that apparently `apk_atom_init` leaks a sizeable amount of memory every time and I can't free it because that's behind an ifdef for valgrind - I guess exactly because it complains there.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10700`apk upgrade some-package` should only upgrade this specific package2020-08-25T13:59:19ZGhost User`apk upgrade some-package` should only upgrade this specific packageLikewise, `apk upgrade -a some-package` sould only upgrade `some-package` to the latest version in the repository.
The latter is IMO quite useful when you want to rollback a package to the version in the repository, without having to re...Likewise, `apk upgrade -a some-package` sould only upgrade `some-package` to the latest version in the repository.
The latter is IMO quite useful when you want to rollback a package to the version in the repository, without having to reinstall and pin each package again.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10701man pages in many -doc packages are not rending correctly2020-06-20T20:51:36ZPaul W. Rankinhello@paulwrankin.comman pages in many -doc packages are not rending correctlyHello, I was encouraged to submit a bug about this.
Many man pages from `*-doc` packages are not rending correctly, e.g. here is some sample output of `man udisksctl` from `udisks2-doc`:
```
UDISKSCTL(1) User Command...Hello, I was encouraged to submit a bug about this.
Many man pages from `*-doc` packages are not rending correctly, e.g. here is some sample output of `man udisksctl` from `udisks2-doc`:
```
UDISKSCTL(1) User Commands UDISKSCTL(1)
.SH "NAME" udisksctl - The udisks command line tool
.SH "SYNOPSIS"
.HP 240u
u�ud�di�is�sk�ks�sc�ct�tl�l
status
.HP 240u
u�ud�di�is�sk�ks�sc�ct�tl�l
info
{
| --object-path _�O_�B_�J_�E_�C_�T
| --block-device _�D_�E_�V_�I_�C_�E
| --drive _�D_�R_�I_�V_�E
}
.HP 240u
u�ud�di�is�sk�ks�sc�ct�tl�l
mount
{
| --object-path _�O_�B_�J_�E_�C_�T
| --block-device _�D_�E_�V_�I_�C_�E
}
[
| --filesystem-type _�T_�Y_�P_�E
]
[--options _�O_�P_�T_�I_�O_�N_�S...]
[--no-user-interaction]
```
Complete output: http://l.termbin.com/6l6b
From #alpine-linux other affected packages include:
```
dbus-doc
gnome-books-doc
gnome-disks-doc
gnome-shell-doc
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10702--repositories-file option for installing commands not working2020-10-05T13:50:11Zeytienne--repositories-file option for installing commands not workingI don't know if it is a common behaviour but the `repositories-file` option has not used my file until I put an absolute path. It didn't work with a relative one and this wasn't mentioned in the concise help page.I don't know if it is a common behaviour but the `repositories-file` option has not used my file until I put an absolute path. It didn't work with a relative one and this wasn't mentioned in the concise help page.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10703Error message when trying to install a nonexistent package is unclear2021-04-11T11:27:49ZTheodore DuboisError message when trying to install a nonexistent package is unclear```
$ apk add python3-pip
ERROR: unsatisfiable constraints:
python3-pip (missing):
required by: world[python3-pip]
```
If you've never used apk before, it's not very obvious that this means there isn't a package called py...```
$ apk add python3-pip
ERROR: unsatisfiable constraints:
python3-pip (missing):
required by: world[python3-pip]
```
If you've never used apk before, it's not very obvious that this means there isn't a package called python3-pip.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10705apk doesn't seem to fully be able to roll back from edge to stable in all cas...2020-08-19T04:51:06ZEllieapk doesn't seem to fully be able to roll back from edge to stable in all cases, and worse, doesn't tell me whyapk doesn't seem to fully be able to roll back from edge to stable in all cases. I went from postmarketOS edge to stable by changing the repo sources and using `sudo apk upgrade -a`. Yet, I seem to be stuck with edge-only `nettle` with s...apk doesn't seem to fully be able to roll back from edge to stable in all cases. I went from postmarketOS edge to stable by changing the repo sources and using `sudo apk upgrade -a`. Yet, I seem to be stuck with edge-only `nettle` with something still depending on it, not letting me remove it:
```
$ sudo apk del nettle
World updated, but the following packages are not removed due to:
nettle: epiphany gnutls samba-libs libsmbclient vlc vlc-qt samba-util-libs
libwbclient gnupg gpgme ffmpeg-libs ffmpeg-dev pipewire firefox mutter
gnome-shell gnome-session phosh postmarketos-ui-phosh qt5-qtwebengine
plasma-angelfish telegram-desktop vte3 kgx lxterminal glib-networking
libsoup evolution-data-server folks calls chatty gnome-calendar rest
gnome-online-accounts libgdata midori libgweather gnome-settings-daemon
gnome-clocks libosinfo tracker-miners nautilus libtracker tracker
webkit2gtk geocode-glib geoclue cups-libs gtk+3.0 libcanberra-gtk3 cheese
gnome-disk-utility gnome-screenshot gnome-bluetooth-libs gnome-bluetooth
network-manager-applet colord-gtk gcr ibus libnma libhandy gnome-desktop
phoc squeekboard eog tepl gedit clutter-gtk caribou gtksourceview4 zenity
gspell clutter clutter-gst libdazzle baobab vino gnome-autoar libpeas amtk
gtk+2.0 adwaita-gtk2-theme gnome-themes-extra lightdm qt5-qtbase-x11 kcrash
kio purpose plasma-framework kdeclarative kglobalaccel kxmlgui kbookmarks
kservice kwallet kauth kconfigwidgets kiconthemes ktextwidgets
qt5-qtdeclarative qt5-qtwayland postmarketos-ui-phosh-qt_tweaks qt5-qtbase
kpackage kdbusaddons karchive kdoctools kwindowsystem knotifications
qt5-qtsvg qt5-qtmultimedia qt5-qtspeech qt5-qtquickcontrols2 kirigami2
kirigami2-libs kguiaddons qt5-qtx11extras kjobwidgets attica
qt5-qtwebchannel kwidgetsaddons kcompletion polkit-qt-1 qt5-qtimageformats
kconfig kactivities-libs quazip kcoreaddons solid-libs kitemviews kcodecs
sonnet kwayland ki18n qt5-qtgraphicaleffects libdbusmenu-qt cups-pk-helper
xorg-server-xwayland
OK: 2677 MiB in 792 packages
```
However, since `nettle` is edge-only, that could only happen if I still have another edge package installed which `sudo apk upgrade -a` should have fixed. Yet, `sudo apk upgrade -a` seems perfectly content with this situation:
```
$ sudo apk upgrade -a
OK: 2677 MiB in 792 packages
```
With those being the current repo sources:
```
$ cat /etc/apk/repositories
http://postmarketos1.brixit.nl/postmarketos/v20.05
http://dl-cdn.alpinelinux.org/alpine/v3.12/main
http://dl-cdn.alpinelinux.org/alpine/v3.12/community
```
So I appear to be stuck in this state, with `apk` not even really telling me why even. This is somewhat unsatisfactory.
1. Is it possible to somehow list all packages that are currently without a source in the repo? (Since that would likely reveal what edge stuff I am unintentionally still stuck with)
2. Why does this not do anything?
```
$ sudo apk del --force-broken-world nettle
World updated, but the following packages are not removed due to:
nettle: epiphany gnutls samba-libs libsmbclient vlc vlc-qt samba-util-libs
libwbclient gnupg gpgme ffmpeg-libs ffmpeg-dev pipewire firefox mutter
gnome-shell gnome-session phosh postmarketos-ui-phosh qt5-qtwebengine
plasma-angelfish telegram-desktop vte3 kgx lxterminal glib-networking
libsoup evolution-data-server folks calls chatty gnome-calendar rest
gnome-online-accounts libgdata midori libgweather gnome-settings-daemon
gnome-clocks libosinfo tracker-miners nautilus libtracker tracker
webkit2gtk geocode-glib geoclue cups-libs gtk+3.0 libcanberra-gtk3 cheese
gnome-disk-utility gnome-screenshot gnome-bluetooth-libs gnome-bluetooth
network-manager-applet colord-gtk gcr ibus libnma libhandy gnome-desktop
phoc squeekboard eog tepl gedit clutter-gtk caribou gtksourceview4 zenity
gspell clutter clutter-gst libdazzle baobab vino gnome-autoar libpeas amtk
gtk+2.0 adwaita-gtk2-theme gnome-themes-extra lightdm qt5-qtbase-x11 kcrash
kio purpose plasma-framework kdeclarative kglobalaccel kxmlgui kbookmarks
kservice kwallet kauth kconfigwidgets kiconthemes ktextwidgets
qt5-qtdeclarative qt5-qtwayland postmarketos-ui-phosh-qt_tweaks qt5-qtbase
kpackage kdbusaddons karchive kdoctools kwindowsystem knotifications
qt5-qtsvg qt5-qtmultimedia qt5-qtspeech qt5-qtquickcontrols2 kirigami2
kirigami2-libs kguiaddons qt5-qtx11extras kjobwidgets attica
qt5-qtwebchannel kwidgetsaddons kcompletion polkit-qt-1 qt5-qtimageformats
kconfig kactivities-libs quazip kcoreaddons solid-libs kitemviews kcodecs
sonnet kwayland ki18n qt5-qtgraphicaleffects libdbusmenu-qt cups-pk-helper
xorg-server-xwayland
OK: 2677 MiB in 792 packages
```
3. Could `sudo apk upgrade -a` possibly be changed to hint at some out-of-repo packages still being in the system? Just as a heads up warning that in overall, the system might not be in a clean state. Like, no need to list them all if that is too verbose, but to have any sort of pointer at that to start with (e.g. by listing the number of out-of-repo packages at least) would be very helpful.
4. It seems like `sudo apk upgrade -a` potentially has a bug, since it feels like it should have resolved this entirely. However, it might be easier to investigate this once I know more about what is even the current state right now in my systemhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10707apk-tools-static: option -X missing2020-09-25T13:31:41ZMarkapk-tools-static: option -X missingI was following this wiki page https://wiki.alpinelinux.org/wiki/Alpine_Linux_in_a_chroot, but when I got to installing the Alpine, I got the following error output:
```
phablet@ubuntu-phablet:/mnt$ ./sbin/apk.static -X http://nl.alpine...I was following this wiki page https://wiki.alpinelinux.org/wiki/Alpine_Linux_in_a_chroot, but when I got to installing the Alpine, I got the following error output:
```
phablet@ubuntu-phablet:/mnt$ ./sbin/apk.static -X http://nl.alpinelinux.org/alpine/edge/main -U --allow-untrusted --root alpine-armv7 --initdb add alpine-base
./sbin/apk.static: unrecognized option: X
ERROR: unsatisfiable constraints:
add (missing):
required by: world[add]
alpine-base (missing):
required by: world[alpine-base]
http://nl.alpinelinux.org/alpine/edge/main (missing):
required by: world[http://nl.alpinelinux.org/alpine/edge/main]
phablet@ubuntu-phablet:/mnt$ ./sbin/apk.static -X ${mirror}/latest-stable/main -U --allow-untrusted --root ${chroot_dir} --initdb add alpine-base
./sbin/apk.static: unrecognized option: X
ERROR: Unable to open root: No such file or directory
ERROR: Failed to open apk database: No such file or directory
```
This is related to some recent update since I already did the thing before, a month or two ago.Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10708Packages missing checksums for files2021-05-01T04:27:28ZKevin DaudtPackages missing checksums for filesI suspect since the release of apk-tools 2.12.0-rc1, we start getting errors from apk like:
> WARNING: installkernel-3.5-r0: no checksum for file sbin/installkernel
See for example alpine/aports#11892I suspect since the release of apk-tools 2.12.0-rc1, we start getting errors from apk like:
> WARNING: installkernel-3.5-r0: no checksum for file sbin/installkernel
See for example alpine/aports#11892Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10709Replacing a package with hard links causes "no hard link target (<target>) in...2022-12-21T20:28:45ZBart RibbersReplacing a package with hard links causes "no hard link target (<target>) in archive"In postmarketOS we for a while had a `mesa-git` package which is just `mesa` but tracking the latest git master rather than using a release tarball.
We're now trying to get rid of it so took the `mesa` package from Alpine and added `rep...In postmarketOS we for a while had a `mesa-git` package which is just `mesa` but tracking the latest git master rather than using a release tarball.
We're now trying to get rid of it so took the `mesa` package from Alpine and added `replaces=""` statements everywhere.
The upgrade on an existing installation is initiated, but `mesa-dri-gallium` fails to install properly with the following messages:
```
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/etnaviv_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/exynos_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/hx8357d_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/ili9225_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/ili9341_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/imx-drm_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/ingenic-drm_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/kgsl_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/kms_swrast_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/lima_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/mcde_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/meson_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/mi0283qt_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/msm_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/mxsfb-drm_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/nouveau_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/panfrost_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/pl111_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/r300_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/r600_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/radeonsi_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/repaper_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/rockchip_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/st7586_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/st7735r_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/stm_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/sun4i-drm_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/swrast_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/tegra_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/v3d_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/vc4_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
ERROR: mesa-dri-gallium-20.1.5-r0: usr/lib/xorg/modules/dri/virtio_gpu_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive
```
However, a simple `apk fix` fixes this indicating that the hard link target _does_ exist. Issues such as these will mean that graphical upgrades using GNOME Software in combination with `gnome-software-plugin-apk` will fail without a clear reason why.
After running `apk fix` `apk info -L mesa-dri-gallium` also shows `/usr/lib/xorg/modules/dri/armada-drm_dri.so` is present in the package:
```
pine64-pinephone:~$ sudo apk fix
[sudo] password for bart:
(1/1) Reinstalling mesa-dri-gallium (20.1.5-r0)
OK: 1027 MiB in 492 packages
pine64-pinephone:~$ apk info -L mesa-dri-gallium
mesa-dri-gallium-20.1.5-r0 contains:
usr/lib/xorg/modules/dri/armada-drm_dri.so
usr/lib/xorg/modules/dri/etnaviv_dri.so
usr/lib/xorg/modules/dri/exynos_dri.so
usr/lib/xorg/modules/dri/hx8357d_dri.so
usr/lib/xorg/modules/dri/ili9225_dri.so
usr/lib/xorg/modules/dri/ili9341_dri.so
usr/lib/xorg/modules/dri/imx-drm_dri.so
usr/lib/xorg/modules/dri/ingenic-drm_dri.so
usr/lib/xorg/modules/dri/kgsl_dri.so
usr/lib/xorg/modules/dri/kms_swrast_dri.so
usr/lib/xorg/modules/dri/lima_dri.so
usr/lib/xorg/modules/dri/mcde_dri.so
usr/lib/xorg/modules/dri/meson_dri.so
usr/lib/xorg/modules/dri/mi0283qt_dri.so
usr/lib/xorg/modules/dri/msm_dri.so
usr/lib/xorg/modules/dri/mxsfb-drm_dri.so
usr/lib/xorg/modules/dri/nouveau_dri.so
usr/lib/xorg/modules/dri/panfrost_dri.so
usr/lib/xorg/modules/dri/pl111_dri.so
usr/lib/xorg/modules/dri/r300_dri.so
usr/lib/xorg/modules/dri/r600_dri.so
usr/lib/xorg/modules/dri/radeonsi_dri.so
usr/lib/xorg/modules/dri/repaper_dri.so
usr/lib/xorg/modules/dri/rockchip_dri.so
usr/lib/xorg/modules/dri/st7586_dri.so
usr/lib/xorg/modules/dri/st7735r_dri.so
usr/lib/xorg/modules/dri/stm_dri.so
usr/lib/xorg/modules/dri/sun4i-drm_dri.so
usr/lib/xorg/modules/dri/swrast_dri.so
usr/lib/xorg/modules/dri/tegra_dri.so
usr/lib/xorg/modules/dri/v3d_dri.so
usr/lib/xorg/modules/dri/vc4_dri.so
usr/lib/xorg/modules/dri/virtio_gpu_dri.so
```
The relevant commit to apk-tools is probably 6484ed9849f03971eb48ee1fdc21a2f128247eb1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10710during pulling indexes of repositories is displayed password from urls with u...2021-04-11T11:27:49ZJiri Kastnerduring pulling indexes of repositories is displayed password from urls with user:passwordalpine is used a lot in cd/ci pipelines but using 3rdparty repositories secured by http auth in /etc/apk/repositories compromise account as warnings/errors reveal password/token used, workaround using ``apk update -q 2>/dev/null`` is not...alpine is used a lot in cd/ci pipelines but using 3rdparty repositories secured by http auth in /etc/apk/repositories compromise account as warnings/errors reveal password/token used, workaround using ``apk update -q 2>/dev/null`` is not solution.
displaying ``*****`` instead of password part should be nice.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10711how can I bundle python app in .apk for alpine?2022-12-21T20:15:14ZAlpana Singhalhow can I bundle python app in .apk for alpine?https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10714Status of *package generation* command2022-12-21T19:35:11ZPaul SpoorenStatus of *package generation* command~~Hi, looking the [apk TODO](https://wiki.alpinelinux.org/wiki/TODO:apk#.apk_Generator) there is a generator function mentioned which I would like to use.~~ EDIT: There will be new commands to create packages, this issue could be used to...~~Hi, looking the [apk TODO](https://wiki.alpinelinux.org/wiki/TODO:apk#.apk_Generator) there is a generator function mentioned which I would like to use.~~ EDIT: There will be new commands to create packages, this issue could be used to track progress on that.
As a proof of concept I plan to integrate `apk` into OpenWrt as a replacement for `opkg`, a fork of `ipkg`, which has some drawbacks.
As OpenWrt supports a complex build system I don't plan to use `abuild` to create the package but just *pack* compiled packages and add a control file.
Anyone knows of progress?