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

Enabling split debug for kernels?
by Jan Alexander Steffens (heftig) 14 Sep '24

14 Sep '24

Hi list, As of Pacman 7.0.0, we can have makepkg create debug packages for our kernels, however... Compressed modules are not scanned, meaning either we continue to use INSTALL_MOD_STRIP=1 (throwing away debuginfo for all modules), we disable compression, or we have to enhance makepkg further. For reference, without module compression, the package size of linux drops from 135 MiB to 98 MiB and its installed size rises from 135 MiB to 562 MiB. Debian has been compressing their kernel modules since last year. Instead of splitting debuginfo, they install unstripped modules into /usr/lib/debug/: https://salsa.debian.org/kernel-team/linux/-/commit/e8b64e4b4318aaaf7222f47… Fedora & RHEL do not compress kernel modules, for the same reason of incompatibility with split debuginfo: https://bugzilla.redhat.com/show_bug.cgi?id=1349651 In addition, with compression disabled, the split debuginfo step of packaging linux takes 1½ hours on our build server, which is less than optimal. From what I can tell, that time is spent in the # create any needed hardlinks loop, causing runtime to explode quadratically (amount of stripped files × amount of files in the package). When the kernel is built with module compression, it also adds support for decompressing modules with the selected compression without help from kmod. This seems to be needed in some edge cases, so reënabling compression wouldn't be as easy as adding a module compression stage to makepkg. Debian ran into problems when they missed enabling this support: https://salsa.debian.org/kernel-team/linux/-/merge_requests/980 The issue tracking split debug is at https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/2 The MR to test split debug is at https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/merge_req… It would be nice to have full debuginfo available. Greetings, Jan

1 0

News draft: Manual intervention for pacman 7.0.0 and local repositories required
by gromit 13 Sep '24

13 Sep '24

Hello everyone, with the move of pacman version 7.0.0 a few changes might require manual intervention from end users, which shall be described in the following news item! If you have feedback to it feel free to reply directly! ------ # Manual intervention for pacman 7.0.0 and local repositories required With the release of [version 7.0.0][0] pacman has added support for downloading packages as a separate user with dropped privileges, which we deem a good default for our distribution. For users with local repos however this might imply that the download user does not have access to the files in question, which can be fixed by assigning the files and folder to the "alpm" group. $ chown $USER:alpm -R /path/to/local/repo This is of course only relevant after you have successfully [merged the .pacnew][1] files. Pacman also introduced [a change][2] to improve checksum stability for git repos that utilize .gitattributes files. This might require a one-time checksum change for PKGBUILDs that use git sources. [0]: https://gitlab.archlinux.org/pacman/pacman/-/blob/master/NEWS?ref_type=heads [1]: https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave [2]: https://gitlab.archlinux.org/pacman/pacman/-/commit/9548d6cc765b1a8dcf933e8…

2 1

Replacing mlocate with plocate
by Morten Linderud 10 Sep '24

10 Sep '24

Yo! I'm going to drop `mlocate` from the repositories and provide `plocate` as the default locate in Arch Linux. mlocate is very much an abandoned project, while plocate is a modern implementation with a faster database implementation along with io_uring support. https://plocate.sesse.net/ The question is if people feel a strong desire to keep a locate implementation in `[core]` or if we are fine with this living inside `[extra]`. Adding `plocate` to `[core]` would mean we would need to move a `liburing` to `[core]` and I don't really know if we need that. Any opinions? -- Morten Linderud PGP: 9C02FF419FECBE16

4 4

Arch Linux public upload server
by Orhun Parmaksiz 03 Sep '24

03 Sep '24

Hey all! As some of you might already know, I maintain an upload server project called `rustypaste`: https://archlinux.org/packages/extra/x86_64/rustypaste/ I’ve been using it daily for a couple of years now and have been quite happy with it. I used to provide a public instance for free use, but due to some issues with the provider, I had to shut it down: https://github.com/orhun/rustypaste/issues/326 The other day, I started wondering why Arch Linux shouldn't support a similar public service, like https://paste.ubuntu.com, but powered by rustypaste. I believe we could configure rustypaste to allow public uploads with a retention period and necessary security measures in place. I was going to bring this up with the DevOps team, but I thought it might be better to get general opinions on the matter first. 🐻 Cheers, Orhun

5 5

RFC Final Comment Period: License Package Sources
by Sven-Hendrik Haase 03 Sep '24

03 Sep '24

An RFC has now entered its 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/40 Please visit the above link for discussion. Summary: Our package sources currently do not have explicit licenses. This RFC proposes to license all Arch Linux package sources under the terms of the Zero-Clause BSD license.

2 2