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

Arch Linux in February 2024
by Levente Polyak 18 Sep '24

18 Sep '24

## Staff We would like to welcome Vincent Dahmen (wahrwolf) as Arch Linux Support Staff with their new role as Mirror Admin. On top we would like to welcome [andreymal and codingkoopa][0] to their new role as ArchWiki Maintainers. Additionally, we would like to congratulate Christian Heusel (gromit) on his promotion to a full DevOps member. ## Testing Team In early February, we issued a [call for participation][1] about joining the [Arch Testing Team][2] which was also shared on the [Forum][3], [Mastodon][4], [Reddit][5] and IRC. The response was overwhelmingly positive, with over 60 new testing accounts created, significantly extending our capacity for more reliable package update testing! For those who haven't joined yet, there's still time! 😉 ## ArchISO For the first time in history, the official Arch ISO [does not fit in a CD][6] as it now exceeds even the largest 900 MiB capacity CDs. Those few still using the coaster form factor instead of USB flash drives will need to switch to a DVD for burning the ISO. ## devtools We released [devtools 1.1.0][7], a major update packed with bug fixes, improvements, and new workflow commands. Notable additions include the `pkgctl version` subcommand, which uses nvchecker to check and apply newer upstream versions, the `pkgctl search` subcommand to search expressions across the entire packaging group, and the `pkgctl aur` subcommand to assist in transitioning packages from official repos to the AUR. Additionally, `makechrootpkg` now allows users to drop into a debug shell for inspecting failed builds within the chroot. All packaging repo clones also come with a default excludes file to ignore common artifacts. Further changes are listed in the [changelog][7]. ## mkinitcpio The latest [mkinitcpio release v38][8] introduces key changes, including the deprecation of `--microcode` option in favor of a new microcode hook for early microcode loading. mkinitcpio now supports creating an early CPIO image, with the `microcode` hook handling the integration of early microcode into this image. ## ArchWiki To enhance readability, [the color of visited links has been updated][9] from gray to the MediaWiki default purple. In addition to [welcoming CodingKoopa and Andreymal][0] to their new roles as ArchWiki Maintainers, we are also excited to [welcome Dybdeskarphet][0], who joins as a new Translator. ## RFC An [RFC has been accepted][10] to add `-fno-omit-frame-pointer` and `-mno-omit-leaf-frame-pointer` to the default compilation flags to improve the effectiveness of profiling and debugging tools. ## Packaging ### ghc We have successfully rolled out GHC 9.2 after resolving all outstanding issues, marking another step toward the latest GHC. ### Plasma 6 Plasma 6, KDE Frameworks 6 and KDE Applications 24.02 (mostly ported to Qt6) are now available in the repositories. ### Statistics In this month, we’ve successfully rolled out 8196 package updates addressing various enhancements and rebuilds, including 2612 package upgrades. Additionally, we’ve received 168 new package issues, while resolving a total of 216 issues. [0]: https://wiki.archlinux.org/title/ArchWiki:News#2024/02/29_-_New_maintainers… [1]: https://lists.archlinux.org/hyperkitty/list/arch-general@lists.archlinux.or… [2]: https://wiki.archlinux.org/title/Arch_Testing_Team [3]: https://bbs.archlinux.org/viewtopic.php?id=293464 [4]: https://fosstodon.org/@archlinux/111907965691846810 [5]: https://www.reddit.com/r/archlinux/comments/1aniloc/join_the_arch_testing_t… [6]: https://gitlab.archlinux.org/archlinux/archiso/-/issues/144 [7]: https://gitlab.archlinux.org/archlinux/devtools/-/releases/v1.1.0 [8]: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v38 [9]: https://wiki.archlinux.org/title/Special:Permalink/800562#Visited_links_are… [10]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/26

1 0

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