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

[arch-dev-public] Scope of arch-projects mailing list
by David Runge 04 Feb '22

04 Feb '22

Hi all, while trying to use the arch-projects mailing list for an announcement I realized, that it is (probably?) not really supposed to be used for that at the moment. It explicitly states to be used for development discussion and providing patches for dbscripts, devtools, mkinitcpio, namcap, netctl, archweb and pyalpm. It seems that apart from netctl none of the above really make much use of this anymore though when it comes to development, as the projects have pivoted towards merge/pull requests on their respective VCS forges. Unless there are any objections, I propose to * add arch-repo-management and arch-release-promotion to it * change arch-projects to *also* become a general discussion list around the above mentioned Arch Linux projects * extend mailing list "about" section with information on how each project prefers to receive patches (e.g. I do not want to use the mailing list for that, but others may) Rationale: We lack a mailing list that revolves around our internal projects and which can also be used by non "elevated users" (such as Trusted Users and Developers) for more general discussion. Given the very low traffic on the arch-projects mailing list I see no issue with it becoming a per-project discussion list as well (as in our case mailing lists seem to be mainly used for discussion and not so much for development anymore these days). Best, David -- https://sleepmap.de

3 3

[arch-dev-public] arch-repo-management walkthrough 2022-02-02 19:00 CET (UTC+01:00)
by David Runge 03 Feb '22

03 Feb '22

Hi all, given recent topics for build automation and work on internal projects I would like to announce a code walkthrough for arch-repo-management [1]. I would like to give an overview of the scope of the project, its current features and which features I would like to see implemented (some of which are still in a discussion phase). I will try to add a few more tickets beforehand to track open features and to outline them better. This way I hope that it becomes easier for interested people to follow up on them. The meeting will take place on Jitsi https://meet.jit.si/20220202-arch-repo-management on 2022-02-02 starting around 19:00 CET (UTC+01:00). Any changes to the date and/or location will be announced in this mail thread. Best, David [1] https://gitlab.archlinux.org/archlinux/arch-repo-management/ -- https://sleepmap.de

4 7

[arch-dev-public] Arch Linux Secure Boot support, get it done ;)
by Tobias Powalowski 02 Feb '22

02 Feb '22

Hi guys, next topic to step up: Secure Boot support I wanted to bring this up to the mailing list to collect all info about the status of SB support. There are different approaches on how to implement SB. My question first: Do we want a signed shim for Arch Linux? If yes, how to achieve this? We should make a process in our infrastructure and document what needs to be done and who does it. Morten would you please add your thoughts about this topic on the ML, i think you are most into SB on linux. Thanks. 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 2

[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