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

zlib-ng
by Jelle van der Waa 11 Nov '24

11 Nov '24

Hey All, I noticed Fedora is discussing switching from zlib to zlib-ng. zlib-ng is a fork of zlib, which seems to offer ~ 40% better performance and a new API. We have about ~ 1000 packages depending on zlib, zlib-ng does offer a compat option to keep zlib API compatibility. [1] # Proposal From a discussion in #archlinux-staff. It was determined that a possible plan would be to introduce zlib-ng as package in [extra] with the modern API enabled, we can then migrate packages over that are compatible to the new API. A zlib-ng-compat package can be provided, as proposed by Fedora, that activates the zlib API compatibility mode and directly provides libz.so. This package can provide/conflict the original zlib package, and potentially be target to replace zlib all together. In short: zlib-ng would provide libz-ng.so zlib-ng-compat would provide libz.so # Packages which might be able to use zlib-ng Alpine offers a package which has 6 required packages.[2] Debian's codesearch suggests a few packages seem to mention a possible zlib-ng compatibility. [3] These notes where written down last Thursday, in the meantime, Anthraxx uploaded zlib-ng to [extra], so we can start switching packages which use the modern API over. Replacing zlib with zlib-ng-compact is something we need to discuss, I've overheard so far that some test suites fail because they check the compressed test artifact's hash which with zlib-ng can be different. [1] https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.o… [2] https://pkgs.alpinelinux.org/package/edge/community/x86/zlib-ng [3] https://codesearch.debian.net/search?q=zlib-ng&literal=1&perpkg=1 Greetings, Jelle van der Waa & Anthraxx

3 3

Consolidating our mkinitcpio hooks
by Morten Linderud 03 Mar '24

03 Mar '24

Hi, Currently we have a lot of our mkinitcpio hooks in several packages which has never been consolidated. This makes it confusing where stuff belong and what is provided where, and I really want to consolidate everything. It would help keeping up the development of the hooks, patch everything and ultimately write a test suite for mkinitcpio. I also have long term plans on moving the default hooks from busybox to systemd, but this will happen at a later point. Initially I really want to move the hooks from `cryptsetup` and `systemd`: * encrypt and sd-encrypt from core/cryptsetup * systemd and udev from core/systemd We could maybe consider a few other hooks from [core] depending on peoples opinion? We are missing a good networking hook for systemd, and that should preferably be solved at some point. A list of possibly other relevant mkinitcpio stuff: Hook Package * btrfs btrfs-progs * dmraid dmraid * mdadm mdadm * mdadm_udev mdadm * lvm2 lvm2 * sd-lvm2 lvm2 * net mkinitcpio-nfs-utils * netconf mkinitcpio-netconf # Migration It's unclear to me how we should best move these hooks. We would need to merge them upstream into `mkinitcpio` first, then remove them from the packages. Is a news item is enough for this? Or do we want to include a couple of package constraints to ensure people are accidentally removing their hooks? What are peoples opinions? -- Morten Linderud PGP: 9C02FF419FECBE16

5 10

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