alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2024-03-24T07:57:45Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15846bemenu with wayland backend broken on phosh2024-03-24T07:57:45ZArnav Singhbemenu with wayland backend broken on phosh[bemenu v0.6.20 wants `zwlr_layer_shell_v1` v3](https://github.com/Cloudef/bemenu/commit/6bcffe408c1519834ed00abec4030b9d49f9a52c) but [phoc v0.36.0 only provides v2.](https://gitlab.gnome.org/World/Phosh/phoc/-/blob/v0.36.0/src/desktop....[bemenu v0.6.20 wants `zwlr_layer_shell_v1` v3](https://github.com/Cloudef/bemenu/commit/6bcffe408c1519834ed00abec4030b9d49f9a52c) but [phoc v0.36.0 only provides v2.](https://gitlab.gnome.org/World/Phosh/phoc/-/blob/v0.36.0/src/desktop.c?ref_type=tags#L57) (Newer phoc v0.37.0 or even its main branch also only provide v2.)
```sh
$ printf 'asd\nqwe\n' | WAYLAND_DEBUG=1 bemenu
[2920359.323] wl_registry@2.global(9, "zwlr_layer_shell_v1", 2)
[2920359.393] -> wl_registry@2.bind(9, "zwlr_layer_shell_v1", 3, new id [unknown]@6)
[2920362.814] wl_display@1.error(wl_registry@2, 0, "invalid version for global zwlr_layer_shell_v1 (9): have 2, wanted 3")
wl_registry@2: error 0: invalid version for global zwlr_layer_shell_v1 (9): have 2, wanted 3
```Sören TempelSören Tempelhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15843Pix - "org.kde.kquickimageeditor" is not installed2024-03-18T14:31:43ZJulian GroßPix - "org.kde.kquickimageeditor" is not installedUpgrading from Plasma Mobile 5 to 6, Pix doesn't start anymore.
Running it from command line has it complain about "org.kde.kquickimageeditor" not being installed. The kquickimageeditor package is installed, however. [pmOS-Edge-Pix_not_s...Upgrading from Plasma Mobile 5 to 6, Pix doesn't start anymore.
Running it from command line has it complain about "org.kde.kquickimageeditor" not being installed. The kquickimageeditor package is installed, however. [pmOS-Edge-Pix_not_starting-2024-03-08.log](/uploads/6fa243ae5bbc5e704ab89c94fceeef25/pmOS-Edge-Pix_not_starting-2024-03-08.log)
This is on postmarketOS Edge.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15841Inconsistencies in busybox .initd2024-03-19T17:10:42ZFxzx micInconsistencies in busybox .initdI found some inconsistencies in busybox .initd:
| file | name | variables |
|------|------|-----------|
| acpid.initd | acpid | no |
| crond.initd | crond | $RC_SVCNAME and $SVCNAME |
| dnsd.initd | dnsd | $RC_SVCNAME and $SVCNAME |
| h...I found some inconsistencies in busybox .initd:
| file | name | variables |
|------|------|-----------|
| acpid.initd | acpid | no |
| crond.initd | crond | $RC_SVCNAME and $SVCNAME |
| dnsd.initd | dnsd | $RC_SVCNAME and $SVCNAME |
| httpd.initd | httpd | $RC_SVCNAME and $SVCNAME |
| inetd.initd | inetd | $RC_SVCNAME and $SVCNAME |
| klogd.initd | klogd | no |
| ntpd.initd | ntpd | $RC_SVCNAME and $SVCNAME |
| syslog.initd | syslog | no |
| udhcpd.initd | udhcpd | $RC_SVCNAME and $SVCNAME |
| watchdog.initd | watchdog | no |
Should we unify these and set a standard? Also, should `syslog` be renamed to `syslogd`?https://gitlab.alpinelinux.org/alpine/aports/-/issues/15840unbound config file2024-03-10T15:44:39ZDave Akersunbound config fileThe unbound conf.d/ini.d script has a variable for a config file but doesn't add `-c $cfgfile` to $command_argsThe unbound conf.d/ini.d script has a variable for a config file but doesn't add `-c $cfgfile` to $command_argsJakub JirutkaJakub Jirutkahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15839TeXLive — t4ht tex4ht binaries missing; never included, since day one2024-03-14T00:10:16ZCarlos eTeXLive — t4ht tex4ht binaries missing; never included, since day oneThis issue has been going
this issue hwas been going on for over a year. heck, since day one for that matter, currently I'm not using the prepackageg texlive, and thought someone would come across first, and at the very least bring it u...This issue has been going
this issue hwas been going on for over a year. heck, since day one for that matter, currently I'm not using the prepackageg texlive, and thought someone would come across first, and at the very least bring it up, hence, saving myself the time to do it instead, but no.
back in whenever, when 7 years ago @maribu was kind enough by putting together this package, the assumption was to follow the same model used by arch linux , and before you knew it, it was put in place. Everyone agreed in a consentual fashion and thought it best to do it that way, https://gitlab.alpinelinux.org/alpine/aports/-/issues/4514#note_20958
but this arch linux way of doing things, may not have been the most appropriate to follow at least not for these binaries anyway
And the problem with this is that tex4ht has been part of texlive since the stoneage wheen all those folks were young fellas and not unlike now all those grumpy old guys. Anyway. All the binaries related to this program are missing: tex4ht t4ht htlatex,and so forth
And Karl Berry had personally given me some compressed files that included both binaries and luckily it did worked. But recently it did not cut it as before.
and I also tried (as before) the binaries from arch linux — which I had done over a year ago — but this time it didn't work.
even with all the binaries that one could think of in place, errors such as
`sh: tex4ht: not found
[FATAL] make4ht-lib: Fatal error. Command tex4ht returned exit code 127` kept coming upMarian BuschsiewekeMarian Buschsiewekehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15837package request: prometheus-podman-exporter2024-03-15T17:18:22ZNavid Yaghoobipackage request: prometheus-podman-exporterPrometheus exporter for podman environments exposing containers, pods, images, volumes and networks information.
https://github.com/containers/prometheus-podman-exporterPrometheus exporter for podman environments exposing containers, pods, images, volumes and networks information.
https://github.com/containers/prometheus-podman-exporterhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15836Package request: flatpak-builder-tools2024-03-06T22:02:42ZAngelo Verlain ShemaPackage request: flatpak-builder-toolshttps://github.com/flatpak/flatpak-builder-tools
From the repo: "This repository contains a collection of various scripts to aid in using flatpak-builder."
It provides tools that work with `flatpak-builder`. It allows generating source...https://github.com/flatpak/flatpak-builder-tools
From the repo: "This repository contains a collection of various scripts to aid in using flatpak-builder."
It provides tools that work with `flatpak-builder`. It allows generating sources for cargo, npm, yarn and others and make building flatpak packages that depend on said build tools easier.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15832thin-provisioning-tools package is missing for s390x in Alpine 3.182024-03-21T12:25:56ZPrabhav Thalithin-provisioning-tools package is missing for s390x in Alpine 3.18thin-provisioning-tools package is not present for alpine v3.18.
```
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/s390x/APKINDEX.tar.gz
ERROR: unable to select packages:
thin-provisioning-tools (no such package):
required ...thin-provisioning-tools package is not present for alpine v3.18.
```
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/s390x/APKINDEX.tar.gz
ERROR: unable to select packages:
thin-provisioning-tools (no such package):
required by: world[thin-provisioning-tools]
```
Looks like the build is disabled for s390x (Ref: [link](https://gitlab.alpinelinux.org/alpine/aports/-/commit/d62aa7ba18f3ef9360799c79c341237db2c084be)). Could you please provide more details about the same?https://gitlab.alpinelinux.org/alpine/aports/-/issues/15830Please Package A Build of River With No XWayland Support i.e. river-noxwayland2024-03-04T19:49:13ZVehementHamPlease Package A Build of River With No XWayland Support i.e. river-noxwaylandI do not need XWayland, and it is extremely bloated. Please package a build that does not requrie it (don't build with `-Dxwayland` flag). The package could be called `river-noxwayland`. A package like this exists in the AUR.I do not need XWayland, and it is extremely bloated. Please package a build that does not requrie it (don't build with `-Dxwayland` flag). The package could be called `river-noxwayland`. A package like this exists in the AUR.Anjandev MomiAnjandev Momihttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15829sub-package request: texlive-context (& possibly texmf-dist-context?)2024-03-03T23:50:03Zomniomni+alpine@hack.orgsub-package request: texlive-context (& possibly texmf-dist-context?)The last alpinelinux release where `/usr/bin/context` and `/usr/bin/mtxrun` etc is available is 3.17
- https://pkgs.alpinelinux.org/contents?file=context&path=&name=&branch=v3.17
- https://pkgs.alpinelinux.org/contents?file=mtxrun&path=...The last alpinelinux release where `/usr/bin/context` and `/usr/bin/mtxrun` etc is available is 3.17
- https://pkgs.alpinelinux.org/contents?file=context&path=&name=&branch=v3.17
- https://pkgs.alpinelinux.org/contents?file=mtxrun&path=&name=&branch=v3.17
I'm guessing that they got lost after an upgrade of `texlive` and `texmf-dist`.Marian BuschsiewekeMarian Buschsiewekehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15828nftables counters added to the default table don't save2024-03-04T06:26:24ZDave Akersnftables counters added to the default table don't saveI've recently starting experimenting with using alpine as a home router. The nftables init script has an option to save counters to a state file. However if you add a counter to the default table in /etc/nftables.nft the counter will be ...I've recently starting experimenting with using alpine as a home router. The nftables init script has an option to save counters to a state file. However if you add a counter to the default table in /etc/nftables.nft the counter will be saved but not reloaded. This is because the state file is included at the end of /etc/nftables.nft and the counters are already defined.
If the state file is included at the beginning of /etc/nftables.nft then the counters will be reloaded and adding new counters to the default table works as expected.
Another alternative would be to move the default table in /etc/nftables.nft to a file in /etc/nftables.d/... then the include order would work as expected. A benefit of moving the default table to nftables.d is to provide an example to the user as to how to use the .d directory.Francesco ColistaFrancesco Colistahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15827[RFC] Disabling "thought-provoking stories" on Firefox new tab2024-03-03T20:11:35ZPatrycja Rosaalpine@ptrcnull.me[RFC] Disabling "thought-provoking stories" on Firefox new tabFirefox 125.0 seems to introduce "exceptional content curated by the Firefox family" on the new tab:
![image](/uploads/201e5b78b8466e7fa0e0c29ba35086ea/image.png)
should Alpine disable those by default in the vendor preferences? the `a...Firefox 125.0 seems to introduce "exceptional content curated by the Firefox family" on the new tab:
![image](/uploads/201e5b78b8466e7fa0e0c29ba35086ea/image.png)
should Alpine disable those by default in the vendor preferences? the `about:config` key responsible for this ( `browser.newtabpage.activity-stream.feeds.section.topstories` ) is also exposed as a checkbox in preferences, so a user would be able to enable them as such:
![image](/uploads/ac55ba47ef3bbe4474051dc64e30052d/image.png)https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues/54Soft RAID doesn't start with Linux 6.7.6 (but does with 5.15.148)2024-03-02T23:26:48ZAdrienSoft RAID doesn't start with Linux 6.7.6 (but does with 5.15.148)Hi,
I'm running Alpine Linux 3.19.1 on a server with 2 soft RAID 1 on 2 SSD:
- `/dev/md0` for `/`
- `/dev/md1` for `/boot`
It works with no issue on Linux 5.15.148 (compiled by myself).
I took the same kernel base configuration and...Hi,
I'm running Alpine Linux 3.19.1 on a server with 2 soft RAID 1 on 2 SSD:
- `/dev/md0` for `/`
- `/dev/md1` for `/boot`
It works with no issue on Linux 5.15.148 (compiled by myself).
I took the same kernel base configuration and compiled Linux 6.7.6.
Since then, my machine doesn't boot and blocks on this:
```
Mounting root...
md/raid1:md0: active with 1 out of 2 mirrors
md0: detected capacity change from 0 to xxxx
```
When selecting the previous 5.15.148 kernel on boot, it works again like a charm.
I have no idea why the RAID doesn't starts with Linux 6.7.6.
I made multiple tests and found a way to start the RAID with no issue by adding `mdadm --assemble --scan` just before https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in?ref_type=heads#L638.
It seems that `nlplug-findfs` starts RAIDs using `mdadm --incremental --run --quiet <devnode>` (see https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/nlplug-findfs/nlplug-findfs.c?ref_type=heads#L484).
In my case it runs these 4 commands as expected:
- `mdadm --incremental --run --quiet /dev/sda1`
- `mdadm --incremental --run --quiet /dev/sdb1`
- `mdadm --incremental --run --quiet /dev/sda2`
- `mdadm --incremental --run --quiet /dev/sdb2`
`nlplug-findfs` mounts each partition that have type `linux_raid_member`.
Maybe we can simply let `mdadm` mount them automatically with `mdadm --assemble --scan` (which seems to read `/proc/mdstat` and `/etc/mdadm.conf`)?
Notes:
- The initramfs are exactly the same between the 2 kernels:
```bash
mkinitfs -n -o /boot/initramfs-5.15.148 5.15.148
mkinitfs -n -o /boot/initramfs-6.7.6 6.7.6
```
- `/etc/mdadm.conf` is well populated and exactly identical in both cases
- There is no difference on RAID part between the configuration of 5.15.148 and 6.7.6
- There is no major difference between the configuration of 5.15.148 and 6.7.6
Best,
Adrienhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10976Conflicting unversioned providers2024-03-12T11:18:48ZSertonixConflicting unversioned providersCurrently 2 packages providing the same name without specifying a version do not conflict. (I know that this is intentional.)
The problem is that some packages providing the same name should conflict but adding a version doesn't makes s...Currently 2 packages providing the same name without specifying a version do not conflict. (I know that this is intentional.)
The problem is that some packages providing the same name should conflict but adding a version doesn't makes sense.
An example from alpine is `busybox-binsh` and `dash-binsh` (and other `*-binsh` packages). They fail to install together since they include the same file. The packages should already conflict in the resolving phase.
This would improve the error message and would allow correct simulation (`-s`).
My proposal is to allow specifying a conflict with a name provided by a package itself:
```
depends="!/bin/sh"
provides="/bin/sh"
```
Changing the resolver to ignore a conflict with a package itself should be enough to get this working. (To be tested)https://gitlab.alpinelinux.org/alpine/aports/-/issues/15819certain public URLs not resolving from Alpine image-based pods2024-03-26T14:26:51ZRamesh Madurangacertain public URLs not resolving from Alpine image-based podsWe are currently experiencing an issue with Alpine Kubernetes pods. Specifically, URLs associated with '*dap.c-path.org' (customer) are not resolving from Alpine image-based pods. As the application is hosted in an AKS cluster, I reached...We are currently experiencing an issue with Alpine Kubernetes pods. Specifically, URLs associated with '*dap.c-path.org' (customer) are not resolving from Alpine image-based pods. As the application is hosted in an AKS cluster, I reached out to Azure support, they have concluded that the problem is linked to Alpine behavior.
Interestingly, these URLs are resolving correctly from local pods (docker desktop), but they are not functioning within AKS Alpine pods. Also, in the same cluster, Ubuntu pods can handle the resolution without any problems.
Appreciate your assistance in investigating and resolving this matter. I'm happy to provide any information you might need from my side.
ex:
$ ping fair.dapstaging.c-path.org \
ping: bad address 'fair.dapstaging.c-path.org'
/ # cat /etc/os-release \
NAME="Alpine Linux" \
ID=alpine \
VERSION_ID=3.19.1 \
PRETTY_NAME="Alpine Linux v3.19"https://gitlab.alpinelinux.org/alpine/aports/-/issues/15818Missing symbols in smbd2024-02-29T07:42:07ZViktorMissing symbols in smbdHello I have a problem running smbd service on Alpine Edge
Installed samba package version `samba-4.19.4-r0`
When attempting to start service or run `ldd /usr/sbin/smbd` I get these lines about missing symbols:
```
Error relocating /us...Hello I have a problem running smbd service on Alpine Edge
Installed samba package version `samba-4.19.4-r0`
When attempting to start service or run `ldd /usr/sbin/smbd` I get these lines about missing symbols:
```
Error relocating /usr/lib/samba/libsmbd-base-samba4.so: ctdbd_unregister_ips: symbol not found
Error relocating /usr/lib/samba/libsmbd-base-samba4.so: ctdbd_passed_ips: symbol not found
Error relocating /usr/sbin/smbd: samba_copyright_string: symbol not found
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/15817community/zlib-ng: Provide variant built with the compat mode as a replacemen...2024-02-26T22:43:48ZJakub Jirutkacommunity/zlib-ng: Provide variant built with the compat mode as a replacement for zlibhttps://fedoraproject.org/wiki/Changes/ZlibNGTransitionhttps://fedoraproject.org/wiki/Changes/ZlibNGTransitionhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15816Upgrade LibreOffice to 7.6.5 or 24.22024-03-01T21:20:13ZjgarciaUpgrade LibreOffice to 7.6.5 or 24.2I am interested in using the latest version of LibreOffice either 7.6.5.2 or 24.2.1.2 since the 7.6.4.1 has a few known vulnerabilities. Is it possible to update the current 7.6.4.1 to at least 7.6.5.2, or even update to all the way to 2...I am interested in using the latest version of LibreOffice either 7.6.5.2 or 24.2.1.2 since the 7.6.4.1 has a few known vulnerabilities. Is it possible to update the current 7.6.4.1 to at least 7.6.5.2, or even update to all the way to 24.2.1.2 for the edge if not possible for 3.19?
Thanks!Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15815podman: Wrong status after service failed to start but some containers did2024-03-01T21:19:21ZDawid Wróbelpodman: Wrong status after service failed to start but some containers didI have podman configured to run as a service at boot time. There are about 6 containers configured to always restart, so the service should pick them all up and start accordingly.
However, for a known reason, some containers fail to sta...I have podman configured to run as a service at boot time. There are about 6 containers configured to always restart, so the service should pick them all up and start accordingly.
However, for a known reason, some containers fail to start, which results in podman service itself failing to start, which is expected:
`Feb 26 12:21:19 myvm daemon.err /etc/init.d/podman[2631]: ERROR: podman failed to start`
The service status, however, is 'stopped', not 'crashed' like it should be:
```
myvm:~# rc-service podman status
* status: stopped
```
The rest of the containers which have not failed are running fine at this point, which makes it impossible to start the service again:
```
myvm:~# rc-service podman start
* Caching service dependencies ... [ ok ]
* Configured as rootful service
* Starting Podman API service ...
* supervise-daemon: /usr/bin/podman is already running
* failed to start Podman API service [ !! ]
* ERROR: podman failed to start
```
The fact that the service is in 'stopped' status already, makes it also impossible to properly shut down the 'zombie' containers (I mean outside of manually iterating them with `podman stop`, but who wants that). At the very least it should be `crashed` status, which would allow to actually issue an `rc-service podman stop` and a subsequent `start`.
It may also be worth considering implementing OpenRC health checks, as explained in https://github.com/OpenRC/openrc/blob/master/supervise-daemon-guide.mdMichał PolańskiMichał Polańskihttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15812git-hook or other to prevent commit messages that doesn't start with somethin...2024-02-25T22:50:12Zomniomni+alpine@hack.orggit-hook or other to prevent commit messages that doesn't start with something in the root of aports/ dirI don't mind if this would disallow commit messages like `*/*: fix thing` (not `community/*: fix thing`) if that's the price to pay to prevent me from accidentally do what I just did when I merged 0ba76300839729d91706dc82247ae765f4813a57I don't mind if this would disallow commit messages like `*/*: fix thing` (not `community/*: fix thing`) if that's the price to pay to prevent me from accidentally do what I just did when I merged 0ba76300839729d91706dc82247ae765f4813a57