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

Re: [arch-dev-public] openssl 3.0
by Pierre Schmitz 15 Dec '22

15 Dec '22

Hi Jelle, (also forwarding to dev-public) definitely yes, OpenSSL 3.0 is on my wish list! :-) I did not want to jump on it at day one though. Even the last minor updates were quite painful and we still have packages requiring version 1.0 and are still not compatible with 1.1. While they claim that most packages should work with a recompile, it would be nice to actually know which packages are not compatible. This should help whether we need another compatibility package are would be able to just replace openssl 1.1 with version 3. I know about foutrelis' awesome rebuilder script, but I wonder if we have something similar that I just could run for half a day to get an idea which package would break and which wont? Like a dry run that wont commit anything. If no such thing exists yet, I might have a look myself. Greetings, Pierre On Wed, Nov 3, 2021 at 9:14 PM Jelle van der Waa <jelle(a)vdwaa.nl> wrote: > > Hi Pierre, > > Shall we start an openssl 3.0 rebuild soon? Fedora/Debian/Alpine seens > to have already started. > > https://fedoraproject.org/wiki/Changes/OpenSSL3.0 > > Greetings, > > Jelle -- Pierre Schmitz, https://pierre-schmitz.com

10 19

[arch-dev-public] packager key revokation
by Andrzej Giniewicz 27 Jan '22

27 Jan '22

Hi all, my away time got longer than I expected (announced October 2020). Due to pandemic I still have no access to my Arch machine. I will get back access to it mid July, so this is not a resignation from my TU role! This notice is due to revocation of Bartłomiej Piotrowski's main key. Together with David Runge we decided, that best approach would be to remove my current key, and add a new one when I have access to my Arch machine. We will transfer the trust to a new key then. Hope to get back to packaging stuff soon, I have a lot of ideas I want to try and being stuck with Windows laptop from work is getting on my nerves. See you soon! Cheers, Andrzej Giniewicz (giniu).

4 3

[arch-dev-public] community.files pacman database corrupt
by Pierre Schmitz 21 Dec '21

21 Dec '21

Hi all, Since Aug 30 07:17:11 CEST the "community.files" database (repos.archlinux.org/community/os/x86_64/community.files) seems to be corrupted. The package "ipguard-1.04-6" has an empty "desc" file. The "files" file has content though. Also the regular "community.db" file does seem fine. I also do not see that package being updated or moved. I did not try to regenerate the file yet to not make it harder to find the issue. Greetings, Pierre

4 5

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

13 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] 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