January 2024 - 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

dropping opera
by Ike Devolder 08 Feb '24

08 Feb '24

Hi, Since I have not really used opera for years, I'm finally going to drop it from the repo's. If someone wants it, feel free to adopt it. Else I will drop it to AUR in 2 weeks. --Ike

1 1

RFC Final Comment Period: Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to default compilation flags
by Morten Linderud 06 Feb '24

06 Feb '24

An RFC has now entered its Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/26 Please visit the above link for the discussion. Summary: Add ``-fno-omit-frame-pointer`` and ``-mno-omit-leaf-frame-pointer`` to the default compilation flags to improve the effectiveness of profiling and debugging tools. -- Morten Linderud PGP: 9C02FF419FECBE16

1 2

Forensic tool release: archlinux-userland-fs-cmp (reproducible pre-compiled binary available)
by kpcyrd 31 Jan '24

31 Jan '24

hello, I released a tool recently that I'd like to share with this list: https://github.com/kpcyrd/archlinux-userland-fs-cmp It's supposed to be used from a rescue image (any Linux) with an Arch install mounted to e.g. /mnt. It does the following: - Open /mnt/var/lib/pacman and extract the list of (allegedly) installed packages. - Instead of trusting the `mtree` files from the mounted file system, the %NAME% and %VERSION% values from the `desc` files are used to start a download stream from archive.archlinux.org. - From the download stream it's decompressing and inspecting the content on-the-fly, since the .MTREE file is near the beginning of the package we can abort the remaining package download after the mtree has been received (saving a lot of time and traffic). - All files in /mnt that are part of a package are hashed and compared with the sha256 hashes in the MTREE files downloaded from the archive. - Finally, it's printing a report of all files that either mismatched or are not a part of any package. This can be redirected to a file using the -o flag. At no point is any file from the mounted filesystem eval'd or otherwise executed. Parsers are written in a memory safe language. Although it's integrating with pacman, the integration with archive.archlinux.org makes this Arch Linux specific, files from AUR, Manjaro or SteamOS packages are all going to be flagged for manual inspection. The authenticity of the .MTREE files is assumed through the https connection they are downloaded from (which is supposed to be sufficient for the use-case it's built for). The release page on github has a pre-compiled, statically linked binary that can trivially be reproduced from source code. The dependency tree is documented in Cargo.lock, the build environment is documented in repro-env.lock. The binary has been tested to be working correctly on a Debian bookworm installer busybox rescue shell. There's a gif in the README showing how the tool looks like in action. --- I also printed reproducible builds stickers with a new and unique design that I'm planning to hand out at FOSDEM (along with some 37c3 leftovers), if you have read this far, feel free to ask me about stickers if you see me there. The print cost geht auf mein Nacken. cheers, kpcyrd

1 0

FOSDEM 2024 Dinner
by Morten Linderud 26 Jan '24

26 Jan '24

Yo! The previous years at FOSDEM we have held a dinner with around 15-20 people. Some maintainers from Arch, and some users that wanted to join. It has been great events and with FOSDEM 2024 happening I thought it was a good idea to do it again :) The dinner will be held Saturday, 3rd of February, around 20:00. The dinner is sponsored by the Arch Linux and should cover a drink and a main course. We will cap the attendees to 25 people. Priority for members of the Arch team (developers, packagers and support staff). Any free spots after this can be taken by anyone interested. Send me an email *offlist* if you want to attend. The users requesting spots will get a heads up the week before FOSDEM to give all staff a chance to reply. Please ask me if you have any questions :) I also plan to announce a pub closer to the FOSDEM weekend, so anyone unable to join the dinner can still come and grab a drink with the rest of us. Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

1 1

Arch Linux in December 2023
by Levente Polyak 23 Jan '24

23 Jan '24

## Staff We would like to welcome [Jakub Klinkovský (lahwaacz)][0] as part of the Arch Linux Package Maintainer team. ## User meetup During the [37th Chaos Communication Congress (37C3)][1], we hosted a user meetup. At this event, we presented our latest achievements and developments. Additionally, we held an open Q&A session to engage and connect with our community. ## dbscripts We performed a thorough cleanup of the codebase, removing all legacy SVN functionality that is no longer necessary. Furthermore, a critical locking issue was resolved, which previously allowed the same file descriptor to be reused multiple times. This correction ensures that each lock is properly maintained, addressing concurrency locking issues and preventing inconsistent states. ## Infrastructure We have rolled out [Keycloak 23][2], to utilize the latest features and fixes for our central Single Sign-On (SSO) system at [accounts.archlinux.org][3]. Additionally, we've activated the Account Console version 3, which grants us access to its custom field support, specifically designed in conjunction with the 'User Profile' feature. ## RFC We [proposed and accepted an RFC][4] to make dbus-broker our default D-Bus daemon, while still allowing the venerable dbus-daemon to be used and minimizing the disruption of existing installations. Furthermore an [RFC has been proposed][5] to add ``-fno-omit-frame-pointer`` and ``-mno-omit-leaf-frame-pointer`` to the default compilation flags to improve the effectiveness of profiling and debugging tools. [0]: https://lists.archlinux.org/hyperkitty/list/aur-general@lists.archlinux.org… [1]: https://events.ccc.de/category/37c3/ [2]: https://www.keycloak.org/2023/11/keycloak-2300-released.html [3]: https://accounts.archlinux.org [4]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/25 [5]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/26

1 0

New checks for SPDX license identifiers with namcap >= 3.5.0
by David Runge 14 Jan '24

14 Jan '24

Hi all! With RFC0016 [1] we have worked out a way to reason about SPDX license identifiers [2] in the context of PKGBUILDs and packages. Over the past months I have worked on the licenses package [3], as well as namcap [4] to create the integration for all packagers. This mail serves as a refresher and general overview of what this means for packagers. TL;DR: Namcap now emits more specific error messages and there are probably a few things in this mail that you will want to learn about! :) To be able to be more specific in the below text, I will use this mini-glossary to explain what some words refer to: * *known* licenses and exceptions - Licenses and license exceptions *known* to SPDX (i.e. they are in the lists [2][5]). * *unknown* licenses and exceptions - Licenses and license exceptions *not known* to SPDX (i.e. they are *not* in the lists [2][5]). License identifiers prefixed with "LicenseRef-" are not considered. * *common* licenses and exceptions - Licenses and license exceptions that are packaged in the context of the licenses package [3] and can be shared *commonly*. * *uncommon* licenses and exceptions - Licenses and license exceptions that are *known*, but are *not common* (i.e. they are in the lists [2][5] but not in the licenses package [3]). License identifiers prefixed with "LicenseRef-" are always considered *uncommon*. For packagers a few things change when it comes to handling license information for packages. * It is encouraged to have a look at the list of *known* license identifiers [2] and exceptions [5] to familiarize yourself with how identifiers look like. The *common* licenses can be found in /usr/share/licenses/spdx/ and the *common* license exceptions in /usr/share/licenses/spdx/exceptions/. * The `license` array in PKGBUILDs should now start to contain valid SPDX license identifiers [2][5] or custom license identifiers, that are prefixed with "LicenseRef-" (e.g. "LicenseRef-Custom-License-1.0"). To keep complex scenarios maintainable and readable, each entry in the `license` array may be interpreted as being concatenated by the `AND` license expression [6]. * We now distinguish between various versions of some identifiers (e.g. previously we were okay with simple identifiers such as "GPL3" but now we have "GPL-3.0-only" and "GPL-3.0-or-later", which are separate from one another). If you are unsure about what applies, either contact upstream or reach out over mail, IRC, Matrix to ask other packagers. * If in doubt, rather be more specific than less specific! * To aide in documenting copyright and attribution, many upstreams rely on SPDX License IDs [7], which are added as comments at the top of each source file. These often help a great deal in figuring out which specific licenses apply and help in finding out whether there are any license files missing. To help you with figuring things out, namcap gained a few more features with > 3.5.0 (although some issues had to be ironed out up until 3.5.2 and I seriously hope I didn't introduce even more bugs ;-)). Please remember that namcap does not take away the work of investigating and providing the correct license identifiers for you! * Namcap now emits errors on all *unknown* license identifiers [2] and license exceptions [5]. * Namcap now lists all *uncommon* licenses and license exceptions while providing an overview about how many license files it found for the amount of *uncommon* identifiers (each *uncommon* identifier requires a separate file). * Namcap now emits errors with suggestions on formatting issues of license expressions (e.g. `MIT and Apache-2.0` -> `MIT AND Apache-2.0`). * Namcap now emits errors on license strings that can not be parsed. * Namcap now emits errors when the license directory is a symlink to a location in another package, that is not in `depends`. * Namcap now emits errors when the license directory is a symlink to a location in another package and license files are missing for *uncommon* identifiers. * Namcap now emits warnings if it detects symlinks for the license directory or single license files to another package. This is done because it is *very* cumbersome and error-prone to detect files in other packages reliably (e.g. those could in turn be symlinks to non-existent files, etc.). It is encouraged to package license files per package! Symlinks in the same package are fine! I hope this summary was not too overwhelming and will help you to get through the licensing jungle! Please do note, that the Arch Wiki section on license identifiers in the PKGBUILD article [8] still needs to be adapted. If there are any questions, please reach out! Many thanks to everyone who worked on the RFC and helped with testing the implementation! Best, David [1] https://rfc.archlinux.page/0016-spdx-license-identifiers/ [2] https://spdx.org/licenses/ [3] https://archlinux.org/packages/core/any/licenses/ [4] https://gitlab.archlinux.org/pacman/namcap/ [5] https://spdx.org/licenses/exceptions-index.html [6] https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/ [7] https://spdx.dev/learn/handling-license-info/ [8] https://wiki.archlinux.org/title/PKGBUILD#license -- https://sleepmap.de

1 0

RFC: Mirror Definition
by Anton Hvornum 09 Jan '24

09 Jan '24

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/29 Please visit the above link for discussion. Summary: Before this proposal, there were a lack of requirements and definition of what a mirror is within the Arch Linux community. This RFC therefore outlines the requirements, definitions and guidelines surrounding both becoming but also maintaining and decommissioning a mirror.

1 0

Making dbus-broker our default D-Bus daemon
by Jan Alexander Steffens (heftig) 05 Jan '24

05 Jan '24

The following change just entered our testing repositories: We are making dbus-broker our default implementation of D-Bus, for improved performance, reliability and integration with systemd. For the foreseeable future we will still support the use of dbus-daemon, the previous implementation. Pacman will ask you whether to install dbus-broker-units or dbus-daemon-units. We recommend picking the default. For a more detailed rationale, please see RFC 25 at https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/25.

1 0