alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2020-05-08T20:12:37Zhttps://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/aports/-/issues/11517pixman-static is missing2020-05-09T21:29:18ZDrew DeVaultpixman-static is missingIt was removed in aca640da654a97c6ad6f9423beda707cd14c8a42 without a clear explanation. @LeoIt was removed in aca640da654a97c6ad6f9423beda707cd14c8a42 without a clear explanation. @LeoLeoLeohttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11513ifupdown package calls run-parts with hardcoded path preventing use with run-...2020-05-11T09:17:36ZDermot Bradleyifupdown package calls run-parts with hardcoded path preventing use with run-parts packagePackage busybox installs /bin/run-parts as a softlink to /bin/busybox, package run-parts installs /usr/bin/run-parts binary.
Whilst trying to debug a network interface issue I ran "ifup --verbose eth0" which gives multiple errors when i...Package busybox installs /bin/run-parts as a softlink to /bin/busybox, package run-parts installs /usr/bin/run-parts binary.
Whilst trying to debug a network interface issue I ran "ifup --verbose eth0" which gives multiple errors when it tried to run scripts:
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
/bin/run-parts: unrecognized option: verbose
This is because Busybox's run-parts does not recognise the "--verbose" option whereas the full version of run-parts does. Even when the run-parts package is installed ifup will only use the Busybox version due to the hardcoded "/bin/" path.
Two solutions, either:
(a) modify ifupdown/execute.c to change its use of "/bin/run-parts" to just "run-parts" and so it will find the binary from the run-parts package, if installed, before the Busybox one, so permitting the use of the "--verbose" option.
or
(b) modify the run-parts package to install its binary into /bin so replacing the Busybox softlink.https://gitlab.alpinelinux.org/alpine/aports/-/issues/11512linux-pam package, invalid option passed to pam_unix.so2020-10-26T20:06:49ZDermot Bradleylinux-pam package, invalid option passed to pam_unix.soIn the linux-pam package the file /etc/pam.d/base-password calls pam_unix with the "obscure" option. There is no such option in pam_unix (I have confirmed by checking the source code). Debian's pam_unix does support an "obscure" option b...In the linux-pam package the file /etc/pam.d/base-password calls pam_unix with the "obscure" option. There is no such option in pam_unix (I have confirmed by checking the source code). Debian's pam_unix does support an "obscure" option but this is because they patch code to add that functionality into the same version of linux-pam.
This reference to an unknown "obscure" option results in log entries such as the following appearing in /var/log/auth.log:
chpasswd[1234]: pam_unix(chpasswd:chauthtok): unrecognized option [obscure]
Simple solution, remove the "obscure" option from the file base-password.pamd in aports/main/linux-pam and rebuild.https://gitlab.alpinelinux.org/alpine/aports/-/issues/11511gsoap package has some libs with static symbols2020-05-19T15:33:08ZTherminoel.kuntze@thermi.consultinggsoap package has some libs with static symbolsHi,
I'm trying to build the kopano-core software in an APKBUILD (manually transformed from the PKGBUILD from the AUR), but it seems linking fails with a problem in libgsoapssl++.a, because it has some static symbols:
```
/usr/lib/gcc/x8...Hi,
I'm trying to build the kopano-core software in an APKBUILD (manually transformed from the PKGBUILD from the AUR), but it seems linking fails with a problem in libgsoapssl++.a, because it has some static symbols:
```
/usr/lib/gcc/x86_64-alpine-linux-musl/9.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/9.2.0/../../../../lib/libgsoapssl++.a(libgsoapssl___a-stdsoap2_ssl_cpp.o): relocation R_X86_64_PC32 against symbol `soap_base64o' can not be used when making a shared object; recompile with -fPIP
```
I already added -fPIC and -fPIE to the CFLAGS and CPPFLAGS in the gsoap package and rebuilt it, but that didn't help. -fPIC and -fPIE in the CFLAGS and CPPFLAGS of the APKBUILD of kopano-core didn't help either.https://gitlab.alpinelinux.org/alpine/aports/-/issues/11510kernel panics after musl upgrade on armhf2020-05-07T11:03:23ZVasile Dankernel panics after musl upgrade on armhfI upgraded musl yesterday on my Raspberry Pi Zero W running Alpine Linux version 3.10 (in sys-mode with community and edge/testing repos enabled — from testing I only have one package installed with no dependencies) and I rebooted. It bo...I upgraded musl yesterday on my Raspberry Pi Zero W running Alpine Linux version 3.10 (in sys-mode with community and edge/testing repos enabled — from testing I only have one package installed with no dependencies) and I rebooted. It booted up at first and I could even ssh into it, but any command I wanted to run over ssh froze the ssh-session. I had to pull the plug. After this it didn't boot anymore. There was a kernel panic every time I started the Pi, which said it couldn't run /sbin/init.
Knowing that the only thing I had upgraded was musl, I downloaded the installation tarball for 3.10.1 again from the main site and manually copied all the files in the .apk archives (musl and musl-utils) to the sdcard of the Pi. This fixed the problem. The tarball is now a month old, so I guess it counts as a downgrade?https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10689wiki: mail() function error2020-11-11T11:44:43ZSPOwiki: mail() function errorI don't see email notifications coming from the wiki.
And checking that, I got this error when attemptling to
manually request a new confirmation email:
Alpine Linux could not send your confirmation mail.
Please check your email ad...I don't see email notifications coming from the wiki.
And checking that, I got this error when attemptling to
manually request a new confirmation email:
Alpine Linux could not send your confirmation mail.
Please check your email address for invalid characters.
Mailer returned: Unknown error in PHP's mail() function.
The saved address does look ok to me,though.
The only thing that could be special might be that I only
added it after first signing up without an email address
(optional field empty).https://gitlab.alpinelinux.org/alpine/aports/-/issues/11506feat Mixxx DJ Software2021-10-02T11:04:19Zwishingwelldevelopmentsfeat Mixxx DJ SoftwareHey Alpine Crew!
I have just discovered alpine and am absolutely loving it.
I would like to be able to use the mixxx dj software and was wondering if anyone would be able to add it to the repos.
I've tried compiling it myself but haven'...Hey Alpine Crew!
I have just discovered alpine and am absolutely loving it.
I would like to be able to use the mixxx dj software and was wondering if anyone would be able to add it to the repos.
I've tried compiling it myself but haven't gotten far as some dependencies are not available.
mixxx's main website : https://www.mixxx.org/
package : https://github.com/mixxxdj/mixxx/archive/release-2.2.3.tar.gz
List of Dependencies :
- libid3tag
- libmad
- libogg
- libvorbis
- libvorbisfile
- libsndfile
- libmodplug
- libflac
- libopus
- libshout
- libhss1394
- taglib
- PortAudio-v19
- portmidi
- QT 4.6+
- scons
- protocol-buffers
- libusb-1.0
- libmp4v2 (optional, m4a support)
- libfaad (optional, m4a support)
- vamp-plugin-sdk (optional, internal version included)
- libchromaprint
- librubberband
Many Thanks.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/aports/-/issues/11502phosh broken dependencies2020-05-07T07:09:34ZRaattyphosh broken dependenciesi think !7535 is the culpriti think !7535 is the culpritRasmus Thomsenoss@cogitri.devRasmus Thomsenoss@cogitri.devhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11501Update community/vault to 1.4.12020-05-06T20:29:57ZTy SarnaUpdate community/vault to 1.4.1I made a stab at this here:
https://gitlab.alpinelinux.org/tsarna/aports/-/tree/tsarna-vault-1.4.1
It builds but I haven't tested yet. I had to enable CGO to get it to build or else I got the "cannot find runtime/cgo" error mentioned h...I made a stab at this here:
https://gitlab.alpinelinux.org/tsarna/aports/-/tree/tsarna-vault-1.4.1
It builds but I haven't tested yet. I had to enable CGO to get it to build or else I got the "cannot find runtime/cgo" error mentioned here https://gitlab.alpinelinux.org/alpine/aports/-/commit/9686793792a2c40a872ebbb2b86fa537f224 but that fix was later reverted for causing other problems.
I don't really understand the implications of CGO and a) whether this is and acceptable workaround or b) there is a better way to deal with the problem.
So, basically I am opening this since I am out of my depth on Go. If the direction I have headed is OK I can test the build and submit an MR, otherwise I'd appreciate advise from the package maintainer, or if they just want to update it themselves that's even better :smile:.
Thanks!Ty SarnaTy Sarnahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11498rpm -i doesn't work2020-05-05T18:27:23ZTheodore Duboisrpm -i doesn't work```
error: Failed to resolve symbol ima_hooks: Symbol not found: nspr_use_zone_allocator
```
This appears to be because the shared libs in /usr/lib/rpm-plugins got stripped, making it impossible to load them.
Commands to reproduce:
```...```
error: Failed to resolve symbol ima_hooks: Symbol not found: nspr_use_zone_allocator
```
This appears to be because the shared libs in /usr/lib/rpm-plugins got stripped, making it impossible to load them.
Commands to reproduce:
```
apk add rpm
wget https://cdn.azul.com/zulu/bin/zulu11.39.15-ca-jdk11.0.7-linux.i686.rpm
rpm -i zulu11.39.15-ca-jdk11.0.7-linux.i686.rpm
```https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10456Setup-gparted-desktop2020-05-28T15:21:43ZMr GreenSetup-gparted-desktopNot so much of a bug as a change needed to above script, currently
script calls for aterm which is not found, suggest using st instead.
(Also edit menu.xml to suit)
*(from redmine: issue id 4603, created on 2015-08-31)*Not so much of a bug as a change needed to above script, currently
script calls for aterm which is not found, suggest using st instead.
(Also edit menu.xml to suit)
*(from redmine: issue id 4603, created on 2015-08-31)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/11493java-snappy-1.1.7.3-r0: bitshuffle.h missing2020-12-29T10:20:18ZKevin Daudtjava-snappy-1.1.7.3-r0: bitshuffle.h missingjava-snappy is failing to build for 3.12:
```
ppc64le -Itarget/bitshuffle-0.3.2/src -c src/main/java/org/xerial/snappy/BitShuffleNative.cpp -o target/snappy-1.1.7-Linux-ppc64le/BitShuffleNative.o
src/main/java/org/xerial/snappy/BitShuff...java-snappy is failing to build for 3.12:
```
ppc64le -Itarget/bitshuffle-0.3.2/src -c src/main/java/org/xerial/snappy/BitShuffleNative.cpp -o target/snappy-1.1.7-Linux-ppc64le/BitShuffleNative.o
src/main/java/org/xerial/snappy/BitShuffleNative.cpp:16:10: fatal error: bitshuffle.h: No such file or directory
16 | #include <bitshuffle.h>
| ^~~~~~~~~~~~~~
```
See:https://build.alpinelinux.org/buildlogs/build-3-12-ppc64le/community/java-snappy/java-snappy-1.1.7.3-r0.log3.12.4Jakub JirutkaJakub Jirutkahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11490Package request: py3-nodeenv2020-08-17T06:49:36ZJ0WIPackage request: py3-nodeenvRequired by `community/ceph`
https://ekalinin.github.io/nodeenv/Required by `community/ceph`
https://ekalinin.github.io/nodeenv/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/aports/-/issues/11489Build failure of virtualbox-guest-additions on arm642021-06-09T03:44:48ZodidevBuild failure of virtualbox-guest-additions on arm64We tried to build VirtualBox-guest-additions from the available source code on arm64 and it failed.
> ubuntu@1pthunderx1-137:~/virtualbox-guest-additions/src/VirtualBox-6.1.6$ ./configure --nofatal --disable-dbus --disable-xpcom --disa...We tried to build VirtualBox-guest-additions from the available source code on arm64 and it failed.
> ubuntu@1pthunderx1-137:~/virtualbox-guest-additions/src/VirtualBox-6.1.6$ ./configure --nofatal --disable-dbus --disable-xpcom --disable-sdl-ttf --disable-pulse --disable-alsa --disable-kmods --build-headless
> Checking for environment: ** Cannot determine system!
We made some fixes and went ahead. Now, the code stuck in include/iprt/cdefs.h:
> error "Architecture identifier missing / not implemented."
In this case, need to find the value of RT_VALID_PTR in the case of arm64.
Then, we had a discussion on VirtualBox Forum and got to know that:
VirtualBox is a virtualizer which passes through directly the Intel/AMD CPU commands to the host. It isn't a simulator which would simulate an ARM CPU for a guest.
So, now my question is "**Is it even possible to port VirtualBox-guest-additions on arm64?**"https://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/aports/-/issues/11485musl-nscd package: nsswitch.conf not working with Samba 4 winbind nss entries2021-09-27T18:27:43Zgeorglizzardmusl-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/aports/-/issues/11484samba-winbind not functional with nsswitch.conf, can't implement Windows ACL ...2021-07-27T14:52:07Zgeorglizzardsamba-winbind not functional with nsswitch.conf, can't implement Windows ACL in Alpinelinux sambaHello,
Tried to make samba-dc a working environment as a domain controller for a samba domain member which supposed to be a fileserver that implements ad-backend and Windows ACL.
I encountered a problem that make this impossible for now:...Hello,
Tried to make samba-dc a working environment as a domain controller for a samba domain member which supposed to be a fileserver that implements ad-backend and Windows ACL.
I encountered a problem that make this impossible for now: winbind NSS doesn't work with musl-libc.
So when try to get Domain Users (and groups) with
`getent passwd SAMDOM\\demo01 `
the result is empty.
I tried musl-nscd which is promising in solve this problem but, probably due to some winbind problems doesn't work for now.
I searched for functional workarounds but didn't find any. I think a possible solution is to compile samba against [nsss](https://skarnet.org/software/nsss/) which is already implemented as a package for AlpineLinux but this is just an opinion.
Another solution is to have a working musl-nscd but the developer doesn't have the proper environment for this.
For now I should go with Debian which I don't consider it as the most happy alternative.
I consider the entire samba-dc effort for AlpineLinux useless if cannot work with Windows ACL.
I anyone can help in solving this issue it will be great, I don't have the necessary knowledge to do it myself.
Thanks!