Arch-dev-public August 2023

arch-dev-public@lists.archlinux.org

6 participants
7 discussions

Consolidating our mkinitcpio hooks
by Morten Linderud 01 Oct '23

01 Oct '23

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

2 2

bash 5.2.x status
by Tobias Powalowski 18 Sep '23

18 Sep '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

2 4

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

zlib-ng
by Jelle van der Waa 28 Aug '23

28 Aug '23

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

1 0

News Draft: ansible-core >= 2.15.3-1 update may require manual intervention
by Robin Candau 17 Aug '23

17 Aug '23

# ansible-core >= 2.15.3-1 update may require manual intervention As of ansible-core version `2.15.3`, upstream moved documentations and examples to a separated [dedicated repository](https://github.com/ansible/ansible-documentation) (see the [related changelogs](https://github.com/ansible/ansible/blob/v2.15.3/changelogs/CHAN…). This means that, starting from version `2.15.3` the `ansible-core` package will stop shipping documentations and a default configuration example under `/etc/ansible/ansible.cfg`. Regarding the documentation, it is available online: <https://docs.ansible.com/> As for the configuration file, as explained in the [wiki](https://wiki.archlinux.org/title/Ansible#Configuration), a base config can be generated with the following command: ```sh ansible-config init --disabled > ansible.cfg ``` After updating from ansible-core <= `2.15.2-1` to >= `2.15.3-1`, everyone using a global Ansible configuration file stored under `/etc/ansible/ansible.cfg` will have their configuration saved as a `pacsave` file. To re-instore it, run the following command: ```sh mv /etc/ansible/ansible.cfg.pacsave /etc/ansible/ansible.cfg ``` -- Regards, Robin Candau / Antiz

1 2

Arch Linux in July 2023
by Levente Polyak 09 Aug '23

09 Aug '23

## Staff We would like to welcome Mario Oenning (moson) as new Arch Linux Support Staff Member. ## devtools arch-nspawn is now utilizing a distinct scope name instead of the previous `--keep-unit` approach. This allows for the creation of a dedicated scope, placing the container within a slice hierarchy which allows a more precise resource control. This enhancement will be part of the next release. Additionally, we've released version [v1.0.3][0], featuring several enhancements and bug fixes. This version enables the building of unofficial packages containing unsupported architectures and implements measures to ensure the `PKGBUILD` file is version controlled for new repositories. ## gluebuddy Gluebuddy, in its latest release [v0.5.6][1], brings an enhancement by automatically providing tag protection for the entire Arch Linux namespace. This feature ensures that all tags are safeguarded, contributing to the integrity and security of our repositories. ## Bugtracker migration Building upon the successful migration of packaging sources to Git, we are now focused on transferring our bug tracking from Flyspray to GitLab. Our progress can be monitored through [`archlinux/infrastructure#522`][2]. We have made substantial advancements in this process, including the preparation of labels for efficient bug management, the initial implementation of bugbuddy to streamline assignment of maintainers and labels, and a thorough revamp of the Flyspray to GitLab conversion tool `flyspray2gitlab`, with preliminary tests carried out in separate namespaces. # SPI We've completed and submitted the Software in the Public Interest (SPI) [annual project update report for the year 2022][3]. This brief report outlines our achievements, developments, and contributions over the past year. [0]: https://gitlab.archlinux.org/archlinux/devtools/-/releases/v1.0.3 [1]: https://gitlab.archlinux.org/archlinux/gluebuddy/-/commit/be32986196f0268bc… [2]: https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/522 [3]: https://gitlab.archlinux.org/archlinux/project-management/-/issues/10

1 0

NEWS DRAFT: Budgie upgrade requires manual intervention
by arch＠serebit.com 04 Aug '23

04 Aug '23

When upgrading from budgie-desktop 10.7.2-5 to 10.7.2-6, the package mutter43 must be replaced with magpie-wm, which currently depends on mutter. As mutter43 conflicts with mutter, manual intervention is required to complete the upgrade. First, remove mutter43 via "pacman -Rdd mutter43", then immediately perform the upgrade via "pacman -Syu". Do not relog or reboot between these steps. This will bypass the conflict.

2 1

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Arch-dev-public August 2023