October 2023 - Arch-dev-public - lists.archlinux.org

zlib-ng
by Jelle van der Waa 11 Nov '24

11 Nov '24

Hey All, I noticed Fedora is discussing switching from zlib to zlib-ng. zlib-ng is a fork of zlib, which seems to offer ~ 40% better performance and a new API. We have about ~ 1000 packages depending on zlib, zlib-ng does offer a compat option to keep zlib API compatibility. [1] # Proposal From a discussion in #archlinux-staff. It was determined that a possible plan would be to introduce zlib-ng as package in [extra] with the modern API enabled, we can then migrate packages over that are compatible to the new API. A zlib-ng-compat package can be provided, as proposed by Fedora, that activates the zlib API compatibility mode and directly provides libz.so. This package can provide/conflict the original zlib package, and potentially be target to replace zlib all together. In short: zlib-ng would provide libz-ng.so zlib-ng-compat would provide libz.so # Packages which might be able to use zlib-ng Alpine offers a package which has 6 required packages.[2] Debian's codesearch suggests a few packages seem to mention a possible zlib-ng compatibility. [3] These notes where written down last Thursday, in the meantime, Anthraxx uploaded zlib-ng to [extra], so we can start switching packages which use the modern API over. Replacing zlib with zlib-ng-compact is something we need to discuss, I've overheard so far that some test suites fail because they check the compressed test artifact's hash which with zlib-ng can be different. [1] https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.o… [2] https://pkgs.alpinelinux.org/package/edge/community/x86/zlib-ng [3] https://codesearch.debian.net/search?q=zlib-ng&literal=1&perpkg=1 Greetings, Jelle van der Waa & Anthraxx

3 3

Consolidating our mkinitcpio hooks
by Morten Linderud 03 Mar '24

03 Mar '24

Hi, Currently we have a lot of our mkinitcpio hooks in several packages which has never been consolidated. This makes it confusing where stuff belong and what is provided where, and I really want to consolidate everything. It would help keeping up the development of the hooks, patch everything and ultimately write a test suite for mkinitcpio. I also have long term plans on moving the default hooks from busybox to systemd, but this will happen at a later point. Initially I really want to move the hooks from `cryptsetup` and `systemd`: * encrypt and sd-encrypt from core/cryptsetup * systemd and udev from core/systemd We could maybe consider a few other hooks from [core] depending on peoples opinion? We are missing a good networking hook for systemd, and that should preferably be solved at some point. A list of possibly other relevant mkinitcpio stuff: Hook Package * btrfs btrfs-progs * dmraid dmraid * mdadm mdadm * mdadm_udev mdadm * lvm2 lvm2 * sd-lvm2 lvm2 * net mkinitcpio-nfs-utils * netconf mkinitcpio-netconf # Migration It's unclear to me how we should best move these hooks. We would need to merge them upstream into `mkinitcpio` first, then remove them from the packages. Is a news item is enough for this? Or do we want to include a couple of package constraints to ensure people are accidentally removing their hooks? What are peoples opinions? -- Morten Linderud PGP: 9C02FF419FECBE16

5 10

bash 5.2.x status
by Tobias Powalowski 29 Oct '23

29 Oct '23

Hi, yesterday anthraxx stated this: - major breakage in potentially a lot of scripts including pacman, dbscripts, devtools and who knows what kind of packages. I tried devtools with 5.2.15 and fixed the only thing I ran into, with this MR: https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/133 shopt handling seems to have changed a bit. I would like to proceed in getting latest bash version into our distribution. Adding bash 5.2.x to staging or testing repository and start fixing eventually borken stuff. Would this ok for you guys? greetings tpowa -- Tobias Powalowski Arch Linux Developer & Package Maintainer (tpowa) https://www.archlinux.org <http://www.archlinux.org> tpowa(a)archlinux.org Archboot Developer https://bit.ly/archboot St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de info(a)st-martin-apo.de

3 5

Arch Linux in September 2023
by Levente Polyak 22 Oct '23

22 Oct '23

## Staff We would like to welcome [Fabian Bornschein (fabiscafe)][0] as part of the Arch Linux Package Maintainer team. ## Bug weekend During the 1st to 3rd of September, we conducted a [bug weekend][1] with the aim of resolving old bugs and implementing proposed solutions. This effort not only reduced the backlog but also contributed to streamlining the upcoming bug tracker migration, resulting in the resolution of approximately 200 bugs. ## devtools We've [released devtools v1.0.4][2], concentrating on bug fixes. Additionally, we implemented unique scope names for nspawn containers, enabling them to fit within a slice hierarchy for better resource management. Also, we now generate a `.SRCINFO` file in the Git repository, simplifying the retrieval of release and source metadata. ## OCI images With the exception of the official DockerHub library image, all [Arch Linux OCI images][3] are now [signed using the built-in sigstore feature][4] in podman and can be verified through cosign. ## RFC We [proposed and accepted an RFC][5] to extend our `LDFLAGS` in order to reduce the size of relocations. You can find more details about [this RFC][5] on GitLab. By making this change, we ensure to reduce the installed size of native packages. ## systemd-boot Starting from version `254.2-1`, the systemd package includes [IA32 systemd-boot EFI binaries][6]. This change allows users with IA32 UEFI systems to opt for the more straightforward [systemd-boot][7] instead of being restricted to the Grub bootloader. ## TU bylaws In September, we discussed and implemented a [change in the Trusted User Bylaws][8]. This update migrates proposed amendments to be submitted as GitLab merge requests, streamlining our workflows and aligning with modern practices applied across our distribution. [0]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t… [1]: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [2]: https://gitlab.archlinux.org/archlinux/devtools/-/releases/v1.0.4 [3]: https://gitlab.archlinux.org/archlinux/archlinux-docker#arch-linux-oci-imag… [4]: https://gitlab.archlinux.org/archlinux/archlinux-docker/-/merge_requests/77 [5]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/23 [6]: https://bugs.archlinux.org/task/79531 [7]: https://wiki.archlinux.org/title/systemd-boot [8]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/m…

1 0

dbscripts leftover packages in staging and testing
by Levente Polyak 21 Oct '23

21 Oct '23

Hi all, this is mostly a notification mail about some inconsistencies with dbscripts where under specific circumstances some leftover packages remain in staging or testing. This issue seems to exist since the last major rollout in June. There seem to be at least two different bugs involved, one in `db remove` and another one in `db move`. I've tracked down the `db remove` one, and am debugging the other issue which also affects libreoffice. I've also written an `fsck` script to detect issues inside the pacman binary repo or within the dbscripts state repo. It seems since June this lead to around 15 occurrences. If you encounter a new leftover package, please feel welcomed to send me a ping. I'm happy to try to help you, or just check if it may be a new or an existing issue. However, there isn't any actionable for packagers for the time being as leftover packages can't be manually removed via `db remove`. I'll correct the inconsistencies as soon as the bug is resolved. Hope this helps one or the other packager to get some insights into the existence of this issue. Cheers, Levente

1 1

News Draft: Incoming changes in JDK / JRE packages may require manual intervention
by Leonidas Spyropoulos 12 Oct '23

12 Oct '23

We are introducing a change in JDK/JRE packages of our distro. This is triggered from the way a JRE is build in modern versions of Java (>9). To sum it up instead of having JDK and JRE packages coexist in the same system we will be making them conflict. The JDK variant package includes the runtime environment to execute Java applications so if one needs compilation and runtime of Java they need only the JDK package in the future. If, on the other hand, they need just runtime of Java then JRE (or jre-headless) will work. This will (potentially) require a manual user action during upgrade: if users have both JDK and JRE installed the can manually install the JDK with pacman -Sy jdk-openjdk and this remove the JRE related packages. if users have both JRE and JRE-headless they will need to choose one of them and install it manually since they would conflict each other now. If they only have one of the JDK/JRE/JRE-headless pacman should resolve dependencies normally no user action is needed. The above are also valid for Java 17 and Java 11 packages as well but not for Java 1.8 since they don’t support modules. -- Leonidas Spyropoulos Developer & DevOps PGP: 59E43E106B247368

1 0

Incoming changes in JDK /JRE packages
by Leonidas Spyropoulos 09 Oct '23

09 Oct '23

Hello, We are introducing a change in JDK/JRE packages of our distro. This is triggered from the way a JRE is build in modern versions of Java (>9). To sum it up instead of having JDK and JRE packages coexist in the same system we will be making them conflict. The JDK variant package includes the runtime environment to execute Java applications so if one needs compilation and runtime of Java they need only the JDK package in the future. If, on the other hand, they need just runtime of Java then JRE (or jre-headless) will work. This will (potentially) require a manual user action during upgrade: - if users have both JDK and JRE installed the can manually install the JDK with `pacman -Sy jdk-openjdk` and this remove the JRE related packages. - if users have both JRE and JRE-headless they will need to choose one of them and install it manually since they would conflict each other now. - If they only have one of the JDK/JRE/JRE-headless pacman should resolve dependencies normally no user action is needed. The above are also valid for Java 17 and Java 11 packages as well but not for Java 1.8 since they don't support modules. Cheers, -- Leonidas Spyropoulos Developer & DevOps PGP: 59E43E106B247368

1 0