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

Final Comment Period: RFC40 amendment
by Morten Linderud 19 Mar '25

19 Mar '25

Yo, We don't have an amendment process for RFCs, but we need to fix up a small part of RFC40 for the REUSE RFC and remove the custom 0BSD license text. I'm putting the amendmend up for a final comment period for any issues or feedback. https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/49 The intention is to extend the RFC process with a proper amendment procedure at a later point. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

RFC Final Comment Period: Upstream package sources
by David Runge 19 Mar '25

19 Mar '25

An RFC has now entered 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/46 Please visit the above link for discussion. Summary: Improve the security of Arch Linux distribution packages by relying on transparent and, if possible, cryptographically verifiable upstream sources by default. Provide guidelines and best practices for distribution package maintainers in a document covering various source types and technologies for digital signatures. Communicate the common goal of transparent and secure package delivery for package maintainers as well as upstream project maintainers.

1 0

RFC Final Comment Period: Shorten default TCP keepalive time
by Jan Alexander Steffens (heftig) 11 Mar '25

11 Mar '25

An RFC has now entered its Final Comment Period. In 14 days, the discussion will end and the proposal will either be accepted, rejected or withdrawn: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/51 Please visit the above link for discussion. Summary: Set our default `net.ipv4.tcp_keepalive_time` to override the extremely conservative kernel default.

1 0

RFC: REUSE for package license linting
by Morten Linderud 11 Mar '25

11 Mar '25

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/52 Please visit the above link for discussion. Summary: Utilize REUSE for package license linting for all package sources. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

RFC: providing an official WSL image
by Robin Candau 03 Mar '25

03 Mar '25

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/50 Please visit the above link for discussion. Summary: Provide an official Arch Linux WSL image and define specifications for it (in terms of maintenance, distribution and support). -- Regards, Robin Candau / Antiz

1 2

Cleaning up old [community*] repos
by Sven-Hendrik Haase 01 Mar '25

01 Mar '25

Hey, The git/community-to-extra migration was almost two years ago. Back then, we left the [community] repository and friends ([community-staging], [community-testing]) in place (though empty) so that users would have an easier time migrating. They've sat there unused for a long time now and I think users have had enough time to migrate. I would like to suggest removing the empty [community] repos from repos.archlinux.org. This could break update workflows for users who haven't updated their /etc/pacman.conf in a long time but apart from that I don't expect any drawbacks. Opinions? Sven

4 5

Standardize on running autoreconf in prepare()
by Jelle van der Waa 27 Feb '25

27 Feb '25

Hi All, After all the recent RISC-V news I went ahead and checked out the existing effort to get Arch Linux supported on RISC-V. Felix maintains an overlay of PKGBUILDs which require customization to be be able to build on RISC-V. A lot of these PKGBUILD's patch autotools projects to run `autoreconf -fiv` in prepare(), this re-generates `configure` to understand RISC-V. Since these patches are simple enough and I don't see them harming Arch Linux, I would argue that we want these patches applied in our packages. Re-generating configure should not break, and if it does we should not accept the patch and get a bug filled upstream. Re-creating configure and thus not using the provided `configure` could arguably also be a good thing regarding supply chain security. And this also should help with other architecture ports. As a follow up we can discuss providing our own "/usr/share/config.site" and then ./configure --prefix=/usr would automatically configure localstatedir, libexecdir, etc. [1] https://github.com/felixonmars/archriscv-packages [2] https://github.com/felixonmars/archriscv-packages/blob/master/libafterimage…

8 7

RFC: Shorten default TCP keepalive time
by Jan Alexander Steffens (heftig) 21 Feb '25

21 Feb '25

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/51 Please visit the above link for discussion. Summary: Set our default `net.ipv4.tcp_keepalive_time` to override the extremely conservative kernel default.

1 0

Grub package removed from [testing], please stay on grub-2:2.12-3
by Tobias Powalowski 19 Feb '25

19 Feb '25

Hi, this afternoon we bumped the grub package to the latest available git snapshot, in order to solve the latest security issues encountered and revealed by the grub devs yesterday night. After some initial testing we decided to remove it again from the [testing] repository. We need now to figure out how we can solve the security issues without breaking user's systems, eg. loopback is broken or accessing encrypted devices. We will forward the detected issues to the grub devs. If you already updated the grub package, please downgrade it to grub-2:2.12-3, that is in [core] repository. Best regards tpowa -- Tobias Powalowski Arch Linux Developer (tpowa) https://www.archlinux.org tpowa(a)archlinux.org Archboot Developer https://archboot.com St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de info(a)st-martin-apo.de

1 0

Rust packaging guidelines: Remove --all-features suggestion
by kpcyrd 19 Feb '25

19 Feb '25

hello, following up on an irc discussion on the Rust packaging guideline, I'd like to propose changing the command in section 5 from: cargo build --frozen --release --all-features to cargo build --frozen --release Enabling all non-default features is rarely what we want, they are usually off for a reason and instead features should be explicitly selected and enabled, or added to the default feature set by upstream if they are meant to be on by default. Setting --all-features in many projects (mine included) would enable the `vendored` feature that opts you out of system libraries, which is something we explicitly don't want. cheers, kpcyrd

2 1