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

tcl/tk 9 pulled out of [testing]
by Jelle van der Waa 18 Jan '25

18 Jan '25

Hi all, tcl/tk 9 was uploaded to [extra-testing] without a rebuild of the dependent packages. It has now been pulled out, so if you had it installed you'll need to manually downgrade. https://gitlab.archlinux.org/archlinux/packaging/packages/tk/-/issues/1

1 1

Arch Linux FOSDEM BOF
by Jelle van der Waa 17 Jan '25

17 Jan '25

Hi All, We managed to get a BOF (Birds Of A Feather) session at FOSDEM, at congress (CCC) we did something similar a short project update and then a Q&A session. [1] I expect the room to be small for this ~ 30-50 people as it is in building AW. Everyone from Staff is allowed to join the Q&A session on stage but note that the space might be limited and we possibly can't accommodate 6 or more people. [1] https://fosdem.org/2025/schedule/event/fosdem-2025-6706-arch-linux- meetup-bof/ Greetings, Jelle

1 0

ruby-liquid 5.6.4 pulled from testing
by Bert Peters 16 Jan '25

16 Jan '25

Hi all, Please note that I've just pulled ruby-liquid 5.6.4 from [extra- testing]. ruby-liquid 5.6.1 raises a dependency on part of the standard library to Ruby 3.4, which we do not yet support. Please downgrade ruby-liquid to the version available in [extra]. Kind regards, Bert.

1 0

News draft: Pango ≥ 1.56.0 fails in the presence of old Electron ≤ 29 apps
by Jan Alexander Steffens (heftig) 15 Jan '25

15 Jan '25

Apps using the incoming `pango 1.56.0` may fail to render text or crash if the user has also run apps based on Electron 29 or older. To immediately mitigate the issue, delete `~/.cache/fontconfig` or run `fc-cache`. However, further use of old Electron apps may cause the problem to reappear. We recommend - switching newer versions of the Electron applications that use at least Electron 30, - using Flatpak releases of the applications, or - giving the applications their own XDG cache directory by running them with `XDG_CACHE_HOME=${HOME}/.cache/appname` in the environment. ### Technical details Pango 1.56.0 depends on "font wrapper" information provided by Fontconfig 2.15.0 in order to determine whether it supports a font. Electron 29 and older are shipping a Git snapshot of Fontconfig that has the same cache version (`9`) as Fontconfig 2.15.0. but lacks the font wrapper information. The Electron version of Fontconfig fails to parse the cache files generated by our version of Fontconfig. It then regenerates them without the font wrapper information. Our Fontconfig still considers these cache files valid, but the missing font wrapper information leads to Pango failing to find any valid fonts. This issue is being tracked at [pango#1]( https://gitlab.archlinux.org/archlinux/packaging/packages/pango/-/issues/1)

3 4

Amending RFC40 to remove custom 0BSD license
by Morten Linderud 09 Jan '25

09 Jan '25

Yo, Today I noticed that the "License package sources" RFC contained an amended 0BSD license that added a two paragraph exception for patch files and other auxiliary files. The purpose of this change is to ensure the license is not covering other files in the repository that the author can't license from the upstream. See: https://rfc.archlinux.page/0040-license-package-sources/ While this is a practical problem that needs to be solved, we should not be doing that through additional text in a FSF- and OSI approved license. This essentially makes it a custom license that is not really going to detected as 0BSD from external sources, and runs against the original goal of removing legal uncertainty. As the change, and by extension the problem itself, is not mentioned in the text it came as a surprise to me that it was done. What I think is more proper is to remove these two lines from the proposed license file, and move this to a separate RFC that would cover a use of the REUSE specification, or SPDX license identifiers. This would serve the same purpose as the Debian `copyright` files, while also being standardized. I have written a proposed amendment to the text that I hope people find okay. https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/49 *Please note that any licenses already added to the repository needs to be amended.* My goal is to write up a RFC for the REUSE/SPDX part of this before the current 3 month timeline where we'll start adding licenses to ensure we don't prolong the process. If people are curious how this would look like, I annotated the `usd` package as an example. https://gitlab.archlinux.org/foxboron/usd/-/tree/morten/reuse See the spec for more details: https://reuse.software/spec-3.2/ Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

6 9

Issues with Libera.Chat and public access via Matrix
by David Runge 09 Jan '25

09 Jan '25

Hi all, back in October I have created channels for the buildbtw and signstar projects [1] which are meant to be publicly accessible for development and general user activities. While these work fine on the Libera.Chat side, the bridging via our private Matrix bridge causes friction: It is not possible to access the bridged rooms from Matrix without either being in the private Arch Linux staff space or being invited specifically to that room. This is due to the fact, that the official bridge has been shut down in August 2023 and eventually sunset entirely [2]. I raised this issue in the #archlinux-devops channel and after a chat with Jan the following possible scenarios materialized: - only use IRC (shut out Matrix users) - only use Matrix (shut out IRC users) - continue to invite interested people to bridged Matrix rooms manually (basically also shut out Matrix users) - switch to a different IRC network that is (still) accessible via a public Matrix bridge (e.g. oftc.net [3]) for public rooms I am not fond of the first three options as they either shut out user groups or require manual handholding of user additions, which in my mind does not scale. I'm raising this as a general note, because this is an issue when it comes to making public rooms available on Matrix beyond our own staff. For the ALPM project I have therefore chosen the path of least resistance and created #alpm on oftc.net for the time being. It would be great to find a less fragmenting solution for public rooms, so I'd be happy to get some input on this topic. Best, David [1]: https://lists.archlinux.org/archives/list/arch-projects@lists.archlinux.org… [2]: https://libera.chat/guides/matrix [3]: https://oftc.net -- https://sleepmap.de

1 0

FOSDEM 2025 Dinner
by Robin Candau 07 Jan '25

07 Jan '25

Hi everyone, Since a few years now, we have held an "Arch dinner" during the FOSDEM weekend. It has been a great and well received event that we'd like to held again this year :) The dinner will be held Saturday, 1st of February at 20:00. The dinner is sponsored by Arch Linux and should cover a drink and a main course. We will cap the attendees to 25 people. Priority for members of the Arch staff (developers, package maintainers and support staff). Any free spots after this can be taken by anyone interested. Please, send me [1] an email *offlist* if you want to attend, including Foxboron as CC [2] to increase the bus factor :P The users requesting spots will get a heads up the week before FOSDEM to give all staff a chance to reply. Please ask me if you have any questions :) I also plan to announce a pub closer to the FOSDEM weekend, so anyone unable to join the dinner can still come and grab a drink with the rest of us. [1] antiz(a)archlinux.org [2] foxboron(a)archlinux.org -- Regards, Robin Candau / Antiz

1 0