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

[arch-dev-public] mkinitcpio some improvements and question on how kernel modules should be treated
by Tobias Powalowski 01 Feb '22

01 Feb '22

Hi guys, did some initcpio optimizing lately and implemented correct symlink handling. This saves already some space. https://bugs.archlinux.org/task/73439 Now one major problem left in recent initcpio, uncompressed modules: https://github.com/archlinux/mkinitcpio/pull/25 https://bugs.archlinux.org/task/72882 At the moment modules are uncompressed during initcpio creation. This leads to bigger RAM usage during boot, makes it a bit smaller on storage, due to not recompress compressed modules. On small initrds for normal boot this is not a big matter. My measurement with all patches added: Ramdisk size uncompressed modules: 13261677 Ramdisk size compressed modules: 13112083 (Note the compressed one is smaller due to the symlink patches added) Unpacked initramfs uncompressed modules: 35 MB Unpacked initramfs compressed modules: 26 MB Using this on the biggest "initramfs testsuite" archboot shows the most advantages. If you like to test it on your own initramfs setup you can use: https://gitlab.archlinux.org/tpowa/archboot/-/blob/master/usr/share/archboo… for /usr/lib/initcpio/functions and recreate your initramdisk. Now my question to the list, what should be the default how arch handles modules in initramfs? - Shall we leave the modules at compression level used during kernel build? --> This means the uncompression should be optional. - Shall we still uncompress the modules always? (Status now) --> Then using modules as is needs to be optional. Thanks for you input. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) https://www.archlinux.org <http://www.archlinux.org> tpowa(a)archlinux.org St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de info(a)st-martin-apo.de

3 3

Re: [arch-dev-public] Debug packages for Arch Linux
by Morten Linderud 30 Jan '22

30 Jan '22

On Sun, Jan 30, 2022 at 08:59:34PM +0100, sL1pKn07 SpinFlo wrote: > El dom, 30 ene 2022 a las 20:54, Morten Linderud (<foxboron(a)archlinux.org>) > escribió: > > > On Sun, Jan 30, 2022 at 08:49:29PM +0100, sL1pKn07 SpinFlo wrote: > > > hi > > > > > > thanks for the work! > > > > Thanks! > > > > > one question. This thing works, for example, if I build one of the > > packages > > > with debug package in the arch debuginfod site with my custom flag for > > > disable an option/feature. the debug package stored in the debuginfod > > site > > > still works? or i need to create a debug package locally? > > > > The buildid would be different so our debuginfo won't work with your > > packages. > > > > You can check with: readelf -n /bin/ls | grep -A4 build.id > > > > > If I need to build a local debug package and I want to use it > > > with debuginfod, is it possible add the link of the custom debuginfod > > site > > > in the DEBUGINFOD_URLS variable? how? is , separate? or ;? > > > > Yes, space is the seperator. See > > https://man.archlinux.org/man/debuginfod-find.1#ENVIRONMENT_VARIABLES > > > > You can also add a file under /etc/debuginfod/*.urls like we did with our > > `debuginfod` package. > > > > -- > > Morten Linderud > > PGP: 9C02FF419FECBE16 > > > > Hi > > thanks for the reply > > is here documented the file/directory structure of debuginfod "repo"? > > greetings I recommend reading the documentation frankly. debuginfod just recursively scans a set of directories which is polling our package repositories. The implementation is linked in the email. https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/168/… -- Morten Linderud PGP: 9C02FF419FECBE16

1 1

Re: [arch-dev-public] Debug packages for Arch Linux
by Morten Linderud 30 Jan '22

30 Jan '22

On Sun, Jan 30, 2022 at 08:49:29PM +0100, sL1pKn07 SpinFlo wrote: > hi > > thanks for the work! Thanks! > one question. This thing works, for example, if I build one of the packages > with debug package in the arch debuginfod site with my custom flag for > disable an option/feature. the debug package stored in the debuginfod site > still works? or i need to create a debug package locally? The buildid would be different so our debuginfo won't work with your packages. You can check with: readelf -n /bin/ls | grep -A4 build.id > If I need to build a local debug package and I want to use it > with debuginfod, is it possible add the link of the custom debuginfod site > in the DEBUGINFOD_URLS variable? how? is , separate? or ;? Yes, space is the seperator. See https://man.archlinux.org/man/debuginfod-find.1#ENVIRONMENT_VARIABLES You can also add a file under /etc/debuginfod/*.urls like we did with our `debuginfod` package. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

[arch-dev-public] Signing enclave
by Kristian Klausen 29 Jan '22

29 Jan '22

Hi all The lack of package database signing was mentioned yet again and I think it is time to get the "Signing enclave" project rolling. A design was sketched two years ago[1], and based on that design I'm proposing a new design, without a HSM, which should be implementable today. The initial goal would be setting up the necessary infrastructure for us to be able to implement package database signing. Afterwards we can iterate and adapt the solution for more use-cases (ex: releng signing). Hosting: - Hosted on a Hetzner cloud VM as most of our infrastructure - Managed by the DevOps team Key management: - A master key is generated and stored encrypted in the infrastructure repository[2] - A subkey for signing is generated and stored encrypted in the infrastructure repository[2] and unencrypted on the signing server Signing: - SSHing to a restricted UNIX user with ForceCommand=signing-script - All signing operations are logged - Only signing requests from gemini's WireGuard IP address is allowed [1] https://gitlab.archlinux.org/archlinux/signstar [2] https://gitlab.archlinux.org/archlinux/infrastructure Best regards Kristian Klausen

3 2

[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] Packages seeking Maintainers
by Jelle van der Waa 21 Jan '22

21 Jan '22

Hello, Noticing that I don't really have time and energy to maintain a part of my packages. I think it's better to disown them and let others take care of them, the list is: chromium-bsu guetzli hey (can be dropped as it's not really maintained anymore and oha is much nicer) podofo rdesktop tidy python-pytest-qt leptonica bonnie++ asciidoctor acpi gsmartcontrol ccd2iso avrdude avr-libc vim-pastie vim-align I've also disowned tesseract* which already has a maintainer, but maybe someone is interested in co-maintaining it. Greetings, Jelle van der Waa

4 3

[arch-dev-public] News draft: linux-firmware 20220119.0c6a7b3-2 requires kernel >=5.3 and package splitting
by Andreas Radke 21 Jan '22

21 Jan '22

The linux-firmware package 20220119.0c6a7b3-2 implements kernel firmware compression. Linux kernel from 5.3 on support loading from xz compressed firmware. CONFIG_FW_LOADER_COMPRESS kernel option must be enabled. All official Arch Linux kernel support this for a long time. [1] The linux-firmware package has been split into smaller packages to further reduce required disc space. Some big firmware files of rarely used hardware have been split into separate packages. This affects firmware for Mellanox Spectrum switches, Marvell devices, Qualcomm SoCs, Cavium LiquidIO server adapters, QLogic devices, Broadcom NetXtreme II 10Gb ethernet adapters. Make sure to install additional firmware packages if needed. [2] [1] https://bugs.archlinux.org/task/72899 [2] https://bugs.archlinux.org/task/72559 + https://github.com/archlinux/svntogit-packages/commit/a12e069d0cae39a87f003…

1 0

[arch-dev-public] Update to asciidoc 10.x
by Caleb Maclennan 17 Jan '22

17 Jan '22

The update from asciidoc 9.x to 10.x has been a long standing fiasco. The initial release had quite a few bugs that completely blocked our usage and (as is the case for many Python projects) packaging has gotten harder as upstream tooling is less distro friendly. After an upstream minor release and several patch releases most of the major issues are resolved and I've cobbled together packaging that works. It has been in the [community-testing] repository for a while now and has a couple signoffs. I've also mentioned some of the differences in IRC, but I thought I would give a warning here — I'm about to move it to [community]. Many Arch packages have asciidoc as a makedepends=(). Most of these do not require it as a library and thus the API changes in 10.x will not be relevant, but they do use the CLI script for converting documentation to man pages. One of the major changes in 10.x relevant to other Arch packages is that these CLI scripts /usr/bin/{a2x,asciidoc}.py are no longer distributed with the .py extension, they are just plain /usr/bin/{a2x,asciidoc}. Many upstream projects have adopted this already, but there may be some that have not and will need patching. If you do run into trouble building anything, that is the most likely culprit and the first thing to search for and patch out of upstream code. Caleb

1 0

[arch-dev-public] Updates to archlinux-keyring and signatures for packager keys
by David Runge 15 Jan '22

15 Jan '22

Hi all, in the past days there have been a few releases of our archlinux-keyring package, which contains the root trust of our distribution. We have successfully switched to using keyringctl [1] to manage the keyring. From now on all changes to the keyring are done via merge requests towards the archlinux-keyring repository, as it now serves as the source of truth, whereas in the past we have been relying on the dying SKS infrastructure or the Ubuntu keyserver (which may or may not support all key types in use). I have contacted all of you over the past months and either requested the addition of an @archlinux.org UID, the creation of a new PGP keypair or the verification of your PGP key by means of a clearsigned token. To all that have added a new @archlinux.org UID or have created a new key, please make sure that all signatures you have received from main signing keys are also present in the current keyring (`pacman-key --list-sigs <nick>@archlinux.org`) or in the current HEAD of archlinux-keyring (`./keyringctl inspect <nick>` in a clone of the archlinux-keyring repository). If you have signatures that are not yet in the keyring, you can add them yourself [2] and do not have to wait on a main signing key holder to do it. To all that have created a new key, please make sure to setup the correct PGP key ID in your archweb profile so that the website displays the signatures correctly [3]. If you have gained more than or equal to three main key signatures for your new PGP key and the key as well as those signatures are already available in the keyring in [core] please rebuild all of your packages using your new key and start the process of having your old key removed [4]. For the purpose of mass package rebuilding you may create a TODO [5] and use `rebuild-todo` (in the archlinux-contrib package) which makes use of our build server infrastructure. I have not yet gotten a response from or have not yet been able to resolve my request with the following packagers (nickname in the archlinux-keyring repository): - bgyorgy - archange - arodseth - kylekeen - daurnimator - pierre - farseerfc Please make some time to create a new key/ UID/ or get signed, as Allan would like to revoke his signing key in the near future (which may mean the inability to sign packages and mass rebuild of packages in question) as soon as the above packager signature situation has stabilized. In case you have questions, feel free to reach out in #archlinux-staff on libera.chat or via mail. If you are interested in helping further develop keyringctl, have a look at the relevant open tickets [6]. Best, David [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/#usage [2] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/… [3] https://archlinux.org/master-keys/#master-sigs [4] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/… [5] https://archlinux.org/todo/add/ [6] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues?scope=all… -- https://sleepmap.de

4 5

[arch-dev-public] Arch Linux in December 2021
by Levente Polyak 09 Jan '22

09 Jan '22

## Staff We are happy to welcome Segaja among the Trusted Users [0]. ## Monthly Report We have switched the format of the monthly report to specifically report the progress of the whole previous month. ## Debug packages The dbscripts repository handling for debug packages has successfully been merged [1] and deployed. Successive integration has been submitted to devtools [2] as well as pacman improvements related to PKGINFO [3] and debugedit [4][5]. ## Keyring As the last step of migrating our keyring to a new tooling and a local source of truth we have re-boostrapped the trust with an initial import of the old trust data into the new curated data structure [6]. We are still inviting people to look at the current trust data and cross verify the results. ## pacman A new library dependency feature has been submitted to makepkg [7]. At the end of package building, makepkg will look in the library directories and auto add a library provide that packages can auto depend on. Patches were submitted to alternatively choose asignify for package signatures [8] while keeping gnupg as default in place. ## LTO With the availability of the latest devtools release a lot of freshly updated packages were built with LTO. We have encountered different set of issues that needed to be tackled. Some language specific problems have popped up including but not limited to Go and Rust that require some documentation and adjustments. ## ArchWiki After being broken for almost four months, ArchWiki is once again readable on small screens. [0] https://www.mail-archive.com/aur-general@lists.archlinux.org/msg00635.html [1] https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/21 [2] https://github.com/archlinux/devtools/pull/78 [3] https://lists.archlinux.org/pipermail/pacman-dev/2022-January/025464.html [4] https://sourceware.org/debugedit/ [5] https://lists.archlinux.org/pipermail/pacman-dev/2022-January/025471.html [6] https://gitlab.archlinux.org/archlinux/archlinux-keyring [7] https://lists.archlinux.org/pipermail/arch-dev-public/2021-December/030582.… [8] https://lists.archlinux.org/pipermail/pacman-dev/2022-January/025439.html

1 0