alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2024-03-19T09:44:10Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15888coq package is incapable of building plugins2024-03-19T09:44:10ZJason Grosscoq package is incapable of building plugins
## Package Information
* Package name: coq
* Package version: `apk info` does not list package versions, see [here](https://github.com/mit-plv/fiat-crypto/actions/runs/8336730797/job/22814340740?pr=1834#step:5:243)
* Alpine version: *A...
## Package Information
* Package name: coq
* Package version: `apk info` does not list package versions, see [here](https://github.com/mit-plv/fiat-crypto/actions/runs/8336730797/job/22814340740?pr=1834#step:5:243)
* Alpine version: *Alpine version from `/etc/alpine-release`* (Will edit in once [CI finishes](https://github.com/mit-plv/fiat-crypto/actions/runs/8338003431/job/22817630366))
* Alpine architecture: *Architecture obtained via `apk --print-arch`* (Will edit in once [CI finishes](https://github.com/mit-plv/fiat-crypto/actions/runs/8338003431/job/22817630366))
## Summary
The `coq` package needs to be rebuilt on top of the latest `ocaml` package, since the current version is incapable of loading plugins, erroring with "Error: Dynlink error: implementation mismatch on Stdlib__List", see [here](https://github.com/mit-plv/fiat-crypto/actions/runs/8336730797/job/22814340740?pr=1834#step:6:1022)
## Steps to reproduce
Clone https://github.com/mit-plv/rewriter, run `make`https://gitlab.alpinelinux.org/alpine/aports/-/issues/15886Migrate aport testing/manticoresearch to testing/manticore; Adopt package2024-03-18T20:45:16ZTherminoel.kuntze@thermi.consultingMigrate aport testing/manticoresearch to testing/manticore; Adopt packageZach already provided feedback he'd be okay with itZach already provided feedback he'd be okay with ithttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15883Switching to edge fails because `so:libkImageAnnotator-Qt6.so.0` is missing a...2024-03-18T11:37:57ZEliasSwitching to edge fails because `so:libkImageAnnotator-Qt6.so.0` is missing and required by KDE's `gwenview`I am trying to switch to edge, but `apk upgrade` fails.
My machine runs Alpine version 3.19.1 with KDE Plasma installed through the setup-desktop script.
I have edited `/etc/apk/repositories` to contain:
```
http://dl-cdn.alpinelinux.o...I am trying to switch to edge, but `apk upgrade` fails.
My machine runs Alpine version 3.19.1 with KDE Plasma installed through the setup-desktop script.
I have edited `/etc/apk/repositories` to contain:
```
http://dl-cdn.alpinelinux.org/alpine/edge/main
http://dl-cdn.alpinelinux.org/alpine/edge/community
```
Then, I ran the following commands and got an error:
```
~ $ doas apk update
fetch http://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/edge/community/x86_64/APKINDEX.tar.gz
v20240315-148-g4d7625e228c [http://dl-cdn.alpinelinux.org/alpine/edge/main]
v20240315-151-gd22bc27559f [http://dl-cdn.alpinelinux.org/alpine/edge/community]
OK: 24068 distinct packages available
~ $ doas apk upgrade
ERROR: unable to select packages:
so:libkImageAnnotator-Qt6.so.0 (no such package):
required by: gwenview-24.02.0-r0[so:libkImageAnnotator-Qt6.so.0]
```
`apk-tools` managed to upgrade before this happened. It is at version `2.14.1-r0`.
What can I try?https://gitlab.alpinelinux.org/alpine/aports/-/issues/15882Include support for libSMI in Wireshark2024-03-18T20:17:36ZFrançois PoirotteInclude support for libSMI in Wireshark## Package Information
* Package name: wireshark
* Package version: 4.2.3-r0
* Alpine version: edge
* Alpine architecture: x86_64
## Summary
I often deal with SNMP packet captures. On other distributions, I can configure Wireshark to ...## Package Information
* Package name: wireshark
* Package version: 4.2.3-r0
* Alpine version: edge
* Alpine architecture: x86_64
## Summary
I often deal with SNMP packet captures. On other distributions, I can configure Wireshark to automatically decode variable bindings using custom MIBs.
This is not currently possible in Alpine Linux because Wireshark is built without support for libSMI (as shown in https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/wireshark/wireshark-4.2.3-r0.log; look for "SMI_LIBRARY").
I believe this is due to the fact that libSMI itself wasn't available in the repositories until recently.
Since libSMI is now available in edge, would you consider adding it as a build dependency for Wireshark?
## Steps to reproduce
* Get a PCAP capture with SNMP packets in them.
* Install the MIBs used in those packets.
* Open the capture in Wireshark/tshark: only basic decoding is done on the SNMP fields.
In particular, when converting the capture to a PDML file using tshark (`tshark -T pdml -r /tmp/snmp.pcap > /tmp/snmp.pdml`), variable bindings which use the "DisplayString" TEXTUAL-CONVENTION are represented as OCTETS objects instead of being decoded properly (i.e. no `snmp.var-bind_str` subtag is created for them).Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10979make zstd dependency optional2024-03-16T13:15:07ZPaul Spoorenmake zstd dependency optionalWould be nice to have zstd support as a meson option, Ideally we don't force OpenWrt to include libzstd by default.Would be nice to have zstd support as a meson option, Ideally we don't force OpenWrt to include libzstd by default.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15874nfs.mount does not continue to mount in background as it should2024-03-14T17:02:00ZDawid Wróbelnfs.mount does not continue to mount in background as it shouldI have a following entry in my fstab:
`10.0.0.22:/mnt/pool1/somelocation /mnt/somelocation nfs rw,nfsvers=3,proto=tcp,nolock,bg 0 0`
The `bg`, per nfs manual, indicates that upon failure to mount the share immediately, a child ...I have a following entry in my fstab:
`10.0.0.22:/mnt/pool1/somelocation /mnt/somelocation nfs rw,nfsvers=3,proto=tcp,nolock,bg 0 0`
The `bg`, per nfs manual, indicates that upon failure to mount the share immediately, a child process should be spawned and the attempt to mount should continue in the background. Since this is a tcp protocol, it should by default try for almost a week before giving up, with a check interval between 60 and 600s using a linear backoff.
However, this doesn't work. Having explicitly downed the remote share, the `/var/log/messages` has following two lines only:
```
Mar 14 14:42:40 host auth.err mount[2881]: mount to NFS server '10.0.0.22' failed: Not supported, retrying
Mar 14 14:42:40 host daemon.info init: starting pid 2923, tty '/dev/tty1': '/sbin/getty 38400 tty1'
Mar 14 14:42:40 host daemon.info init: starting pid 2924, tty '/dev/tty2': '/sbin/getty 38400 tty2'
Mar 14 14:42:40 host daemon.info init: starting pid 2928, tty '/dev/tty3': '/sbin/getty 38400 tty3'
Mar 14 14:42:40 host daemon.info init: starting pid 2932, tty '/dev/tty4': '/sbin/getty 38400 tty4'
Mar 14 14:42:40 host daemon.info init: starting pid 2936, tty '/dev/tty5': '/sbin/getty 38400 tty5'
Mar 14 14:42:40 host daemon.info init: starting pid 2940, tty '/dev/tty6': '/sbin/getty 38400 tty6'
Mar 14 14:42:41 host auth.err mount[2885]: mount to NFS server '10.0.0.22' failed: Not supported, retrying
```
No other attempts are made, the share remains unmounted. Also note the two consecutive mount attempts are barely within a second of each other, which is odd.
Calling the `mount /mnt/somelocation` explicitly I see:
```
host:~# mount /mnt/somelocation
mount.nfs: backgrounding "10.0.0.22:/mnt/pool1/somelocation"
mount.nfs: mount options: "rw,nfsvers=3,proto=tcp,nolock,bg,addr=10.0.0.22"
```
If I then immediately check running processes for `mount`, I can see `mount.nfs` running for a couple seconds, before it's gone. This results in two identical `/var/log/messages` log lines as shown above.
Also, adding "retry=10000" to the arguments explicitly doesn't help.
I am not sure if this is an NFS or a mount issue, hope you can help triaging it. FYI, I am using an up-to-date Alpine Stable.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15871Tailscale - Latest Version (1.62.0) [UPDATE]2024-03-16T13:18:59ZMartin von ReichenbergTailscale - Latest Version (1.62.0) [UPDATE]Anybody willing to **update** [Tailscale](https://github.com/tailscale/tailscale/releases/tag/v1.62.0) to its **_latest_** stable upstream version ?_?
One of release notes for Linux is:
- Changed: [Auto-update](https://github.com/tailsc...Anybody willing to **update** [Tailscale](https://github.com/tailscale/tailscale/releases/tag/v1.62.0) to its **_latest_** stable upstream version ?_?
One of release notes for Linux is:
- Changed: [Auto-update](https://github.com/tailscale/tailscale/blob/v1.62.0/kb/1067/update#auto-updates) version detection on _Alpine Linux_ is improved
There should not be almost any changes to the APKBUILD file.
_Thank you for complying.
Martin_https://gitlab.alpinelinux.org/alpine/aports/-/issues/15870crun 1.14.4-r0: `Error: OCI runtime error: crun: Error relocating /usr/bin/cr...2024-03-14T12:22:17ZSviatoslav Sydorenko (Святослав Сидоренко)crun 1.14.4-r0: `Error: OCI runtime error: crun: Error relocating /usr/bin/crun: statx: symbol not found`This crun version seems to be causing problems in Alpine 3.16, 3.17 and 3.18. It's failing in our (ansible-core) CI starting today. Specifically, a podman test errors out with `Error: OCI runtime error: crun: Error relocating /usr/bin/cr...This crun version seems to be causing problems in Alpine 3.16, 3.17 and 3.18. It's failing in our (ansible-core) CI starting today. Specifically, a podman test errors out with `Error: OCI runtime error: crun: Error relocating /usr/bin/crun: statx: symbol not found`. The last successful run was yesterday with crun 1.14.3-r0: https://dev.azure.com/ansible/ansible/_build/results?buildId=106375&view=logs&j=dbe9fb76-0199-5563-3b19-1ec608621e63&t=ab23c890-6432-5a05-cf7e-d4a4aa5ed608&l=605. This is probably an upstream issue so I've file a report there too: https://github.com/containers/crun/issues/1436. Recording it here for people landing from a search engine.
This seems to be connected to the upstream update: https://gitlab.alpinelinux.org/alpine/aports/-/commit/16366704caf925a1fab205889d2a126366380ac1#note_384116https://gitlab.alpinelinux.org/alpine/aports/-/issues/15868CVE-2023-38469, CVE-2023-38470, CVE-2023-38471, CVE-2023-38472, & CVE-2023-38...2024-03-13T12:08:03Zmitchrv10CVE-2023-38469, CVE-2023-38470, CVE-2023-38471, CVE-2023-38472, & CVE-2023-38473 Remediation for avahi-libsPackage: avahi
OS: 3.19
@ncopa can you help fix these CVEs? Since they were detected in 11/2023 these are overdue for remediation. Appreciate your help and assistance.
CVEs:
CVE-2023-38469 (medium severity)
- A vulnerability was foun...Package: avahi
OS: 3.19
@ncopa can you help fix these CVEs? Since they were detected in 11/2023 these are overdue for remediation. Appreciate your help and assistance.
CVEs:
CVE-2023-38469 (medium severity)
- A vulnerability was found in Avahi, where a reachable assertion exists in avahi_dns_packet_append_record.
- https://nvd.nist.gov/vuln/detail/CVE-2023-38469
- https://security.alpinelinux.org/vuln/CVE-2023-38469
CVE-2023-38470 (medium severity)
- A vulnerability was found in Avahi. A reachable assertion exists in the avahi_escape_label() function.
- https://nvd.nist.gov/vuln/detail/CVE-2023-38470
- https://security.alpinelinux.org/vuln/CVE-2023-38470
CVE-2023-38471 (medium severity)
- A vulnerability was found in Avahi. A reachable assertion exists in the dbus_set_host_name function.
- https://nvd.nist.gov/vuln/detail/CVE-2023-38471
- https://security.alpinelinux.org/vuln/CVE-2023-38471
CVE-2023-38472 (medium severity)
- A vulnerability was found in Avahi. A reachable assertion exists in the avahi_rdata_parse() function.
- https://nvd.nist.gov/vuln/detail/CVE-2023-38472
- https://security.alpinelinux.org/vuln/CVE-2023-38472
CVE-2023-38473 (medium severity)
- A vulnerability was found in Avahi. A reachable assertion exists in the avahi_alternative_host_name() function.
- https://nvd.nist.gov/vuln/detail/CVE-2023-38473
- https://security.alpinelinux.org/vuln/CVE-2023-38473Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15865netdata-go-plugins: check() fails2024-03-12T14:24:23ZSören Tempelnetdata-go-plugins: check() failsCurrently (with Go 1.22) the `check()` for netdata-go-plugins fails with:
```
time=2024-03-12T10:44:50.263Z level=error msg="topic filer initialization: parse matcher \"+\" error: invalid syntax" plugin=go.d
time=2024-03-12T10:44:50.263...Currently (with Go 1.22) the `check()` for netdata-go-plugins fails with:
```
time=2024-03-12T10:44:50.263Z level=error msg="topic filer initialization: parse matcher \"+\" error: invalid syntax" plugin=go.d
time=2024-03-12T10:44:50.263Z level=error msg="config validation: URL is not set" plugin=go.d
time=2024-03-12T10:44:50.263Z level=error msg="client initializing: error on creating TLS config: could not read certificate \"testdata/tls\": open testdata/tls: no such file or directory" plugin=go.d
time=2024-03-12T10:44:50.263Z level=error msg="server 'http://127.0.0.1:44843' returned HTTP status code 404 (404 Not Found)" plugin=go.d
time=2024-03-12T10:44:50.264Z level=error msg="Get \"http://127.0.0.1:38001/metrics\": dial tcp 127.0.0.1:38001: connect: connection refused" plugin=go.d
time=2024-03-12T10:44:50.266Z level=error msg="returned metrics aren't Apache Pulsar metrics" plugin=go.d
time=2024-03-12T10:44:50.267Z level=error msg="strconv.ParseFloat: parsing \"and\": invalid syntax" plugin=go.d
time=2024-03-12T10:44:50.267Z level=error msg="returned metrics aren't Apache Pulsar metrics" plugin=go.d
time=2024-03-12T10:44:50.268Z level=error msg="strconv.ParseFloat: parsing \"and\": invalid syntax" plugin=go.d
time=2024-03-12T10:44:50.268Z level=error msg="server 'http://127.0.0.1:43027' returned HTTP status code 404 (404 Not Found)" plugin=go.d
time=2024-03-12T10:44:50.268Z level=error msg="Get \"http://127.0.0.1:38001/metrics\": dial tcp 127.0.0.1:38001: connect: connection refused" plugin=go.d
--- FAIL: TestPulsar_Collect (0.04s)
--- FAIL: TestPulsar_Collect/standalone_v2.5.0_namespaces (0.01s)
pulsar_test.go:210:
Error Trace: github.com/netdata/go.d.plugin/modules/pulsar/pulsar_test.go:210
github.com/netdata/go.d.plugin/modules/pulsar/pulsar_test.go:169
Error: Should be true
Test: TestPulsar_Collect/standalone_v2.5.0_namespaces
Messages: collected metrics has no data for dim 'pulsar_topics_count_%s' chart 'broker_components'
…
```
Example build log: [netdata-go-plugins-0.58.0-r1.log](/uploads/446d6f70cd7e3f488dd0c0e77c4c6eb6/netdata-go-plugins-0.58.0-r1.log)
CC: @HRiohttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15861busybox wget https://www.netfilter.org fails2024-03-11T13:18:12ZNatanael Copabusybox wget https://www.netfilter.org fails```
$ wget https://www.netfilter.org
Connecting to www.netfilter.org ([2001:4b98:dc0:43:216:3eff:fe87:a456]:443)
wget: server returned error: HTTP/1.1 403 Forbidden
```
curl works:
```
$ curl https://www.netfilter.org > /dev/null
% T...```
$ wget https://www.netfilter.org
Connecting to www.netfilter.org ([2001:4b98:dc0:43:216:3eff:fe87:a456]:443)
wget: server returned error: HTTP/1.1 403 Forbidden
```
curl works:
```
$ curl https://www.netfilter.org > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 21803 100 21803 0 0 16773 0 0:00:01 0:00:01 --:--:-- 16784
```
Adding `--header 'Accept: *'` or `--header 'Accept: */*'` makes it work:
```
$ wget --header 'Accept: */*' https://w
ww.netfilter.org
Connecting to www.netfilter.org ([2001:4b98:dc0:43:216:3eff:fe87:a456]:443)
saving to 'index.html'
index.html 100% |****************************************************| 21803 0:00:00 ETA
'index.html' saved
```
Curl also adds this header.
```
$ curl --silent --verbose https://www.
netfilter.org > /dev/null
* Host www.netfilter.org:443 was resolved.
* IPv6: 2001:4b98:dc0:43:216:3eff:fe87:a456
* IPv4: 92.243.18.11
* Trying [2001:4b98:dc0:43:216:3eff:fe87:a456]:443...
* Connected to www.netfilter.org (2001:4b98:dc0:43:216:3eff:fe87:a456) port 443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [93 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4160 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 / prime256v1 / rsaEncryption
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
* subject: CN=iptables.org
* start date: Mar 2 10:37:06 2024 GMT
* expire date: May 31 10:37:05 2024 GMT
* subjectAltName: host "www.netfilter.org" matched cert's "www.netfilter.org"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
} [5 bytes data]
> GET / HTTP/1.1
> Host: www.netfilter.org
> User-Agent: curl/8.6.0
> Accept: */*
>
{ [5 bytes data]
< HTTP/1.1 200 OK
< Date: Mon, 11 Mar 2024 10:46:11 GMT
< Server: Apache
< Last-Modified: Fri, 17 Nov 2023 10:59:02 GMT
< ETag: "552b-60a570636932f"
< Accept-Ranges: bytes
< Content-Length: 21803
< Content-Type: text/html; charset=UTF-8
<
{ [5 bytes data]
* Connection #0 to host www.netfilter.org left intact
```
This was discovered in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61665
I will report this upstream but I created this issue to have the details documented somewhere.3.20.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/15860prometheus-json-exporter: Downloads pre-build promu binary2024-03-12T11:04:30ZSören Tempelprometheus-json-exporter: Downloads pre-build promu binaryFrom the build log:
```
curl -s -L https://github.com/prometheus/promu/releases/download/v0.14.0/promu-0.14.0.linux-s390x.tar.gz | tar -xvzf - -C /tmp/tmp.LiOLKf
promu-0.14.0.linux-s390x/
promu-0.14.0.linux-s390x/LICENSE
promu-0.14.0.li...From the build log:
```
curl -s -L https://github.com/prometheus/promu/releases/download/v0.14.0/promu-0.14.0.linux-s390x.tar.gz | tar -xvzf - -C /tmp/tmp.LiOLKf
promu-0.14.0.linux-s390x/
promu-0.14.0.linux-s390x/LICENSE
promu-0.14.0.linux-s390x/NOTICE
promu-0.14.0.linux-s390x/promu
mkdir -p /home/soeren/go/bin
cp /tmp/tmp.LiOLKf/promu-0.14.0.linux-s390x/promu /home/soeren/go/bin/promu
rm -r /tmp/tmp.LiOLKf
```
promu is a wrapper around `go build`.
Instead of downloading pre-build binaries, promu should be packaged and the package should be used for building prometheus-json-exporter.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15858community/kio: fortify abort in sprintf() on 32-bit2024-03-11T01:42:54ZPatrycja Rosaalpine@ptrcnull.mecommunity/kio: fortify abort in sprintf() on 32-bitpartial backtrace:
```
(gdb) bt full
#0 sprintf (__f=0xf736c016 "%6llx_%2x_", __s=0xfff58740 "5500000100_")
at /usr/include/fortify/stdio.h:133
__b = 12
__r = 20
__b = <optimized out>
__r = <optimized...partial backtrace:
```
(gdb) bt full
#0 sprintf (__f=0xf736c016 "%6llx_%2x_", __s=0xfff58740 "5500000100_")
at /usr/include/fortify/stdio.h:133
__b = 12
__r = 20
__b = <optimized out>
__r = <optimized out>
#1 KIO::ConnectionBackend::sendCommand (this=0xf67e9bc0, cmd=85, data=...)
at /home/buildozer/aports/community/kio/src/kio-6.0.0/src/core/connectionbackend.cpp:177
buffer = "5500000100_"
#2 0xf724e353 in KIO::Connection::sendnow
(data=..., cmd=<optimized out>, this=<optimized out>)
at /home/buildozer/aports/community/kio/src/kio-6.0.0/src/core/connection.cpp:186
#3 KIO::ConnectionPrivate::dequeue (this=this@entry=0xf4e20bd0)
at /home/buildozer/aports/community/kio/src/kio-6.0.0/src/core/connection.cpp:26
task = @0xf4e1a25c: {cmd = 85, data = {d = {d = 0xf51d1280, ptr = 0xf51d128c "", size = 256}}}
__for_range = @0xf4e20bd0: {<QListSpecialMethods<KIO::Task>> = {<QListSpecialMethodsBase<KIO::Task>> = {<No data fields>}, <No data fields>}, d = {d = 0xf4e1a250, ptr = 0xf4e1a25c, size = 4}}
__for_begin = {i = <optimized out>}
__for_end = {i = <optimized out>}
#4 0xf724e5f6 in KIO::ConnectionPrivate::dequeue (this=0xf4e20bd0)
at /home/buildozer/aports/community/kio/src/kio-6.0.0/src/core/connection.cpp:21
task = <optimized out>
__for_range = <optimized out>
__for_begin = {i = <optimized out>}
__for_end = {i = <optimized out>}
#5 0xf7250b13 in KIO::ConnectionServer::setNextPendingConnection
(this=0xf4f42d80, conn=0xf4f42df0) at /usr/include/c++/13.2.1/bits/unique_ptr.h:199
newBackend = 0xf67e9bc0
```
seems like the upstream was well aware this might happen:
https://invent.kde.org/frameworks/kio/-/blob/v6.0.0/src/core/connectionbackend.cpp?ref_type=tags#L175
```c
// KF6 TODO: check if this breaks 32bit support,
// see https://invent.kde.org/frameworks/kio/-/merge_requests/1141#note_606633
sprintf(buffer, "%6llx_%2x_", data.size(), cmd);
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/15853bash is a hard dependency for gnome-session2024-03-10T20:11:48ZLassebqbash is a hard dependency for gnome-sessionI already know about #10953
But can we instead make it work with available `/etc/shells`?
I don't think anyone expects .bash_profile being source in a graphical session when they use another login shell.
Speaking of `.bash_profile`. It'...I already know about #10953
But can we instead make it work with available `/etc/shells`?
I don't think anyone expects .bash_profile being source in a graphical session when they use another login shell.
Speaking of `.bash_profile`. It's not being sourced on latest edge. Even though though there's !54014. Neither `.profile` nor `.bash_profile` is being sourced with login shell set to bash. `.profile` is not sourced by other POSIX shells either.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15847[lists/~alpine-devel] shadow 4.14 build errors on Alpine Linux2024-03-11T02:16:11ZKevin Daudt[lists/~alpine-devel] shadow 4.14 build errors on Alpine Linux[Forwarded from ~alpine/devel]
Hi,
I've noticed both Alpine Linux has a patch
<fix-undefined-reference.patch> for shadow, and that Void Linux
considered picking it.
The most likely reason for that patch was the bug reported by Gentoo:...[Forwarded from ~alpine/devel]
Hi,
I've noticed both Alpine Linux has a patch
<fix-undefined-reference.patch> for shadow, and that Void Linux
considered picking it.
The most likely reason for that patch was the bug reported by Gentoo:
<https://github.com/shadow-maint/shadow/issues/791>
and fixed in 4.14.1:
<https://github.com/shadow-maint/shadow/pull/792>
<https://github.com/shadow-maint/shadow/pull/794>
We never knew why it failed. It was an obscure problem with the
autotools-based build system. But we fixed it with the big hammer.
Please drop that patch, since the issue has been fixed upstream. And
please report any build errors upstream.
Have a lovely day!
Alex
---
See the release annotations, which document the fix:
$ git show 4.14.1
tag 4.14.1
Tagger: Alejandro Colomar <alx@kernel.org>
Date: Mon Sep 25 18:00:29 2023 +0200
shadow-4.14.1 (Casín) - shadow utils
Bugfix release. Changes since shadow-4.14.0:
shadow-4.14.1:
- Build system:
> - Merge libshadow and libmisc into a single libshadow. This fixes
> problems in the linker, which were reported at least in Gentoo.
And also documented in 4.15.0:
$ git show 4.15.0
tag 4.15.0
Tagger: Serge Hallyn <serge@hallyn.com>
Date: Fri Mar 8 16:06:06 2024 -0600
Release 4.14.0: dubliner
- libshadow:
- Use utmpx instead of utmp. This fixes a regression introduced in
4.14.0.
- Fix build error (parameter name omitted).
- Build system:
- Link correctly with libdl.
- Install pam configs for chpasswd(8) and newusers(8) when using
`./configure --with-libpam --disable-account-tools-setuid`.
> - Merge libshadow and libmisc into a single libshadow. This fixes
> problems in the linker, which were reported at least in Gentoo.
- Fix build with musl libc.
- Support out of tree builds
- useradd(8):
- Set proper SELinux labels for def_usrtemplate
--
<https://www.alejandro-colomar.es/>
[signature.asc](/uploads/e7bf8580ccd2978bdce2f71fd42fe63e/signature.asc)Stuart CardallStuart Cardallhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15845superd-services swww.service uses unsupported value causing panic2024-03-10T14:46:33Z1.11e-1f64superd-services swww.service uses unsupported value causing panicIn the package superd-services, it adds a service file called "swww.service"
this causes a panic when running 'superd'
`unsupported value for "Before=|After=": graphical-session.target
panic: swww: unsupported value for "Before=|After...In the package superd-services, it adds a service file called "swww.service"
this causes a panic when running 'superd'
`unsupported value for "Before=|After=": graphical-session.target
panic: swww: unsupported value for "Before=|After=": graphical-session.target
goroutine 1 [running]:
main.main()
sr.ht/~craftyguy/superd/cmd/superd/main.go:136 +0x88f`
the fix is to remove swww.service and it lets superd run againHugo BarreraHugo Barrerahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15844Cannot open HEIC files on KDE2024-03-12T13:14:58ZJulian GroßCannot open HEIC files on KDEI cannot open any HEIC files (Apple specific format using H265 for pictures) on postmarketOS Edge.
From what I read online, KDE Frameworks should have HEIC support since 5.80.
On 5.113, these files don't open in Pix or Okular.
On 6.0.0, ...I cannot open any HEIC files (Apple specific format using H265 for pictures) on postmarketOS Edge.
From what I read online, KDE Frameworks should have HEIC support since 5.80.
On 5.113, these files don't open in Pix or Okular.
On 6.0.0, these files don't open in Koko or Okular. (Pix is currently broken)
Maybe KDE Frameworks is built without HEIC support? Other packages like ImageMagick apparently needed this to be enabled: https://gitlab.alpinelinux.org/alpine/aports/-/commit/0ac585f438686c5c720343fd8b019ed86d905bf2https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10977`apk add` tries to set directory permissions when running as non-root user2024-03-11T13:54:53Zleso-kn`apk add` tries to set directory permissions when running as non-root userFrom the apk-tools documentation:
> ```
> --no-chown
> Do not change file owner or group. By default apk will manage the file
> ownership when running as root. However, this option is turned on when
> running as non-root user, a...From the apk-tools documentation:
> ```
> --no-chown
> Do not change file owner or group. By default apk will manage the file
> ownership when running as root. However, this option is turned on when
> running as non-root user, as changing file ownership is not permitted
> by the system then.
> ```
#### Reproducing the error
```bash
# as a non-root user
$ mkdir -p test-sysroot/etc/apk/keys
$ uname -m > test-sysroot/etc/apk/arch
$ cp /etc/apk/repositories test-sysroot/etc/apk
# let's try to install vim
$ apk --root=$PWD/test-sysroot add --initdb --allow-untrusted vim
(1/6) Installing vim-common (9.1.0-r1)
(2/6) Installing musl (1.2.5-r0)
(3/6) Installing xxd (9.1.0-r1)
(4/6) Installing ncurses-terminfo-base (6.4_p20231125-r0)
(5/6) Installing libncursesw (6.4_p20231125-r0)
(6/6) Installing vim (9.1.0-r1)
ERROR: 71 errors updating directory permissions
OK: 32 MiB in 6 packages
```
#### Expected behaviour
After vim is installed `apk` should not try to set any permissions, as `--no-chown` is implicitly passed by running as a non-root user.
**Note:** Passing `--no-chown` explicitly results in the same behaviour.
#### Actual behaviour
`apk` tries to set to set directory permissions despite the `--no-chown` flag in [database.c:2101](https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/6cd7f31d9bde79bb6361f2d2cbe37bfbafa342ea/src/database.c#L2101).https://gitlab.alpinelinux.org/alpine/aports/-/issues/15838community/tokodon: fails to launch2024-03-15T08:10:48ZMarco Schrödercommunity/tokodon: fails to launchTokodon does not launch.
The following is printed in the log:
```
QQmlApplicationEngine failed to load component
qrc:/qt/qml/org/kde/tokodon/content/ui/Main.qml: module "org.kde.desktop" is not installed
```
System information:
- postm...Tokodon does not launch.
The following is printed in the log:
```
QQmlApplicationEngine failed to load component
qrc:/qt/qml/org/kde/tokodon/content/ui/Main.qml: module "org.kde.desktop" is not installed
```
System information:
- postmarketOS edge
- tokodon 24.02.0-r0https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10817Latest development not updated anymore2024-03-06T19:20:53ZJ0WILatest development not updated anymoreThe newest commit shown in the «Latest development» section is from 2024-02-04The newest commit shown in the «Latest development» section is from 2024-02-04