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

Arch Linux in October 2023
by Levente Polyak 10 Dec '23

10 Dec '23

## Staff We would like to welcome [Christian Heusel (gromit)][0] to the Arch Linux DevOps team, expanding his responsibilities. ## bugbuddy The initial version of [Bugbuddy][1], our GitLab bug bot, has been introduced. This tool assigns package maintainers to confirmed GitLab issues in the packaging group. Notably, the code has undergone substantial improvement, now operating as a daemon process that can promptly respond to GitLab webhook calls. ## dbscripts The `db-remove` command has been streamlined, eliminating the need to pass an `arch` parameter by adding automatic resolution. Moreover, the `db-update` command now properly checks staged packages against staging/testing, addressing a loophole that previously caused state inconsistencies. Additionally we've enhanced the development process by parallelizing test execution, massively reducing unit testing duration. ## RFC In late 2021, an [RFC was proposed][2] to rename the `Trusted User` role to `Package Maintainer`, aligning it with the role's evolving nature within the Arch staff. The RFC, voted positively in late 2022, has now resulted in the successful renaming across various Arch resources, including the [Packaging Bylaws][3], [ArchWeb][4], [AURWeb][5], [ArchWiki][6], and the "[What can I do for Arch Linux?][7]" page. ## ArchWiki The [ArchWiki has been updated to MediaWiki 1.40][8], necessitating adjustments to the ArchLinux extension due to upstream changes in the Vector 2022 skin. This has prompted consideration of [switching to the Timeless skin][9]. Additionally, there has been a switch from PNG to SVG images in the wiki for article status templates and statistic histograms. The wiki now features the addition of [Extension:Thanks][10] and [Extension:DiscussionTools][11], offering users a streamlined way to express gratitude and heavily simplifying discussions on talk pages. ## ArchISO The ISO now provides a `/boot/grub/loopback.cfg` file which GRUB and Super GRUB2 Disk users can use to boot the ISO file without needing to manually specify the kernel, initrd and kernel command line parameters. Documentation on utilizing the `loopback.cfg` file is available both [upstream][12] and on [ArchWiki][13]. [0]: https://lists.archlinux.org/hyperkitty/list/arch-devops@lists.archlinux.org… [1]: https://gitlab.archlinux.org/archlinux/bugbuddy/ [2]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/7 [3]: https://gitlab.archlinux.org/archlinux/package-maintainer-bylaws/-/merge_re… [4]: https://github.com/archlinux/archweb/pull/478 [5]: https://gitlab.archlinux.org/archlinux/aurweb/-/merge_requests/755 [6]: https://wiki.archlinux.org/index.php?title=ArchWiki_talk:Requests&oldid=790… [7]: https://gitlab.archlinux.org/archlinux/neoasknot/-/merge_requests/84 [8]: https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/747 [9]: https://github.com/archlinux/archwiki/pull/71 [10]: https://www.mediawiki.org/wiki/Extension:Thanks [11]: https://www.mediawiki.org/wiki/Extension:DiscussionTools [12]: https://www.supergrubdisk.org/wiki/Loopback.cfg [13]: https://wiki.archlinux.org/title/Multiboot_USB_drive#Arch_Linux_monthly_rel…

1 0

RFC: Make dbus-broker our default D-Bus daemon
by Jan Alexander Steffens (heftig) 08 Dec '23

08 Dec '23

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/25 Please visit the above link for discussion. Summary: Make dbus-broker our default D-Bus daemon, while still allowing the venerable dbus-daemon to be used and minimizing the disruption of existing installations.

1 0

Proposal: Automating release artifacts signing and deployment
by Kristian Klausen 02 Dec '23

02 Dec '23

Hi all, nl6720 has proposed[1] that DevOps create a CA for signing the iPXE and initramfs release artifacts. The goal is to be less dependent on a single person's signing key. After dialogue on IRC, we came to the conclusion, that maybe automating signing of the release artifacts (ISO included) is feasible. So the plan we came up with: 1. DevOps creates a CA with a lifetime of 10 years and stores it in their vault 2. DevOps binds a private key to the TPM on secure-runner1.archlinux.org[2] and create a CSR 3. DevOps signs the CSR with the created CA 4. DevOps creates a dedicated GitLab runner, on the mentioned server, with direct access to the TPM and restricted to specific GitLab projects 5. DevOps assigns the runner to the releng project[3] 6. The releng team set up automation for signing the release artifacts with the TPM To keep the implementation simple, the plan is to sign the ISO with `openssl cms` instead of OpenPGP. With that done, the next step would be the automatic synchronization to the mirros and archweb integration. We would like some input on the approach mentioned. If no concerns are raised, we will start implementing it. [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/548 [2] Server for running pipelines for trusted Arch Linux projects [3] https://gitlab.archlinux.org/archlinux/releng/ Cheers, Kristian Klausen

1 0

News Draft: "Bugtracker migration to GitLab completed"
by gromit 01 Dec '23

01 Dec '23

Hello everyone, as we have completed the bugtracker migration it would be good to post a news item about it. Please give feedback if you have any about the draft below! Cheers, klausenbusk & gromit --- # Bugtracker migration to GitLab completed We are happy to announce that the migration of the bugtracker to GitLab is done! 🥳 This means the issue tracker and merge requests on the Gitlab package repos are now enabled. The old bugtracker will subsequently be closed down. For archiving reasons there will be a static copy so that links (for example the randomly picked [Task #56716][0]) are still stable, migrated bugs have a closing comment pointing to the new URL on GitLab. Packaging bugs are now opened on the repo hosting the corresponding packaging sources, the "Add a new Bug" Button on the package page on archlinux.org will automatically direct you to the correct place to open the issue. The workflow afterwards is mostly the same, first our [Bug Wranglers][1] will have a look at the issues and triage them and then they will be handed over to the respective [Package Maintainers][2] to fix. A list of all issues can be found [here][3]. If you do not have an account for GitLab already please write us a mail with your desired username to accountsupport(a)archlinux.org as advised in the banner! Thanks to everyone who has helped during the migration! [0]: https://bugs.archlinux.org/task/56716 [1]: https://gitlab.archlinux.org/groups/archlinux/teams/bug-wranglers/-/group_m… [2]: https://gitlab.archlinux.org/archlinux/teams/package-maintainer-team [3]: https://gitlab.archlinux.org/groups/archlinux/packaging/-/issues

1 0

Bugtracker Migration to GitLab
by Levente Polyak 25 Nov '23

25 Nov '23

## Scope Our primary goal is to migrate bugs.archlinux.org to GitLab, focusing on packaging bugs and our internal projects. In this email, we'll outline the workflow for packaging bugs and seek your assistance in testing the migration and the bug bot in the [test migration group](https://gitlab.archlinux.org/groups/flyspray-migration/packaging/pac…. Please pay attention to the relevant paragraphs and everyone is strongly encouraged to conduct testing as outlined in the testing section. ## Contribution The biggest chunk of the issue migration preparation and testing has been done by gromit, who elevated a former contribution from kevr into its current awesome state. On top, jelle has assisted in various ways to help providing the migration data and infra setup for the test migration. Additionally, I hacked together the bug bot that follows the defined workflow and labels. ## Issue Conversion Please review the converted issues to ensure there are no significant issues with packaging project assignments or issue content/metadata. You can find packaging issues at: [Packaging Issues](https://gitlab.archlinux.org/groups/flyspray-migration/packaging/pa…. Following the rollout of the issue migration, the [canonical source for packaging issues](https://gitlab.archlinux.org/groups/archlinux/packaging/packages/-/… will shift to each individual package repository. ## Workflow Our workflow will continue to rely on a team effort, similar to the bug wranglers used in Flyspray, but now within the GitLab environment. When new issues are opened, our bug wranglers will validate them, ensuring packagers receive high-quality bug reports. We'll use GitLab's status labels like "unconfirmed" and "confirmed" as well as issue assignees to streamline the process. ## Bug Bot Our bug bot, named bugbuddy, will play a crucial role in this workflow. When a new issue is opened, the bot will automatically assign the issue to all bug wranglers and set the label to "unconfirmed" for easy filtering. Once a bug wrangler confirms the issue, they will assign the "confirmed" status label. This, in turn, triggers the bug bot to automatically assign the issue to the current package maintainers. If packagers adopt or orphan packages in archweb, the bot will reassign the issues accordingly. ## Testing To ensure a smooth transition, we kindly request your assistance in testing the entire migration process and the functionality of our bug bot. Here are the steps to follow: 1. Check multiple converted issues in the [test migration group](https://gitlab.archlinux.org/groups/flyspray-migration/packaging/pac…. 2. Familiarize yourself with the workflow outlined above. 3. Open a test issue. 4. Monitor the bug bot's automatic assignment and the initial label, which should be "unconfirmed." 5. Progressively move the issue to the "confirmed" status. 6. Observe the automatic reassignment to the appropriate package maintainers. ## Labels To maintain useful fields and efficient issue filtering, we will use the following labels for issue categorization: Scope: bug, documentation, enhancement, feature, question, regression, reproducibility, security Status: unconfirmed, confirmed, in-progress, in-review, on-hold, waiting-input, waiting-upstream Resolution: cant-reproduce, completed, duplicate, invalid, not-a-bug, upstream, wont-fix Severity: 1-critical, 2-high, 3-medium, 4-low, 5-lowest Priority: 1-urgent, 2-high, 3-normal, 4-low ## Per Packager Settings For your convenience, we've implemented a feature that allows you to have more control over your assigned issues. This can be done by reacting with emojis in the bugbuddy issue tracker at [this link](https://gitlab.archlinux.org/archlinux/bugbuddy/-/issues/1). To assign yourself to unconfirmed issues related to your own packages, simply react to the control issue by using the magnifying glass emoji. This action will modify bugbuddy's behavior and ensure that you are assigned alongside the bug wranglers to unconfirmed issues within your domain. ## Rollout Timeline If no significant issues arise, we will proceed with the rollout in approximately 2 weeks. This entails disabling login on Flyspray and importing all bugs into GitLab. Subsequently, Flyspray will be replaced with static sites to preserve historical data for some time. ## User Signup The primary challenge we face currently is the account setup in Keycloak, as we have temporarily disabled signup in GitLab due to a high volume of spam. We discussed potential solutions during the Arch Summit 2023 to address the spam issue and allow users to sign up without requiring manual approval. Our DevOps team is actively working on resolving this spam issue to enable account signup for the migration. Meanwhile, the DevOps team will make every effort to promptly create the accounts. Cheers, Levente, Christian & Jelle

3 3

Winter is coming - orphan cleanups
by Jelle van der Waa 25 Nov '23

25 Nov '23

Hi all, Winter is coming and I am looking at orphans in our repos which I would propose to move to the AUR in a week if no one adopts them: - gambit-c - midori - vim-align - vim-pastie - uhttpmock - tty-proggy-clean - tcacpi-bat - archey3 - aurphan - autocutsel - cherrytree - gdlmm - gv - howl - hyena - icecast - libgsystem - libident - libnl1 - libxml++2.6-docs - livewallpaper - ollama-cuda - poppler-sharp - python-aiohttp-cors - python-cx-freeze - python-gnuplot - python-ibm-db-sa - python-magic-filter - razercfg - rhino-javadoc - sparkleshare - zsh-theme-powerlevel10k Greetings, Jelle van der Waa

1 0

bash 5.2.x status
by Tobias Powalowski 29 Oct '23

29 Oct '23

Hi, yesterday anthraxx stated this: - major breakage in potentially a lot of scripts including pacman, dbscripts, devtools and who knows what kind of packages. I tried devtools with 5.2.15 and fixed the only thing I ran into, with this MR: https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/133 shopt handling seems to have changed a bit. I would like to proceed in getting latest bash version into our distribution. Adding bash 5.2.x to staging or testing repository and start fixing eventually borken stuff. Would this ok for you guys? greetings tpowa -- Tobias Powalowski Arch Linux Developer & Package Maintainer (tpowa) https://www.archlinux.org <http://www.archlinux.org> tpowa(a)archlinux.org Archboot Developer https://bit.ly/archboot St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de info(a)st-martin-apo.de

3 5

Arch Linux in September 2023
by Levente Polyak 22 Oct '23

22 Oct '23

## Staff We would like to welcome [Fabian Bornschein (fabiscafe)][0] as part of the Arch Linux Package Maintainer team. ## Bug weekend During the 1st to 3rd of September, we conducted a [bug weekend][1] with the aim of resolving old bugs and implementing proposed solutions. This effort not only reduced the backlog but also contributed to streamlining the upcoming bug tracker migration, resulting in the resolution of approximately 200 bugs. ## devtools We've [released devtools v1.0.4][2], concentrating on bug fixes. Additionally, we implemented unique scope names for nspawn containers, enabling them to fit within a slice hierarchy for better resource management. Also, we now generate a `.SRCINFO` file in the Git repository, simplifying the retrieval of release and source metadata. ## OCI images With the exception of the official DockerHub library image, all [Arch Linux OCI images][3] are now [signed using the built-in sigstore feature][4] in podman and can be verified through cosign. ## RFC We [proposed and accepted an RFC][5] to extend our `LDFLAGS` in order to reduce the size of relocations. You can find more details about [this RFC][5] on GitLab. By making this change, we ensure to reduce the installed size of native packages. ## systemd-boot Starting from version `254.2-1`, the systemd package includes [IA32 systemd-boot EFI binaries][6]. This change allows users with IA32 UEFI systems to opt for the more straightforward [systemd-boot][7] instead of being restricted to the Grub bootloader. ## TU bylaws In September, we discussed and implemented a [change in the Trusted User Bylaws][8]. This update migrates proposed amendments to be submitted as GitLab merge requests, streamlining our workflows and aligning with modern practices applied across our distribution. [0]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t… [1]: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [2]: https://gitlab.archlinux.org/archlinux/devtools/-/releases/v1.0.4 [3]: https://gitlab.archlinux.org/archlinux/archlinux-docker#arch-linux-oci-imag… [4]: https://gitlab.archlinux.org/archlinux/archlinux-docker/-/merge_requests/77 [5]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/23 [6]: https://bugs.archlinux.org/task/79531 [7]: https://wiki.archlinux.org/title/systemd-boot [8]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/m…

1 0

dbscripts leftover packages in staging and testing
by Levente Polyak 21 Oct '23

21 Oct '23

Hi all, this is mostly a notification mail about some inconsistencies with dbscripts where under specific circumstances some leftover packages remain in staging or testing. This issue seems to exist since the last major rollout in June. There seem to be at least two different bugs involved, one in `db remove` and another one in `db move`. I've tracked down the `db remove` one, and am debugging the other issue which also affects libreoffice. I've also written an `fsck` script to detect issues inside the pacman binary repo or within the dbscripts state repo. It seems since June this lead to around 15 occurrences. If you encounter a new leftover package, please feel welcomed to send me a ping. I'm happy to try to help you, or just check if it may be a new or an existing issue. However, there isn't any actionable for packagers for the time being as leftover packages can't be manually removed via `db remove`. I'll correct the inconsistencies as soon as the bug is resolved. Hope this helps one or the other packager to get some insights into the existence of this issue. Cheers, Levente

1 1

News Draft: Incoming changes in JDK / JRE packages may require manual intervention
by Leonidas Spyropoulos 12 Oct '23

12 Oct '23

We are introducing a change in JDK/JRE packages of our distro. This is triggered from the way a JRE is build in modern versions of Java (>9). To sum it up instead of having JDK and JRE packages coexist in the same system we will be making them conflict. The JDK variant package includes the runtime environment to execute Java applications so if one needs compilation and runtime of Java they need only the JDK package in the future. If, on the other hand, they need just runtime of Java then JRE (or jre-headless) will work. This will (potentially) require a manual user action during upgrade: if users have both JDK and JRE installed the can manually install the JDK with pacman -Sy jdk-openjdk and this remove the JRE related packages. if users have both JRE and JRE-headless they will need to choose one of them and install it manually since they would conflict each other now. If they only have one of the JDK/JRE/JRE-headless pacman should resolve dependencies normally no user action is needed. The above are also valid for Java 17 and Java 11 packages as well but not for Java 1.8 since they don’t support modules. -- Leonidas Spyropoulos Developer & DevOps PGP: 59E43E106B247368

1 0