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

[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

[arch-dev-public] Call for review: keyringctl as tooling for a curated keyring
by Levente Polyak 26 Oct '21

26 Oct '21

Hi all, to mitigate different issues with the current status of PGP keyservers and to simplify the management of our keyring we worked towards exploring a new way to handle our keyring: The idea is to have a curated keyring whose source of truth is the repository itself without relying on external component to collect the WoT. The repository will consist of atomic files representing PGP packets which a directory structure logically combines into individual certificates. The advantage is that a new signature is literally just a new independent file as a merge request against the repository which is also very easy to audit. David and me have spent quite some time to develop keyringctl [0]. This tool will provide a convenient UX to work with, and inspect the decomposed certificates. Furthermore it will also be responsible to join all certificates into a keyring and export ownertrust and revocation status as pacman requires. For now bootstrap the keyring directory from the old PGP data by: > ./keyringctl import --main master master-revoked > ./keyringctl import packager packager-revoked We are calling for review and testing specifically for the following: - Try to find bugs by bench testing the commands with real world use cases and files. Some usage examples: [1] - have individual people verify the pacman compatible artifacts created by the `build` command. cheers, David & Levente [0] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/merge_requests/24 [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/blob/feature/cur…

1 0

[arch-dev-public] RFC Final Comment Period: Adoption of a distribution-wide Code of Conduct
by David Runge 11 Oct '21

11 Oct '21

An RFC has now entered 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/6 Please visit the above link for discussion. Summary: The adoption of a distribution-wide Code of Conduct (CoC) helps to describe the social contract by which communication takes place on the various communication channels offered by Arch Linux. This document describes the current CoC, its purpose and location and how to interact with it. Best, David

7 20

[arch-dev-public] New archweb release
by Jelle van der Waa 29 Sep '21

29 Sep '21

Hi all, Today archlinux.org was updated to the latest version with some notable changes: * Port more jQuery code to vanilla JavaScript, saves a wopping 30 kB of network data for the package detail view. * Fixed a bug in the importing of rebuilderd data with packages which contain an epoch. * Full GPG fingerprint are now shown in Developer Profiles * Reporead (imports repository databases) now supports falling back to reading package signatures from disk. This work is done in preparation for when pacman no longer embeds signatures in the repository database saving some bandwidth when fetching the repo databases. Greetings, Jelle van der Waa

1 0