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

Ruby 3.2.4
by Andreas 'Segaja' Schleifer 09 Aug '24

09 Aug '24

Hello, after a lot of work and some wrong avenues we are finally ready to update Ruby in Arch Linux to version 3.2.4. For this we will block staging from tomorrow (09.05.2024) on to do the rebuild, and it might take some time to complete. At the same time we also replace the approach of providing an /etc/gemrc with the more up-to-date approach of providing an operating_system.rb for ruby to rely on. This should solve several issues currently open for the ruby and the rubygems package. We know that Ruby 3.2.4 isn’t the latest version but we decided to do this one and maybe in a couple of months update to ruby 3.3.x once we are sure it is ready. During the update we will also drop some ruby default gem packages which are not needed anymore as we will not de-vendor all ruby defaultgems in the future. There might arise some dependency issues but we will have to face them when we see them. Best regards Segaja

1 3

RFC Final Comment Period: Distribution Developer Manual
by Levente Polyak 09 Aug '24

09 Aug '24

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/21 Please visit the above link for discussion. Summary: This RFC proposes the migration of Arch Linux's operational distro specifications from existing ArchWiki and other sources to a dedicated GitLab developer manual repository. The intention is to document how to run the distribution while leveraging GitLab's collaboration features and streamlined workflows for maintaining and evolving the resulting specifications. This change aims to centralize and enhance the efficiency of specification management while preserving the integrity of the community-contributed contentin the Wiki. This request for comments is superseding RFC-0005 by extending its scope to handle all distro specifications coherently instead of handling a single sub section (packaging guidelines) differently to others.

1 0

RFC: License Package Sources
by Sven-Hendrik Haase 07 Aug '24

07 Aug '24

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/40 Please visit the above link for discussion. Summary: Our package sources currently do not have explicit licenses. This RFC proposes to license all Arch Linux package sources under the terms of the Zero-Clause BSD license.

1 0

Away until 2024-08-12
by David Runge 30 Jul '24

30 Jul '24

Hi all, I'll be on holidays from tomorrow until 2024-08-12 and only sporadically read mails etc. Please feel free to bump/move packages I maintain. Have a good summer! :) Best, David -- https://sleepmap.de

1 0

Resignation
by Florian Pritz 28 Jul '24

28 Jul '24

Hi, Sadly I have no longer had the time necessary to properly handle master key holder and packager duties for a while now. I don't feel like it's fair to you guys and our users to keep this up any longer so I'm officially resigning now. Most pressing topics that come to mind for someone wanting to take over: * I hold a master key, so you'll need to find a new holder for that * perl 5.40 update * various bug reports on Gitlab for my packages * a few flagged packages Thanks for all the nice memories since "[2008-10-19 14:38] installed filesystem (2008.03-2)". While I will no longer be involved in Arch development, I'll still continue to use it and this nice, old install will also continue to live on. Hope to see you guys around :) Florian

5 4

libassuan 3.0.1-1 pulled from testing after crashing pacman
by David Runge 22 Jul '24

22 Jul '24

Hi all, please note that I have just pulled libassuan 3.0.1-1 from core-testing. In this patch-level release some major issues emerged, that break pacman: ``` pacman -Ss test pacman: /usr/lib/libassuan.so.9: version `LIBASSUAN_1.0' not found (required by /usr/lib/libgpgme.so.11) ``` Please note that if you have libassuan 3.0.1-1 installed, you may have to use an installation media or static pacman to get back to 3.0.0-1. I'm very sorry to have caused any inconvenience over this. I will contact upstream about this momentarily. Best, David -- https://sleepmap.de

1 0

Fwd: [PATCH v6] kbuild: add script and target to generate pacman package
by Jan Alexander Steffens (heftig) 16 Jul '24

16 Jul '24

Hi, recently there's been an effort to add a `pacman-pkg` target to the Linux kernel build system, which uses a PKGBUILD to build `linux-upstream` packages for Arch Linux. Since this is of interest to us, I'm forwarding the latest patch email to our list here to give you a chance to provide feedback to the author. I can see this making bisection of kernel issues (or just testing patches) much easier, especially for users. It's also quite an unusual way of calling makepkg. The email is also available at [lore.kernel.org](https://lore.kernel.org/linux-kbuild/20240716-kbuild-pacma…. Greetings, Jan PS: My apologies for sending this twice; the first email was sent with "Markdown" formatting in Evolution, which didn't quite do what I think it would. This one uses "Markdown as HTML", which should have both `text/plain` and `text/html` variants.

1 0

Fwd: [PATCH v6] kbuild: add script and target to generate pacman package
by Jan Alexander Steffens (heftig) 16 Jul '24

16 Jul '24

1 0

AUR Maintenance Saturday 13 July 12:00 UTC
by Jelle van der Waa 13 Jul '24

13 Jul '24

Hi all, We are having some performance issues with the AUR's git repository which requires some maintenance. [1] This means that the AUR will be unavailable for some time starting 12:00 UTC till it is done (hopefully 2 hours, could be more). [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/599

2 1

Urgent news draft: The sshd service needs to be restarted after upgrading to openssh-9.8p1
by Robin Candau 01 Jul '24

01 Jul '24

Hi everyone, As you might have heard by now (or experienced it already), the latest openssh-9.8p1 release requires the sshd daemon to be restarted otherwise new connections cannot establish (the one used to upgrade the package remains intact though). To prevent people from eventually blocking themselves out any further, we would like to introduce a `post_upgrade` transaction for the openssh-9.8p1 package which will restart the sshd service (a MR for that is being worked on [1]), accompanied by an urgent news entry (similarly to what was done for the openssh-8.2p1 release) [2]. Given the urgent aspect of the news, it would be nice to have some quick feedback if possible. I intend to post the news as soon as openssh-9.8p1-2 is released with the `post_upgrade` transaction. --------------- News draft: # The sshd service needs to be restarted after upgrading to openssh-9.8p1 After upgrading to openssh-9.8p1, the existing SSH daemon will be unable to accept new connections. (See https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/5) When upgrading remote hosts, please make sure to restart the SSH daemon using `systemctl restart sshd` right after upgrading. If you are upgrading to openssh-9.8p1-2 or higher, this restart will happen automatically. --------------- [1] https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/… [2] https://archlinux.org/news/sshd-needs-restarting-after-upgrading-to-openssh… -- Regards, Robin Candau / Antiz

2 2