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

[arch-dev-public] Arch monthly report December 2021
by Levente Polyak 21 Dec '21

21 Dec '21

## Report The pad for the next January 2022 report is available at [0]. ## Staff We are happy to welcome artafinde [1] among the Trusted Users. Additionally Segaja has applied [2] to become a Trusted User and the vote is currently in progress. ## mkinitcpio A new mkinitcpio version v31 has been released [3]. Besides various nice improvements the biggest highligh of this release is support for efi stub generation [4]. There is also a new wiki page for Unified kernel images [5]. ## Keyring The new keyringctl tooling has been finalized and merged. The next steps are to convert the keyring data using the new tooling to a curated source of truth. Additionally we have started to replace packager keys that were not meeting our latest strength requirements [6] and to ensure that each key has a dedicated @archlinux.org UID. The goal is that for packaging purpose we only sign @archlinux.org UIDs with the main keys but still allow web-of-trust cross-sigs issued from packager keys. ## Devtools A new devtools version 20211129 has been released [7]. The new devtools package is waiting in [staging] for the python 3.10 rebuild to finish in order to avoid additional hassle with an already cumbersome rebuild. LTO has additionally been enabled is this release as the issues should be easy to spot and extremely simple to work around by just setting an `options` knob inside the PKGBUILD. Once devtools has been moved out of [testing], a wide ranged rebuild is planned to make use of the new flags on a broad scale. ## Python The process to upgrade to Python 3.10 has started and we are currently rebuilding [8] all Python packages. Packagers are also actively working on removing Python 2 from the repositories. Packages used for development, like python2-virtualenv and python2-pip, was recently removed [9] and there is work under way to clear out rest of the python2 packages. ## archinstall A new archinstall version 2.3.0 has been released [10] with a lot of new functionality and improvements. Most notably it contains: * GRUB and Disk Encryption now properly works and supports multiple encrypted volumes. * BTRFS subvolumes *(beta only supports a nested structure [11] and has some known issues [12])* * A rudimentary plugin-support [13], allowing users to create their own plugins. * swap [14] has been added into the mix using zram [15] and zram-generator [16]. ## Reproducible Builds A new rebuilderd version has been released that supports build groups, meaning it's now possible to have one build reproduce multiple artifacts at once. This aids being able to check split packages more efficiently instead of building the whole group multiple times for every single split artifact. archlinux-repro has also had a new bugfix release [17]. [0] https://md.archlinux.org/Hu6IMKXCTLa9bv0yh-WCrg [1] https://lists.archlinux.org/pipermail/aur-general/2021-October/036617.html [2] https://lists.archlinux.org/pipermail/aur-general/2021-November/036672.html [3] https://github.com/archlinux/mkinitcpio/releases/tag/v31 [4] https://linderud.dev/blog/mkinitcpio-v31-and-uefi-stubs/ [5] https://wiki.archlinux.org/title/Unified_kernel_image [6] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/best-pract… [7] https://github.com/archlinux/devtools/releases/tag/20211129 [8] https://lists.archlinux.org/pipermail/arch-dev-public/2021-November/030564.… [9] https://lists.archlinux.org/pipermail/arch-dev-public/2021-November/030555.… [10] https://gitlab.archlinux.org/archlinux/archinstall/-/tags/v2.3.0 [11] https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Nested [12] https://github.com/archlinux/archinstall/issues/718 [13] https://github.com/archlinux/archinstall/blob/master/archinstall/lib/plugin… [14] https://wiki.archlinux.org/title/Swap [15] https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html [16] https://wiki.archlinux.org/title/Swap#zram-generator [17] https://github.com/archlinux/archlinux-repro/releases/tag/20211205

3 2

[arch-dev-public] Library dependencies
by Allan McRae 17 Dec '21

17 Dec '21

Hi all, I submitted a patchset to pacman that I would like some packager feed-back on. [1] Essentially this replaces the old libdepends/libprovides system into something akin to that used by APK. In short, makepkg.conf will have a variable like: LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32') At the end of package building, makepkg will look in the library directories and add a provide. E.g. for pacman: provide = lib:libalpm.so.13 Note the prefix matches the prefix given to the relevant directory in LIB_DIRS. Similarly, makepkg can add dependencies on libraries. E.g. pacman may have: depends = lib:libgpgme.so.11 Note, to help with bootstrapping this system, or if packages just do not want to add libprovides, the depends entries are only added if a package actually provides them. This is different to the APK system for libraries which uses "so" as the prefix and is not configurable. But Alpine used musl, which has no concept of multilib, so we need to be a bit more flexible. Note the "lib" and "lib32" prefixes are just for discussion. Arch can configure how they want. The dependency/provides additions can all be disabled in pacman.conf with the '!autodeps' option. Note that APK has similar things for binaries and pkg-config files. e.g. provides = cmd:pacman provides = pc:libalpm These can now be readily be added as dropins to libmakepkg. Any opinions on this would be greatly appreciated. Is this a better system than the current one? Is adding automatic dependencies against the spirit of makepkg where everything is in the PKGBUILD? Thanks, Allan [1] https://gitlab.archlinux.org/pacman/pacman/-/commits/allan/autodeps

3 6

[arch-dev-public] Debug package support in dbscripts
by Jelle van der Waa 16 Dec '21

16 Dec '21

Hi All, Foxboron has been working on support for debug packages in dbscripts the past year. The progress has been slow but we are at a stage where we want to deploy the dbscripts portion of this. That means that on Thursday 17:00 until 20:00 UTC+1 we will close down repos.archlinux.org for any package updates. The idea is to try limit any potential unforseen bugs and have a small testing phase before opening it like normal. If we do find bugs we will rollback any changes and work out the bugs. If everything goes according to plan we’ll work on a devtools patch that would allow debug package updates. Then it is up to us if we enable debug for all packages or make it opt in. If people are curious about the introduced changes, they can be found here: https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/21 The original proposal from November last year can be found here: https://lists.archlinux.org/pipermail/arch-dev-public/2020-November/030222.… Cheers, Foxboron & Jelle

2 3

[arch-dev-public] Python 3.10 rebuilds
by Evangelos Foutras 12 Dec '21

12 Dec '21

For the next few days we'll be doing (semi-automated) rebuilds for Python 3.10. Please avoid adding new Python packages and starting other rebuilds during this time. *This is a strong suggestion in order to minimize the pain of this huge rebuild.* Some PKGBUILDs were modified in /trunk to use the Python 3.10 site-packages path (among other tweaks). Building those against Python 3.9 might fail or produce incorrect packages. The affected packages are listed in the following two commits and care should be taken when updating them while the Python rebuild is ongoing. https://lists.archlinux.org/pipermail/arch-commits/2021-November/1084956.ht… https://lists.archlinux.org/pipermail/arch-commits/2021-November/1084957.ht…

2 4

[arch-dev-public] RFC: add an official mediation program to our organization
by Levente Polyak 08 Dec '21

08 Dec '21

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/9 Please visit the above link for discussion. Summary: Add an official mediation program to our organization consisting of elected mediators to help settle disputes and provide a clear escalation path. Best, Levente

1 0

[arch-dev-public] RFC: Rename the Trusted User role
by Konstantin Gizdov 02 Dec '21

02 Dec '21

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/7 Please visit the above link for discussion. Summary: It is shown in some cases that the Trusted User role naming leads to some confusion and misunderstanding in broader contexts outside Arch Linux. It is furthermore recently been discussed that it also led to similar confusion among members of Arch Linux as well internally. This RFC aims to remedy that with a better suited term to reflect more accurately upon TUs' roles and responsibilities as well as their position in the Arch Linux Organisation. -- Regards, Konstantin

1 0

[arch-dev-public] Arch Monthly Report - November
by Jelle van der Waa 01 Dec '21

01 Dec '21

Hi All, This is the first of hopefully a monthly mail on the first day of the month on the progress of important parts of our distribution. If have something which should be included, please pm / mail me. Or add it to the pad. https://md.archlinux.org/ejoz5fgLTzaSxlBBZcgphA Now for the news: ## Devtools A new devtools release is being prepared with it's most notable changes: [0] * Now licensed to GPLv3 * devtools now records the used BUILDTOOL / BUILDTOOLVER in BUILDINFO, this is required for when we need to reproduce an old package which was build with a different devtools version then the current. (And devtools changed the CFLAGS, etc.) * makerepropkg now supports reading BUILDTOOL / BUILDTOOLVER from a BUILDINFO file and use the makepkg.conf from the correct devtools version. * pacman's makepkg.conf is synced with new hardening CFLAGS such as `-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection` * More missing man pages have been added for archbuild, makechrootpkg, arch-nspawn. ## DBScripts There has been great progress on debug support for dbscripts , review and testing is very much appreciated. [1] Dbscripts was moved to Gitlab with Gitlab CI coverage integration. ## Keyring The archlinux-keyring project gained new tooling called keyringctl to more easily handle the distribution's chain of trust, identify problems with packager keys and allow for a git-based workflow around addition, signing and revocation of packager and main signing keys. The keyring will become a curated source of truth and removes dependency on remote keyservers. [2] archlinux-keyring is now also moved to Gitlab with Gitlab CI coverage integration. ## aurweb Aurweb is being rewritten in Python using FastAPI, an announcement has been posted that the new port can be tested on https://aur-dev.archlinux.org [3] The AUR now provides metadata archives of all AUR packages, to offload requests from the AUR RPC interface. https://aur.archlinux.org/packages-meta-v1.json.gz https://aur.archlinux.org/packages-meta-ext-v1.json.gz For more information see the post on aur-general. [4] ## Arch Linux website A MR has been made to make our navbar responsive and in the future archweb (archlinux.org) responsive in this PR. Moving to SASS also makes it easier to get a working dark mode. [5] [6] Additionally a new archweb release should have a feature to add a note to a package to show why it's outdated. [7] ## releng The monthly release artifacts (i.e. installation medium, bootstrap image, iPXE images) can now be built in GitLab CI and are released automatically on a monthly basis in the releng project. [8] To further automate the release process on the main repository server, arch-release-promotion is about to be tested for the promotion and synchronization of release artifacts in the relevant projects (i.e. releng or arch-boxes). This will enable for a streamlined and automated update of the Arch Linux website with new release information. [9] A related ticket tracks the work on restructuring the output directory to offer a unified approach to non-package releases on the main repository server in the future. [10] [0] https://github.com/archlinux/devtools/compare/20210202...master [1] https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/21 [2] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/merge_requests/24 [3] https://lists.archlinux.org/pipermail/aur-general/2021-October/036614.html [4] https://lists.archlinux.org/pipermail/aur-general/2021-November/036659.html [5] https://gitlab.archlinux.org/archlinux/archlinux-common-style/-/merge_reque… [6] https://github.com/archlinux/archweb/pull/382 [7] https://github.com/archlinux/archweb/issues/269 [8] https://gitlab.archlinux.org/archlinux/releng [9] https://gitlab.archlinux.org/archlinux/arch-release-promotion [10] https://gitlab.archlinux.org/archlinux/releng/-/issues/11

4 7

[arch-dev-public] Dropping python2 as a development environment
by Jelle van der Waa 29 Nov '21

29 Nov '21

Hi All, I would like to propose that we start deprecating python2 and only allowing to exists for: * Make dependencies where required (js68, grafana-zabbix, etc.) * Runtime dependencies such as (john, displayical, etc.) This would basically imply that we drop python2-pip and python2-virtualenv from our repositories and with them tons of python2 modules. A follow up step is to consider dropping check() from python2 modules but I'd prefer to drop python2-virtualenv and python2-pip first and see what's left. Another option is dropping all python2 optional dependencies, but this list is getting smaller every day. Postgresql should drop it's python2 optional dependency by now. Greetings, Jelle van der Waa

2 2

[arch-dev-public] RFC: Rename the Trusted User role
by Konstantin Gizdov 12 Nov '21

12 Nov '21

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/7 Please visit the above link for discussion. Summary: It is shown in some cases that the Trusted User role naming leads to some confusion and misunderstanding in broader contexts outside Arch Linux. It is furthermore recently been discussed that it also led to similar confusion among members of Arch Linux as well internally. This RFC aims to remedy that with a better suited term to reflect more accurately upon TUs' roles and responsibilities as well as their position in the Arch Linux Organisation. -- Regards, Konstantin

4 5

[arch-dev-public] Netboot of 2021.11.01 ISO image is broken
by Pierre Schmitz 01 Nov '21

01 Nov '21

Hi all, I did have some trouble build the current ISO image. As archiso requires to be run as root I had to work around some issues with GPG. As those did no longer work I thought I manually sign the artifacts. This did work fine, but later on I noticed that when using Netboot (PXE), mkinicpio-archiso is no longer able to verify the FS due to lack of any public key for GPG to use. In the meantime I moved the arch folder from the release directory. Note: just using Netboot is broken; the regular ISO image is fine. The whole PXE boot setup is weird though. It starts with a openssl signature for which I am the only one to sign it. We then verify the airootfs using gpg for which we provide the public key (the part which is currently broken). Wouldn't it be enough to instead verify the integrity using the sha checksums we already have, if it was already contain in the ssl signed image? Before diving deeper into the issue in oder to solve it, I was wondering if it wouldn't be better to ditch the whole netboot setup. It is quite complex and hard to test. What do you think? I have to admit that I do not know of any use case where you could not use a regular ISO image and had to use PXE boot. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

2 3