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

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

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

Consolidating our mkinitcpio hooks
by Morten Linderud 03 Oct '23

03 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

3 3

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

News Draft: ppp >= 2.5.0-1 update may require manual intervention
by Felix Yan 14 Sep '23

14 Sep '23

As you may or may not have noticed, both `ppp` and `rp-pppoe` package used to ship a `rp-pppoe.so` and they are not 100% compatible. Back in 2021, ppp 2.4.9 starts to rename its own copy of `rp-pppoe.so` to `pppoe.so`. As of `ppp 2.5.0`, upstream decided to remove the `rp-pppoe.so` symlink and thus broke configurations with the old name. If you still have the old ppp package's `rp-pppoe.so` configured somewhere (likely in /etc/ppp/peers/), please update it to use just `pppoe.so`. Configurations with the same plugin from the `rp-pppoe` package (using full path like /usr/lib/rp-pppoe/rp-pppoe.so) are not affected. -- Regards, Felix Yan

3 3

Arch Linux in August 2023
by Levente Polyak 10 Sep '23

10 Sep '23

## Staff We would like to welcome Tomaz Canabrava (tcanabrava) as part of the Arch Linux Package Maintainer team. ## AURWeb In [AURWeb v6.2.7][0], we primarily focused on bug fixes while revamping Prometheus metrics. We introduced new measures like request tracking and cache-hit/miss ratios for search queries, enhancing our ability to make development decisions and aiding the AUR moderation team in identifying trends. Collaborating with the DevOps team, we introduced a CI/CD feature called [Review Apps][1]. This feature enables us to create virtual machines running AURWeb for each merge request, facilitating change showcases, manual testing, and involving a wider audience for performance, stress-testing, and UI verification. ## RFC We [proposed and accepted an RFC][2] to define the default of not using `PyPI` for Python package sources and only use the platform if there is no other alternative. You can find more details about [this RFC][2] on GitLab. By making this change, we ensure to have a more reliable and less cumbersome default. ## Trademark Policy We've [relocated our Trademark Policy][3] from the Developer area of the ArchWiki to the [service-agreements GitLab repository][4], which is published at [`terms.archlinux.org`][5]. This move centralizes all legal documents, ensuring consistent collaboration across our service agreement materials. [0]: https://gitlab.archlinux.org/archlinux/aurweb/-/tags/v6.2.7 [1]: https://docs.gitlab.com/ee/ci/review_apps/ [2]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/20 [3]: https://gitlab.archlinux.org/archlinux/service-agreements/-/merge_requests/… [4]: https://gitlab.archlinux.org/archlinux/service-agreements/ [5]: https://terms.archlinux.org/docs/trademark-policy/

1 0

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

03 Sep '23

A new RFC (request for comment) has been opened here: 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.

1 0