alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2024-03-29T01:01:00Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15930/var/lock directory or symlink2024-03-29T01:01:00ZSertonix/var/lock directory or symlink`/var/lock` is packaged in `alpine-baselayout` as a directory (containing `/var/lock/subsys`).
Contrary `openrc` (in the `bootmisc` service) will try to migrate that directory to `/run/lock` with a symlink ([code](https://github.com/Ope...`/var/lock` is packaged in `alpine-baselayout` as a directory (containing `/var/lock/subsys`).
Contrary `openrc` (in the `bootmisc` service) will try to migrate that directory to `/run/lock` with a symlink ([code](https://github.com/OpenRC/openrc/blob/12e1e884750cc6cf592bbbdaef6f40ceee304b25/init.d/bootmisc.in#L187)).
Packages are configured to ether of these inconsistently. I would like to have one preferred directory and fix ether `alpine-baselayout` or `openrc` for that.
(My preference is `/run/lock`)
CC @ncopa idk who is responsible for thathttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15929community/pavucontrol: desktop entry refers to missing icon2024-03-28T23:34:55ZHugo Barreracommunity/pavucontrol: desktop entry refers to missing icon## Package Information
* Package name: pavucontrol-5.0-r4
* Alpine version: 3.20.0_alpha20240315
* Alpine architecture: x86_64
## Summary
This package installs a desktop entry which refers to an icon:
```console
> grep Icon /usr/shar...## Package Information
* Package name: pavucontrol-5.0-r4
* Alpine version: 3.20.0_alpha20240315
* Alpine architecture: x86_64
## Summary
This package installs a desktop entry which refers to an icon:
```console
> grep Icon /usr/share/applications/pavucontrol.desktop
Icon=multimedia-volume-control
````
But the icon is not installed as part of this package, so launchers (e.g.: fuzzel) will show an empty icon.
pavucontrol's icon should be installed into /app/share/icons/hicolor/scalable/apps/multimedia-volume-control.svg
## Steps to reproduce
Use any launcher (e.g.: `fuzzel`) and find `pavucontrol`'s desktop entry.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15928testing/py3-ovos-utils: deprecated sound API errors with Python 3.122024-03-28T15:45:27ZPatrycja Rosaalpine@ptrcnull.metesting/py3-ovos-utils: deprecated sound API errors with Python 3.126 tests fail on Python 3.12:
```
2024-03-28 15:41:17.605 - OVOS - ovos_utils.sound:play_wav - WARNING - Deprecation version=0.1.0. Caller=test_audio_utils:109. please emit mycroft.audio.play_sound instead
```
full log: https://tpaste.us...6 tests fail on Python 3.12:
```
2024-03-28 15:41:17.605 - OVOS - ovos_utils.sound:play_wav - WARNING - Deprecation version=0.1.0. Caller=test_audio_utils:109. please emit mycroft.audio.play_sound instead
```
full log: https://tpaste.us/wxN5https://gitlab.alpinelinux.org/alpine/aports/-/issues/15927ash never seems to source any startup files2024-03-28T15:13:59ZDavid Favorash never seems to source any startup files## Package Information
* Package name: ash
* Package version: busybox-1.36.1-r15
* Alpine version: 3.19.1
* Alpine architecture: x86_64
## Summary
ash never attempts to source /etc/profile + /root/.profile at startup.
## Steps to rep...## Package Information
* Package name: ash
* Package version: busybox-1.36.1-r15
* Alpine version: 3.19.1
* Alpine architecture: x86_64
## Summary
ash never attempts to source /etc/profile + /root/.profile at startup.
## Steps to reproduce
Camping on /etc + /root show startup files are never accessed.
I'm running ash using "lxc exec CNAME ash" which starts ash correctly, just no startup files sourced.
inotifywait shows only .ash_history is hit...
```
net17 # dirwatch net17-template-alpine-319/rootfs/root net17-template-alpine-319/rootfs/etc
inotifywait --timefmt '%Y-%m-%d-%T' -qmr --format '%T %w%f %e' --exclude '.(bak|sw[xp])$' net17-template-alpine-319/rootfs/root net17-template-alpine-319/rootfs/etc
2024-03-28-09:00:17 net17-template-alpine-319/rootfs/root/.ash_history OPEN
2024-03-28-09:00:17 net17-template-alpine-319/rootfs/root/.ash_history ACCESS
2024-03-28-09:00:17 net17-template-alpine-319/rootfs/root/.ash_history CLOSE_NOWRITE,CLOSE
```
Someone let me know how to fix this.
Thanks!https://gitlab.alpinelinux.org/alpine/aports/-/issues/15926Request to upgrade main/libxml2 to version 2.12.6 in 3.192024-03-28T10:37:00ZMoritz HaaseRequest to upgrade main/libxml2 to version 2.12.6 in 3.19## Package Information
* Package name: *main/libxml2*
* New version: *2.12.6 (as present in `edge`)*
* Release notes: https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.12.6
## Summary
While preparing an upgrade from Alpine Linux 3....## Package Information
* Package name: *main/libxml2*
* New version: *2.12.6 (as present in `edge`)*
* Release notes: https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.12.6
## Summary
While preparing an upgrade from Alpine Linux 3.17 to 3.19 for some of our containers we noticed a
regression in xmllint (which is part of libxml2-utils).
The version shipped in 3.19 doesn't return `!= 0` anymore in case the result of an XPath query is
empty. This started with [this
commit](https://gitlab.gnome.org/GNOME/libxml2/-/commit/e85f9b98a5389c69167176ae6600091e719ec38f)
that made it into [2.11.0](https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.11.0).
After some discussion in upstream issues [673](https://gitlab.gnome.org/GNOME/libxml2/-/issues/673)
and [690](https://gitlab.gnome.org/GNOME/libxml2/-/issues/690), the previous behaviour was restored
in release [2.12.6](https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.12.6).
It'd be great if the libxml2(-utils) version in 3.19 could either be bumped to the latest release or
pull in the [fix as a
patch](https://gitlab.gnome.org/GNOME/libxml2/-/commit/87bebd25f11be333f0742ee5dc80e07d306c76df).https://gitlab.alpinelinux.org/alpine/aports/-/issues/15925community/kicad: wxWidgets 3.2.0 or greater is required2024-03-28T08:46:15ZPatrycja Rosaalpine@ptrcnull.mecommunity/kicad: wxWidgets 3.2.0 or greater is requiredlatest KiCad from edge seems to fail build with:
```
CMake Warning at cmake/FindwxPython.cmake:87 (message):
Could not determine wxWidgets version used by Phoenix, requesting 3.0.2
Call Stack (most recent call first):
CMakeLists.txt:...latest KiCad from edge seems to fail build with:
```
CMake Warning at cmake/FindwxPython.cmake:87 (message):
Could not determine wxWidgets version used by Phoenix, requesting 3.0.2
Call Stack (most recent call first):
CMakeLists.txt:942 (find_package)
CMake Error at CMakeLists.txt:949 (message):
wxWidgets 3.2.0 or greater is required
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/15924virt-manager support for pytest 82024-03-28T07:48:06ZLeonardo Arenavirt-manager support for pytest 8virt-manager does not pass tests with pytest 8.x
This has been reported upstream: https://github.com/virt-manager/virt-manager/issues/648virt-manager does not pass tests with pytest 8.x
This has been reported upstream: https://github.com/virt-manager/virt-manager/issues/6483.20.0Leonardo ArenaLeonardo Arenahttps://gitlab.alpinelinux.org/alpine/cloud/alpine-cloud-images/-/issues/158NoCloud x86_64 BIOS images hang at preboot in libvirt2024-03-28T00:37:38Zjon ⚝NoCloud x86_64 BIOS images hang at preboot in libvirtUsing the images
- https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/cloud/nocloud_alpine-3.19.1-x86_64-bios-tiny-r0.qcow2
- https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/cloud/nocloud_alpine-3.19.1-x86_64-bios-cloudinit-r0.qc...Using the images
- https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/cloud/nocloud_alpine-3.19.1-x86_64-bios-tiny-r0.qcow2
- https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/cloud/nocloud_alpine-3.19.1-x86_64-bios-cloudinit-r0.qcow2
with [an Ansible playbook that also crafts cloud-init images](https://github.com/christianb93/ansible-samples/tree/master/libvirt) leads to a running domain, which will not continue after preboot. It forever hangs at:
```
Loading vmlinuz-virt... ok
Loading initramfs-virt...ok
```
### Screenshots
![grafik](/uploads/3cee10f62c915d069d821dc4cbc2e123/grafik.png)
![grafik](/uploads/a56cceb691b27d7e42379e193806a738/grafik.png)
### Details
<details><summary>XML</summary>
```xml
<domain type='kvm' id='9'>
<name>alpine0</name>
<uuid>0ba7aa97-3342-48b3-b596-9a84898cd0f4</uuid>
<memory unit='KiB'>1000448</memory>
<currentMemory unit='KiB'>1000000</currentMemory>
<vcpu placement='static'>1</vcpu>
<resource>
<partition>/machine</partition>
</resource>
<os>
<type arch='x86_64' machine='pc-i440fx-mantic'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
</features>
<cpu mode='custom' match='exact' check='full'>
<model fallback='forbid'>EPYC-Rome</model>
<vendor>AMD</vendor>
<feature policy='require' name='x2apic'/>
<feature policy='require' name='tsc-deadline'/>
<feature policy='require' name='hypervisor'/>
<feature policy='require' name='tsc_adjust'/>
<feature policy='require' name='stibp'/>
<feature policy='require' name='arch-capabilities'/>
<feature policy='require' name='ssbd'/>
<feature policy='require' name='cmp_legacy'/>
<feature policy='require' name='amd-ssbd'/>
<feature policy='require' name='virt-ssbd'/>
<feature policy='require' name='lbrv'/>
<feature policy='require' name='tsc-scale'/>
<feature policy='require' name='vmcb-clean'/>
<feature policy='require' name='pause-filter'/>
<feature policy='require' name='pfthreshold'/>
<feature policy='require' name='v-vmsave-vmload'/>
<feature policy='require' name='vgif'/>
<feature policy='require' name='svme-addr-chk'/>
<feature policy='require' name='rdctl-no'/>
<feature policy='require' name='skip-l1dfl-vmentry'/>
<feature policy='require' name='mds-no'/>
<feature policy='require' name='pschange-mc-no'/>
<feature policy='disable' name='xsaves'/>
<feature policy='require' name='topoext'/>
</cpu>
<clock offset='utc'>
<timer name='rtc' tickpolicy='catchup'/>
<timer name='pit' tickpolicy='delay'/>
<timer name='hpet' present='no'/>
</clock>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<pm>
<suspend-to-mem enabled='no'/>
<suspend-to-disk enabled='no'/>
</pm>
<devices>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/home/user/src/github.com/christianb93/ansible-samples/libvirt/.state/pool/alpine0' index='2'/>
<backingStore type='file' index='3'>
<format type='qcow2'/>
<source file='/home/user/src/github.com/christianb93/ansible-samples/libvirt/.state/alpine0.qcow2'/>
<backingStore/>
</backingStore>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/home/user/src/github.com/christianb93/ansible-samples/libvirt/.state/pool/cloud-config.iso' index='1'/>
<backingStore/>
<target dev='vdb' bus='sata'/>
<readonly/>
<alias name='sata0-0-1'/>
<address type='drive' controller='0' bus='0' target='0' unit='1'/>
</disk>
<controller type='usb' index='0' model='ich9-ehci1'>
<alias name='usb'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x7'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci1'>
<alias name='usb'/>
<master startport='0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci2'>
<alias name='usb'/>
<master startport='2'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci3'>
<alias name='usb'/>
<master startport='4'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x2'/>
</controller>
<controller type='pci' index='0' model='pci-root'>
<alias name='pci.0'/>
</controller>
<controller type='sata' index='0'>
<alias name='sata0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
</controller>
<interface type='network'>
<mac address='52:54:00:03:6d:f3'/>
<source network='ansible' portid='b8856b89-1c67-4aae-9ec6-d476d6fe1909' bridge='ansible-bridge'/>
<target dev='vnet8'/>
<model type='rtl8139'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
<serial type='pty'>
<source path='/dev/pts/8'/>
<target type='isa-serial' port='0'>
<model name='isa-serial'/>
</target>
<alias name='serial0'/>
</serial>
<console type='pty' tty='/dev/pts/8'>
<source path='/dev/pts/8'/>
<target type='serial' port='0'/>
<alias name='serial0'/>
</console>
<input type='mouse' bus='ps2'>
<alias name='input0'/>
</input>
<input type='keyboard' bus='ps2'>
<alias name='input1'/>
</input>
<graphics type='vnc' port='5900' autoport='yes' listen='127.0.0.1'>
<listen type='address' address='127.0.0.1'/>
</graphics>
<audio id='1' type='none'/>
<video>
<model type='cirrus' vram='16384' heads='1' primary='yes'/>
<alias name='video0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</video>
<memballoon model='virtio'>
<alias name='balloon0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</memballoon>
</devices>
<seclabel type='dynamic' model='apparmor' relabel='yes'>
<label>libvirt-0ba7aa97-3342-48b3-b596-9a84898cd0f4</label>
<imagelabel>libvirt-0ba7aa97-3342-48b3-b596-9a84898cd0f4</imagelabel>
</seclabel>
<seclabel type='dynamic' model='dac' relabel='yes'>
<label>+64055:+105</label>
<imagelabel>+64055:+105</imagelabel>
</seclabel>
</domain>
```
</details>https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10577setup-desktop: Add elementaryOS2024-03-27T22:18:30ZAngelo Verlain Shemasetup-desktop: Add elementaryOSelementaryOS could be added with pantheon, elementary-photos, etc..elementaryOS could be added with pantheon, elementary-photos, etc..https://gitlab.alpinelinux.org/alpine/aports/-/issues/15923main/util-linux-login: su segmentation fault2024-03-27T22:13:10Zshummain/util-linux-login: su segmentation fault## Package Information
* Package name: `util-linux-login`
* Package version: `2.39.3-r1`
* Alpine version: `3.20.0_alpha20240315` (edge)
* Alpine architecture: `x86_64`
## Summary
Executing `su` from `util-linux-login` in up-to-date A...## Package Information
* Package name: `util-linux-login`
* Package version: `2.39.3-r1`
* Alpine version: `3.20.0_alpha20240315` (edge)
* Alpine architecture: `x86_64`
## Summary
Executing `su` from `util-linux-login` in up-to-date Alpine Edge install segfaults with the message:
```sh
❯ su -
Password:
Segmentation fault
```
Interestingly, running `su` without `-` results in different message:
```sh
❯ su
Password:
su: failed to execute /bin/ash: Bad address
```
Also, every execution of the command prints segfaults in dmesg:
```sh
[ 2801.095382] su[32281]: segfault at ffffffffac2e89c5 ip 00007fdfac35053b sp 00007ffc44cb6728 error 5 in ld-musl-x86_64.so.1[7fdfac30b000+54000] likely on CPU 10 (core 5, socket 0)
[ 2801.095395] Code: e9 59 ff ff ff c6 02 00 48 89 d3 4c 29 c3 e8 0a 00 00 00 48 83 c4 08 48 01 d8 5b 5d c3 48 89 f8 eb 04 48 83 c0 01 a8 07 74 09 <80> 38 00 75 f3 48 29 f8 c3 49 b8 ff fe fe fe fe fe fe fe 48 be 80
```
## Steps to reproduce
1. `docker run --rm -it alpine:edge`
2. `apk upgrade -a && apk add util-linux-login`
3. `su`https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/issues/33Automatically assign issues in aports.git based on issue templates2024-03-27T21:32:01ZSören TempelAutomatically assign issues in aports.git based on issue templatesThis is a follow up to https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61558
We have now use issue templates in aports.git and, from what I have seen so far, they work quite well. The templates enable use to automatically ...This is a follow up to https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61558
We have now use issue templates in aports.git and, from what I have seen so far, they work quite well. The templates enable use to automatically assign created issues in aports.git to the package maintainer, in the hopes that this results in the issue to be resolved faster. This requires us to add some more code to alpine-qa-bot essentially doing the following:
1. Be notified when a new issue is created
2. Check if the issue uses a pre-defined issue template
3. Extract the package name from the issue description
4. Determine the maintainer of this package
5. Map maintainer information to a GitLab user name
6. Assign the issue
7. Additionally: Assign labels tot he issue based on the template type extracted in 2.
This issue serve as a remainder to implement feature and should track the progress on the implementation.
I am currently busy with upgrading GHC but plan on looking into after.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10989Question: About apk-tools-zsh-completion2024-03-27T23:37:17ZMalik NQuestion: About apk-tools-zsh-completionIt seems I have a package called apk-tools-zsh-completion, but I cant find it in the world file, not with `whereis apk-tools-zsh-completion`, and not in the aports repository. It is only visible in gnome software with the same version nu...It seems I have a package called apk-tools-zsh-completion, but I cant find it in the world file, not with `whereis apk-tools-zsh-completion`, and not in the aports repository. It is only visible in gnome software with the same version number like apk-tools 2.14.1.
What might have caused this and how I can source those files in my .zshrc?https://gitlab.alpinelinux.org/alpine/aports/-/issues/15922community/cadaver: Listing local files broken2024-03-27T17:04:56ZDaniel Fancsalicommunity/cadaver: Listing local files broken<!--
This is the issue template for reporting an issue with a specific package. You
can select a different issue template from the dropdown above. Also, feel free
to use the "No template" option in case no template applies to your issue....<!--
This is the issue template for reporting an issue with a specific package. You
can select a different issue template from the dropdown above. Also, feel free
to use the "No template" option in case no template applies to your issue.
Also note that this repository is intended for reporting issues with packages.
For other components, separate issue trackers exist:
* Installer issues: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues
* Infrastructure issues: https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues
* Initramfs issues: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues
-->
## Package Information
* Package name: community/cadaver
* Package version: 0.24-r1
* Alpine version: edge
* Alpine architecture: arv7l
## Summary
Starting `cadaver` and issuing the `lls` command results in an error message instead of the list of the local directory.
The message is suspiciously similar to the an error message from BusyBox.
## Steps to reproduce
* Start the program: `cadaver`
* Feel free to actually connect to a server
* Issue the command `lls` (i.e. try to obtain the list of local files)
* Observe the error message: `lls: applet not found`https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10988should provider format allow `,` and `[`2024-03-27T14:51:23ZSertonixshould provider format allow `,` and `[`alpine linux includes providers that don't follow the current spec since they contain `,` and `[` characters. The question is if they should be allowed or excluded as providers.
```
cmd:[
cmd:sxmo_deviceprofile_fairphone,fp4.sh
cmd:sxmo...alpine linux includes providers that don't follow the current spec since they contain `,` and `[` characters. The question is if they should be allowed or excluded as providers.
```
cmd:[
cmd:sxmo_deviceprofile_fairphone,fp4.sh
cmd:sxmo_deviceprofile_kobo,clarahd.sh
cmd:sxmo_deviceprofile_lge,hammerhead.sh
cmd:sxmo_deviceprofile_longcheer,l8150.sh
cmd:sxmo_deviceprofile_motorola,harpia.sh
cmd:sxmo_deviceprofile_nokia,omap3-n900.sh
cmd:sxmo_deviceprofile_oneplus,cheeseburger.sh
cmd:sxmo_deviceprofile_oneplus,dumpling.sh
cmd:sxmo_deviceprofile_oneplus,enchilada.sh
cmd:sxmo_deviceprofile_oneplus,fajita.sh
cmd:sxmo_deviceprofile_pine64,pinebook-pro.sh
cmd:sxmo_deviceprofile_pine64,pinebook.sh
cmd:sxmo_deviceprofile_pine64,pinenote.sh
cmd:sxmo_deviceprofile_pine64,pinephone-1.0.sh
cmd:sxmo_deviceprofile_pine64,pinephone-1.1.sh
cmd:sxmo_deviceprofile_pine64,pinephone-1.2.sh
cmd:sxmo_deviceprofile_pine64,pinephone-pro.sh
cmd:sxmo_deviceprofile_pine64,rockpro64-v2.1.sh
cmd:sxmo_deviceprofile_purism,librem5r2.sh
cmd:sxmo_deviceprofile_purism,librem5r3.sh
cmd:sxmo_deviceprofile_purism,librem5r4.sh
cmd:sxmo_deviceprofile_qcom,msm8226-mtp.sh
cmd:sxmo_deviceprofile_samsung,a3u-eur.sh
cmd:sxmo_deviceprofile_samsung,a5u-eur.sh
cmd:sxmo_deviceprofile_samsung,coreprimevelte.sh
cmd:sxmo_deviceprofile_samsung,e5.sh
cmd:sxmo_deviceprofile_samsung,e7.sh
cmd:sxmo_deviceprofile_samsung,grandmax.sh
cmd:sxmo_deviceprofile_samsung,gt510.sh
cmd:sxmo_deviceprofile_samsung,i9300.sh
cmd:sxmo_deviceprofile_samsung,j5.sh
cmd:sxmo_deviceprofile_samsung,j5x.sh
cmd:sxmo_deviceprofile_samsung,n8010.sh
cmd:sxmo_deviceprofile_shift,axolotl.sh
cmd:sxmo_deviceprofile_wingtech,wt88047.sh
cmd:sxmo_deviceprofile_xiaomi,beryllium.sh
cmd:sxmo_deviceprofile_xiaomi,elish.sh
cmd:sxmo_deviceprofile_xiaomi,polaris.sh
cmd:uutils-[
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10987apk3 fails to parse apk2 install_if2024-03-27T15:36:33ZSertonixapk3 fails to parse apk2 install_ifWhen I run `apk3 -s upgrade` on an apk2 system I get false package installation:
```
~/src/apk-tools$ output/src/apk -s upgrade
(1/4) Installing opensmtpd-openrc (7.4.0p1-r1)
(2/4) Installing opensmtpd-doc (7.4.0p1-r1)
(3/4) Installing o...When I run `apk3 -s upgrade` on an apk2 system I get false package installation:
```
~/src/apk-tools$ output/src/apk -s upgrade
(1/4) Installing opensmtpd-openrc (7.4.0p1-r1)
(2/4) Installing opensmtpd-doc (7.4.0p1-r1)
(3/4) Installing owfs-doc (3.2p4-r0)
(4/4) Installing tcptraceroute-doc (1.5b7-r4)
OK: 4855 MiB in 1366 packages
```
apk2:
```
~$ apk -s upgrade
OK: 4855 MiB in 1366 packages
```
It seems that apk3 doesn't parse the install_if field correctly in apk2 packages:
```
~/src/apk-tools$ output/src/apk info tcptraceroute-doc --install-if
tcptraceroute-doc-1.5b7-r4 has auto-install rule:
docs
```
apk2:
```
~$ apk info tcptraceroute-doc --install-if
tcptraceroute-doc-1.5b7-r4 has auto-install rule:
docs
tcptraceroute=1.5b7-r4
```
This may be related to the still undocumented `digit{letter{digit}}` format used on alpine linux (https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10972#note_380899).https://gitlab.alpinelinux.org/alpine/aports/-/issues/15921community/pdal: 112 - pdal_info_test (Failed)2024-03-28T16:11:49ZNatanael Copacommunity/pdal: 112 - pdal_info_test (Failed)<!--
This is the issue template for reporting an issue with a specific package. You
can select a different issue template from the dropdown above. Also, feel free
to use the "No template" option in case no template applies to your issue....<!--
This is the issue template for reporting an issue with a specific package. You
can select a different issue template from the dropdown above. Also, feel free
to use the "No template" option in case no template applies to your issue.
Also note that this repository is intended for reporting issues with packages.
For other components, separate issue trackers exist:
* Installer issues: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues
* Infrastructure issues: https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues
* Initramfs issues: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues
-->
## Package Information
* Package name: comunity/pdal
* Package version: 2.7.0
* Alpine version: 3.20.0_alpha20240315
* Alpine architecture: x86_64
*
## Summary
build fails during check:
```
[ RUN ] Info.stac
/home/ncopa/aports/community/pdal/src/PDAL-2.7.0-src/test/unit/apps/InfoTest.cpp:62: Failure
Expected: (output.find(validation)) != (std::string::npos), actual: 18446744073709551615 vs 18446744073709551615
Found: '{
"file_size": 3742038,
"filename": "/home/ncopa/aports/community/pdal/src/PDAL-2.7.0-src/test/data/las/autzen_trim.las",
"now": "2024-03-27T12:01:59+0100",
"pdal_version": "2.7.0 (git-version: 4f8157)",
"reader": "readers.las",
"stac":
{
"assets":
{
"data":
{
"href": "/home/ncopa/aports/community/pdal/src/PDAL-2.7.0-src/test/data/las/autzen_trim.las",
"title": "Pointcloud data"
}
},
"bbox":
[
-123.0734622,
44.04990616,
406.26,
-123.068918,
44.05155049,
520.51
],
...
{
"name": "Latitude of 2nd standard parallel",
"value": 45.5,
"unit": "degree",
"id": {
"authority": "EPSG",
"code": 8824
}
},
{
"name": "Easting at false origin",
"value": 1312335.95800525,
"unit": {
"type": "LinearUnit",
"name": "foot",
"conversion_factor": 0.3048
},
"id": {
"authority": "EPSG",
"code": 8826
}
},
{
"name": "Northing at false origin",
"value": 0,
"unit": {
"type": "LinearUnit",
"name": "foot",
"conversion_factor": 0.3048
},
"id": {
"authority": "EPSG",
"code": 8827
}
}
]
},
"coordinate_system": {
"subtype": "Cartesian",
"axis": [
{
"name": "Easting",
"abbreviation": "",
"direction": "east",
"unit": {
"type": "LinearUnit",
"name": "foot",
"conversion_factor": 0.3048,
"id": {
"authority": "EPSG",
"code": 9002
}
}
},
{
"name": "Northing",
"abbreviation": "",
"direction": "north",
"unit": {
"type": "LinearUnit",
"name": "foot",
"conversion_factor": 0.3048,
"id": {
"authority": "EPSG",
"code": 9002
}
}
}
]
}
},
"proj:wkt2": "PROJCS[\"NAD_1983_HARN_Lambert_Conformal_Conic\",GEOGCS[\"NAD83(HARN)\",DATUM[\"NAD83_High_Accuracy_Reference_Network\",SPHEROID[\"GRS 1980\",6378137,29
8.257222101004,AUTHORITY[\"EPSG\",\"7019\"]],AUTHORITY[\"EPSG\",\"6152\"]],PRIMEM[\"Greenwich\",0],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9122\"]]],PROJECT
ION[\"Lambert_Conformal_Conic_2SP\"],PARAMETER[\"latitude_of_origin\",41.75],PARAMETER[\"central_meridian\",-120.5],PARAMETER[\"standard_parallel_1\",43],PARAMETER[\"standa
rd_parallel_2\",45.5],PARAMETER[\"false_easting\",1312335.95800525],PARAMETER[\"false_northing\",0],UNIT[\"foot\",0.3048,AUTHORITY[\"EPSG\",\"9002\"]],AXIS[\"Easting\",EAST
],AXIS[\"Northing\",NORTH]]"
},
"stac_extensions":
[
"https://stac-extensions.github.io/pointcloud/v1.0.0/schema.json",
"https://stac-extensions.github.io/projection/v1.1.0/schema.json"
],
"stac_version": "1.0.0",
"type": "Feature"
}
}
'
expected: '
"properties":
{
"datetime": "2015-09-10T00:00:00Z",
"pc:count": 110000,
"pc:encoding": ".las",
'
[ FAILED ] Info.stac (426 ms)
[----------] 6 tests from Info (2735 ms total)
[----------] Global test environment tear-down
[==========] 6 tests from 1 test suite ran. (2739 ms total)
[ PASSED ] 5 tests.
[ FAILED ] 1 test, listed below:
[ FAILED ] Info.stac
1 FAILED TEST
118/122 Test #37: pdal_io_ept_addon_writer_test ................ Passed 6.03 sec
119/122 Test #92: pdal_filters_pmf_test ........................ Passed 5.58 sec
120/122 Test #38: pdal_io_copc_reader_test ..................... Passed 7.63 sec
121/122 Test #65: pdal_filters_colorization_test ............... Passed 7.15 sec
122/122 Test #118: translate_test ............................... Passed 5.93 sec
99% tests passed, 1 tests failed out of 122
Total Test time (real) = 8.31 sec
The following tests FAILED:
112 - pdal_info_test (Failed)
Errors while running CTest
>>> ERROR: pdal: check failed
```
## Steps to reproduce
`abuild -r`3.20.0Bart RibbersBart Ribbershttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15920Package request Metaflac2024-03-27T18:09:42ZVehementHamPackage request Metaflac## Package Information
* Name: metaflac
* Homepage: https://xiph.org/flac/documentation_tools_metaflac.html
* Source code: https://ftp.osuosl.org/pub/xiph/releases/flac/flac-1.4.3.tar.xz
## Description
This package is useful for flac ...## Package Information
* Name: metaflac
* Homepage: https://xiph.org/flac/documentation_tools_metaflac.html
* Source code: https://ftp.osuosl.org/pub/xiph/releases/flac/flac-1.4.3.tar.xz
## Description
This package is useful for flac metadata management. The source code compiles without errors. I assume it would be easy to package.https://gitlab.alpinelinux.org/alpine/aports/-/issues/15919Make /etc/network/if-up.d/dad POSIX complaint2024-03-28T16:20:00ZMarcel SteinbeckMake /etc/network/if-up.d/dad POSIX complaint## Package Information
* Package name: busybox-ifupdown (`/etc/network/if-up.d/dad`)
* Package version: 1.36.1
* Alpine version: 3.19.1
* Alpine architecture: x86_64
## Summary
The script: `/etc/network/if-up.d/dad` is not POSIX compl...## Package Information
* Package name: busybox-ifupdown (`/etc/network/if-up.d/dad`)
* Package version: 1.36.1
* Alpine version: 3.19.1
* Alpine architecture: x86_64
## Summary
The script: `/etc/network/if-up.d/dad` is not POSIX complaint. When replacing `/bin/sh -> /bin/busybox` with `/bin/sh -> /usr/bin/dash`, the following error message is shown when booting the system:
```sh
/etc/network/if-up.d/dad: 11: arithmetic expression: expecting primary: " counter-- "
```
I didn't test this yet, but maybe the following could do the trick:
```sh
#!/bin/sh
# Block ifup until DAD completion
# Copyright (c) 2016-2018 Kaarle Ritvanen
has_flag() {
ip address show dev "$IFACE" up | grep -q " $1 "
}
counter=100
while [ "$counter" -gt 0 ] &&
has_flag tentative &&
! has_flag dadfailed; do
sleep 0.2
counter=$((counter - 1))
done
```
## Steps to reproduce
* Install `dash`: `apk add dash`
* Link `sh` to `dash`: `ln -sfn /usr/bin/dash /bin/sh`
* Reboot the systemhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15918main/powertop: v2.15-r4 does not report power estimates2024-03-26T12:53:30Zedepamain/powertop: v2.15-r4 does not report power estimates## Package Information
* Package name: powertop
* Package version: powertop-2.15-r4
* Alpine version: 3.19.1
* Alpine architecture: x86_64
## Summary
Power estimates are not shown in "powertop --calibrate" output, nor in "powertop" o...## Package Information
* Package name: powertop
* Package version: powertop-2.15-r4
* Alpine version: 3.19.1
* Alpine architecture: x86_64
## Summary
Power estimates are not shown in "powertop --calibrate" output, nor in "powertop" output. "/var/cache/powertop/saved_parameters.powertop" is not created.
## Steps to reproduce
On a fresh installation of Alpine Standard 3.19.1, install powertop using "apk update", followed by "apk add powertop".
Run the command "powertop --calibrate".
No power estimates column shown in output.
No "/var/cache/powertop/saved_parameters.powertop" produced.
Downgrading to 2.11-rc1 resolves the issue, and "/var/cache/powertop/saved_parameters.powertop" is produced too.Steven GuikalSteven Guikalhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10986xattrs are not correctly treated by audit2024-03-26T13:09:53ZDaniel Kolesaxattrs are not correctly treated by auditWhen you have binaries with xattrs, they will always show as `x` in audit:
```
x usr/bin/clockdiff
x usr/bin/ping
```
the binaries otherwise have correct permissions/xattrsWhen you have binaries with xattrs, they will always show as `x` in audit:
```
x usr/bin/clockdiff
x usr/bin/ping
```
the binaries otherwise have correct permissions/xattrs