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

GHC 9.4.8 enters [extra-testing]
by Felix Yan 03 Apr '25

03 Apr '25

Hi all, The long delayed GHC 9.4.x updates have been done and moved to [extra-testing]. Two obsolete packages were retired from the distribution. If you still have them installed, please consider removing them: - haskell-configurator - haskell-critbit Many thanks again to @Vekhir who helped me a lot for preparing this batch and many previous batches of Haskell updates. As always, please report any issues and have fun! -- Regards, Felix Yan

1 0

Spring cleanup '25
by Antonio Rojas 02 Apr '25

02 Apr '25

Time to clean up old cruft again. Please head to https://archlinux.org/devel/reports/unneeded-orphans/ and adopt packages you want to keep in the repos. For reference, a current list of packages is attached (but this may vary if packages are adopted/disowned). If you adopt a package from the list, make sure to check its dependencies and also adopt them in case they are orphan. This is also a good time to check your out-of-date packages and disown the ones you no longer have interest in/time to maintain, so they can find a maintainer in the official repos or otherwise in AUR. Keeping packages out of date and/or with unfixed issues for months/years is not ideal and can be detrimental to the overall quality of our distro in the long run. I will start dropping packages to AUR in ~ 10 days. ack acpilight arc-solid-gtk-theme arduino-builder aspell-da b43-fwcutter caja-actions echoping flterm fusesoc gauche gmrun gpgit gradle7 hitch hq kakoune-lsp lastpass-cli libutp libxml++2.6-docs log4cpp lxsplit mailgraph med-openmpi megatools molecule-plugins netcf obconf ophcrack perl-app-borgrestore perl-config-simple perl-cpanplus-dist-arch perl-data-messagepack perl-dir-self perl-statistics-descriptive physlock pinta psiconv python-clint python-glfw python-migen python-nptyping python-olm python-pyswip python-sounddevice reflector rhino-javadoc rp-pppoe ruby-cairo sc scim-chewing sipcalc smokeping snap-sync spampd swaks sx t-prot taskd tenshi tree-sitter-bash tree-sitter-python ttf-joypixels vbam-sdl vbam-wx web-ext wldash xautolock xcftools xplc

13 12

Heads up: cmake 4 may cause build failures
by Antonio Rojas 27 Mar '25

27 Mar '25

cmake 4 (currently in testing) removes support for cmake_minimum_required values below 3.5. This may cause build failures especially for unmaintained or poorly maintained upstream projects. Those can be fixed by increasing the cmake_minimum_required value in CMakeLists.txt. Note that this will change the default value of some policies so may cause some behavior change. Also, OLD vaue for some deprecated policies is no longer supported. If whatever the policy's OLD behavior does is still needed, it will need to be set in some other way. Check the specific policy's documentation for more info.

1 0

Re: Spring cleanup '25
by Chih-Hsuan Yen 22 Mar '25

22 Mar '25

Antonio Rojas <arojas(a)archlinux.org> 於 2025年3月22日週六下午6:50寫道： > > Time to clean up old cruft again. Please head to https://archlinux.org/devel/reports/unneeded-orphans/ and adopt packages you want to keep in the repos. For reference, a current list of packages is attached (but this may vary if packages are adopted/disowned). If you adopt a package from the list, make sure to check its dependencies and also adopt them in case they are orphan. > > This is also a good time to check your out-of-date packages and disown the ones you no longer have interest in/time to maintain, so they can find a maintainer in the official repos or otherwise in AUR. Keeping packages out of date and/or with unfixed issues for months/years is not ideal and can be detrimental to the overall quality of our distro in the long run. > > I will start dropping packages to AUR in ~ 10 days. > > ack > acpilight > arc-solid-gtk-theme > arduino-builder > aspell-da > b43-fwcutter > caja-actions > echoping > flterm > fusesoc > gauche > gmrun > gpgit > gradle7 > hitch > hq > kakoune-lsp > lastpass-cli > libutp > libxml++2.6-docs > log4cpp > lxsplit > mailgraph > med-openmpi > megatools > molecule-plugins > netcf > obconf > ophcrack > perl-app-borgrestore > perl-config-simple > perl-cpanplus-dist-arch > perl-data-messagepack > perl-dir-self > perl-statistics-descriptive > physlock > pinta > psiconv > python-clint > python-glfw > python-migen > python-nptyping > python-olm > python-pyswip > python-sounddevice > reflector > rhino-javadoc > rp-pppoe > ruby-cairo > sc > scim-chewing > sipcalc > smokeping > snap-sync > spampd > swaks > sx > t-prot > taskd > tenshi > tree-sitter-bash > tree-sitter-python > ttf-joypixels > vbam-sdl > vbam-wx > web-ext > wldash > xautolock > xcftools > xplc > > > > Thank you for organizing the event. I orphaned some packages that I'm not going to maintain anymore, and some of them become unneeded-orphans. * libkscreen5 * libqt5xdg * lxqt-build-tools-qt5 * python-django-fake-model * python-pynamodb * python-sshpubkeys Best, Chih-Hsuan Yen (yan12125)

1 0

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