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

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

Incoming changes in JDK /JRE packages
by Leonidas Spyropoulos 09 Oct '23

09 Oct '23

Hello, 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. Cheers, -- Leonidas Spyropoulos Developer & DevOps PGP: 59E43E106B247368

1 0

RFC Final Comment Period: Add -Wl,-z,pack-relative-relocs
by Jan Alexander Steffens (heftig) 25 Sep '23

25 Sep '23

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/23 Please visit the above link for discussion. Summary: Add -Wl,-z,pack-relative-relocs to our LDFLAGS in order to reduce the size of relocations.

2 1

News Draft: Default password hashing algorithm changed to yescrypt
by David Runge 20 Sep '23

20 Sep '23

Hi all, with shadow 4.14.0 I introduced some changes to default password hashing algorithms and would like to post the following on the website once the relevant packages (filesystem, pambase, shadow) move to [core]: ```markdown With shadow >= `4.14.0`, Arch Linux's default password hashing algorithm changed from `SHA512` to [yescrypt](https://www.openwall.com/yescrypt/) and [PAM](https://wiki.archlinux.org/title/PAM) honors the chosen `ENCRYPT_METHOD` in /etc/login.defs. While this should not require any direct user intervention, do note that since we now fully integrate with PAM the `YESCRYPT_COST_FACTOR` setting in `/etc/login.defs` is currently without effect, until [PAM implements reading its value](https://github.com/linux-pam/linux-pam/issues/607). If a `YESCRYPT_COST_FACTOR` higher (or lower) than the default (`5`) is needed, it can be set using the `rounds` option of the [pam_unix](https://man.archlinux.org/man/pam_unix.8) module (i.e. in /etc/pam.d/system-auth). Furthermore, additional changes in the filesystem (>= `2023.09.18`) and pambase (>= `20230918`) packages now ensure [umask](https://man.archlinux.org/man/umask.1p) being set centrally in /etc/login.defs instead of /etc/profile. ``` Best, David -- https://sleepmap.de

1 2

Bug Day
by Jelle van der Waa 17 Sep '23

17 Sep '23

Hey All, I'd like to propose that we have a bug weekend on 1-3 September to clean up our bug tracker before we fully migrate it to Gitlab. We already have less issues then before! [1] But getting the number of issues to be migrated down would be a good thing and make our users happy :-) There is a list of "easy" of fail to build from source and issues with patches. [2] [3] Most of the coordination should happen on #archlinux-bugs on libera.chat. [1] https://dashboards.archlinux.org/d/c9a9b812-a067-4534-96bf-c21ba7a0c47d/fly… [2] https://bugs.archlinux.org/index.php?string=FTBFS&project=0 [3] https://bugs.archlinux.org/index.php?string=&project=0&opened=loqs Greetings, Jelle van der Waa

2 4