alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2022-06-06T17:42:35Zhttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/17alpine-glibc2022-06-06T17:42:35ZAriadne Conillariadne@ariadne.spacealpine-glibcIt has come to the security team's attention that there are Docker images that make use of `alpine-pkg-glibc`.
It has also come to the security team's attention that end users and developers of these Docker images believe that `alpine-p...It has come to the security team's attention that there are Docker images that make use of `alpine-pkg-glibc`.
It has also come to the security team's attention that end users and developers of these Docker images believe that `alpine-pkg-glibc` is supported by the Alpine community in some way, which it obviously is not.
aports!24647 was a proposed update to `musl` which blocks installation of the glibc packages provided by the `alpine-pkg-glibc` project. The `alpine-pkg-glibc` project may rebuild the `musl` package with `ALLOW_GLIBC_PKG=1` in `abuild.conf` if they wish to provide their own `musl` package in their repo. We have concluded based on informal consensus to approach this as a documentation issue instead.
We may also wish to request the `alpine-pkg-glibc` project rename itself in order to make it more clear to the community that it is NOT an officially blessed project of Alpine, but that is an issue for the council.
Thusly, there are two items referred:
* ~~Should we accept the proposed `musl-1.2.2-r6` update into `edge`?~~
* Should we refer the `alpine-glibc` branding issue to the council to follow up on?2021-08-30https://gitlab.alpinelinux.org/alpine/tsc/-/issues/39[3.17] replace busybox ash with another /bin/sh2023-05-18T19:51:42ZAriadne Conillariadne@ariadne.space[3.17] replace busybox ash with another /bin/shWe've stared deep into the void of the busybox ash parsing code and found it staring back. Among other things we've found:
* `mempcpy` used in a situation where `memmove` must be used
* a serious shell substitution bug
* attempting to ...We've stared deep into the void of the busybox ash parsing code and found it staring back. Among other things we've found:
* `mempcpy` used in a situation where `memmove` must be used
* a serious shell substitution bug
* attempting to zero memory used by AST nodes in the stack code makes the whole thing violently explode, which should not ever happen in an otherwise correct codebase
This issue is about proposing a replacement /bin/sh. We want something similar to what we have now, but with a cleaner codebase, probably `mksh` or something.2022-10-01https://gitlab.alpinelinux.org/alpine/tsc/-/issues/28consider LibreSSL as default OpenSSL provider again2022-07-16T16:45:17ZAriadne Conillariadne@ariadne.spaceconsider LibreSSL as default OpenSSL provider againThis should not be considered a formal system change proposal yet, but more a brain dump regarding my thoughts concerning the recently aborted OpenSSL 3 migration, the future of the OpenSSL project governance, and how trying LibreSSL aga...This should not be considered a formal system change proposal yet, but more a brain dump regarding my thoughts concerning the recently aborted OpenSSL 3 migration, the future of the OpenSSL project governance, and how trying LibreSSL again might be a better path for us. This would be targeted at 3.17 or perhaps 3.18 release if implemented, as there are surely things that would need implementation in LibreSSL.
## Current situation
The current situation is that [we ran into a serious regression with OpenSSL 3 involving apk-tools](https://github.com/openssl/openssl/issues/16660), which was caused by the implementation of the new providers API. Implementation of the new providers API also caused fallout in other packages, such as wpa-supplicant, which use deprecated protocols such as MD4 as required by the WPA-PSK specification.
As we did not have good answers on how to move forward, we hit the timeout period for the system change proposal and the contingency plan automatically went into effect, leading to the revert which has concluded today.
## Current status of OpenSSL
The aforementioned regression has been acknowledged, but no work has been done to fix it, despite being a serious regression and open for a month as of this writing. It seems like it will be difficult to fix due to the way the providers API is implemented.
Meanwhile, there are more problems: it turns out that OpenSSL 3.x will not have LTS releases of the same length as past branches of OpenSSL. In addition, there are governance problems, as outlined by Rich Salz in his [email to the openssl-project mailing list](https://mta.openssl.org/pipermail/openssl-project/2021-October/002777.html): the OpenSSL developers appear to want to focus on developing new features rather than cleaning up the mess of regressions they have created with OpenSSL 3.
Finally, my own review of how the OpenSSL providers API has been implemented makes me doubt the performance impact will be negligible. There is, for example, no caching of provider requests, and lazily loading provider modules on demand means that initial connections serviced by a TLS server/client using OpenSSL 3 may have significant latencies.
In short, based on the real-world deployment of OpenSSL 3 in Alpine, I have a lot of doubt about it. The governance-related discussions have done nothing to assuage these doubts. I also have doubt that the EVP_md_null regression, which is known to be related to the introduction of the providers API, is the only regression, there could be other crash issues, or worse yet, the possibility of a cryptographic downgrade attack (consider downgrade to NULL cipher, for example).
## Revisiting the rationale for switching to OpenSSL 3
There were two areas of concern which made OpenSSL 3 desirable to Alpine:
### Licensing
OpenSSL 3 was relicensed under the Apache 2.0 license. Many copyleft licenses are known to be explicitly compatible with the Apache 2.0 license, such as the GPLv3.
However, it is the opinion of the Alpine license review community that the Apache 2.0 license is *not* compatible with GPLv2. It is also the opinion of the Alpine license review community that the OpenSSL 1.x license was *already* compatible with both GPLv2 *and* GPLv3 due to the system library exception: it is generally not possible to install an Alpine system *without* having an OpenSSL implementation, so it clearly qualifies as a system library.
This means that the originally perceived benefit of OpenSSL 3's Apache licensing is moot: from our perspective, which we believe would be defensible, OpenSSL is a system library and therefore the GPL requirements do not apply to it.
There are also some which have doubted the methods used to support the relicensing effort. This was not a direct concern of anybody dealing with legal issues in Alpine, but one could raise questions about indemnification.
### Providers API
It is known to us (and presumably everyone else) that the OpenSSL ENGINE subsystem is a mess. We had an explicit interest in the providers API as a replacement to the ENGINE subsystem. However, the providers API has introduced regressions, and *many* ENGINE modules were not ported over as providers. It is unknown whether these modules will ever be ported over, before they are removed in OpenSSL 3.1 -- initially I was hopeful, but now I am a bit more doubtful.
Meanwhile, the hardware acceleration capabilities enabled by the ENGINE modules was one of the primary reasons we switched back to OpenSSL from LibreSSL to begin with. So, if we are doomed to lose support for Padlock and other AES accelerators in OpenSSL 3, then this is not a compelling reason to stick with it.
By comparison, the LibreSSL developers do not plan to reintroduce the ENGINE API, but I have been told that they would be willing to consider an alternative implementation, as long as it is clean and passes review. This means that basically, either way, we are probably going to be stuck porting the ENGINE modules for the AES accelerators we want to support, therefore I consider LibreSSL and OpenSSL 3 equal here.
Accordingly, regardless of which path we take, figuring out what happens with Padlock should be considered an action item.
## Current status of LibreSSL
While the OpenSSL project was busy missing the OpenSSL 3 release date by several years, firing multiple project managers in the process, the LibreSSL developers have started to replace large swaths of the OpenSSL codebase with new ISC-licensed code, while maintaining compatibility with the majority of OpenSSL 1.0 and 1.1 APIs. LibreSSL also has not fired any project managers or missed any key deadlines. Also, Alpine already has a productive working relationship with the OpenBSD community relating to other initiatives.
While it is laudable that the OpenSSL developers are starting to clean up the OpenSSL API, one could argue that we should really migrate applications to using the `libtls` API instead, which is already a clean, high-level API that is well understood and audited.
And, as noted above, the LibreSSL developers are willing to collaborate on missing functionality as needed. I do not think we can expect such levels of collaboration with the OpenSSL team, even if their project had healthy governance: they appear to have intentionally installed multiple layers of red tape between themselves and the community.
### FIPS mode
One major issue that would require addressing is that LibreSSL has removed FIPS mode, while we have end users who require FIPS mode for compliance reasons. One possibility could be to reintroduce FIPS mode as a set of configurations which restrict ciphersuites to ones that have been approved for use under FIPS. In the past, however, this led to OpenSSL being used for some packages in lieu of LibreSSL so that those users could make use of a FIPS module.
Discussing FIPS compliance functionality with LibreSSL developers would be considered a task item if we looked in this direction.2022-10-01https://gitlab.alpinelinux.org/alpine/council/-/issues/8Define the scope of the Council2023-10-24T21:05:30ZKevin DaudtDefine the scope of the CouncilWe need to document what the scope of the council is. What types of things should be handled by the council, and what not.We need to document what the scope of the council is. What types of things should be handled by the council, and what not.Kevin DaudtKevin Daudt2023-04-01https://gitlab.alpinelinux.org/alpine/tsc/-/issues/66armhf status2023-11-02T21:29:51ZGhost Userarmhf statuschoices:
- drop
- keep
prior discussion:
- https://lists.alpinelinux.org/~alpine/devel/%3C20200528104748.4d37ede5%40ncopa-desktop.copa.dup.pw%3E
reasons for keep:
- some (seemingly mostly abandoned?) postmarketos devices. almo...choices:
- drop
- keep
prior discussion:
- https://lists.alpinelinux.org/~alpine/devel/%3C20200528104748.4d37ede5%40ncopa-desktop.copa.dup.pw%3E
reasons for keep:
- some (seemingly mostly abandoned?) postmarketos devices. almost all of these use not-up-to-date-kernels now
+ slightly dated issue in pmos: https://gitlab.com/postmarketOS/pmaports/-/issues/599
- the [rpi0](https://www.raspberrypi.com/products/raspberry-pi-zero/) and [rpi0 w](https://www.raspberrypi.com/products/raspberry-pi-zero-w/)
+ these are produced until 2026, and are quite popular.
+ however, almost no other devices really use this architecture, [except...](https://social.hackerspace.pl/@q3k/109673111874789884)
reasons for drop:
- toolchain support for armv6 only gets increasingly poorer. issues such as https://github.com/llvm/llvm-project/issues/41201 have existed for years without resolution, and that one specifically causes e.g. [rust to fail](https://gitlab.alpinelinux.org/alpine/aports/-/issues/14667) without applying workaround
+ of course, one could say this is niche to our setup. it also cost me dozens of hours until clandmeter remembered what the issue was...
- most patches to 'fixing something on armhf' are usually something of a weirder hack and never upstream. i don't have any links, however
- the 'passive costs' of keeping an architecture
+ niche failures cause someone to look at them at least once, take up CI time, ..
+ a (mostly) full built package set takes mirror space, including every release
+ some people find it 'annoying' to do `arch="all !arch"` and try to enable things on every arch even when it does not make sense, and spend both their own time and maintenance time on things like enabling packages that don't have value (graphical apps, ..)
+ (so by dropping it, the `!arch` is not even needed in that case and nobody thinks about it)
currently the status can be summarised as follows:
- armhf is enabled, some stuff like qt5 is disabled on it
- when something doesn't build on armhf, it just gets disabled and everyone moves on. no time spent on it
+ this is okay, as practically nothing disabled would be ran on these tiny 512M devices anyway (graphical apps)
continuing to do that is okay. dropping it would also have its maintenance benefits.2024-04-27https://gitlab.alpinelinux.org/alpine/aports/-/issues/15876Transition to php832024-03-26T00:45:40ZAndy PostnikovTransition to php83PHP 8.1 going out of [security](https://www.php.net/supported-versions.php) support in November so should be moved to testing before 3.20 **TBD**
~~Before 3.20 PHP 8.3 should be set default (priority=100) and 8.2 priority to 60~~ !6288...PHP 8.1 going out of [security](https://www.php.net/supported-versions.php) support in November so should be moved to testing before 3.20 **TBD**
~~Before 3.20 PHP 8.3 should be set default (priority=100) and 8.2 priority to 60~~ !62886
remaining aports requiring 8.1
- https://pkgs.alpinelinux.org/package/edge/community/x86_64/php81
- https://pkgs.alpinelinux.org/package/edge/community/x86_64/php81-apache2
- https://pkgs.alpinelinux.org/package/edge/community/x86_64/php81-fpm
remaining aports requiring 8.2
- https://pkgs.alpinelinux.org/package/edge/community/x86_64/php82
- https://pkgs.alpinelinux.org/package/edge/community/x86_64/php82-apache2
- https://pkgs.alpinelinux.org/package/edge/community/x86_64/php82-fpm3.20.0Andy PostnikovAndy Postnikov2024-05-01https://gitlab.alpinelinux.org/alpine/aports/-/issues/15571Roadmap to Alpine 3.202024-03-08T14:45:58ZFrancesco ColistaRoadmap to Alpine 3.20Here we can keep track of what we want to include in Alpine 3.20, as part of the Roadmap.
- [x] Rust (2 versions behind)
- [ ] LLVM 18
- [ ] GCC 14 expected to be released soon
- [x] Musl 1.2.5
- [x] ~~APKv3?~~ will not be for 3.20.
- [...Here we can keep track of what we want to include in Alpine 3.20, as part of the Roadmap.
- [x] Rust (2 versions behind)
- [ ] LLVM 18
- [ ] GCC 14 expected to be released soon
- [x] Musl 1.2.5
- [x] ~~APKv3?~~ will not be for 3.20.
- [ ] python 3.12
- [ ] boost 1.843.20.02024-06-01https://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/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).