aports issueshttps://gitlab.alpinelinux.org/alpine/aports/-/issues2024-03-27T19:29:01Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15862community/goimapnotify: Internal linking error on ppc64le2024-03-27T19:29:01ZSören Tempelcommunity/goimapnotify: Internal linking error on ppc64leWhile rebuilding `community/*` with Go 1.22.1 the following build error showed up on ppc64le for goimapnotify:
```
go: downloading github.com/emersion/go-imap v1.0.0-beta.4.0.20190414203716-b7db4a2bc5cc
go: downloading github.com/emersi...While rebuilding `community/*` with Go 1.22.1 the following build error showed up on ppc64le for goimapnotify:
```
go: downloading github.com/emersion/go-imap v1.0.0-beta.4.0.20190414203716-b7db4a2bc5cc
go: downloading github.com/emersion/go-imap-idle v0.0.0-20180114101550-2af93776db6b
go: downloading github.com/sirupsen/logrus v1.8.1
go: downloading github.com/emersion/go-sasl v0.0.0-20200509203442-7bfe0ed36a21
go: downloading golang.org/x/text v0.3.2
# gitlab.com/shackra/goimapnotify.test
panic: bad carrier sym for symbol runtime.elf_savegpr0.args_stackmap (funcdata runtime.elf_savegpr0#0), want go:func.* got ?
goroutine 129 [running]:
cmd/link/internal/ld.writeFuncs(0xc0000fa000, 0xc001c8a438, {0xc0008f6000, 0xc51, 0xc000f50000?}, 0xc0006d05a0, {0xc000f50000, 0xc51, 0x1ee5fc?}, {0xc0008a3800, ...}, ...)
cmd/link/internal/ld/pcln.go:747 +0xc20
cmd/link/internal/ld.(*pclntab).generateFunctab.func1(0xc0000fa000, 0xba810?)
cmd/link/internal/ld/pcln.go:544 +0x100
cmd/link/internal/ld.writeBlock(0xc0000fa000, 0xc00021a000, 0xc0000ec008, {0xc00084e978?, 0xc0000f44d0?, 0xc0000f8000?}, 0xc0000ec008?, 0xc000848000?, {0x544c60, 0x200, ...})
cmd/link/internal/ld/data.go:1092 +0x434
cmd/link/internal/ld.writeBlocks.func1(0x0?, 0xc0000fa000?, {0xc00084e978?, 0x88028?, 0x1?}, 0x2?, 0x100000000000000?, {0x544c60?, 0xc00000e360?, 0xc001c357a8?})
cmd/link/internal/ld/data.go:1045 +0xc0
created by cmd/link/internal/ld.writeBlocks in goroutine 84
cmd/link/internal/ld/data.go:1044 +0x50c
FAIL gitlab.com/shackra/goimapnotify [build failed]
FAIL
```
This looks like a Go 1.22 regressions, needs further investigation.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12328Missing preloadable_libiconv.so file in gnu-libiconv 1.16-r02024-03-05T14:44:20ZJáchym ToušekMissing preloadable_libiconv.so file in gnu-libiconv 1.16-r0The latest version of [gnu-libiconv](https://pkgs.alpinelinux.org/package/edge/community/armhf/gnu-libiconv) no longer contains the `preloadable_libiconv.so` file which is necessary to use it in libc plug/override mode.
See: https://git...The latest version of [gnu-libiconv](https://pkgs.alpinelinux.org/package/edge/community/armhf/gnu-libiconv) no longer contains the `preloadable_libiconv.so` file which is necessary to use it in libc plug/override mode.
See: https://github.com/docker-library/php/issues/240#issuecomment-762401135https://gitlab.alpinelinux.org/alpine/aports/-/issues/15767community/qemu: qemu-riscv64 segfaults on building various packages2024-02-09T00:31:12ZPatrycja Rosaalpine@ptrcnull.mecommunity/qemu: qemu-riscv64 segfaults on building various packagesa regression in qemu 8.1 ( probably [this one][1]? ) is causing processes to segfault - initially just libsecret (!60394), but now we have even more packages failing with segfaults on small build steps ( plasma-workspace, composer, etc. ...a regression in qemu 8.1 ( probably [this one][1]? ) is causing processes to segfault - initially just libsecret (!60394), but now we have even more packages failing with segfaults on small build steps ( plasma-workspace, composer, etc. )
opening this issue for the sake of having this written down somewhere else than #-commits
[1]: https://gitlab.com/qemu-project/qemu/-/issues/1908https://gitlab.alpinelinux.org/alpine/aports/-/issues/12358Behavior change of nslookup with NXDOMAIN in 3.132024-02-07T10:53:58ZLesterpigBehavior change of nslookup with NXDOMAIN in 3.13Hello,
I'm encountering a strange issue after switching to Alpine 3.13.
I am running Alpine containers on LXD, and containers are unable to resolve local hostnames after upgrade.
After investigation, it looks like **nslookup is now ret...Hello,
I'm encountering a strange issue after switching to Alpine 3.13.
I am running Alpine containers on LXD, and containers are unable to resolve local hostnames after upgrade.
After investigation, it looks like **nslookup is now returning non-zero when unable to resolve IPv6** (NXDOMAIN received).
Is it expected? Does the problem come from LXD (which uses dnsmasq internally)?
Thanks a lot for your help!
---
Here is the full log:
Alpine 3.12
-----------
```
~ # apk list -I
busybox-initscripts-3.2-r2 armhf {busybox-initscripts} (GPL-2.0-only) [installed]
musl-1.1.24-r10 armhf {musl} (MIT) [installed]
alpine-conf-3.9.0-r1 armhf {alpine-conf} (MIT) [installed]
busybox-suid-1.31.1-r19 armhf {busybox} (GPL-2.0-only) [installed]
zlib-1.2.11-r3 armhf {zlib} (Zlib) [installed]
apk-tools-2.10.5-r1 armhf {apk-tools} (GPL-2.0-only) [installed]
musl-utils-1.1.24-r10 armhf {musl} (MIT BSD GPL2+) [installed]
libssl1.1-1.1.1i-r0 armhf {openssl} (OpenSSL) [installed]
alpine-baselayout-3.2.0-r7 armhf {alpine-baselayout} (GPL-2.0-only) [installed]
alpine-keys-2.2-r0 armhf {alpine-keys} (MIT) [installed]
busybox-1.31.1-r19 armhf {busybox} (GPL-2.0-only) [installed]
scanelf-1.2.6-r0 armhf {pax-utils} (GPL-2.0-only) [installed]
alpine-base-3.12.3-r0 armhf {alpine-base} (MIT) [installed]
ca-certificates-bundle-20191127-r4 armhf {ca-certificates} (MPL-2.0 GPL-2.0-or-later) [installed]
libc-utils-0.7.2-r3 armhf {libc-dev} (BSD-2-Clause AND BSD-3-Clause) [installed]
libtls-standalone-2.9.1-r1 armhf {libtls-standalone} (ISC) [installed]
ssl_client-1.31.1-r19 armhf {busybox} (GPL-2.0-only) [installed]
libcrypto1.1-1.1.1i-r0 armhf {openssl} (OpenSSL) [installed]
openrc-0.42.1-r11 armhf {openrc} (BSD-2-Clause) [installed]
~ # nslookup web
Server: 10.1.9.1
Address: 10.1.9.1:53
** server can't find web.moria2: NXDOMAIN
Name: web.moria2
Address: 10.1.8.242
~ # echo $?
0
~ # ping web
PING web (10.1.8.242): 56 data bytes
64 bytes from 10.1.8.242: seq=0 ttl=64 time=1.240 ms
64 bytes from 10.1.8.242: seq=1 ttl=64 time=1.163 ms
64 bytes from 10.1.8.242: seq=2 ttl=64 time=1.078 ms
^C
--- web ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.078/1.160/1.240 ms
```
TCP Dump Log
```
10:37:15.615509 IP 10.1.9.16.49631 > 10.1.9.1.53: 31506+ A? web.moria2. (28)
10:37:15.616196 IP 10.1.9.16.49631 > 10.1.9.1.53: 36715+ AAAA? web.moria2. (28)
10:37:15.617189 IP 10.1.9.1.53 > 10.1.9.16.49631: 36715 NXDomain 0/0/0 (28)
10:37:15.619423 IP 10.1.9.1.53 > 10.1.9.16.49631: 31506* 1/0/0 A 10.1.8.242 (54)
10:37:15.619939 IP 10.1.9.16 > 10.1.8.242: ICMP echo request, id 15105, seq 0, length 64
10:37:15.621099 IP 10.1.8.242 > 10.1.9.16: ICMP echo reply, id 15105, seq 0, length 64
10:37:16.620249 IP 10.1.9.16 > 10.1.8.242: ICMP echo request, id 15105, seq 1, length 64
10:37:16.621303 IP 10.1.8.242 > 10.1.9.16: ICMP echo reply, id 15105, seq 1, length 64
10:37:17.620533 IP 10.1.9.16 > 10.1.8.242: ICMP echo request, id 15105, seq 2, length 64
10:37:17.621517 IP 10.1.8.242 > 10.1.9.16: ICMP echo reply, id 15105, seq 2, length 64
```
Alpine 3.13
-----------
```
~ # apk list -I
busybox-initscripts-3.2-r2 armhf {busybox-initscripts} (GPL-2.0-only) [installed]
musl-1.2.2-r0 armhf {musl} (MIT) [installed]
alpine-conf-3.11.0-r2 armhf {alpine-conf} (MIT) [installed]
busybox-suid-1.32.1-r2 armhf {busybox} (GPL-2.0-only) [installed]
zlib-1.2.11-r3 armhf {zlib} (Zlib) [installed]
apk-tools-2.12.1-r0 armhf {apk-tools} (GPL-2.0-only) [installed]
ifupdown-ng-0.10.2-r2 armhf {ifupdown-ng} (ISC) [installed]
musl-utils-1.2.2-r0 armhf {musl} (MIT BSD GPL2+) [installed]
libssl1.1-1.1.1i-r0 armhf {openssl} (OpenSSL) [installed]
alpine-baselayout-3.2.0-r8 armhf {alpine-baselayout} (GPL-2.0-only) [installed]
alpine-keys-2.2-r0 armhf {alpine-keys} (MIT) [installed]
busybox-1.32.1-r2 armhf {busybox} (GPL-2.0-only) [installed]
scanelf-1.2.8-r0 armhf {pax-utils} (GPL-2.0-only) [installed]
alpine-base-3.13.0-r0 armhf {alpine-base} (MIT) [installed]
ca-certificates-bundle-20191127-r5 armhf {ca-certificates} (MPL-2.0 AND MIT) [installed]
libc-utils-0.7.2-r3 armhf {libc-dev} (BSD-2-Clause AND BSD-3-Clause) [installed]
libtls-standalone-2.9.1-r1 armhf {libtls-standalone} (ISC) [installed]
ssl_client-1.32.1-r2 armhf {busybox} (GPL-2.0-only) [installed]
libcrypto1.1-1.1.1i-r0 armhf {openssl} (OpenSSL) [installed]
openrc-0.42.1-r19 armhf {openrc} (BSD-2-Clause) [installed]
~ # nslookup web
Server: 10.1.9.1
Address: 10.1.9.1:53
** server can't find web.moria2: NXDOMAIN
Name: web.moria2
Address: 10.1.8.242
~ # echo $?
1
~ # ping web
ping: bad address 'web'
```
TCP Dump Log
```
10:41:05.106448 IP 10.1.9.253.58333 > 10.1.9.1.53: 29384+ A? web.moria2 (28)
10:41:05.106530 IP 10.1.9.253.58333 > 10.1.9.1.53: 32342+ AAAA? web.moria2. (28)
10:41:05.107455 IP 10.1.9.1.53 > 10.1.9.253.58333: 32342 NXDomain 0/0/0 (28)
10:41:05.109138 IP 10.1.9.1.53 > 10.1.9.253.58333: 29384* 1/0/0 A 10.1.8.242 (54)
10:41:05.109266 IP 10.1.9.253.50466 > 10.1.9.1.53: 50960+ A? web. (21)
10:41:05.109320 IP 10.1.9.253.50466 > 10.1.9.1.53: 54585+ AAAA? web. (21)
10:41:05.109677 IP 10.1.9.1.53 > 10.1.9.253.50466: 50960 ServFail 0/0/0 (21)
10:41:05.109778 IP 10.1.9.253.50466 > 10.1.9.1.53: 50960+ A? web. (21)
10:41:05.109794 IP 10.1.9.1.53 > 10.1.9.253.50466: 54585 ServFail 0/0/0 (21)
10:41:05.109828 IP 10.1.9.253.50466 > 10.1.9.1.53: 54585+ AAAA? web. (21)
10:41:05.110076 IP 10.1.9.1.53 > 10.1.9.253.50466: 50960 ServFail 0/0/0 (21)
10:41:05.110129 IP 10.1.9.253.50466 > 10.1.9.1.53: 50960+ A? web. (21)
10:41:05.110172 IP 10.1.9.1.53 > 10.1.9.253.50466: 54585 ServFail 0/0/0 (21)
10:41:05.110216 IP 10.1.9.253.50466 > 10.1.9.1.53: 54585+ AAAA? web. (21)
10:41:05.110414 IP 10.1.9.1.53 > 10.1.9.253.50466: 50960 ServFail 0/0/0 (21)
10:41:05.110521 IP 10.1.9.1.53 > 10.1.9.253.50466: 54585 ServFail 0/0/0 (21)
10:41:07.612186 IP 10.1.9.253.50466 > 10.1.9.1.53: 50960+ A? web. (21)
10:41:07.612296 IP 10.1.9.253.50466 > 10.1.9.1.53: 54585+ AAAA? web. (21)
10:41:07.613157 IP 10.1.9.1.53 > 10.1.9.253.50466: 50960 ServFail 0/0/0 (21)
10:41:07.613324 IP 10.1.9.253.50466 > 10.1.9.1.53: 50960+ A? web. (21)
10:41:07.613494 IP 10.1.9.1.53 > 10.1.9.253.50466: 54585 ServFail 0/0/0 (21)
10:41:07.613807 IP 10.1.9.253.50466 > 10.1.9.1.53: 54585+ AAAA? web. (21)
10:41:07.614171 IP 10.1.9.1.53 > 10.1.9.253.50466: 50960 ServFail 0/0/0 (21)
10:41:07.614320 IP 10.1.9.253.50466 > 10.1.9.1.53: 50960+ A? web. (21)
10:41:07.615134 IP 10.1.9.1.53 > 10.1.9.253.50466: 50960 ServFail 0/0/0 (21)
10:41:07.615427 IP 10.1.9.1.53 > 10.1.9.253.50466: 54585 ServFail 0/0/0 (21)
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/15382nuxt.js v2 + element.ui site does not start on latest node:alpine docker image2023-10-23T10:23:10ZSoby Devnuxt.js v2 + element.ui site does not start on latest node:alpine docker imageduring start site in docker container get error:
ERROR Cannot read properties of undefined (reading 'toLowerCase')
at Module.<anonymous> (node_modules/element-ui/lib/element-ui.common.js:9992:0)
at __webpack_require__ (node_modules/eleme...during start site in docker container get error:
ERROR Cannot read properties of undefined (reading 'toLowerCase')
at Module.<anonymous> (node_modules/element-ui/lib/element-ui.common.js:9992:0)
at __webpack_require__ (node_modules/element-ui/lib/element-ui.common.js:21:0)
...
found error in this line of element.ui code
var isFirefox = typeof navigator !== 'undefined' && navigator.userAgent.toLowerCase().indexOf('firefox') > -1;
looks navigator.userAgent is null or undefined
this code is working Ok on 23 days old version node:18.18.0-alpine
2 days old version node:alpine failshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15292sudo make install fails to set suid bits2023-10-02T14:45:25ZMetric Hensudo make install fails to set suid bits```plaintext
$ sudo make PREFIX=${HOME}/.local install
install -D -t /home/nero/.local/bin -o root -g root -m 04111 brightness
install -D -t /home/nero/.local/share/man/man1 brightness.1
$ stat /home/nero/.local/bin/brightness
File: /h...```plaintext
$ sudo make PREFIX=${HOME}/.local install
install -D -t /home/nero/.local/bin -o root -g root -m 04111 brightness
install -D -t /home/nero/.local/share/man/man1 brightness.1
$ stat /home/nero/.local/bin/brightness
File: /home/nero/.local/bin/brightness
Size: 19000 Blocks: 40 IO Block: 4096 regular file
Device: fd01h/64769d Inode: 4849710 Links: 1
Access: (0111/---x--x--x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2023-09-21 16:12:04.397232551 +0000
Modify: 2023-09-21 16:12:04.397232551 +0000
Change: 2023-09-21 16:12:04.397232551 +0000
```
The suid bit is lost. This is a problem with the busybox coreutils/install.c:
strace:
```plaintext
chmod("/home/nero/.local/bin/brightness", 04111) = 0
lchown("/home/nero/.local/bin/brightness", 0, 0) = 0
```
From chown(2):
> When the owner or group of an executable file is changed by an unprivileged user, the S_ISUID and S_ISGID mode bits are cleared. POSIX does not specify whether this also should happen when root does the chown(); the Linux behavior depends on the kernel version, and since Linux 2.2.13, root is treated like other users.
For `install` to work correctly in this case, it needs to chown first and chmod second.
coreutils doing things in the right order:
```plaintext
fchownat(3, "brightness", 0, 0, AT_SYMLINK_NOFOLLOW) = 0
fchmodat(3, "brightness", 04111) = 0
```
Patch proposal for busybox:
```plaintext
diff --git a/coreutils/install.c b/coreutils/install.c
index c0f1c538a..a81a5a1ef 100644
--- a/coreutils/install.c
+++ b/coreutils/install.c
@@ -244,6 +244,14 @@ int install_main(int argc, char **argv)
}
}
+ /* Set the user and group id */
+ if ((opts & (OPT_OWNER|OPT_GROUP))
+ && lchown(dest, uid, gid) == -1
+ ) {
+ bb_perror_msg("can't change %s of %s", "ownership", dest);
+ ret = EXIT_FAILURE;
+ }
+
/* Set the file mode (always, not only with -m).
* GNU coreutils 6.10 is not affected by umask. */
if (chmod(dest, mode) == -1) {
@@ -254,13 +262,6 @@ int install_main(int argc, char **argv)
if (use_default_selinux_context)
setdefaultfilecon(dest);
#endif
- /* Set the user and group id */
- if ((opts & (OPT_OWNER|OPT_GROUP))
- && lchown(dest, uid, gid) == -1
- ) {
- bb_perror_msg("can't change %s of %s", "ownership", dest);
- ret = EXIT_FAILURE;
- }
next:
if (ENABLE_FEATURE_CLEAN_UP && isdir)
free(dest);
```Sören TempelSören Tempelhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12232community/xmlsec-1.2.30-r0: test failures2023-07-04T13:51:48ZKevin Daudtcommunity/xmlsec-1.2.30-r0: test failuresxmlsec has a lot of test failures, most similar to:
```
/keys/rsakey.p12 --pwd secret123 --url-map:http://www.w3.org/TR/xml-stylesheet /home/buildozer/aports/community/xmlsec/src/xmlsec-xmlsec-1_2_30/tests/external-data/xml-stylesheet-2...xmlsec has a lot of test failures, most similar to:
```
/keys/rsakey.p12 --pwd secret123 --url-map:http://www.w3.org/TR/xml-stylesheet /home/buildozer/aports/community/xmlsec/src/xmlsec-xmlsec-1_2_30/tests/external-data/xml-stylesheet-2018 /home/buildozer/aports/community/xmlsec/src/xmlsec-xmlsec-1_2_30/tests/aleksey-xmldsig-01/signature-two-keynames.xml
func=xmlSecNssAppPkcs12LoadSECItem:file=app.c:line=781:obj=unknown:subj=SEC_PKCS12DecoderValidateBags:error=4:crypto library function failed:NSS error: -8099
func=xmlSecNssAppKeyLoadSECItem:file=app.c:line=353:obj=unknown:subj=xmlSecNssAppPkcs12LoadSECItem:error=1:xmlsec library function failed:
func=xmlSecNssAppKeyLoad:file=app.c:line=276:obj=unknown:subj=xmlSecNssAppKeyLoadSECItem:error=1:xmlsec library function failed:
Error: xmlSecCryptoAppKeyLoad failed: filename=/home/buildozer/aports/community/xmlsec/src/xmlsec-xmlsec-1_2_30/tests/keys/rsakey.p12
Error: failed to load pkcs12 key from "/home/buildozer/aports/community/xmlsec/src/xmlsec-xmlsec-1_2_30/tests/keys/rsakey.p12".
Error: keys manager creation failed
Unknown command
```
See for example: https://build.alpinelinux.org/buildlogs/build-3-13-x86_64/community/xmlsec/xmlsec-1.2.30-r0.logSander MaijersSander Maijershttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11602Libvirt service (libvirtd) not starting correctly since upgrading Alpine from...2023-06-26T05:36:29ZFernando Casas SchössowLibvirt service (libvirtd) not starting correctly since upgrading Alpine from 3.11.6 to 3.12.0Hi there,
Last weekend I updated two KVM hosts (x86_64) running Alpine 3.11.6 to 3.12.0.
Since upgrading libvirt service (libvirtd) is not starting correctly.
Two processes of libvirtd are spawned and interaction with libvirt (ie: virsh...Hi there,
Last weekend I updated two KVM hosts (x86_64) running Alpine 3.11.6 to 3.12.0.
Since upgrading libvirt service (libvirtd) is not starting correctly.
Two processes of libvirtd are spawned and interaction with libvirt (ie: virsh or remotely over TLS) doesn't work. If you run a virsh command, the command will just hang for a long time until I press ctrl+c to stop it.
If I manually kill one of the libvirtd processes, libvirt seems to start working again. I can execute virsh commands without any issues, same with remote access.
I found this other issue that may be related but I'm not really sure: [11361](https://gitlab.alpinelinux.org/alpine/aports/-/issues/11361)
The problem is not only happening at startup, I'm still investigating but even while libvirt is already running, after sometime a second process is spawned (don't know why yet) and libvirt stops working again. I need to connect to the KVM host, kill the new libvirtd process that was spawned, and operation resumes as usual.
Any ideas?
Thanks.3.12.1Francesco ColistaFrancesco Colistahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15047file: tar.gz mime-type returns as empty2023-06-22T07:24:53ZWouter Wijsmanfile: tar.gz mime-type returns as empty# Summary
The file command gets the mime-type of tar.gz archives wrong on alpine 3.18 and edge. This was not the case in 3.16. This is causing an issue for my project.
# What happens
When using the following commands:
```
wget http://p...# Summary
The file command gets the mime-type of tar.gz archives wrong on alpine 3.18 and edge. This was not the case in 3.16. This is causing an issue for my project.
# What happens
When using the following commands:
```
wget http://prdownloads.sourceforge.net/argtable/argtable2-13.tar.gz
file --no-sandbox --uncompress --mime-type argtable2-13.tar.gz
```
I see the following result with Alpine 3.18 and Edge:
```
argtable2-13.tar.gz: application/x-empty
```
In 3.16 it returns the following:
```
argtable2-13.tar.gz: application/x-tar
```
On Debian 12 and Archlinux, I see the same result as in Alpine 3.16, even though they use the same version of file as Edge and 3.18. This is what I would expect on all systems.
For some extra info, the `--no-sandbox` option is required when using `--uncompress`. I can reproduce this on at least 11 different tar.gz archives in this repo: https://github.com/pspdev/psp-packages
# What might solve this
It seems there is a possible upstream patch [here](https://github.com/file/file/commit/1dd21dd360472d7b830825df8e40a06cdc1cbbcf), but in my tests it did not resolve the issue.
The project linked is a community made and maintained homebrew SDK for the Playstation Portable. We use pacman to package our stuff, which uses file to determine what to do with archives under the hood when building package. The exact command it uses is `file -S -bizL -- "argtable2-13.tar.gz"`, which also returns `application/x-empty` as mime-type.
I hope this gives enough information to be able to debug this and possibly address this.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15038Port signal-cli and java-libsignal-client to aarch642023-06-20T15:09:24ZEnguerran P.Port signal-cli and java-libsignal-client to aarch64Hello @bratkartoffel ,
I saw that you're the maintainer of the [signal-cli](https://pkgs.alpinelinux.org/package/edge/testing/x86_64/signal-cli) and [java-libsignal-client](https://pkgs.alpinelinux.org/package/edge/testing/x86_64/java-l...Hello @bratkartoffel ,
I saw that you're the maintainer of the [signal-cli](https://pkgs.alpinelinux.org/package/edge/testing/x86_64/signal-cli) and [java-libsignal-client](https://pkgs.alpinelinux.org/package/edge/testing/x86_64/java-libsignal-client) packages.
Is it possible to port those packages to aarch64 ?
According to the docs, it looks like it could be supported https://packaging.gitlab.io/signal-cli/, what do you think ?https://gitlab.alpinelinux.org/alpine/aports/-/issues/15036busctl can't find libelogind-shared.so2023-06-18T20:04:06ZArnav Singhbusctl can't find libelogind-shared.sobusctl-252.9-r0 , elogind-common-252.9-r0 , aarch64, Edge
Upstream issue: https://github.com/elogind/elogind/issues/258
```sh
$ apk manifest elogind-common
sha1:53bc6d235dd522b202fbf5c52e1efa48902be281 usr/libexec/elogind/libelogind-...busctl-252.9-r0 , elogind-common-252.9-r0 , aarch64, Edge
Upstream issue: https://github.com/elogind/elogind/issues/258
```sh
$ apk manifest elogind-common
sha1:53bc6d235dd522b202fbf5c52e1efa48902be281 usr/libexec/elogind/libelogind-shared-252.9.so
$ strace -fe file -- busctl --help |& grep libelogind-shared
openat(AT_FDCWD, "/usr/lib/elogind/libelogind-shared-252.9.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/libelogind-shared-252.9.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/local/lib/libelogind-shared-252.9.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/libelogind-shared-252.9.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Error loading shared library libelogind-shared-252.9.so: No such file or directory (needed by /usr/bin/busctl)
$ readelf -d /usr/bin/busctl
...
0x000000000000001d (RUNPATH) Library runpath: [/usr/lib/elogind]
...
```
Per [blame](https://github.com/elogind/elogind/blame/v252.9/meson.build#L3984), in 252.9 [this commit](https://github.com/elogind/elogind/commit/b1bb46fa48b8ecd1983c30cca217d99bcc21dff2) changed `install_rpath : rootlibexecdir` to `install_rpath : rootpkglibdir` for a bunch of binaries, including `busctl`. But it also didn't change `loginctl`, `elogind` etc, so I can see why [this patch](https://gitlab.alpinelinux.org/alpine/aports/-/blob/afb95ae020d8262a04220785c8a9168a6fc57b66/community/elogind/rootlibexecdir.patch) was added.
So I guess either we need the patch to also change `busctl` etc binaries that have `install_rpath : rootpkglibdir` , or we undo that patch and instead patch `loginctl` etc to have `install_rpath : rootpkglibdir` ? The latter approach is what the patch in the GH issue does and is smaller, so maybe that's better?https://gitlab.alpinelinux.org/alpine/aports/-/issues/13504Busybox/ed crashes with illegal instruction2023-06-09T19:35:43ZDerek AtkinsBusybox/ed crashes with illegal instructionWhen trying to delete from a line, ed (via busybox) crashes (this is on
x86_x64, but possible other platforms too). A simple test case:
```
[core-ssh ~]$ echo "# test" > test
[core-ssh ~]$ ed test
"test", 1 lines, 7 chars
: s/#//
Trace...When trying to delete from a line, ed (via busybox) crashes (this is on
x86_x64, but possible other platforms too). A simple test case:
```
[core-ssh ~]$ echo "# test" > test
[core-ssh ~]$ ed test
"test", 1 lines, 7 chars
: s/#//
Trace/breakpoint trap (core dumped)
```
Similar testcase:
```
$ docker run -it alpine
/ # echo "# test" > test
/ # ed test
"test", 1 lines, 7 chars
: s/#//
Illegal instruction (core dumped)
```
c.f. https://github.com/home-assistant/addons/issues/2338Sören TempelSören Tempelhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13755Mysterious Segmentation fault that only happen in 3.14+ alpine2023-05-12T03:33:01ZKim Yu NgMysterious Segmentation fault that only happen in 3.14+ alpineHi, I have run into segmentation fault which doesn't appear to occur on ubuntu/mac, can only be repro-ed in alpine distro. The segmentation fault happened when [rmagick](https://github.com/rmagick/rmagick) (ruby library/gem) try to read ...Hi, I have run into segmentation fault which doesn't appear to occur on ubuntu/mac, can only be repro-ed in alpine distro. The segmentation fault happened when [rmagick](https://github.com/rmagick/rmagick) (ruby library/gem) try to read in pdf uses ghostscript (c/library) under the hood and we're guessing it might collide with symbol from another [rbtree](https://github.com/kyrylo/rbtree3) (ruby library) which both of them should be isolated
Affecting Environment:
- Alpine: 3.14/3.15+
Setup:
- Ruby: 2.7/3.0/3.1
- ImageMagick: 7+
- ghostscript: 9.5+
Here is the minimal gist to reproduce the bug using docker
- https://gist.github.com/Watson1978/0ec37694a363c64414b944ed47dd8373
Reference:
- Original bug report at rmagick repo: https://github.com/rmagick/rmagick/issues/1334https://gitlab.alpinelinux.org/alpine/aports/-/issues/14846Compatibility with golang 1.20 via libc6-compat2023-04-30T00:24:55ZNuruCompatibility with golang 1.20 via libc6-compatPrior to the release of `go` v1.20, Alpine could run dynamically linked binaries produced by `go` for `GOOS=linux` if `libc6-compat` was installed. This has been broken in `go` v1.20 by a change in their build support. The response of th...Prior to the release of `go` v1.20, Alpine could run dynamically linked binaries produced by `go` for `GOOS=linux` if `libc6-compat` was installed. This has been broken in `go` v1.20 by a change in their build support. The response of the maintainers is that if people want to use tools written in `go` on Alpine, they should build them themselves and link against `musl`. While this is, of course, an option, it would be simpler and more convenient if `libc6-compat` were enhanced to supply `libresolv.so`. See references for more details.
## References
- https://github.com/golang/go/issues/59305
- https://github.com/kubernetes/minikube/issues/16228https://gitlab.alpinelinux.org/alpine/aports/-/issues/14805p7zip has a serious buffer overrun issue when handling zip files2023-04-20T00:24:24ZlibTorrentUserp7zip has a serious buffer overrun issue when handling zip filesThe bug makes the code think file paths are way longer than they actually are and, because of that, sometimes the user might see 7z complaining there is already a file with the same name as the one currently being extract inside the dest...The bug makes the code think file paths are way longer than they actually are and, because of that, sometimes the user might see 7z complaining there is already a file with the same name as the one currently being extract inside the destination directory.
I've already reported the bug upstream
https://github.com/p7zip-project/p7zip/issues/112#issuecomment-1509959881
The above link also has more details about the bug.https://gitlab.alpinelinux.org/alpine/aports/-/issues/14706main/openrc: rc-service stop deley one second for each service2023-03-11T15:10:42ZJustinmain/openrc: rc-service stop deley one second for each service
@psykose
# issue
let's say we have 5 services to stop in a script :
```sh
for service in A B C D E ; do rc-service $service stop ; done
```
A takes 0.09s to stop, but after that, **each of B C D E takes about 1 seconds to stop**.
...
@psykose
# issue
let's say we have 5 services to stop in a script :
```sh
for service in A B C D E ; do rc-service $service stop ; done
```
A takes 0.09s to stop, but after that, **each of B C D E takes about 1 seconds to stop**.
Tested on alpine 3.11-3.17 and current edge, aarch64 and x86_64, all have the same issue
**Also tested on Gentoo livecd /openrc 0.45.2 , but NO issue.** every service takes about 0.05s~0.09s to stop
some questions: is this related to musl libc or the patches alpine uses or the openrc compile options?
it would be nice if the devs could run below test and verify, thanks a lot
# test script
```sh
#!/bin/sh
# what is this for
# well, if we stop multiple services in a script
# the first one is always fast, but after that, it becomes super slow
#
# nc is a good program to test supervise-daemon
# create 5 nc daemons, listen on 5 different port
# prepare
echo '+++ prepare 5 nc daemons +++'
echo
for i in 1 2 3 4 5 ; do
cat <<EOF > /etc/init.d/supervise-daemon_$i
#!/sbin/openrc-run
supervisor="supervise-daemon"
command="/bin/busybox"
command_args="nc -l -s 127.0.0.1 -p 3000$i"
EOF
chmod +x /etc/init.d/supervise-daemon_$i
echo "created /etc/init.d/supervise-daemon_$i"
done
echo
# measure start
echo "+++ measure time to start 5 daemons +++"
echo
for i in 1 2 3 4 5 ; do
echo "==> starting supervise-daemon_$i"
time rc-service -q supervise-daemon_$i start
echo
done
echo "+++ measure time to stop 5 daemons +++"
echo
# measure stop
for i in 1 2 3 4 5 ; do
echo "==> stopping supervise-daemon_$i"
time rc-service -q supervise-daemon_$i stop
echo
done
# clean
for i in 1 2 3 4 5 ; do
rm -f /etc/init.d/supervise-daemon_$i
echo "/etc/init.d/supervise-daemon_$i deleted"
done
```
# test result
```
+++ prepare 5 nc daemons +++
created /etc/init.d/supervise-daemon_1
created /etc/init.d/supervise-daemon_2
created /etc/init.d/supervise-daemon_3
created /etc/init.d/supervise-daemon_4
created /etc/init.d/supervise-daemon_5
+++ measure time to start 5 daemons +++
==> starting supervise-daemon_1
real 0m 0.91s
user 0m 0.43s
sys 0m 0.49s
==> starting supervise-daemon_2
real 0m 0.09s
user 0m 0.02s
sys 0m 0.04s
==> starting supervise-daemon_3
real 0m 0.08s
user 0m 0.03s
sys 0m 0.03s
==> starting supervise-daemon_4
real 0m 0.09s
user 0m 0.02s
sys 0m 0.03s
==> starting supervise-daemon_5
real 0m 0.10s
user 0m 0.03s
sys 0m 0.03s
+++ measure time to stop 5 daemons +++
==> stopping supervise-daemon_1
real 0m 0.09s
user 0m 0.03s
sys 0m 0.04s
==> stopping supervise-daemon_2
real 0m 1.00s
user 0m 0.06s
sys 0m 0.33s
==> stopping supervise-daemon_3
real 0m 1.00s
user 0m 0.09s
sys 0m 0.36s
==> stopping supervise-daemon_4
real 0m 0.99s
user 0m 0.09s
sys 0m 0.35s
==> stopping supervise-daemon_5
real 0m 1.00s
user 0m 0.08s
sys 0m 0.39s
/etc/init.d/supervise-daemon_1 deleted
/etc/init.d/supervise-daemon_2 deleted
/etc/init.d/supervise-daemon_3 deleted
/etc/init.d/supervise-daemon_4 deleted
/etc/init.d/supervise-daemon_5 deleted
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/13962main/libstdc++: std::locale("") throws invalid locale2023-02-11T16:35:26ZGhost Usermain/libstdc++: std::locale("") throws invalid localequick reproduction:
```c++
#include <locale>
int main() {
std::locale("");
}
```
(you need to have any non-C locale. LC_ALL=C is the only way to make that not throw- LC_ALL=C.UTF-8 does)
this is quite an old issue- it's been know...quick reproduction:
```c++
#include <locale>
int main() {
std::locale("");
}
```
(you need to have any non-C locale. LC_ALL=C is the only way to make that not throw- LC_ALL=C.UTF-8 does)
this is quite an old issue- it's been known for an extremely long time here and there, and is caused by a shortcoming in the posix/generic libstdc++ locale backend.
the specific issue comes from [here](https://github.com/gcc-mirror/gcc/blob/f9764ea128c99ba1c10de21a092266cd7da8700a/libstdc++-v3/config/locale/generic/c_locale.cc#L242-L247):
```c++
// Currently, the generic model only supports the "C" locale.
// See http://gcc.gnu.org/ml/libstdc++/2003-02/msg00345.html
__cloc = 0;
if (strcmp(__s, "C"))
__throw_runtime_error(__N("locale::facet::_S_create_c_locale "
"name not valid"));
```
however, merely patching this check out, with a patch carried by both [void](https://github.com/void-linux/void-packages/commit/d4a9febf12a5d5cdfbee54703335e8dd1fe98848) and [adélie](https://git.adelielinux.org/adelie/packages/-/commit/d09b437d), makes that not throw. and then the application does work, and that code does what it's intended to (set locale to user LC/LANG locale with `std::locale::global(std::locale(""));` or similar, as the default is C), and the actual localisation/translations work.
the only issue is that, some strings do actually segfault when passed to std::locale (only with the above patch)- notably:
```c++
std::locale(setlocale(/* basically anything */));
```
the reason why is setlocale returns things that are `;` delimited, and that causes something in that std::locale backend to segfault. however, i don't believe this is actually allowed by the standard? i'm not sure, but..
in any case, my proposal is to add the above patch, as without it localisations cannot work in some programs- in testing/easyeffects for instance i had to patch out every ("") to () to fix them, as otherwise it can only be launched with LC_ALL=C. and if these other distros carry it too, then i assume it's been tested in practice well enough that probably no random program is going to crash.
if someone knows how to efficiently grep through a ton of code in debian codesearch or something for that specific instance preemptively that would be nice, but it's fine to patch regardless imo
the real solution would be fixing this in libstdc++, but i have no actual knowledge of how to do so.Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13211util-linux mount (losetup) fails on docker running qemu arm32v7/alpine:3.142023-02-07T14:55:26ZSabin Huibanutil-linux mount (losetup) fails on docker running qemu arm32v7/alpine:3.14util-linux mount fails (as losetup fails as well) on docker running qemu arm32v7/alpine:3.14
The error message when executing either mount or losetup commands is:
_Unsupported ioctl: cmd=0x4c0a_util-linux mount fails (as losetup fails as well) on docker running qemu arm32v7/alpine:3.14
The error message when executing either mount or losetup commands is:
_Unsupported ioctl: cmd=0x4c0a_https://gitlab.alpinelinux.org/alpine/aports/-/issues/12194upx aarch64 support is required2023-02-07T13:22:55Ztim-oleksiiupx aarch64 support is requiredHello,
Can you please provide support of aarch64 for `upx` package? It seems that the tool does support aarch64
https://upx.github.io/main/2017/05/12/UPX-3.94-released.html
OleksiiHello,
Can you please provide support of aarch64 for `upx` package? It seems that the tool does support aarch64
https://upx.github.io/main/2017/05/12/UPX-3.94-released.html
Oleksiihttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13769Discrepancy between BusyBox's (re-)implementation of xxd's -r (reverse) optio...2023-02-07T12:20:54ZRichard MilneDiscrepancy between BusyBox's (re-)implementation of xxd's -r (reverse) option and that of the stand-alone package.Apologies if I've opened this issue in the incorrect Alpine sub-project; this seemed the most suitable of all the options.
Apologies, too, if this doesn't concern you - if I should (only) report the issue to the BusyBox project, let me ...Apologies if I've opened this issue in the incorrect Alpine sub-project; this seemed the most suitable of all the options.
Apologies, too, if this doesn't concern you - if I should (only) report the issue to the BusyBox project, let me know. I thought, however, that you might still be interested in the differences in your distribution.
The issue lies with the two `xxd` implementations (specifically, the implementation of `xxd -r`) available in the distribution - the BusyBox implementation, and that provided by the package `xxd`. The BusyBox implementation seems to introduce extraneous bytes after decoding the first 64.
I've been able to reproduce the discrepancy in `alpine:3.15`, and have itemised the steps I took in the attached [Dockerfile.xxd](/uploads/fb12153bface97fdfaca21e3e190d96a/Dockerfile.xxd). Please see the comments in that file for a discussion of what I did and what I expected to see, as well as the output from actually building the file, which I did via
docker build --no-cache -f Dockerfile.xxd .