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

News draft: varnish renamed to vinyl-cache, action required for users
by Sven-Hendrik Haase 23 May '26

23 May '26

Hey all, Recently, the upstream project Varnish was renamed to Vinyl Cache for legal reasons. There were some internal discussions on what to do here because this rename is very disruptive to users. This is not a drop-in replacement. Everything was renamed and Vinyl Cache doesn't have a compatibility layer with Varnish. It's a bit gnarly, honestly. Here's my draft. Lemme know what you think. --- # Breaking changes for all users of `varnish`, renamed to `vinyl-cache` The Varnish project has [renamed itself to Vinyl Cache][0]. We followed this rename with a [new `vinyl-cache` package][1]. This upgrade results in [breaking changes][2] and users are advised to study these changes and how it affects them before following the replacement. All references to "varnish" have been changed to "vinyl" in all binaries and directories. At minimum, users will have to: - rename `/etc/varnish` to `/etc/vinyl-cache` - rename `/var/lib/varnish` to `/var/lib/vinyl-cache` - fix up ownership of files inside `/var/lib/varnish` - user `varnish` becomes `vinyl` - group `varnish` becomes `vinyl` - user `varnishlog` becomes `vinyllog` - user `vcache` remains the same - disable the old `varnish.service` and `varnishncsa.service` systemd units - enable the new `vinyl-cache.service` and `vinylncsa.service` systemd units The former `varnish` package has been dropped from repos. We're not currently planning to maintain a new "varnish" package as it's a different upstream project. [0]: https://vinyl-cache.org/organization/on_vinyl_cache_and_varnish_cache.html#… [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/vinyl-cache [2]: https://vinyl-cache.org/docs/9.0/whats-new/upgrading-9.0.html

2 1

archlinux.org status update
by Jelle van der Waa 17 May '26

17 May '26

Hi all, I've just rolled out a new updated archlinux.org, notable changes are: * Developer reports now contain a link to a list of pkgbases * bumpbuddy out of date data import support The bumpbuddy import has now been deployed and is running. See for example aws-vault being flagged by bumpbbuddy. Note that the automatic import doesn't send any email notification like the manual flagging out of date does. [1] In the future the flag out of date button will be disabled in favor of importing bumpbuddy out of date data. Note that we still lack nvchecker integration in packages in this To-Do. [2] [1] https://archlinux.org/packages/extra/x86_64/aws-vault/ [2] https://archlinux.org/todo/add-nvchecker-integration/

4 5

Rebuilder for Arch Linux images
by Robin Candau 29 Apr '26

29 Apr '26

Hello everyone, As a follow-up to our work on achieving bit-by-bit reproducibility for some Arch Linux images [1][2], I have set up a rebuilder for them, accessible at https://archimgrepro.antiz.fr This page shows the results of verification builds for the official Docker and WSL Arch Linux images. Additional images may be added in the future as progress continues. Rebuilds are currently triggered weekly (on Wednesday mornings) against the latest available images. Source code is available on Arch GitLab [3]. It's very simple in its current state, though the setup should be pretty straightforward and distro agnostic. Note that this rebuilder is not (yet) an official Arch Linux service. It is currently hosted on my own VPS and domain. We will evaluate if and how it might be integrated into the official Arch Linux infrastructure. Happy to share this, hopefully it’s useful to some! :) [1] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [2] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [3] https://gitlab.archlinux.org/antiz/archimgrepro -- Regards, Robin Candau / Antiz

1 0

(optional) AUR helper in archinstall
by Anton Hvornum 24 Apr '26

24 Apr '26

Over the years, one of the most requested features by a long shot (statistics based on memories and conversations) for `archinstall` is having access to AUR helpers. So far, the answer to this has always been no "because the AUR is unsupported". Historically, the previously existing AUR feature was removed in commit [6338e71] as a prerequisite in order for `archinstall` to become adopted as an official package. If I remember correctly, the reasoning back then revolved around the support staff being potentially unhappy/overrun by workload, and also because the "AUR is not officially supported" argument. With [archinstall#4447] we received yet another request with regards to this topic: The chosen approach is to add the (optional) possibility of building and installing paru and/or yay (as two of the most popular AUR helpers) using a dedicated menu entry under "archinstall" -> "Applications" -> "AUR Helpers". The menu entry is accompanied by a warning that the use of the AUR and the AUR helpers is not supported, thus potentially satisfying one of the historical concerns. In my opinion, this placement is good, as it is clearly separated from the remaining installation workflow and warns the user. However, given the previous reasoning for not including AUR helpers directly, I'd like to open up the discussion on this topic. Would now be a good time to allow AUR helpers to be installed via `archinstall`? Not AUR packages, but helpers. It seems like a large portion of users install yay/paru anyway (as of writing this), and it makes sense from a repetitive-task-standpoint to allow users to choose — whether or not they want access to AUR early in the installation process, rather than us saying no and making it less accessible. Aside from apparently being a common repetitive task of setting an AUR helper up, there are also certain drivers[1] users want to pull in during installation, as well as AUR packagers would slightly benefit from this option if they want to try their packages during installation. So with this, I would like to open up the discussion — where both "yes" and "no" are welcome, but I'd appreciate some reasonings behind them as I'm most likely going to reference this mail thread if the consensus is "no". And I hope that "I don't care" people speak up too (we'll count them as leaning towards "sure, go ahead"), so I can get a reliable benchmark of what we think about it. //Torxed [archinstall#4447]: https://github.com/archlinux/archinstall/pull/4447 [1]: https://github.com/archlinux/archinstall/discussions/4075 [6338e71]: https://github.com/archlinux/archinstall/commit/6338e7116ef5405cd9b97f066e4…

6 8

Arch Linux now has a bit-for-bit reproducible Docker image
by Robin Candau 20 Apr '26

20 Apr '26

Hey everyone, As a follow-up to the related milestone achieved for our WSL image a few months ago [1], I'm proud to announce that Arch Linux now has a bit-for-bit reproducible Docker image! This bit-for-bit reproducible image is distributed under a new "repro" tag [2]. This is due to one important caveat: to ensure reproducibility, the pacman keys have to be stripped from the image, meaning that pacman is not usable *out of the box* in this image. Users will need to (re)generate the pacman keyring (by running `pacman-key --init && pacman-key --populate archlinux`) before being able to update the system and install packages via pacman. While waiting to find a suitable solution to this technical constraint, we are therefore providing this reproducible image under a dedicated tag as a first milestone. The bit-for-bit reproducibility of the image is confirmed by digest equality across builds (`podman inspect --format '{{.Digest}}' <image>`) and by running `diffoci` [3] to compare builds. We provide documentation on how to reproduce this Docker image [4] (as we did for the WSL image as well [5]). Building the base rootFS for the Docker image in a deterministic way was the main challenge, but it reuses the same process as for our WSL image [6] (as both share the same rootFS build system). The main Docker-specific adjustments include: - Set `SOURCE_DATE_EPOCH` and honor it in the `org.opencontainers.image.created` LABEL in the Dockerfile - Remove the ldconfig auxiliary cache file (which introduces non-determinism) from the built image in the Dockerfile - Normalize timestamps during `docker build` / `podman build` using the `--source-date-epoch=$SOURCE_DATE_EPOCH` and `--rewrite-timestamp` options. You can check the related change set in our archlinux-docker repository [7] for more details. This represents another meaningful achievement in our "reproducible builds" efforts and we’re already looking forward to the next step! [1] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [2] https://hub.docker.com/layers/archlinux/archlinux/repro [3] https://github.com/reproducible-containers/diffoci [4] https://gitlab.archlinux.org/archlinux/archlinux-docker/-/blob/master/REPRO… [5] https://gitlab.archlinux.org/archlinux/archlinux-wsl/-/blob/main/REPRO.md [6] https://gitlab.archlinux.org/archlinux/archlinux-wsl/-/commit/7c0340e263580… [7] https://gitlab.archlinux.org/archlinux/archlinux-docker/-/merge_requests/96… -- Regards, Robin Candau / Antiz

1 0

postfix-tlspol 1.9.0-1 pulled out of [extra-testing]
by Robin Candau 17 Apr '26

17 Apr '26

Hi all, postfix-tlspol 1.9.0-1 was pulled out of [extra-testing] as the package needs changes to work with the new upstream socket setup. A new version will be pushed to testing once we figured it out. Testing users can downgrade to the postfix-tlspol 1.8.27-1 package currently in [extra]. -- Regards, Robin Candau / Antiz

1 0

Spring cleanup '26
by Antonio Rojas 11 Apr '26

11 Apr '26

It's that time of the year 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 as 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 and/or unmaintained by upstream 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. archlinux-themes-slim axel b43-fwcutter banner beebeep byobu caja-actions clusterssh coolreader cutefish-screenshot djview dma dnsperf erlang-docs finch focuswriter gcdmaster gephi gobby gtksourceviewmm-docs hepmc hepmc-docs horst inadyn ipv6calc josm lhapdf libbobcat libmemcached-awesome libofa libxml++2.6-docs ls++ ltrace manuskript merkaartor mono-addins nginx-mod-vts nitroshare nrpe openui5 pam-krb5 pencil2d penguin-subtitle-player photoflare php-geoip php-legacy-geoip php-legacy-memcache php-memcache php-memcached polly purple-plugin-pack python-cpplint python-olm python-oset python-sphinxcontrib-bibtex python-sphinxcontrib-spelling python-virtualenvwrapper qjournalctl qnapi quilt radcli reactphysics3d reactphysics3d-docs remind rhino-javadoc rofi-pass slim-themes splix sysdig tinyemu ukui-notification-daemon vim-seti volumeicon wakatime xbindkeys xfce4-artwork xfce4-datetime-plugin xfwm4-themes xplot

4 6

Update on Valve sponsored work in Q1 2026
by Sven-Hendrik Haase 08 Apr '26

08 Apr '26

Hi all, here is a quick progress report on Valve sponsored work in Q1 2026. We figured quarterly reports is a good cadence. ## Signstar - Milestones have been added and adjusted to contain work items for the proposed steps described in [RFC 0059]. - We have split out the mkosi-based image-building setup to the separate [Signstar-OS GitLab] repository. - In a [milestone for YubiHSM2 support] we track the remaining work required to automate the use of a YubiHSM2 as backend with Signstar - In this context we have rewritten the configuration layer, to accommodate several backends and are still busy with a few places to refactor for this larger change. - Improvements to the project's task running integration have been made to simplify this for direct use and CI. - We fixed a couple of bugs in the YubiHSM library (`yubihsm.rs`). - A small proof-of-concept has been designed and implemented for encryption and decryption of Yubico backup format, including parsing and wrapping ed25519 signing keys, AES-128 authorization keys and opaque data. The backup format is compatible with Yubico's own tools. Work is under way to expose these features as a CLI tool. - In a [milestone for a virtualized test setup] we are working towards creating a public environment that can be used by interested developers and package maintainers for test purposes and will at the same time serve as a long-term staging environment for automated updates. Generally, you can follow our work on the [Signstar GitLab] and [Signstar-OS GitLab] projects. ## Buildbtw Following the concessions of the last progress report, we are happy to report that we're now back to full capacity. In the last report, we announced that we had started work on the production version of buildbtw. By now, we have migrated most of the code from the PoC into the new production version and done most of the production-readiness work we set out to do. In contrast to the PoC, all the new production code is reviewed in-depth, documented, and well-tested. - Continuous deployment for review, staging and production environments ([buildbtw-archlinux-org]) - Keycloak roles are automatically mapped to buildbtw roles for permission management - Build graph calculation, diffing, and persistence - GitLab Executor running builds in vmexec and uploads artifacts - vmexec fixes, features, and a lot of testing - Modern responsive web UI - Session management & API keys - Parallel repo updater/cloner Next steps and in-progress work: - Nice bbtw CLI with good developer experience - API docs - Finish up pipeline scheduling - Separate out the repo-updater crate into its own project - Deploy the GitLab Executor As always, you can follow us over at GitLab [gitlab-buildbtw] and specifically the current milestone [buildbtw-milestone]. ## Meeting Notes Meeting notes are available for staff in the [internal-notes] repository. [RFC 0059]: https://rfc.archlinux.page/0059-automated-digital-signing-of-os-artifacts/ [Signstar GitLab]: https://gitlab.archlinux.org/archlinux/signstar [Signstar-OS GitLab]: https://gitlab.archlinux.org/archlinux/signstar-os [buildbtw-archlinux-org]: https://buildbtw.archlinux.org/ [buildbtw-milestone]: https://gitlab.archlinux.org/archlinux/buildbtw/-/milestones/10 [gitlab-buildbtw]: https://gitlab.archlinux.org/archlinux/buildbtw/-/boards/24162 [internal-notes]: https://gitlab.archlinux.org/archlinux/internal-notes/-/tree/main/valve [milestone for a virtualized test setup]: https://gitlab.archlinux.org/archlinux/signstar/-/milestones/6 [milestone for YubiHSM2 support]: https://gitlab.archlinux.org/archlinux/signstar/-/milestones/12

1 0

RFC: Boot standardization and bootchain package
by Morten Linderud 07 Apr '26

07 Apr '26

Yo, A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/66 Please visit the above link for discussion. Summary: Standardize and unify the Arch Linux boot chain with `kernel-install` and the `bootchain` package. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

News draft: kea >= 1:3.0.3-2 update requires manual intervention
by Robin Candau 05 Apr '26

05 Apr '26

Hi everyone, Our Kea (ISC's DHCP server) package is moving to a non-root setup to run services for improved security. This implies a manual intervention for users upgrading from an existing installation. See the news draft below (pad available at https://md.archlinux.org/1TykcWc0TPaz3MAuwfm9Fw) --- Starting with `kea 1:3.0.3-2`, all kea services now run as a dedicated non-privileged `kea` user (instead of `root`) for improved security. This change requires a manual intervention for users upgrading from `kea` <= `1:3.0.3-1` to >= `1:3.0.3-2`, in order to update the permissions and ownership of the kea files and directories accordingly. After upgrading, run the following commands to update permissions and ownership of kea files and directories, then restart the affected services (if they are running): ```bash chmod 755 /etc/kea/{,radius} /usr/include/kea/{,asiodns,asiolink,cc,config,config_backend,cryptolink,d2srv,database,dhcp,dhcp_ddns,dhcpsrv,dhcpsrv/parsers,dns,eval,exceptions,hooks,http,log,log/interprocess,mysql,pgsql,process,process/cfgrpt,stats,tcp,util,util/encode,util/io} /usr/lib/kea/{,hooks} /usr/lib/python3.14/site-packages/kea/{,__pycache__/} /usr/share/kea/{,api,meson-info,scripts,scripts/mysql,scripts/pgsql} chmod 644 /etc/kea/*.conf /etc/kea/radius/* chown kea: /var/lib/kea/* /var/log/kea/* /run/lock/kea/logger_lockfile systemctl try-restart kea-ctrl-agent.service kea-dhcp{4,6,-ddns}.service ``` If necessary, you can run `pacman -Qkk kea` to find any other permission deviations and adjust as needed. --- -- Regards, Robin Candau / Antiz

1 1

cryptsetup 2.8.5-1 pulled from core-testing
by Christian Hesse 02 Apr '26

02 Apr '26

Hello everybody, I pushed a bad package of cryptsetup to core-testing. Pulled it from the repository after just 72 seconds... Anyway - if you managed it install it please downgrade to the last stable version still in core. Already reported the issue: https://gitlab.com/cryptsetup/cryptsetup/-/work_items/984 -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 0

News draft: iptables now defaults to the nft backend
by Felix Yan 02 Apr '26

02 Apr '26

The old iptables-nft package name is replaced by iptables, and the legacy backend is available as iptables-legacy. When switching packages (among iptables-nft, iptables, iptables-legacy), check for .pacsave files in /etc/iptables/ and restore your rules if needed: - /etc/iptables/iptables.rules.pacsave - /etc/iptables/ip6tables.rules.pacsave Most setups should work unchanged, but users relying on uncommon xtables extensions or legacy-only behavior should test carefully and use iptables-legacy if required. -- Regards, Felix Yan

1 0

util-linux v2.42 pre-releases
by Christian Hesse 01 Apr '26

01 Apr '26

Hello everybody, Karel Zak has pushed the first util-linux pre-release for the upcoming v2.42 release. Please see the NEWS [0] for details. As announced in the PKGBUILD [1] I have prepared packages and pushed them to my personal testing repository. Have a look at this if you are brave and want to have a first look. Happy testing! [0] https://github.com/util-linux/util-linux/blob/stable/v2.42/NEWS [1] https://gitlab.archlinux.org/archlinux/packaging/packages/util-linux/-/blob… -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 2

HEADS UP: Qt 6.11 in testing
by Antonio Rojas 23 Mar '26

23 Mar '26

As usual, this means the anything compiled against it will automatically depend on it so will have to stay in testing until Qt itself moves. With 6.11, besides the usual private API changes, there is an additional potentially breaking change due to a QWayland native interface version bump. The symptoms may vary from programs not starting to subtle bugs, but the issue can be easily identified by the message "warning: Native interface revision mismatch (requested 1 / available 2) for interface QWaylandApplication" printed in the application's logs. Unfortunately, it is not easy to figure out in advance which applications will be affected. So please test Qt applications thoroughly, and if you notice an affected one, rebuild it with Qt 6.11 in testing and add it to the todo list https://archlinux.org/todo/additional-qt-611-rebuild/[1] to make sure it's moved to stable along with Qt. -------- [1] https://archlinux.org/todo/additional-qt-611-rebuild/

1 0

Removal of remaining packages signed by 86CFFCA918CF3AF47147588051E8B148A9999C34
by David Runge 20 Mar '26

20 Mar '26

Hi all, a rebuild of the remaining packages signed by Evangelos Foutras has been started in January[1]. It unfortunately still has six remaining packages: - dosemu - icoutils - libcdaudio - netperf - tsocks - wipe None of the above are used by other packages (any longer) and fail to build (for various reasons) and are mostly just extremely old/unmaintained pieces of software. To not block the revocation of the certificate [2] further I suggest to remove those remaining packages from the repositories. If you intend to keep any of the above packages in the repositories, please fix and rebuild them before 2026-03-22. I will move any remaining packages to the AUR on that day. Best, David [1] https://archlinux.org/todo/rebuild-packages-signed-by-86cffca918cf3af471475… [2] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/314

3 2

systemd v260 pre-releases
by Christian Hesse 17 Mar '26

17 Mar '26

Hello everybody, the systemd development team has pushed the first pre-release for the upcoming v260 release. Please see the NEWS [0] for details. As announced in the PKGBUILD [1] I have prepared packages and pushed them to my personal testing repository. Have a look at this if you are brave and want to have a first look. Happy testing! [0] https://github.com/systemd/systemd/blob/v260-rc1/NEWS [1] https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/blob/ma… -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 2

Stepping down as Arch Linux Packager
by kgizdov＠archlinux.org 15 Feb '26

15 Feb '26

Dear all, After careful consideration, I have decided to step down from my role as an Arch Linux Packager. Over the past months I have not been able to maintain the level of activity and responsiveness that this role requires. I made several attempts to reorganize my schedule and return to consistent contributions, but it has become clear that I cannot currently dedicate the time and focus that Arch deserves. I believe it is more responsible to step aside. It has been a privilege to contribute to Arch and to work alongside such a competent and principled team. The standards we uphold are something I deeply respect. This is not a farewell to the project itself. I hope to return to an active Packager role in the future when I can commit the time and energy it deserves. Thank you all for the collaboration, the discussions, the memories, and the shared commitment to keeping Arch on the edge. Best regards, Konstantin Gizdov

5 4

glibc 2.43 in testing - moving to stable repos affected
by Frederik Schwan 10 Feb '26

10 Feb '26

I've pushed glibc 2.43 to testing. Do not move packages linked against 2.43 to extra or core until glibc itself moves around Thursday/Friday. Otherwise the package will probably break. Best regards, Frederik

1 0

radicale 3.6.0-1 pulled from extra-testing
by Jakub Klinkovský 09 Feb '26

09 Feb '26

Hi, the radicale 3.6.0-1 package has been pulled from extra-testing. If you have upgraded, downgrade to the version available in extra. The reason is that the new version strictly requires python-bcrypt < 5.0.0 *or* the "libpass" fork of python-passlib. Since we already have python-bcrypt 5.0.0, we need to wait until we can package libpass in our repositories: https://github.com/notypecheck/passlib/issues/11 Jakub

1 0

Guidelines for reproducible Go binaries (2026)
by kpcyrd 04 Feb '26

04 Feb '26

hello, I joined as co-maintainer for syft after the recent todo item[1] and modernized the PKGBUILD. Based on the repro-get package[2] (which did reproduce successfully) I've changed the syft build instructions to this: ``` export CGO_CPPFLAGS="${CPPFLAGS}" export CGO_CFLAGS="${CFLAGS}" export CGO_CXXFLAGS="${CXXFLAGS}" export CGO_LDFLAGS="${LDFLAGS}" export CGO_REQUIRED="1" mkdir -p build go build \ -o build/ \ -buildmode=pie \ -mod=readonly \ -ldflags "-compressdwarf=false -linkmode=external -X main.version=${pkgver}" \ ./... ``` This did not reproduce in our verification system however: ``` │ ├── usr/bin/syft │ │┄ File has been modified after NT_GNU_BUILD_ID has been applied. │ │ ├── readelf --wide --notes {} │ │ │ @@ -1,16 +1,16 @@ │ │ │ │ │ │ Displaying notes found in: .note.gnu.property │ │ │ Owner Data size Description │ │ │ GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: x86 ISA needed: x86-64-baseline │ │ │ │ │ │ Displaying notes found in: .note.gnu.build-id │ │ │ Owner Data size Description │ │ │ - GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: 5d4cf47367358962632d3bfd04530c513f897790 │ │ │ + GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: dd9283dbad8ad8c4b742f7ac88f6a0e1f3b9acc1 │ │ │ │ │ │ Displaying notes found in: .note.go.buildid │ │ │ Owner Data size Description │ │ │ - Go 0x00000053 GO BUILDID description data: 42 49 56 6f 41 61 39 67 43 50 4e 49 6e 37 70 49 55 2d 76 64 2f 5f 6b 4a 66 6e 31 37 68 6e 4b 42 65 42 66 62 6f 39 74 4d 4b 2f 59 39 66 41 33 4d 74 7a 69 66 56 71 4b 4a 42 42 68 78 7a 57 2f 42 50 73 44 75 79 76 55 49 4c 37 30 47 37 73 6e 67 6a 55 73 │ │ │ + Go 0x00000053 GO BUILDID description data: 50 44 71 65 63 37 36 71 30 4e 52 69 4b 36 69 57 63 31 73 52 2f 5f 6b 4a 66 6e 31 37 68 6e 4b 42 65 42 66 62 6f 39 74 4d 4b 2f 59 39 66 41 33 4d 74 7a 69 66 56 71 4b 4a 42 42 68 78 7a 57 2f 73 6a 72 50 70 62 38 39 32 41 4c 48 4e 62 6c 4d 72 75 4d 46 │ │ │ │ │ │ Displaying notes found in: .note.ABI-tag │ │ │ Owner Data size Description │ │ │ GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag) OS: Linux, ABI: 4.4.0 │ │ ├── strings --all --bytes=8 {} │ │ │ @@ -1,8 +1,8 @@ │ │ │ -BIVoAa9gCPNIn7pIU-vd/_kJfn17hnKBeBfbo9tMK/Y9fA3MtzifVqKJBBhxzW/BPsDuyvUIL70G7sngjUs │ │ │ +PDqec76q0NRiK6iWc1sR/_kJfn17hnKBeBfbo9tMK/Y9fA3MtzifVqKJBBhxzW/sjrPpb892ALHNblMruMF │ │ │ /lib64/ld-linux-x86-64.so.2 │ │ │ __libc_start_main │ │ │ __cxa_finalize │ │ │ __vfprintf_chk │ │ │ sigfillset │ │ │ pthread_sigmask │ │ │ pthread_attr_init │ │ ├── readelf --wide --decompress --hex-dump=.gnu_debuglink {} │ │ │ @@ -1,4 +1,4 @@ │ │ │ │ │ │ Hex dump of section '.gnu_debuglink': │ │ │ - 0x00000000 73796674 2e646562 75670000 ca77ec4e syft.debug...w.N │ │ │ + 0x00000000 73796674 2e646562 75670000 6b0247ba syft.debug..k.G. ``` From what I understand both build IDs are hashes over other parts of the binary. Since they are the only difference though, the problem is likely in the debug symbols that get detached after the compile (and also after this hashing is done), but before diffoscope is executed on the final release artifact. Our guidelines for Go[3] mention the -trimpath option (which I forgot to add, but also wasn't necessary for repro-get), but since we have normalized paths in our build containers I'm not sure if the claim about Reproducible Builds applies to non-AUR packages? Using the data from reproducible.archlinux.org, there's currently 371 packages that depend on our Go package and have some kind of status attached to it: % rg -c GOOD resolved-go.txt 240 % rg -c BAD resolved-go.txt 131 Which is about ~65% In comparison, although many packages still use the `rustc --print` approach, our Rust build instructions essentially boil down to: ``` cargo fetch --locked --target host-tuple cargo build --frozen --release ``` Those two commands with no further manually set environment variables gets us: % rg -c GOOD resolved-rust.txt 669 % rg -c BAD resolved-rust.txt 86 Which is ~89% Although 20 percent-points doesn't seem like that much, it's a difference of "every 1 out of 3" vs "every 1 out of 10". Is there anything we can do to improve this overall situation? Both the amount of complexity necessary to compile a simple binary, as well as the reproducible build success ration? Maybe we could have something like /etc/makepkg.conf.d/rust.conf but for Go? cheers, kpcyrd [1]: https://archlinux.org/todo/rebuild-packages-signed-by-anatolik-morganamilo-… [2]: https://gitlab.archlinux.org/archlinux/packaging/packages/repro-get/-/blob/… [3]: https://wiki.archlinux.org/title/Go_package_guidelines

2 5

RFC Final Comment Period: "buildbtw build service"
by Rafael Epplée 03 Feb '26

03 Feb '26

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/63 Please visit the above link for discussion. Summary: """ This RFC proposes a first vertical slice of a build service to streamline rebuilding packages with many reverse dependencies. It tackles problems like repetitive manual work, blocking staging repositories, missed reverse dependencies and lack of shared context, like build logs. Goals include automating rebuilds and build ordering, enabling unattended builds, and providing isolated repos for parallel work. Builds run in secure virtual machines via a GitLab executor, organized into namespaces with histories and automatic dependency graphs. Interaction happens through CLI (pkgctl) and a web UI with SSO. """

1 1

First step for non-x86_64 contributions
by Levente Polyak 27 Jan '26

27 Jan '26

# First step for non-x86_64 contributions Hey everyone, I'd like to share my view on the first step for targeting non-x86_64 architectures in our packages. While our official infrastructure for non-x86 support isn't ready yet and will still take some time to materialize, I'd very much like to avoid siting on our hands until that day comes. There's already a ton of community interest and effort around non-x86_64. There's plenty of low hanging fruits and clean patches that are easy to review, well contained, and good groundwork. So instead of waiting for the perfect day before starting, I'd like to open the door to small, clear, and non intrusive contributions under tightly scoped rules. We should rather slowly and carefully build up compatibility now, than scramble once infra, hardware and tooling catches up. I propose the following guidelines as a first step towards implementing [RFC0032](https://rfc.archlinux.page/0032-arch-linux-ports/). ## Guidelines ### Protecting x86_64 We do not want to compromise on our primary platform. Clearly do not break or remove x86_64 behavior, functionality or features. Incompatible features or dependencies must be proposed in a way that preserves the functionality of our primary platform. ### Non-intrusive Small, focused changes that are easy to understand at a glance and can be reasoned about even without building and running it on different architectures. ### No downstream wizardry Complex, opaque, or heavy software patching is out of scope. Carrying around massive software patches downstream isn't feasible at this stage, save that for later and work together with upstream instead. ### Merge-request indicator All secondary architecture related merge-requests must be flagged with the new `pkg::ports` GitLab label. It'll help separate them from the usual requests and allow interested packagers and contributors to filter on them globally, to help out others. ### Manageable load Contributors must stick to small merge-request batches max 10 open MRs per person. All proposals must be sent manually, no fire-and-forget scripts. Collaboration is expected. If questions come up, we expect thoughtful responses from people who precisely know the changes they're submitting. ## Out of scope ### arch array No changes to `arch=()` arrays. ### non-x86_64 issues No issues or bug reports for non-x86_64. If something's broken with the `PKGBUILD`, you'll need to sort it out and send a merge-request. Don't file bugs in the tracker for other architectures. --- This approach allows us to slowly build up compatibility and make good progress without burning out our packagers and bug-wranglers or flooding our GitLab with changes and bug reports we can't handle. We can stretch out the work by allowing confined changes and avoid to stack it all for later. It gives us room to prepare without needing full build infrastructure, provide active support or require special hardware in place today. I think this really hits the right balance, tight enough to avoid burnout, open enough to make progress and welcoming enough to motivate and start harvesting work from our community. Cheers, Levente

9 14

Adding Christian Heusel as new main signing key holder
by David Runge 25 Jan '26

25 Jan '26

Hey all, for a while now we are short one active main signing key [1]. Traditionally, we have selected new main signing key holders from the list of developers. During Arch Linux summit 2025 we have been discussing this topic and brought forth the idea of selecting main signing key holders generally from the larger group of active staff instead. After a short discussion on the arch-dev mailing list, we received generally positive responses. As such, we are adding Christian Heusel as new main signing key holder [2] and Robin Candau as his revoker. His certificate has the OpenPGP fingerprint `99B6618472A3B3B814185BAED7D3D823B88BDB9B` and will be added to the archlinux-keyring. Best, David [1]: https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/269 [2]: https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/313 -- https://sleepmap.de

1 0

FOSDEM 2026 Dinner
by Robin Candau 24 Jan '26

24 Jan '26

Hi everyone, As usual, a few members of the Arch Linux team will be present at FOSDEM [1] this year. 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! 🙂 It will be held Saturday, January 31 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 20 people. Priority for members of the Arch staff. Any free spots after this can be taken by anyone interested. Please, send an email *offlist* to me [2] and Rafael [3] if you want to attend. The community 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. 🙂 [1] https://fosdem.org/2026/ [2] antiz(a)archlinux.org [3] raffomania(a)archlinux.org -- Regards, Robin Candau / Antiz

1 1

Arch Linux at FOSDEM 2026
by Robin Candau 22 Jan '26

22 Jan '26

Hi everyone, Members of the Arch Linux staff have historically always attended FOSDEM and this year is no different! A few of our staff members will be present at FOSDEM 2026. As always, we will try to settle down somewhere in the cantina so people can meet us (and also get some goodies 🤫). As last year, we will also hold an Arch Linux user meetup / BoF [1]! This BoF session will give a status update on the distribution, adjacent projects and future plans. There will be a short presentation followed by a Q&A session with Arch Linux distribution maintainers and project developers. Some of our staff members are also giving talks: - Rafael Epplée (raffomania): Federated Bookmark Sharing [2] - Robin Candau (Antiz): Relying on more transparent & trustworthy sources for Arch Linux packages [3] Finally, there's a "Reproducible Builds" meetup / BoF [4] to which some of us will participate or attend to as well. We wish everyone a good FOSDEM and we're looking forward to meet some of you there! 🤗 [1] https://fosdem.org/2026/schedule/event/LMBYTE-arch-linux-meetup-bof/ [2] https://fosdem.org/2026/schedule/event/YAMEDX-federated_bookmark_sharing/ [3] https://fosdem.org/2026/schedule/event/FFWA7E-transparent-sources-for-arch-… [4] https://fosdem.org/2026/schedule/event/8ETZS3-reproducible_builds_meetup/ -- Regards, Robin Candau / Antiz

1 0

Please finish the package license todo-list
by Jelle van der Waa 20 Jan '26

20 Jan '26

Hi all, The Python rebuild is off to a bit of a rocky start with ~ 100 packages which fail `pkgctl license check`. Please help complete this todo so we can keep rebuilding. [1] https://archlinux.org/todo/make-packages-license-compliant/

2 1

Changes in pacman-mirrorlist package regarding HTTP mirrors
by pitastrudl 17 Jan '26

17 Jan '26

Hi all, A week ago or so [1] a change in the pacman-mirrorlist package was merged, where we removed listings of HTTP based mirror URLs so only HTTPS based mirrors remain in the newly released pacman-mirrorlist package. To further clarify, this does not translate to making HTTP based mirrors unsupported, they are still available on the mirrorlist[2] endpoint that is used by other mirrorlist fetching tools like reflector. Best regards, Arun Mirrorlist team [1]https://gitlab.archlinux.org/archlinux/packaging/packages/pacman-mirrorli… [2]https://archlinux.org/mirrorlist/

2 1

p11-kit pulled from testing
by Jan Alexander Steffens (heftig) 16 Jan '26

16 Jan '26

I've removed p11-kit 0.26.0-1 from testing as it causes Firefox to distrust all the system CAs, failing to connect. This concerns the following packages: - libp11-kit - p11-kit - p11-kit-docs - lib32-p11-kit Please downgrade these packages to the last release (0.25.10-2) if you've upgraded already.

1 0

Bumpbuddy: New dashboard and features
by Robin Candau 15 Jan '26

15 Jan '26

Hi everyone, Last summer, we introduced bumpbuddy [1], a daemon watching for new upstream releases for our packages. Bumpbuddy offers a centralized and automated way for tracking and reporting new upstream release for our Package Maintainers; also providing a public place (in the form of GitLab issues [2]) for anyone to discuss the state of a pending package update, allowing for more transparency in the process. Since the initial introduction published a few months ago, bumpbuddy got a fair amount of new features & releases, so we thought it might be a good time for a follow-up! ## Dashboard Bumpbuddy's data are now publicly exposed and reported on a dedicated web dashboard [3]. This dashboard allows anyone to visualize and search through the state of monitored packages. Here are the list of the reported parameters: - Package: The package name. - Local version: The current version of the package in our GitLab package repositories. - Upstream version: The latest upstream version for the package reported by bumpbuddy. - Up to date: "Up to date" status of the package. - ✅ = Up to date - ❌ = Out of date - ⚠️ = Bumpbuddy is not able to determine the latest upstream release (due to nvchecker failures) - Issues: Link to the GitLab issue reporting the "out of date" status of a package and / or repeated nvchecker failures. - Last check: Time and date of the last check for the package. ## Report of repeated nvchecker failures As mentioned in the dashboard paragraph, bumpbuddy now also reports repeated nvchecker failures (after a specific threshold) through GitLab issues [4]. This allows to keep track and investigate eventual faulty nvchecker configurations preventing bumpbuddy to properly detect new upstream releases. Once the issue is fixed (and if not done already); such issues are automatically closed by bumpbuddy itself at the next run [5]. ## New dedicated issue labels To allow for more fine grained classification of the opened GitLab issues, the `scope::out-of-date` label was replaced by `package::out-of-date`, so that the reported upstream release can be further classified (e.g. with `scope::security` or `scope::bug`). Following the same pattern, issues for repeated nvchecker failures are labelled with `package::nvchecker` and `scope::bug`. ## General improvements and fixes Various improvements and fixes have been added, including: - Error handling for API calls, avoiding unexpected duplicate issues. - Continious update of the API data, to ensure up to date data for consumers. - Improvements of the pkgbases to GitLab path names conversion (so that e.g. the `bonnie++` pkgbase is correctly converted to `bonnieplusplus` in the GitLab path name). - Update opened GitLab issues on local package version changes (and not only on upstream version changes). - Deletion of the automated comment when updating an opened issue (as it globally ended up as extra "noise"). ## Work in progress We have some work in progress regarding our future goals, most notably: - pkgctl: Automatically close 'out-of-date' issue when releasing a new package version [6], allowing for an instant closing of 'out-of-date' issues when the matching (or a newer) version is being pushed (as compared to today where issues are only closed at the next bumpbuddy run), and generally reducing the extra "noise" cause by the multiple notifications when an issue is being closed by bumpbuddy. - archweb: import bumpbuddy data [7], getting closer to our future goal of replacing the current "Flag Package Out-of-Date" manual button by automated bumpbuddy reports. Further work regarding additional future goals will follow! Huge thanks to klausenbusk, anthraxx and jelle for their amazing work on those new features, improvements and ongoing efforts! [1] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [2] https://gitlab.archlinux.org/archlinux/packaging/packages/python-fastapi/-/… [3] https://bumpbuddy.archlinux.org/ [4] https://gitlab.archlinux.org/archlinux/packaging/packages/schroot/-/issues/1 [5] https://gitlab.archlinux.org/archlinux/packaging/packages/schroot/-/issues/… [6] https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/338 [7] https://github.com/archlinux/archweb/pull/598 -- Regards, Robin Candau / Antiz

1 0

new unstable repositories
by Christian Hesse 06 Jan '26

06 Jan '26

Hello everybody, for some time I used to push rc release for some packages (namely systemd & util-linux) to core-testing. This broke once, when a package was built against that rc release and thus did depend on new symbols, then finally was moved before the package it was built against. After that I pushed all the rc releases to a public personal repository, anybody interested could test from there. But I think the audience was a lot smaller, and last systemd release revealed some unexpected regressions *after* final release. That situation is not any better, especially when rc releases in Arch were a major factor in finding regressions early. At Arch Summit 2025 we had a chat about that situation and discussed several ideas. In the end we came up with one reasonable solution: We should introduce new repositories [core-unstable] and [extra-unstable] for this kind of testing. People would still have to enable these repositories, but I guess chances are higher than for my personal repository. I guess we have three places that need to be touched: * create repositories on servers (-> DevOps) * dbscripts * devtools Anything more? Feedback is welcome, same for other ideas - this is not set in stone and I am open for anything that works for me/us. Thanks! -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

7 19

Adding the Mediation Team as Code of Conduct body for staff
by gromit 03 Jan '26

03 Jan '26

Hello everyone, I wanted to bring some attention to [this merge request][0], in order to gather feedback on the contained proposal and to follow the established process for making changes to the code of conduct. The underlying motivation for this request has been that I always felt that we as mediators were elected make sure that everyone keeps enjoying to contribute their free time to the Arch Linux projects and finds themselves in a welcoming and fun environment if they decide to do so. In order to get achieve this we started to take two types of actions: - Reactive: As specified in the [RFC!0009] the mediation team can be queried to settle disputes and newly establish previously lost trust between two parties that clashed over personal or other matters. - Proactive: Whenever people act in a manner that is detrimental to the atmosphere in the project or not constructive to a specific discussion we tried to intervene in order to have everyone be nice to each other again and to allow everyone to focus on the actual issues being discussed. Reflecting on some of the instances where we tried to proactively moderate a discussion we realized in the team that we don't have much options beyond a "hey please don't do that" and for example can't formally warn people if their conduct stays unchanged. This is unless there is a failed mediation (see the RFC for details on that) which in itself is an involved process and requires some other party to request mediation, which is not sensible for all kinds of situations. The resulting proposal therefore is that we as a mediator team assist the project leader for code of conduct related topics concerning Arch Linux staff itself. The process mentioned in the beginning of this mail defines a 14-day discussion period, but given that a lot of people are currently on vacation and might not neccesarily pay attention to their email it's fair to extend this by another week to the 13th January. If you have any feedback this is very much welcome, lets discuss it on the merge request! Cheers, Christian / gromit P.S.: I wish everyone a merry christmas if you celebrate it and a few refreshing days with friends, family and hopefully lots of nice food over new year! [0]: https://gitlab.archlinux.org/archlinux/service-agreements/-/merge_requests/… [1]: https://rfc.archlinux.page/0009-mediation-program/

2 2

News draft: NVIDIA 590 driver drops Pascal support; main packages switch to Open Kernel Modules
by Peter Jung 18 Dec '25

18 Dec '25

Hey all, Below you can find the news draft for the changes in the new 590 Driver. You can also find an explanation in this commit: https://gitlab.archlinux.org/archlinux/packaging/packages/nvidia-utils/-/co… With the update to driver version 590, the NVIDIA driver no longer supports Pascal (GTX 10xx) GPUs or older. We will replace the `nvidia` package with `nvidia-open`, `nvidia-dkms` with `nvidia-open-dkms`, and `nvidia-lts` with `nvidia-lts-open`. **Impact:** Updating the NVIDIA packages on systems with Pascal, Maxwell, or older cards will fail to load the driver, which may result in a broken graphical environment. **Intervention required for Pascal/older users:** Users with GTX 10xx series and older cards must switch to the legacy proprietary branch to maintain support: * Uninstall the official `nvidia`, `nvidia-lts`, or `nvidia-dkms` packages. * Install `nvidia-580xx-dkms` from the AUR Users with Turing (20xx and GTX 1650 series) and newer GPUs will automatically transition to the open kernel modules on upgrade and require no manual intervention. Best regards, Peter

1 0

systemd v259 pre-releases
by Christian Hesse 18 Dec '25

18 Dec '25

Hello everybody, the systemd development team has pushed the first pre-release for the upcoming v259 release. Please see the NEWS [0] for details. As announced in the PKGBUILD [1] I have prepared packages and pushed them to my personal testing repository. Have a look at this if you are brave and want to have a first look. Happy testing! [0] https://github.com/systemd/systemd/blob/v259-rc1/NEWS [1] https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/blob/ma… -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 3

The Arch Linux WSL image is now reproducible
by Robin Candau 17 Dec '25

17 Dec '25

Hi everyone, Allow me to share a great milestone we've been able to recently reach: Our WSL image [0] is now bit-for-bit reproducible [1]! Here is a quick sum up of the issue we faced and the fixes we applied for them: ----- ## Installing packages from an archived repo snapshot To ensure that the same exact versions / releases of packages get installed in the image across builds, we defined an archived snapshot of our repositories (via our "Arch Linux Archive" service [2][3]) as the source to download packages during build. The date for the daily archived repo snapshot is based against the version of the built image (which is date based). The same date is also used as the `SOURCE_DATE_EPOCH` (SDE) timestamp (see below points for SDE usage). ## Normalize filesystem `mtimes` with SDE With SDE set in our build script, we normalized `mtimes` of the rootFS against it as a post-build operation to avoid non-deterministic timestamps on that front: ``` find "$BUILDDIR" -exec touch --no-dereference --date="@$SOURCE_DATE_EPOCH" {} + ``` ## Get rid of Pacman logs during build (timestamps recording) Pacman records each operation with the associated timestamp in its logfile (/var/log/pacman.log). Since we don't particularly need Pacman logs to be recorded during the image build, we redirected them to `/dev/null/`: ``` pacman \ [...] --logfile /dev/null \ [...] ``` ## Normalize packages' installation date in Pacman's local package DB Pacman records packages' installation date, resulting in non-deterministic timestamps recording in the metadata included in the local package database. Fortunately, Jelle van der Waa recently brought support in Pacman for honoring SDE on that front [4]. With the related commit being merged in our latest pacman package release, simply exporting SDE in our build script was enough to normalize packages' installation date in Pacman's local package database. ## Delete Pacman keyring Pacman OpenPGP keys (generated with `pacman-key`) implies non-deterministic data in the local Pacman keyring. Fortunately, WSL has a built-in "oobe" (Out Of the Box Experience) mechanism [5] that allows to automatically run a script at the first boot of the image. We therefore took advantage of this mechanism to completely delete the Pacman's keyring as a post-build operation and automatically recreate it at the first boot of the image via the "oobe" script (by running `pacman-key --init && pacman-key --populate archlinux` from it). ## Normalize tar's `mtimes` and ordering Our rootFS for the WSL image is archived with `tar`, to which we added a few options to normalize `mtimes` (against SDE) as well as ordering, in order to avoid non-determinism on that front: ``` tar \ [...] --mtime="@$SOURCE_DATE_EPOCH" \ --clamp-mtime \ --sort=name \ [...] ``` ## Delete tar's `atimes` / `ctimes` Finally, we got rid of tar's `atimes` / `ctimes` to avoid non-deterministic timestamps in the archive's metadata: ``` tar \ [...] --pax-option=delete=atime,delete=ctime \ [...] ``` ----- For more details, you can take a look at the related merge requests, respectively to test the image reproducibility from a dedicated GitLab CI stage [6] and to actually make the image reproducible (including all the above fixes) [7]. At the moment, the result of the dedicated CI stage verifying the image reproducibility is non-blocking for releasing, but we intend to make it mandatory soon (given that we achieved to maintain a full reproducibility until then). The additional good news is that, since it's built in a similar way, most of those fixes should also apply to our Docker image [8] as well ; with the exception of the Pacman keyring related issue which will need to be dealt with differently, somehow... (since, as far as I know, OCI images doesn't have any built-in / straightforward mechanism to run a script or commands automatically at first boot, like the WSL "oobe" mechanism). This represents a meaningful achievement regarding our global "reproducible builds" related efforts and is encouraging for future related work on our other releng images! [0] https://gitlab.archlinux.org/archlinux/archlinux-wsl [1] https://reproducible-builds.org/ [2] https://archive.archlinux.org [3] https://wiki.archlinux.org/title/Arch_Linux_Archive [4] https://gitlab.archlinux.org/pacman/pacman/-/commit/f4bdb77470528019aaba4d8… [5] https://learn.microsoft.com/en-us/windows/wsl/build-custom-distro#add-the-w… [6] https://gitlab.archlinux.org/archlinux/archlinux-wsl/-/merge_requests/74 [7] https://gitlab.archlinux.org/archlinux/archlinux-wsl/-/merge_requests/76 [8] https://gitlab.archlinux.org/archlinux/archlinux-docker -- Regards, Robin Candau / Antiz

1 0

GitLab behind Anubis
by Kristian Klausen 14 Dec '25

14 Dec '25

Hi all, To deflect yet another scraping attack against our GitLab instance, it has been hastily put behind Anubis. This may have broken stuff. Please reach out if notice anything that does not work, either by replying to this email or #archlinux-devops on IRC. Cheers, Kristian Klausen DevOps

1 0

Python 3.14 rebuild starting
by Jelle van der Waa 13 Dec '25

13 Dec '25

Hi all! Let's start the Python 3.14 rebuild as Christmas present for our users! This effectively means [staging] will be blocked for a longer period of time before everything is rebuild. I'll start after the hdf5 rebuild has been moved and will first bootstrap the build tooling (setuptools, flit, pytest, etc.). When that's done a todolist will be opened for all Python packages. Do note that there will be cycles which need to be broken up by building packages without tests first. Greetings, Jelle

1 0

Fwd: Looking for feedback on CONFIG_MODULE_HASHES for Linux
by Robin Candau 10 Dec '25

10 Dec '25

Hi everyone, As discussed during this year's Arch summit, Thomas is seeking help / support from projects that could benefit from his patch set which aims to enable reproducible kernel packages for Linux distributions (see the forwarded mail below). As far as I can tell, this is something we would be interested in. I think it would be nice if we could "officially" claim our interest as "Arch Linux" to hopefully provide some assistance to Thomas for his incoming discussion with upstream. Does any of the kernel packages maintainers on our side wants to jump in (or anyone else interested with some kernel knowledge, I guess)? -------- Forwarded Message -------- Subject: Looking for feedback on CONFIG_MODULE_HASHES for Linux Date: Thu, 13 Nov 2025 21:10:58 +0100 From: Thomas Weißschuh via rb-general <rb-general(a)lists.reproducible-builds.org> Reply-To: General discussions about reproducible builds <rb-general(a)lists.reproducible-builds.org> To: rb-general(a)lists.reproducible-builds.org CC: Thomas Weißschuh <thomas(a)t-8ch.de> Hi everyone, I am the author of the CONFIG_MODULE_HASHES patchset [0] for the Linux kernel which aims to enable reproducible kernel packages for Linux distributions. My goal is to reignite development and continue with the upstream process. To have a better base to argue with I'd like to get some confirmation that distributions have looked at the patches and do intent to adapt this scheme when it is available in the mainline kernel. That should help me get some leverage with the upstream maintainers. The current form of the patches can be found at [1], they are only slightly adapted from the previous submission to LKML. Remaining open topics before the next submission are proper IMA support and stripping of modules. Future changes may introduce more hash algorithms and performance improvements, but these should not be relvant for now. So if you are packaging Linux for your distribution, have looked at my patches and are eager to use them, please let me know. My plan is to talk with the upstream maintainers at the upcoming Linux Plumbers Conference on 11th of December. Thanks, Thomas [0] https://lore.kernel.org/lkml/20250429-module-hashes-v3-0-00e9258def9e@weiss… [1] https://git.kernel.org/pub/scm/linux/kernel/git/thomas.weissschuh/linux.git…

2 1

News draft: .NET packages may require manual intervention
by George Rawlinson 09 Dec '25

09 Dec '25

The following packages may require manual intervention due to the update from 9.0 to 10.0: * aspnet-runtime * aspnet-targeting-pack * dotnet-runtime * dotnet-sdk * dotnet-source-built-artifacts * dotnet-targeting-pack pacman may display the following error `failed to prepare transaction (could not satisfy dependencies)` for the affected packages. If you are affected by this and require the 9.0 packages, the following commands will update e.g. aspnet-runtime to aspnet-runtime-9.0: ```sh pacman -Syu aspnet-runtime-9.0 pacman -Rs aspnet-runtime ```

1 0

Archive repos snapshot changes
by Kristian Klausen 09 Nov '25

09 Nov '25

Hi all, We (DevOps) want to reduce [the I/O stress][1] on the archive server (archive.archlinux.org) by reducing the numbers of inodes (currently 55 millions). Most of these inodes (52,6 millions) originates from the daily snapshot (64k inodes) of the repositories. Going forward only the database files and the "sources" directory will be included in the snapshot (~120 inodes + ~2400 inodes for "sources") and all HTTP requests for package files will be redirected to the relevant package at https://archive.archlinux.org/packages/. E.g. https://archive.archlinux.org/repos/2025/11/02/core/os/x86_64/linux-6.17.6.… -> https://archive.archlinux.org/packages/l/linux/linux-6.17.6.arch1-1-x86_64.… Package files from existing snapshots will be removed at a later date. The "sources" directory will be removed at a later date, when a proper replacement is in place. If no concerns are raised before 2025-11-21 EOD, we will move forward with the changes. [1] All inodes must be traveresed for backup and hardlinking Cheers, Kristian Klausen DevOps

1 0

Dropping qt5-webengine
by Antonio Rojas 08 Nov '25

08 Nov '25

Hi, Qt5 is EOL since May. In particular, qt5-webengine's Chromium ships with unfixed vulnerabilities. Its code is bitrotting, which also makes it a costly package to maintain due to the frequent API changes in its dependencies (I had to give up on system ffpmeg and switch to its ancient bundled version, and currently doesn't build against ICU 78). I therefore think it's wise to drop it from our repos. Its remaining reverse dependencies are: csoundqt - can be built without it by disabling remote debugging support, MR at [1] fcitx-libpinyin - archived upstream for over a year globalprotect-openconnect - very out of date, a new version switching to wbkitgtk and rust is available in testing. kchmviewer - dead upstream (no activity in 4 years) qmc2 - dead upstream (no activity in 1.5 years) wiznote - dead upstream (no activity in 4 years) openshot - the only case of a (semi-)maintained application still unported to Qt6 - there was an attempt 3 years ago [2] aborted due to some drama and no signs of new efforts since then, porting is non-trivial. If there are no objections (that include an offer to pick up maintenance of the package), I will drop it and all its unported reverse dependencies in a few days. [1] https://gitlab.archlinux.org/archlinux/packaging/packages/csoundqt/-/merge_… [2] https://github.com/OpenShot/openshot-qt/pull/4836

3 3

GitLab unavailable at the moment
by Jelle van der Waa 05 Nov '25

05 Nov '25

Hi All, GitLab is experiencing some high load due to unknown reasons, devops is investigating. Expect issues when updating packages so maybe postpone them if you can. Greetings, Jelle

2 1

News Draft: waydroid >= 1.5.4-3 update may require manual intervention
by George Hu 05 Nov '25

05 Nov '25

The `waydroid` package prior to version `1.5.4-2` (including `aur/waydroid`) creates byte-compiled Python files (.pyc) at runtime which were untracked by pacman. This issue has been fixed in 1.5.4-3, where byte-compiling these files is now done during the packaging process. As a result, the upgrade may overwrite the unowned files created in previous versions. If you encounter errors like the following during the update: ``` error: failed to commit transaction (conflicting files) waydroid: /usr/lib/waydroid/tools/__pycache__/__init__.cpython-313.pyc exists in filesystem waydroid: /usr/lib/waydroid/tools/actions/__pycache__/__init__.cpython-313.pyc exists in filesystem waydroid: /usr/lib/waydroid/tools/actions/__pycache__/app_manager.cpython-313.pyc exists in filesystem ``` You can safely remove the conflicting files by running the following command before upgrading: ```sh find /usr/lib/waydroid/tools/ -type d -name __pycache__ -exec sudo rm -rf '{}' + ``` -- Best Regards, George Hu / Integral

4 5

mkinitcpio v40, packaging changes and kernel-install
by Morten Linderud 04 Nov '25

04 Nov '25

Yo, I'm dropping the new `mkinitcpio` v40 release into [core-testing] right after this email. Generally the changes are not super interesting, but we got a new build system with meson for this release. This has given us the option to enable and disable the default hooks for `mkinitcpio` during building. As a result I have made two packaging decisions! # Disabled fallback image creation for new installs. Generally they are not super useful and people that need them can enable them if they would like too. This is only affects new installs as we can't change the hook files on existing installs. # Switched over to `systemd` hooks by default. This is generally a change I think we should have done a long time ago. The systemd side of our initramfs is getting a lot of changes thanks to systemd moving the needle forward, however our busybox hooks are not getting any of these improvements and have generally stalled for years. I have swapped things over on our side, and will continue to maintain the busybox hooks upstream. Further release notes can be found here: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v40 # kernel-install Beyond this next on my todo is to see if we can move us wholesale away from the custom libalpm hooks we currently have to using `kernel-install`. This is going to make things much easier for us and users to swap between initrd and uki generators. It would also allow us to simplify our kernel installation and boot creation as we can probably automatically generate configs with hooks. I plan on writing a rough outline of my idea to arch-dev-public before doing a RFC, mostly because I haven't completely decided on how we would like to do this smoothly and people might have better ideas then me. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

News draft: dovecot >= 2.4 requires manual intervention
by Thore Bödecker 29 Oct '25

29 Oct '25

Hi folks, the upstream dovecot 2.4 branch comes with handful of breaking changes, mostly concerning configuration semantics and syntax. For this, upstream provides a migration guide [1]. We've kept dovecot 2.4.1 in [testing] for quite some time and it received a decent number of signoffs. There was already a bit of chatter on arch-general regarding the availability of a dovecot 2.4 package in [extra]. While slightly unintentional, I've built and pushed todays upstream release version 2.4.2 to [extra]. However, there is a feature disparity: the 2.4 branch no longer supports replication. My own setup relies on that particular feature and I've grown quite fond of it, so I'm a bit sad to see it going away. As per upstreams EOL announcement [2], the 2.3 branch is supposedly going to receive critical secrity fixes, which I considered "maintained enough" to warrant packaging it separately until upstream fully drops it. The following packages are now available in [extra]: - dovecot23 - pigeonhole23 - dovecot23-fts-elastic - dovecot23-fts-xapian Where applicable, they are configured with the necessary conflicts/provides. The most recent dovecot-2.4.2-3 build also contains the following dovecot.install notice: > ==> Dovecot 2.4 is incompatible with older configurations and requires manual intervention. > ==> Refer to 'https://doc.dovecot.org/latest/installation/upgrade/2.3-to-2.4.html' for upgrading instructions. > ==> Alternatively, there is a dovecot23 (and pigeonhole23) package available. Given the fact that any dovecot 2.4 binary *will not* start with a <= 2.3 configuration file, it seems reasonable for us to publish an announcement to make users aware of this situation while also informing them about the alternate 2.3 packages we provide. News draft below. ----8<---- # dovecot >= 2.4 requires manual intervention The dovecot 2.4 release branch has made breaking changes which result in it being incompatible with any <= 2.3 configuration file. Thus, the dovecot service will no longer be able to start until the configuration file was migrated, requiring manual intervention. For guidance on the 2.3-to-2.4 migration, please refer to the following upstream documentation: [Upgrading Dovecot CE from 2.3 to 2.4](https://doc.dovecot.org/latest/installation/upgrade/2.3-to-2.4.html) Furthermore, the dovecot 2.4 branch no longer supports their replication feature, it was removed. For users relying on the replication feature or who are unable to perform the 2.4 migration right now, we provide alternative packages available in [extra]: - dovecot23 - pigeonhole23 - dovecot23-fts-elastic - dovecot23-fts-xapian The dovecot 2.3 release branch is going to [receive critical security fixes](https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/threa… from upstream until stated otherwise. ---->8---- [1] https://doc.dovecot.org/latest/installation/upgrade/2.3-to-2.4.html [2] https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/3P45L… Cheers -- Thore "foxxx0" Bödecker GPG ID: 0xEB763B4E9DB887A6 GPG FP: 051E AD6A 6155 389D 69DA 02E5 EB76 3B4E 9DB8 87A6

1 0

Remove GTK2 from the official repositories
by Balló György 26 Oct '25

26 Oct '25

Hi all, I think we've reached the point when we can remove the very old GTK2 package from the official repositories. I recently dropped the GTK2 version of LXDE, and there are only a few applications left that still depend on GTK2: - alltray - amsynth - bless - calf - eq10q - gimp-nufraw - gkrellm - gpsim - gtk2fontsel - gtk-chtheme - hexchat - hexter - leafpad - mono-tools - nitrogen - nspluginwrapper - osdlyrics - parcellite - pidgin - sbxkb - trayer - xboard - xdialog - xlockmore Most of these have no active development a long time ago. If no one has objections, I'll drop these packages to AUR in the next days if it's not possible to build them without GTK2. Any opinion? -- György Balló Package Maintainer

2 2

New CDN based mirror now available: fastly.mirror.pkgbuild.com
by gromit 20 Oct '25

20 Oct '25

Hello everyone, we [have now setup][0][1] an additional option for a worldwide mirror: https://fastly.mirror.pkgbuild.com With the caching done by the Fastly CDN, the bandwidth speeds and time to first byte should be quite good all around the globe, especially as more and more people start using the service. Thanks a lot to Fastly for sponsoring us with free access to their services! This new mirror can be seen as an orthogonal approach to the already existing, also DevOps administered geomirrors, which will not be replaced by the CDN based mirror. Please check it out and [let us know][2] if you find any problems with it! Kind regards, Antiz, Pitastrudl and gromit [0]: https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/1031 [1]: https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/639 [2]: https://gitlab.archlinux.org/archlinux/infrastructure/-/issues

1 0

GHC 9.6.6 enters [extra-testing]
by Felix Yan 13 Oct '25

13 Oct '25

Hi all, The GHC 9.6.x updates have now entered [extra-testing]. This time, four packages have been retired, so please remove them manually if you have them installed: - haskell-configfile - haskell-monad-gen - haskell-monad-journal - haskell-success Again a special thanks to @Vekhir for helping me in preparing many batches of updates, including this one. Please let me know if you encounter any issues. Otherwise, the batch will be moved to [extra] in a few days. -- Regards, Felix Yan

1 0

New filesystem in core-testing with fully locked accounts
by David Runge 12 Oct '25

12 Oct '25

Hi all, please note, that filesystem 2025.10.12 in core-testing now features fully locked user accounts [1] based on the ongoing related TODO [2]. In case you run into any issues with those user accounts because of this, please report them as ticket on the package. Best, David [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/filesystem/-/comm… [2]: https://archlinux.org/todo/change-sysusers-to-fully-locked-system-accounts/

1 0

HEADS UP: Qt 6.10 in [extra-testing]
by Antonio Rojas 07 Oct '25

07 Oct '25

This is a reminder that anything compiled against 6.10 will automatically depend on it, so it will have to stay in testing until Qt itself moves.

1 0

arch-install-scripts v30
by Morten Linderud 27 Sep '25

27 Sep '25

Yo, I've cut a new release of arch-install-scripts ahead of next months ISO. Changes and features in the new release: * Removal of `DownloadUser` from `pacman.conf` in `pacstrap` to prevent errors where the `alpm` user does not have access to the given path. * `arch-chroot` now has a new flag, `-S`, which uses `systemd-run` under the hood. * Uses the new `X-mount.nocanonicalize=target` option from `util-linux` to mount symlinks. * `genfstab` now properly understand `zram` swap targets, and will ignore them. * `pacstrap` now respects all paths from `pacman.conf` when initializing a new chroot. * Shellcheck no longer makes complaints about the project. It's been pushed to `[testing]`. https://gitlab.archlinux.org/archlinux/arch-install-scripts/-/releases/v30 Cheers. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

ffmpeg 8.0 rebuild on hold
by Lukas Fleischer 24 Sep '25

24 Sep '25

Hi all, The ffmpeg 8.0 rebuild [1] overlaps with other pending rebuilds. Those rebuilds need to be completed and moved out of the staging repositories first. Please do not continue working on the ffmpeg rebuild until the other rebuilds are completed. We'll send an update once things are ready. Thanks! Lukas [1] https://archlinux.org/todo/ffmpeg-80-and-friends/

1 1

RFC: buildbtw build service
by Rafael Epplée 23 Sep '25

23 Sep '25

Hey all, A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/63 Please visit the above link for discussion. Summary: This RFC proposes a first vertical slice of a build service to streamline rebuilding packages with many reverse dependencies. It tackles problems like repetitive manual work, blocking staging repos, missed reverse dependencies and lack of shared context like build logs. Goals include automating rebuilds and build ordering, enabling unattended builds, and providing isolated repos for parallel work. Builds run in secure virtual machines via a GitLab executor, organized into namespaces with histories and automatic dependency graphs. Interaction happens through CLI (`pkgctl`) and a web UI with SSO. - Cheers, Rafael

1 0

systemd v258 pre-releases
by Christian Hesse 17 Sep '25

17 Sep '25

Hello everybody, the systemd development team has pushed the first pre-release for the upcoming v258 release. It is a massive feature release, with a huge amount of new functionality and goodies. Please see the NEWS [0] for details. As announced in the PKGBUILD [1] I have prepared packages and pushed them to my personal testing repository. Have a look at this if you ware brave and want to have a first look. The comes with an updated mkinitcpio package, cherry-picking systemd-related changes. We should merge these before v258 release. Happy testing! [0] https://github.com/systemd/systemd/blob/v258-rc1/NEWS [1] https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/blob/ma… [2] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/merge_reques… -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 4

Update on Valve sponsored work in July 2025
by Rafael Epplée 08 Sep '25

08 Sep '25

Hi all, here is a quick progress report on Valve sponsored work in July 2025. ## Signstar Based on feedback from reviewers, we have added further research and data to [RFC 0059] which provides information on specific costs and technological differences between discussed options. Due to reviewer concerns with regards to colocation hosting feasibility and costs we have pivoted to support the YubiHSM 2 as default backend for the proposed solution. The existing NetHSM integration will remain for as long as possible to potentially be re-evaluated in the future. The code coverage setup has been split so that unit tests and integration tests each have their own report. In an additional step, we have also added coverage reporting for use-cases in which tests have to switch users. Logging to systemd journal with rich metadata has been added, in case journald is available in the given environment. An issue with doctests coverage being broken for multi-member projects has been investigated (see [cargo-llvm-cov#440]). A large part of the NetHSM handling backend has been merged and released, which allows to synchronize a NetHSM backend with a Signstar configuration file ([signstar!249]). To support further backends in the future, work on making the Signstar configuration file format less dependent on the existing set of crates related to the NetHSM has been started ([signstar!292]). A sample signer [yubihsm-pgp] with mock YubiHSM has been implemented. The PoC exercises all major features we would need (creating new ed25519 asymmetric key; creating new wrapping key, backed by 3 out of 5 Shamir’s Secret Sharing and key export/import; creating new OpenPGP certificate using HSM key; signing given data file using that certificate; verifying that file with SOP implementations). YubiHSM additionally has support for [key attestation], sadly, due to RustCrypto version drift it doesn't work when mixed with rPGP. Additionally, investigated internal YubiHSM audit log for operations, which stores all operations executed on the HSM. The log can be cryptographically verified that it has not been tampered with. [YubiHSM logs] ## wkd-exporter Added code coverage, based on the existing code from signstar. Generated code quality file for Gitlab so that each merge request has a nice presentation of what would change. Contributed `[metadata]` attributes to `just` [just#2794] and used that to track CI job package dependencies [wkd-exporter#16]. ### Hours billed for Signstar David (85h), Wiktor (124h) ## Buildbtw We've received lots of feedback from PoC testers which as lead to lots of improvements and a treasure trove of new issues we'll be able to reference while building towards the next milestone: the first "production" release. Our plan is to take all learnings from the PoC and use them to build a small, but polished foundation which will provide build services to all staff members (and eventually also drive-by gitlab contributors). The PoC will continue running for a while (consider joining the testing instance if you haven't done so!), and we've continued working on it. We drastically improved the scheduler's memory usage and performance, fixed lots of papercuts in the CLI and web UI, and fixed bugs, a major one of them in the graph calculation algorithm. We also merged the first contributions from gromit. Thank you, gromit! The impulses for these changes came from onboarding sessions for the PoC testing instance. Thanks to everyone who participated so far! For the new production milestone, we've created plans based on our experience with the PoC: an overhauled data structure for improved performance, a deployment concept and release strategy, OIDC authentication, an improved JSON API for scheduling builds, and a new module structure for the code. Last but not least, we started writing an RFC covering major workflows and requirements for the production system we're envisioning. ### Hours billed for buildbtw Rafael (79h), Sven (39.5h), Levente (0h) ## Package Source Licensing Implemented [pkgctl license](https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/3… and worked through many packages with bad licenses. Created a [todo to make all packages license compliant](https://archlinux.org/todo/make-packages-license-compliant/). ### Hours billed for Package Source Licensing Rafael (4h), Sven (81h) ## Meeting Notes Meeting notes are available for staff in the [internal-notes] repository. [internal-notes]: https://gitlab.archlinux.org/archlinux/internal-notes/-/tree/main/valve [RFC 0059]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/59 [cargo-llvm-cov#440]: https://github.com/taiki-e/cargo-llvm-cov/issues/440 [yubihsm-pgp]: https://gitlab.archlinux.org/wiktor/yubihsm-pgp [key attestation]: https://docs.yubico.com/hardware/yubihsm-2/hsm-2-user-guide/hsm2-core-conce… [just#2794]: https://github.com/casey/just/pull/2794 [signstar!249]: https://gitlab.archlinux.org/archlinux/signstar/-/merge_requests/249 [signstar!292]: https://gitlab.archlinux.org/archlinux/signstar/-/merge_requests/292 [wkd-exporter#16]: https://gitlab.archlinux.org/archlinux/wkd-exporter/-/merge_requests/16/dif… [YubiHSM logs]: https://docs.yubico.com/hardware/yubihsm-2/hsm-2-user-guide/hsm2-core-conce…

1 0

glib2 removed from core-testing
by Jan Alexander Steffens (heftig) 06 Sep '25

06 Sep '25

glib2 2.86.0-1 was removed from core-testing as it prevented gnome-shell from launching. Please downgrade any updated installs back to core/glib2 2.84.4-2. lib32-glib2 was removed as well.

1 0

New way to support Arch Linux: GitHub Sponsors
by Levente Polyak 05 Sep '25

05 Sep '25

Hey everyone, We've got a new way for you to support Arch Linux and help us pay our bills: GitHub Sponsors! https://github.com/sponsors/archlinux/ All funds go to our existing fiscal host at SPI, just like with PayPal or credit card donations: https://www.spi-inc.org/projects/archlinux/ Your support means the world to us, not just financially but also by being an active part of our community. We're super grateful and send love to our community 🫶. Let's keep this distro rolling together. 🚀

1 0

Standardize on running autoreconf in prepare()
by Jelle van der Waa 01 Sep '25

01 Sep '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 8

namcap 3.6.0 released
by Jelle van der Waa 24 Aug '25

24 Aug '25

Hi, Seen a long hiatus, finally a new namcap release has entered [extra-testing] Release notes: - Allow rules to be disabled by default - Allow namcap-devel to be run from any directory - Support '+' in license expressions - New unreproducible sphinx cache file rule - New dbus services improperly installed in /etc rule - Introduce typechecking using mypy and extend ruff linting rules - Don't crash on missing description, only throw error lint - Remove python-six from tests - Fix safeguards against false positives for QML dependency check - Limit shadow stack check to x86_64 binaries - Change from getopt to argparse Please report issues on GitLab [1] Thanks! Jelle [1] https://gitlab.archlinux.org/pacman/namcap/-/issues/

1 0

RFC Final Comment Period: "Automated digital signing of OS artifacts"
by David Runge 19 Aug '25

19 Aug '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/59 Please visit the above link for discussion. Summary: """ Introduce a centralized, hardware backed solution for the digital signing of OS artifacts. Gradually replace the need for manual signing of artifacts throughout the distribution. The stepwise plan in this document will eventually lead to changes for the following existing roles within Arch Linux staff: - _Package maintainers_ will no longer sign packages using their individual OpenPGP private key. - The amount of OpenPGP certificates for _main signing key holders_ to care for will be drastically reduced. - The _DevOps team_ will have to monitor and administrate additional physical machines. New groups of people within Arch Linux staff will - collectively take care of the administrative credentials for the described system as _holders of shares of a shared secret_, - provide software upgrades for components of the system as _developers of Signstar_ - and create releases for a central, image-based OS as _developers of Signstar OS_. For details refer to the section **changes for users and staff**. """

1 0

PKGBUILD SPDX License array RFC status
by Jelle van der Waa 18 Aug '25

18 Aug '25

Hi All, Some time ago we decided to adopt SPDX license identifiers in the license array of PKGBUILD's. Without having progress reports its hard to know what the current status is, so I made a little script with some borrowed logic from namcap. [1] This uses expac to extract the licenses array from the local package sync db (/var/lib/pacman/sync). The unknown / invalid entries are emitted on stderr and stdout contains JSON data to be consumed by whatever tool you might suit you :-) A test run on my machine gave the following output, in summary: [2] * invalid: 62 * unknown: 4743 I hope having an easy script to collect statistics will move the conversion process forward. But do note that the original RFC does not yet tackle the `custom` license question. [3] [1] https://github.com/jelly/Dotfiles/blob/master/bin/arch-spdx-statistics [2] https://gist.githubusercontent.com/jelly/c5b790c3b1223f91362d956d50401e93/r… [3] https://rfc.archlinux.page/0016-spdx-license-identifiers/#unresolved-questi…

2 2

Removing port 222 for git on gitlab.archlinux.org
by Kristian Klausen 09 Aug '25

09 Aug '25

Hi all, the git migration happened more than two years ago[1] and as part of that the SSH port for git was changed from port 222 to the default SSH port 22[2]. A port redirect was added at the time to avoid disrupting existing local git repositories using the old port. Time has now come to removing said port redirect, which will happen one week from now. So if you have local git repositories using the old port, please change them to use the standard SSH port. See below for an example. $ git remote -v origin ssh://git@gitlab.archlinux.org:222/archlinux/infrastructure.git (fetch) origin ssh://git@gitlab.archlinux.org:222/archlinux/infrastructure.git (push) $ git remote set-url origin git@gitlab.archlinux.org:archlinux/infrastructure.git $ git remote -v origin git@gitlab.archlinux.org:archlinux/infrastructure.git (fetch) origin git@gitlab.archlinux.org:archlinux/infrastructure.git (push) [1] https://archlinux.org/news/git-migration-completed/ [2] https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/bc1e7f777283… Cheers, Kristian Klausen DevOps

1 1

Introducing bumpbuddy
by Robin Candau 07 Aug '25

07 Aug '25

Hi everyone, We are very happy to announce the addition of a new member to the "buddy" family: bumpbuddy! [1] Initially introduced to Arch staff during last year's Arch Summit as the "nvchecker-poc" [2], bumpbuddy is now (a)live and ready to assist our package maintainers and users in monitoring new upstream releases for our packages. ## What is bumpbuddy? Bumpbuddy is a daemon watching for new upstream releases for our packages. It automatically opens GitLab issues for out of date packages [3], keep them updated if needed (e.g. if a newer upstream release supersedes the initially reported one) [4] and closes them once the matching version has been pushed [5]. It intends to fill the gaps in current methods for new upstream release tracking and reporting by proposing a centralized and automated solution. ## Benefits for package maintainers Bumpbuddy takes advantage of the `.nvchecker.toml` file from GitLab's packages repo to perform automated tracking of new upstream releases. Therefore, Package Maintainers won't need to rely on manual `pkgctl version check` runs or "homemade" solutions to track new upstream releases for their packages anymore. The reporting of new upstream releases being done via GitLab issues offers a (public) place to discuss and collaborate around eventual problems or blocking points preventing a new release from being packaged [6]. Assignment to those "out of date" issues is opt-in and can be enabled by reacting with the "package" emoji from bugbuddy's user settings [7]. Note that such issues are automatically opened as "confirmed", so bug-wranglers will not get assigned. ## Benefits for users Thanks to bumpbuddy automated tracking and reporting, our package maintainers should now be aware of new upstream releases without requiring users to manually flag packages out of date via the dedicated button on Archweb (which we actually intend to get rid of at some point, more on that in the next chapter). Another benefit for users is that, as opposed to the current "flag out of date" feature, GitLab issues offer a public place to look for (or ask for) the state of a pending update. This should hopefully allow for more transparency towards users wondering why a specific update is taking some time to be packaged. ## Current specifications and future work Bumpbuddy currently runs every 3 hours, which means that it may take up to 3 hours for new releases to be reported and for the associated GitLab issue to be automatically close once the matching version has been pushed. It's also worth reminding that the version tracking is based on the `.nvchecker.toml` configuration file of packages repo, meaning that an erroneous configuration file may result in erroneous version reporting and that packages that miss a configuration file will not be monitored. Here are a few mid / long term goals we have for bumpbuddy: - Provide a web overview for reports [9]. - Provide an API endpoint for `pkgctl version check` (to produce faster results). - Manage "out of date" status for packages on Archweb and get rid of the "flag out of date" button; which is manual (and therefore error prone), may be used wrongly/abusively (e.g. to report bugs or send some spam), is highly dependent on packages popularity and lacks transparency (as it doesn't provide a public place to discuss eventual blocking points). - Open merge requests rather than (or in addition of) GitLab issues, including the result of `pkgctl version upgrade` (regarding our future goal to adopt a gitops workflow for packaging). - And more... [10]. ## Conclusion This is the first iteration of bumpbuddy and things are still at a fairly early stage, so bear with us and don't hesitate to open issues [10] to submit bug reports or suggesting improvements. I would like to thank everyone who helped us improving bumpbuddy so far by opening issues, sharing opinions and opening merge requests. I would also like to give a special thank to Segaja, mh4ckt3mh4ckt1c4s and yan12125, who have been (beta) testing bumpbuddy for the past few months, as well as a huge thanks to klausenbusk & gromit for their amazing work and precious help on that project! [1] https://gitlab.archlinux.org/archlinux/bumpbuddy [2] https://pkgbuild.com/~antiz/presentations/Nvchecker_PoC/ [3] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issue… [4] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issue… [5] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issue… [6] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issue… [7] https://gitlab.archlinux.org/archlinux/bugbuddy/-/issues/1 [8] https://archlinux.org/packages/extra/x86_64/timeshift/flag/ [9] https://gitlab.archlinux.org/archlinux/bumpbuddy/-/issues/10 [10] https://gitlab.archlinux.org/archlinux/bumpbuddy/-/issues/ -- Regards, Robin Candau / Antiz

3 3

News draft: zabbix >= 7.4.1-2 may requires manual intervention
by Robin Candau 04 Aug '25

04 Aug '25

Hi, I've been working on a significant rework of the zabbix split package [1] over the past few days, introducing a fair amount of changes and improvements. One key change consists of replacing the multiple sysusers historically created for each zabbix components with a single shared "zabbix" user: - It aligns better with the intended upstream standard and the way other distributions does this (see [2] for more details). - The previous historical approach was somewhat *hacky*, e.g. relying on unnecessarily static UID:GID for each user and running some `chown` during `package()` rather than relying on systemd sysusers.d / tmpfiles.d. That said, this change *may* require manual intervention from users. While I'm aware that Zabbix component usage on Arch Linux might be relatively low, I believe that monitoring components are critical enough to warrant a news entry about this change and the potential impact it implies. Of course, feel free to let me know if you think otherwise. News draft below. Pad available at [3]. ---------- # zabbix >= 7.4.1-2 may requires manual intervention Starting withi `7.4.1-2`, the following Zabbix system users (previously shipped by their related packages) will no longer be used. Instead, all Zabbix components will now rely on a shared `zabbix` user (as originally [intended by upstream](https://www.zabbix.com/documentation/current/en/manual/installati… and done by other distributions): - zabbix-server - zabbix-proxy - zabbix-agent *(also used by the `zabbix-agent2` package)* - zabbix-web-service This shared `zabbix` user is provided by the newly introduced `zabbix-common` *split* package, which is a now a dependency for all relevant `zabbix-*` packages. The switch to the new user is handled automatically in the corresponding `systemd` service units. However, **manual intervention may be required** if you have custom files or configurations referencing / being owned by the above deprecated users, for example: - `PSK` files used for encrypted communication - Custom scripts for metrics collections / report generations - `sudoers` rules to metrics requiring elevated privileges to be collected - ... Those should therefore be updated to refer to / be owned by the new `zabbix` user, otherwise some services may fail to start properly (if not at all). Once migrated, you may optionally remove the obsolete users and their primary groups from your system (see the [related Arch Wiki page](https://wiki.archlinux.org/title/Users_and_groups) for details). ---------- [1] https://gitlab.archlinux.org/archlinux/packaging/packages/zabbix [2] https://gitlab.archlinux.org/archlinux/packaging/packages/zabbix/-/issues/1… [3] https://md.archlinux.org/YjsLnkzRRoeMa7BP3gxYKw# -- Regards, Robin Candau / Antiz

2 4

glibc 2.42 in testing - moving to stable repos affected
by Frederik Schwan 29 Jul '25

29 Jul '25

I'm about to push glibc 2.42 to testing. Do not move packages linked against 2.42 to extra or core until glibc itself moves around Thursday/Friday. Otherwise the package will probably break. Best regards, Frederik

1 0

Arch Linux devblog
by David Runge 24 Jul '25

24 Jul '25

Hi all, during and since last Arch Summit some of us have been discussing a dedicated blog focused on Arch Linux development topics. This blog is now live at https://devblog.archlinux.page and is also available through the Arch Planet feed aggregator [1]. The devblog is meant for all Arch Linux staff to highlight work on Arch Linux projects. Topics may include (but are not limited to) - providing an overview of recent/current/future developments (e.g. contextualizing our existing tech stack with new tools) - explaining more intricate or complex topics of our projects to a wider audience (e.g. the use of tools with code examples, etc.) Here, the audience may range from Arch Linux staff to anyone interested in the technical developments of the distribution. While this blog is probably a good place to highlight new work, it may also serve as an avenue to reduce our tribal knowledge a bit and give in-depth insights. As a side effect of producing technical posts generally increasing the knowledge about our projects, we also hope to attract new contributors. If you are interested in writing something, head on over to the repository for the blog [2] and open a merge request. In case you are interested in helping review posts, please reach out to the current developers of the project [3]. Happy writing! Best, David [1]: https://archlinux.org/planet/ [2]: https://gitlab.archlinux.org/archlinux/devblog [3]: https://gitlab.archlinux.org/archlinux/devblog/-/project_members -- https://sleepmap.de

1 0

Licensing changes in package sources (implementing RFC40 and RFC52)
by Sven-Hendrik Haase 23 Jul '25

23 Jul '25

Hey all, With [RFC40][0] and [RFC52][1] merged, we're now going full steam to make sure the changes outlined in those RFCs are soon implemented. If you are a packager and only care about how this concerns you without the nitty gritty details, here's what you need to know in short: 1. PKGBUILDs and auxiliary files (e.g. config files, etc.) that Arch Linux contributors provided will be licensed under 0BSD. Full current list [here][3]. 2. Licensing information will be documented in a `REUSE.toml` file per repository and will be maintained by package maintainers going forward. 3. We will generate a `REUSE.toml` (using `pkgctl license setup`) for most packages. 4. You may have to make changes to your packages (details below)! 5. When moving package source repositories from the AUR, either contact past contributors and ask for consent to license under 0BSD, or rewrite the package sources. The changes introduced in [RFC40][0] and [RFC52][1] have a general impact on packaging work. To clearly document which licenses apply to which files, we are introducing REUSE [2], which provides a structured configuration file format (`REUSE.toml`) for mapping files to concrete licenses. In the near future, we will add these files to package source repos in an automated fashion using `pkgctl license setup`. While doing so, we will exclude some packages added after 2024-11-01, see [this issue][4] for further details. In some cases (around 750 out of 12462 repos), packager maintainers will need to manually perform some changes, as adding a `REUSE.toml` will not work out of the box. There will be a todo list on Arch web for those packages where manual action is required. The most common reasons for this are: 1. The package's license isn't specified in an SPDX conforming fashion (e.g. `GPL2` instead of `GPL-2.0-or-later`). There are open MRs on GitLab to make some packages SPDX conforming [5]. We will go through these and we'll try to merge all of these. 2. Multiple license identifiers are specified in the PKGBUILD and SRCINFO files and patch files are present in the package source repository. In this case, we can't automatically pick a suitable upstream license. By default, all files in package source repos must be licensed under 0BSD. 0BSD is very permissive and files licensed under its terms can be contributed upstream under their desired license. For some files, 0BSD might not be suitable, and contributors need to choose a different license depending on the situation. Here are some common cases: - Included files originating from contributors that have not agreed to the 0BSD license. If the files are available under a FOSS license, mark the files under that particular license in the `REUSE.toml`. If no license is provided, the files need to be rewritten or removed. - Patches taken from upstream and committed to the repository need to be annotated with the correct upstream license. `pkgctl license` will be available from devtools v1.4.0 onwards. After this release, you will encounter a warning when running `pkgctl release` if your package source repository isn't compliant. If there are any open questions with existing packages and the new reuse setup, reach out over the mailing list or in the packaging channel. Cheers, Rafael and Sven [0]: https://rfc.archlinux.page/0040-license-package-sources/ [1]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/52 [2]: https://reuse.software/ [3]: https://gitlab.archlinux.org/archlinux/devtools/-/blob/b8c475b3f402809fc65b… [4]: https://gitlab.archlinux.org/archlinux/packaging/licensing-package-sources/… [5]: https://gitlab.archlinux.org/search?scope=merge_requests&search=spdx&state=…

1 0

Scheduled maintenance for gitlab.archlinux.org
by gromit 09 Jul '25

09 Jul '25

Hello everyone, our hosting provider Hetzner has just informed us that there will be a scheduled downtime window on the 9th July 2025 starting on 10:00 GMT+2 until 14:00 GMT+2 [to replace the mainboard of our Gitlab server][0]. During this time period the service will be offline for up to 40 minutes + however long it takes us to fix potentially resulting issues with the booloader, network configuration and so on. This will effect the following services/components of our distribution ecosystem: - Packaging: No packages can be updated during the downtime (as the source repositories for it will be offline) - Project Maintainers: The other projects (pacman, aurweb, buildbtw, signstar, mirrors repo etc.) will be unavailable - Bugtracker: No bugs can be reported during this timeframe - Static sites as served via Gitlab Pages (Arch Linux WKD, project pages etc.) will not be available We can not really circumvent the downtime and think it's an acceptable timeframe to not warrant any further action from us as a team. Let us know if you have any questions or additions to the above! Cheers, Christian for the DevOps Team [0]: https://docs.hetzner.com/robot/dedicated-server/general-information/mainboa…

1 1

Orphaning phosh
by Jelle van der Waa 06 Jul '25

06 Jul '25

Hi All, Lately I have noticed I haven't gotten around to updating phosh to the latest version. As this is a returning issue and I don't use phosh anymore as GNOME is good enough for tablets I decided to orphan it. Maintenance should be fairly trivial, the only issue is that it requires a revert on top of wlroots and of course needs to catch up to wlroots from time to time. [1] Upstream is very friendly and nice. [2] The packages in question which are now orphan: * phoc * phosh * phosh-mobile-settings * libgmobile * feedbackd If no one picks it up I will drop the packages to the AUR in one month so someone there can maintain it. [1] https://gitlab.archlinux.org/archlinux/packaging/packages/wlroots0.19/-/blo… [2] https://phosh.mobi/

1 0

Re: What is "Arch Linux Modernity" these days? (cvlc12)
by Cédric Clavel 22 Jun '25

22 Jun '25

Hi, I'd like to chip in about modernity, and draw attention to https://gitlab.archlinux.org/archlinux/ideas/-/issues/13 It's still not really possible to perform a clean installation using UKIs straight out of the box, at least not by following the installation guide. Using UKIs will most likely require using pacman hooks from AUR or added manually. I think it should be a lot more straightforward to set that up in a 'modern' OS. Using 'kernel-install' would probably streamline things a lot, and choosing between UKIs and traditional linux/initrds is as simple as setting this in `/etc/kernel/install.conf` Happy to hear your thoughts, have a good day Le dimanche 22 juin 2025 à 08:09 +0000, arch-dev-public-request(a)lists.archlinux.org a écrit : > Send Arch-dev-public mailing list submissions to > arch-dev-public(a)lists.archlinux.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > arch-dev-public-request(a)lists.archlinux.org > > You can reach the person managing the list at > arch-dev-public-owner(a)lists.archlinux.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Arch-dev-public digest..." > Today's Topics: > > 1. What is "Arch Linux Modernity" these days? (Andrei Korshikov) > 2. Re: What is "Arch Linux Modernity" these days? (Andrei > Korshikov) > _______________________________________________ > Arch-dev-public mailing list -- arch-dev-public(a)lists.archlinux.org > To unsubscribe send an email to > arch-dev-public-leave(a)lists.archlinux.org

1 0

What is "Arch Linux Modernity" these days?
by Andrei Korshikov 21 Jun '25

21 Jun '25

Hi, folks. I don't like the second paragraph of [1]. All that stuff (systemd, udev, …) was modern 10+ years ago, but nowadays they all are kind of mainstream. So, could you say what you think about modernity? My very personal opinion [2]—that second paragraph should be just deleted. But I hope you will point me out. --- Andrej Koršikov [1]: https://wiki.archlinux.org/title/Arch_Linux#Modernity [2]: https://wiki.archlinux.org/index.php?diff=838344

2 2

RFC - Manual changes for Plasma 6.4.0
by Tomaz Canabrava 20 Jun '25

20 Jun '25

Plasma 6.4.0 will need manual intervention if you are on X11 On Plasma 6.4 the wayland session will be the only one installed when the users does not manually specify kwin-x11. With the recent split of kwin into kwin-wayland and kwin-x11, users running the old X11 session needs to manually install plasma-x11-session, or they will not be able to login. Currently pacman is not able to figure out your personal setup, and it wouldn't be ok to install plasma-x11-session and kwin-x11 for every one using Plasma. tldr: Install plasma-x11-session if you are still using x11

2 2

News draft: linux-firmware >= 20250613.12fe085f-5 upgrade requires manual intervention
by Jan Alexander Steffens (heftig) 18 Jun '25

18 Jun '25

Hi all, The linux-firmware package in core-testing has been through some churn as of late, as I've been trying to split the firmware properly and ran into several issues in the process. I apologize for the mess. Unfortunately, we're not done. This time it's a Pacman limitation involving symlinks and multiple packages that I don't remember how to handle properly. The best solution I see is instructing a manual intervention. Is this how we handled this situation in the past? Does anybody have a better idea? Draft: --- With `20250613.12fe085f-5`, we split our firmware into several vendor-focused packages. `linux-firmware` is now an empty package depending on our default set of firmware. Unfortunately, this coincided with upstream reorganizing the symlink layout of the NVIDIA firmware, resulting in a situation that Pacman cannot handle. When attempting to upgrade from `20250508.788aadc8-2` or earlier, you will see the following errors: linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad103 exists in filesystem linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad104 exists in filesystem linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad106 exists in filesystem linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad107 exists in filesystem To progress with the system upgrade, first remove `linux-firmware`, then reinstall it as part of the upgrade: # pacman -Rdd linux-firmware # pacman -Syu linux-firmware --- Greetings, Jan

1 0

RFC: Automated digital signing of OS artifacts
by David Runge 17 Jun '25

17 Jun '25

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/59 Please visit the above link for discussion. Summary: Introduce a centralized, hardware backed solution for the digital signing of OS artifacts. Gradually replace the need for manual signing of artifacts throughout the distribution. The stepwise plan in this document will eventually lead to changes for the following existing roles within Arch Linux staff: - Package maintainers will no longer sign packages using their individual OpenPGP private key. - The amount of OpenPGP certificates for main signing key holders to care for will be drastically reduced. - The DevOps team will have to monitor and administrate additional physical machines in a colocation. New groups of people within Arch Linux staff will - collectively take care of the administrative credentials for the described system as holders of shares of a shared secret, - provide software upgrades for components of the system as developers of Signstar - and create releases for a central, image-based OS as developers of Signstar OS. For details refer to the section "changes for users and staff".

1 0

Update on Valve sponsored work in May 2025
by Rafael Epplée 17 Jun '25

17 Jun '25

Hi all, here is a quick progress report on Valve sponsored work in May 2025. ## Weeklies - [2025-05-13] - [2025-05-20] - [2025-05-27] ## Signstar This month we have been focusing on getting the RFC for automated signing of OS artifacts ready (we apologize in advance - it is not going to be a short one). We estimate to publish it this month (June). In the Signstar project we have improved the way we run integration tests, by implementing a custom target runner, that allows us to seamlessly run some tests in containerized environments (see [signstar!237]). We've updated our cryptography libraries (rpgp 0.16 includes support for Post Quantum Cryptography) and started work on gathering code coverage for tests. Further work has gone into adding a module for NetHSM syncing and state handling to the signstar-config crate (see [signstar!165]/[signstar!249]). ### Hours billed for Signstar April: David (35h), Wiktor (91h) ## Buildbtw We're focused on getting builds running in VMs inside gitlab pipelines. Besides that, we want to release parts of the PoC that can already be useful to other Arch Linux projects. - We've implemented background running of virtual machines in vmexec to support our custom gitlab runner executor which runs in multiple discrete steps, requiring virtual machines to stay running between each of them ([vmexec-background]). - We've improved vmexec's robustness, and fixed more bugs ([vmexec-pty], [vmexec-exit-codes], [vmexec-stderr]). - We've decided to license the buildbtw source code under GPL. - We're planning to release a standalone tool for keeping a local copy of all of Arch Linux' package source repositories and automatically fetching any changes. This can be used by projects such as bumpbuddy or ALPM. - We've started polishing up the CLI, web UI and documentation in preparation for a first PoC user test. We'd like to invite everyone who's interested to participate in our weekly coordination meetings. Tuesdays at 17:00 UTC (19:00 CEST), we meet on the Arch Linux Mumble server to discuss the current state of the project, groom gitlab issues, discuss technical questions and plan the week ahead. You're welcome to join and listen, or to contribute your expertise. If you'd like to participate through other means, we've also made an effort to clean up our issue tracker. Please browse the issues and pitch in if something feels unclear, or information is missing. You can follow along our day-to-day progress on the proof-of-concept milestone ([poc-milestone]) and the standalone tool milestone ([tool-milestone]). ### Hours billed for buildbtw and package source licensing May: Rafael (53h), Sven (81h), Levente (0h) ## Package Source Licensing - After some last fine-tuning, Morten has merged the RFC40 amendment (thanks!) ([rfc40]) - We've prepared a draft mail with packager guidelines for arch-dev-public ([licensing-adp-mail]) - We've created a plan for licensing new contributions since our last batch of licensing notification mails. Once RFC52 is merged and we've added REUSE.toml files to all repositories where all contributors have been notified, we'll send out a second batch of licensing notifications for new contributors. After a second 4 month waiting period, we'll add REUSE.toml files to the rest of the repositories. [2025-05-13]: https://md.archlinux.org/wmTzaT1IQlGp3S3WuDJgiA# [2025-05-20]: https://md.archlinux.org/s2yfyaFJTVavU1nMI2h6XQ# [2025-05-27]: https://md.archlinux.org/JDxTHJ4-Sw60bnDNPTWZXg# [vmexec-background]: https://gitlab.archlinux.org/archlinux/vmexec/-/merge_requests/5 [poc-milestone]: https://gitlab.archlinux.org/archlinux/buildbtw/-/milestones/11#tab-issues [signstar!165]: https://gitlab.archlinux.org/archlinux/signstar/-/merge_requests/165 [signstar!237]: https://gitlab.archlinux.org/archlinux/signstar/-/merge_requests/237 [signstar!249]: https://gitlab.archlinux.org/archlinux/signstar/-/merge_requests/249 [tool-milestone]: https://gitlab.archlinux.org/archlinux/buildbtw/-/milestones/17#tab-issues [vmexec-pty]: https://gitlab.archlinux.org/archlinux/vmexec/-/merge_requests/1 [vmexec-exit-codes]: https://gitlab.archlinux.org/archlinux/vmexec/-/merge_requests/7 [vmexec-stderr]: https://gitlab.archlinux.org/archlinux/vmexec/-/merge_requests/6 [rfc40]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/49 [licensing-adp-mail]: https://md.archlinux.org/PYvbvENaTni5Skf67V1Jgg#

1 0

Zig packaging guidelines
by kpcyrd 17 Jun '25

17 Jun '25

hello, I've just changed minisign from C to Zig since this is now supported by upstream (it was quite the journey though). I noticed we don't have any packaging guideline for Zig yet so I would like to propose adding one. The example based on my notes is quite straight-forward: ``` depends=( glibc ) makedepends=( zig ) build() { cd "${pkgname}-${pkgver}" zig build --verbose -Dcpu=baseline -Doptimize=ReleaseSmall } package() { cd "${pkgname}-${pkgver}" install -Dm755 -t "${pkgdir}/usr/bin" zig-out/bin/example } ``` Common gotchas were: - The `zig build` command is essentially fully silent if no interactive terminal is attached, `--verbose` helped but it's still very little info - Without `-Dcpu=baseline` the compiler is going to probe the build server cpu, which both causes problems with Reproducible Builds, but more importantly can also make the binary crash with `Illegal instruction` errors, since the default binaries aren't really distributable Looking at the ncdu PKGBUILD shows there's some room for improvement: ``` build() { cd "${pkgname}-${pkgver}" DESTDIR="build" zig build \ --summary all \ --global-cache-dir ../zig-global-cache \ --prefix /usr \ --search-prefix /usr \ --release=safe \ -Dtarget=native-linux.6.1-gnu.2.38 \ -Dcpu=baseline \ -Dpie=true } check() { cd "${pkgname}-${pkgver}" zig build test \ --summary all \ --global-cache-dir ../zig-global-cache \ --prefix /usr \ --search-prefix /usr \ --release=safe \ -Dtarget=native-linux.6.1-gnu.2.38 \ -Dcpu=baseline \ -Dpie=true } ``` More input very welcome, but I'm also fine with adding a very basic one by myself and whoever has something to add can just edit the wiki. Never lose the plot, kpcyrd

5 5

Transition to the new WoW64 wine and wine-staging
by Peter Jung 14 Jun '25

14 Jun '25

We are transitioning the wine and wine-staging package to a pure wow64(1] build. This change removes the dependency on the multilib repository. The main reason for this is to align with upstream Wine development, which simplifies packaging and the dependency chain. Potential Issues: - OpenGL Performance: A known limitation of the new WoW64 mode is reduced performance for 32-bit applications that use OpenGL directly. - Breaking Changes: Existing 32-bit prefixes needs to be recreated If you are facing issues with 32 bit prefixes, please recreate these and reinstall the application. [1]: https://gitlab.winehq.org/wine/wine/-/releases/wine-9.0#wow64

2 1

RFC Final Comment Period: REUSE for package license linting
by Morten Linderud 13 Jun '25

13 Jun '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/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 Final Comment Period: Establish default build flags for Fortran
by Jakub Klinkovský 12 Jun '25

12 Jun '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/54 Please visit the above link for discussion. Summary: This RFC establishes default build flags (`FFLAGS`, `FCFLAGS`, `DEBUG_FFLAGS`) for compiling Fortran code in Arch Linux packages, aligning them with the security hardening standards defined for C.

1 0

Adopting similar packages in extra
by Quentin Michaud 10 Jun '25

10 Jun '25

Hi all, I am interested in packaging vscodium [1] into extra but am worried that it would be seen as a duplicate of the code [2] package. This situation is unclear and not explicitly mentioned in the wiki [3]. I asked the question on Matrix/IRC and this stirred a larger debate, so artafinde suggested me to post the question here in order to have a record of the discussion and potential decisions. The (more generic) questions are the following: under which criteria do we want to accept multiple "similar" packages in official repos or replace one by another? Do we want to fix (or already have) rules or guidelines for these situations or do we want to proceed on a case-by-case basis? "similar" packages can mean different things, I see several categories: - Hard fork of a project but projects are very close / are trying to stay compatible. Examples : redis (AUR) / valkey (extra), terraform (extra) / opentofu (extra) - Soft fork of a project aiming at adding / removing functionalities using patches. Examples : vscode (extra) / vscodium (AUR), firefox (extra) / librewolf (AUR) and other Firefox forks - Rewrite of a project but aiming to achieve the exact same goals / drop-in replacement : Examples: sudo (core) / sudo-rs (extra), coreutils (core) / uutils (extra). This category is tricky because the definition of "exact same goals" is unclear, but I exclude software that implement common standards but that are vastly different in practice, such as docker / podman or openssh / dropbear. This is more relevant to the "replace one by another" part, as Ubuntu did recently with sudo [4]. As for the criteria on which to base these decisions, they are many but the most important ones that I was able to think of are: - licensing changes - user impact - compatibility / conflicts between forks / flavors of the same software I hope thinking and discussing about this will help us to set guidelines on how to handle such situations in the future and document it in the wiki. Your thoughts are welcome :) Cheers, Quentin Michaud / mh4ckt3mh4ckt1c4s [1]: https://vscodium.com/ [2]: https://archlinux.org/packages/extra/x86_64/code/ [3]: https://wiki.archlinux.org/title/Package_Maintainer_guidelines#Rules_for_pa… [4]: https://discourse.ubuntu.com/t/adopting-sudo-rs-by-default-in-ubuntu-25-10/…

5 5

Adopting similar packages in extra
by Quentin MICHAUD 09 Jun '25

09 Jun '25

1 0

Switch to a versioned packaging scheme for wlroots
by Robin Candau 31 May '25

31 May '25

Hi, Wlroots is one of the packages for which we need to keep multiple versions around to ensure compatibility with reverse dependencies. At the moment, we have a wlroots0.17 package [1] (for the few packages that still require it, most notably qtile [2]) and a "regular" wlroots package [3] that currently points to 0.18. We are evaluating bumping the wlroots package to 0.19, but that requires the introduction of a new wlroots0.18 package to preserve compatibility with reverse dependencies that are not yet compatible with 0.19 (similar to what was done with the wlroots0.17 package). This method makes new wlroots releases difficult to triage as we have to release both the wlroots package bump and the new wlroots0.18 package at the same time (to avoid breaking changes regarding reverse dependencies) while ensuring that we defined proper "conflicts" to avoid conflicting files issues during upgrade [4] (since we can't control in which order packages will be upgraded on users' system). For instance, the new wlroots0.18 package would likely need a "conflicts" array that looks like this; in order to avoid files collision with the "regular" wlroots package until it gets updated to 0.19 on users' system, and also to avoid an unexpected conflict with the wlroots0.17 package. ``` conflicts=( "wlroots<0.19" "wlroots>=0.18" ) ``` While the above _should_ work, this is a quirky dance that will eventually get more and more complex over time (e.g. if we have to accumulate more versions of wlroots in the future). As such, I would like to switch to a versioned packaging scheme for wlroots. This means dropping the "regular" wlroots package and solely rely on versioned packages like: wlroots0.17, wlroots0.18 & wlroots0.19 (similar to e.g. gtk2, gtk3, gtk4 in a sense). Wlroots already adopted a versioned so/lib naming scheme so there is no file collision between e.g. wlroots0.18 and wlroots0.19 (meaning we won't need the above "conflicts" array dance anymore). Technically speaking, that means introducing a new wlroots0.18 package that conflicts and replaces the current "regular" wlroots package (to ensure people make the switch without file conflicting issue) and a new wlroots0.19 package. We could then drop the "regular" wlroots package from the repo and keep moving with versioned packages only in the future (e.g. wlroots0.20, wlroots0.21, and so on...). Reverse dependencies can then explicitly point to the version they need (similar to how it's done currently with wlroots0.17). I'm aware that this may be unconventional regarding how we usually do things in Arch Linux, but I think it's fair to say that current way we have to deal with new wlroots releases is confusing and causes more harm than good. I think the above suggestion is a practical and relevant solution for such specific case. I created a related task todo list [5] that I will tackle today and put to staging. I intend to leave it in staging for a week or two in order to leave some time for people to react and / or raise any concerns I may have missed about switching to a versioned packaging scheme. Thanks :) [1] https://archlinux.org/packages/extra/x86_64/wlroots0.17/ [2] https://github.com/qtile/qtile/blob/master/docs/manual/wayland.rst?plain=1#… [3] https://archlinux.org/packages/extra/x86_64/wlroots/ [4] https://gitlab.archlinux.org/archlinux/packaging/packages/wlroots0.17/-/iss… [5] https://archlinux.org/todo/switch-to-a-versioned-packaging-scheme-for-wlroo… -- Regards, Robin Candau / Antiz

2 4

Amending RFC40 to remove custom 0BSD license
by Morten Linderud 26 May '25

26 May '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 11

pulling mariadb-lts from extra-testing
by Christian Hesse 22 May '25

22 May '25

Hello everbody, I have just pulled mariadb-lts (11.4.6-1) from extra-testing. Several upstream bug reports indicate that there is a serious performance regression, though the exact cause it not yet known. Another release is expected really soon, possibly even in the following week. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 2

IRC Channel for mirror related discussions now available
by pitastrudl 19 May '25

19 May '25

Hi all, We've created, some time ago already, a new channel on libera.chat for any Arch Linux mirror / mirrorlist related questions and chat. This is just another communication channel for all things related. It is still advised to report any issues to https://gitlab.archlinux.org/archlinux/arch-mirrors/-/issues for easier visibility and tracking of progress. Thank you for all your contributions, past and future! Channel name: #archlinux-mirrors Regards, Arun

1 0

Docker Open Source Community Program renewed for 2025
by Levente Polyak 13 May '25

13 May '25

Hi all, I've prolonged our Docker Open Source Community Program for another year for 2025. We've also received the approval and confirmation of the application. One of the benefits is, that this allows for our images to have relaxed pull limits. This is a yearly renewal. The next renewal will be popping up around March 2026. https://hub.docker.com/repository/docker/archlinux/archlinux Cheers, Levente

1 0

On dropping Redis
by Bert Peters 13 May '25

13 May '25

Hi all, A while ago we as a distro decided to stop supporting Redis, due to their licence change [1], and move to Valkey. Through a combined effort, we removed all direct dependencies on redis, replacing them with vault and patching until that worked. The announcement was posted, and a deadline was set. This may or may not have caused Redis to reconsider their license change, and have announced another relicencing, this time to the AGPL [2] [3]. With that change, I personally believe there is no longer a reason to remove redis from [extra], and keep it in the repos as-is. Redis is almost but not quite compatible with Valkey, so dropping it without good cause would be a disservice to our community. Now, I don't want to make light of the harm that Redis inc initially wrought on the open source community with their license change, or waste the work that was done to make everything work with Valkey. Pushback like this is what caused the license change. As such, I propose we continue to use Valkey as the implementation for all purposes that don't strictly require Redis, and maintain Redis simply as a package for our commynity's convenience. That way, should the licensing change again in the future, we do not have a similar amount of work ahead of us. This seems to me the Arch way: pragmatic and user central. Now I know that this is not a universally shared opinion, so please consider this email an invitation for discussion on what we should be doing here. Cheers, Bert [1]: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [2]: https://antirez.com/news/151 [3]: https://redis.io/blog/agplv3/

8 10

RFC: Introducing a process for sponsorships
by gromit 06 May '25

06 May '25

Hello everyone, A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/55 Please visit the above link for discussion. Summary: This RFC introduces a process which gives sponsorships a clear point of contact, introduces fitting measures of transparency and specifies a set of guidelines for such engagements with external entities.

1 0

Sunsetting epapirus-icon-theme
by Felix Yan 05 May '25

05 May '25

Hi, As per upstream suggested in the release note [1], epapirus-icon-theme is no longer provided in [extra] now. Users are suggested to use Papirus / Papirus-Dark from now on. [1] https://github.com/PapirusDevelopmentTeam/papirus-icon-theme/releases/tag/2… -- Regards, Felix Yan

1 0

RFC: Establish default build flags for Fortran
by Jakub Klinkovský 04 May '25

04 May '25

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/54 Please visit the above link for discussion. Summary: This RFC establishes default build flags (`FFLAGS`, `FCFLAGS`, `DEBUG_FFLAGS`) for compiling Fortran code in Arch Linux packages, aligning them with the security hardening standards defined for C.

1 0

Ruby 3.4.2
by Andreas 'Segaja' Schleifer 28 Apr '25

28 Apr '25

Hello, we have started today to update Ruby in Arch Linux to version 3.4.2 and for this we block staging from today on until it is completed. The progress can be watched on [0]. If you want to help in the rebuild effort please contact me on IRC or Matrix to coordinate. Best regards Segaja [0] https://archlinux.org/todo/draft-ruby-34-rebuild/

1 2

Orphaning buildbot, AWS-related and several other packages
by Chih-Hsuan Yen 23 Apr '25

23 Apr '25

Hi all, I'm getting busier with work and life, so I would like to focus on packages I still use. Here is the list of packages I orphaned earlier today. Packages include buildbot, AWS-related packages and other packages that are no longer used by my remaining packages. Some of them require extra care. For example, python-aiobotocore is tightly coupled with specific botocore/boto3/aws-cli versions and should be updated together. Feel free to reach me for more details if needed, thank you. aws-cli buildbot flatbuffers python-aiobotocore python-aioitertools python-autobahn python-aws-sam-translator python-aws-xray-sdk python-awscrt python-boto3 python-botocore python-cfn-lint python-croniter python-evalidate python-flask-cors python-hvac python-joserfc python-jschema-to-python python-jsondiff python-jsonpath-ng python-jsonschema-path python-junit-xml python-jwcrypto python-klein python-moto python-openapi-schema-validator python-openapi-spec-validator python-py-partiql-parser python-pyhcl python-pypugjs python-pytest-env python-pytrie python-s3transfer python-sarif-om python-snappy python-sphinx-jinja python-treq python-tubes python-txaio python-txrequests python-ubjson python-unidiff Best Regards, Chih-Hsuan Yen (yan12125)

2 1

News draft: Valkey to replace Redis in the [extra] Repository
by Frederik Schwan 18 Apr '25

18 Apr '25

Hi everyone, As you might have heard by now redis got a new license and *some* forks were created [1]. Valkey as one of them is developed by the Linux Foundation, and adopted by Fedora already [2]. So we think it's a good step to follow that path and replace redis by valkey. ------ # Valkey to replace Redis in the [extra] Repository valkey, a modern in-memory data store, will soon be replacing redis in the [extra] repository. This change is due to Redis modifying its license from BSD-3-Clause to RSALv2 and SSPLv1 on March 20th, 2024[1]. Arch Linux Package Maintainers intend to support the availability of the redis package for roughly 90 days from the day of this post, to enable a smooth transition to valkey. After the 90 transition period has ended, the redis package will be moved to the AUR. Also, from this point forward, the redis package will not receive any additional updates and should be considered deprecated until it is removed. Users are recommended to begin transitioning their use of redis to valkey as soon as possible to avoid possible complications after the 90 day transition window closes. [0] https://github.com/redis/redis/commit/0b34396924eca4edc524469886dc5be6c77ec… ------ Best regards, Andrew and Frederik [1] https://redis.io/blog/redis-adopts-dual-source-available-licensing/ [2] https://www.linuxfoundation.org/press/linux-foundation-launches-open-source…

2 3

Official Arch Linux image for WSL
by Robin Candau 17 Apr '25

17 Apr '25

Hi everyone, I'm writing this mail to collect thoughts and interests about providing an official Arch Linux image for WSL (Windows Subsystem for Linux) [1]. Indeed, after a quick related discussion over on IRC, I started tinkering with this and I personally would be eventually interested in proposing this "officially", if that's of interest. This proposal is inspired by the related Fedora one [2] (which was accepted and planned for Fedora 42). # Benefits An official Arch Linux image for WSL would provide an easy way for people to give Arch Linux a try directly from their Windows system, making our distro more "discoverable" and accessible. Additionally, some people may have no other choice but to use Windows in specific situations (despite not necessarily being the best choice for their needs / duties), e.g. on their company's workstation (like it's the case for me). While WSL consists of an acceptable solution to get access to a Linux environment in such situations, the lack of an official image for Arch Linux either "suggests" the use of a different distribution or "forces" people to rely on unofficial Arch Linux WSL images (which quality may vary). # Distribution / Installation WSL images can be distributed via tarballs, Appx packages, or via the Windows Store. From what we know, distributing images from the Windows Store implies agreeing to the store policies & developer agreement, and may imply additional eventual concerns related to TOS/EULA. I unfortunately don't have much details on that front currently but I think that distribution from the Windows Store should be out of scope for now. Moreover, since version 2.4.4, WSL greatly improved the way to install tarballs outside from the store by adding "click-to-install" support for tarballs using the ".wsl" extension, as well as automatic first setup script support. As such, I would personally advice for that distribution method for the time being. Indeed, downloading such an Arch Linux ".wsl" tarball and (double) clicking on it would be all that's needed to be able to use Arch Linux with WSL. Note that WSL 2.4.4 and greater are still qualified as pre-releases at the time I'm writing those lines [3], but can still be installed with a single command line from a PowerShell prompt (`wsl --update --pre-release` from a system with WSL2 installed). If anything, installing such tarballs from WSL prior to 2.4.4 can still be done "manually" via a single command line (`wsl --import <DistroName> <InstallationPath> <TarballPath>`). With a proper documentation, using Arch Linux with WSL prior to 2.4.4 would still be pretty straightforward. # Technical details WSL2 provides a single virtual machine managed by the Windows host which runs guest Linux distributions as containers. As such, the Arch Linux base container image [4] can already be used for basic WSL support. To define some default parameters and provide additional functionalities, some specific WSL configuration files can be added to it. This, for instance, allows to add `systemd` support out of the box [5], define default parameters (e.g. default user, icon for the app shortcut or terminal profile) and automatic first setup script (which can be used to create a default non-root user and perform basic system setup interactively at first run for instance) [6]. The archive just needs to be renamed from ".tar.zst" to ".wsl" to allow "click-to-install" with WSL >= 2.4.4. For those interested, I actually "built" such a ".wsl" Arch Linux tarball [7] based on our latest base container image which can be installed & uses with WSL2 (made for test purposes). Make sure to read the README [8], which contains important information such as how the tarball was generated and how to use it. # Tarball maintenance / management Given that the WSL tarball would be based on our Docker / Container image, it could eventually be maintained in the same repo [4], although I'm not sure that mixing a WSL specific image with our "Docker" images is desirable. We also have the arch-boxes repo [9] which provides multiple kind of Arch images (vagrant, qcow2, cloud...). I think a WSL image could fit well there. Alternatively, a new dedicated repo could be created. When it comes to actual maintenance / management, I think the image generation and releasing should be fairly easy to automate via a scheduled GitLab CI (as it is currently done for our Docker images for instance). The process is fairly straightforward (grab latest base Docker image / tarball, un-archive it, add a few WSL specific files, re-archive it, rename it from ".tar.zst" to ".wsl"). I guess a monthly generation / release would be more than enough. We would still need a few people to watch over and feel responsible to maintain this. I'd happily be one of them, but please feel free to express interest :) # Unresolved questions / issues From a purely technical stand point, there is one pending issue which, fortunately, can be easily worked around. But the actual root cause and proper fix are unknown yet. See the last section of the README [8] for more details. On another level, I guess the important point here is to determine if we actually want this and, if so, how? For instance, which level of support do we want to provide (if we are to do this)? Since it would be pretty close in terms of "design" and usage, I personally think we could provide a similar level of support than the Docker images & Arch boxes images. Anyway, sorry for the long read 0:) Just to clarify, the actual purpose of this mail is to collect thoughts, concerns, questions, interests (both regarding using such an "official" Arch Linux WSL image and / or helping maintaining it), ... Please, share opinions if you have some :) [1] https://learn.microsoft.com/en-us/windows/wsl/about [2] https://fedoraproject.org/wiki/Changes/FedoraWSL [3] https://github.com/microsoft/WSL/releases [4] https://gitlab.archlinux.org/archlinux/archlinux-docker [5] https://devblogs.microsoft.com/commandline/systemd-support-is-now-available… [6] https://learn.microsoft.com/en-uisns/windows/wsl/build-custom-distro#add-th… [7] https://pkgbuild.com/~antiz/WSL/ [8] https://pkgbuild.com/~antiz/WSL/README.md [9] https://gitlab.archlinux.org/archlinux/arch-boxes -- Regards, Robin Candau / Antiz

12 32

Packaging repositories are now automatically archived upon inactivity
by Jelle van der Waa 17 Apr '25

17 Apr '25

Hi everyone, Thanks to Levente reviewing, fixing and deploying a new gluebuddy. Packaging repositories which have no activity for the last 30 days are now automatically archived, making it clearer to users that this package is not available in our repositories when browsing/searching GitLab. If a package repository was archived which you still want to work on, please reach out to the devops team to unarchive it. Due to GitLab permissions issues we cannot allow packagers via pkgctl to unarchive a repository. Greetings, Jelle

1 1

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

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

22 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

News draft: Cleaning up old repositories
by Sven-Hendrik Haase 17 Feb '25

17 Feb '25

Hey all, in an earlier thread [0], I proposed cleaning up the unused repos from repos.archlinux.org. They've become unused and stagnant after the git migration almost two years ago. We kept them around so it wouldn't break setups of users that tried to get the repository sync databases with an outdated pacman.conf. The old repos are safe to remove. Originally I had planned to just remove them and leave it at that. However, some people mentioned that it might still confuse users who haven't updated their pacman.conf in a long time. In order to inform those users there should be a news post. [0] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… --- # Cleaning up old repositories Around two years ago, we've merged the [community] repository into [extra] as part of the git migration. In order to not break user setups, we kept these repositories around in an unused and empty state. We're going to clean up these old repositories on *2025-03-01*. On systems where `/etc/pacman.conf` still references the old `[community]` repository, `pacman -Sy` will return an error on trying to sync repository metadata. The following deprecated repositories will be removed: `[community], `[community-testing]`, `[testing]`, `[testing-debug]`, `[staging]`, `[staging-debug]`. Please make sure to remove all use of the aforementioned repositories from your `/etc/pacman.conf`! --- Cheers, Sven

2 2

Fwd: Phasing out reiserfsprogs (EOL)
by Tobias Powalowski 06 Feb '25

06 Feb '25

Hi folks, as Giancarlo and Gromit mentioned, this is worth sharing on the public mailing list too. So here the mentioned mails from me for the public. Best regards tpowa -------- Weitergeleitete Nachricht -------- Betreff: Re: Phasing out reiserfsprogs (EOL) Datum: Thu, 6 Feb 2025 09:35:18 +0100 Von: Tobias Powalowski <tobias.powalowski(a)googlemail.com> An: staff(a)lists.archlinux.org Am 28.08.24 um 14:20 schrieb Tobias Powalowski: > Hi folks, > > reiserfs is a dead horse, I started to drop it from btrfs-progs > depends already. > > Any strong objection in removing it as depend from all packages? > > Thanks for your opinions. > > Best regards > > tpowa > Hi folks, 6.13 reached the repositories, all packages that depended on reiserfs were updated some time ago. The reiserfsprogs are now gone from the official repositories. Best regards tpowa

1 0

News draft: glibc 2.41 breaks Discord
by Frederik Schwan 04 Feb '25

04 Feb '25

Hi everyone, as discussed in the Matrix packaging channel, the upcoming glibc move from testing to stable will break audio connectivity for Discord clients. Discord has fixed the issue in their canary build and has communicated an eta for the fix in stable for 2025-02-10. As the glibc update holds off package moves from testing to stable I would like to continue releasing the toolchain and give everyone instructions on how to fix their Discord installation. ------ # Glibc 2.41 corrupting Discord installation Glibc and it's friends will move from testing to stable on approx. 2025-02-03. After installing the update, the Discord client will show a read warning that the installation is corrupt. This issue has been fixed in the Discord canary build. Until the fix hits the stable Discord release, please use the canary build or login via browser if you rely on audio connectivity. There have been no reports that (written) chat connectivity is affected. ------ Best regards, Frederik

4 5

glibc 2.41 in testing - moving to stable repos affected
by Frederik Schwan 30 Jan '25

30 Jan '25

I just pushed glibc 2.41 to testing. Do not move packages linked against 2.41 to extra or core until glibc itself moves around Sunday/Monday. Otherwise the package will probably break. Best regards, Frederik

1 0

Talks from Arch contributors at FOSDEM 2025
by Morten Linderud 24 Jan '25

24 Jan '25

Yo, FOSDEM is approaching and several Arch contributors and maintainers are holding talks next weekend. I have taken the liberty to collect up all the talks in this email so other staff, and users, are aware. Some talks are Arch related, some talks less so. But still interesting topics nonetheless! # David Runge Adventures in oxidizing Arch Linux Package Management When: Saturday 18:05 - 18:45 Room: Rust Devroom - UB2.252A (Lameere) https://fosdem.org/2025/schedule/event/fosdem-2025-6259-adventures-in-oxidi… # Filipe Laíns Understanding (modern) Python packaging When: Sunday 10:00 - 10:30 Room: Python Devroom - UD2.218A https://fosdem.org/2025/schedule/event/fosdem-2025-4242-understanding-moder… # Morten Linderud Hardware backed SSH keys: ssh-tpm-agent When Saturday 15:00 - 15:30 Room: Security Devroom - UB4.132 https://fosdem.org/2025/schedule/event/fosdem-2025-5544-hardware-backed-ssh… # Orhun Parmaksız Bringing terminal aesthetics to the Web with Rust (and vice versa) When: Saturday 12:25 - 13:05 Room: Rust Devroom - UB2.252A (Lameere) https://fosdem.org/2025/schedule/event/fosdem-2025-5496-bringing-terminal-a… From Side Projects to Sustainable Open Source When: Saturday 15:05 - 15:30 Room: Community Devroom - UB5.230 https://fosdem.org/2025/schedule/event/fosdem-2025-5498-from-side-projects-… # Remi Gacogne Honey, I shrunk DNSdist When: Saturday 18:20 - 18:45 Room: DNS Devroom H.2213 https://fosdem.org/2025/schedule/event/fosdem-2025-4991-honey-i-shrunk-dnsd… -- Morten Linderud PGP: 9C02FF419FECBE16

2 1

FOSDEM 2025 Dinner
by Robin Candau 24 Jan '25

24 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 1

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

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

Splitting the Arch Linux repo and archive server
by Kristian Klausen 27 Dec '24

27 Dec '24

Hi all, The DevOps team is working on splitting[0] the repo server and the archive server, which are currently still located on the same box (gemini.archlinux.org) This reason for splitting it is mainly due to I/O issues and to ensure separation of concerns. Please see [1] and [2] for a bit more context. We have already ordered the new repo server (AX41-NVMe[3] with an extra 1 TB NVMe SSD) and switched the rsync endpoint for the mirrors 7 months ago[2], so now the time has come to move the home of the repos from gemini to the new repo server. Christian and I are planning on taking a stab on this in a few hours, during which the access to the repos will be cut off. [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/531 [2] https://lists.archlinux.org/archives/list/arch-mirrors@lists.archlinux.org/… [3] https://www.hetzner.com/dedicated-rootserver/ax41-nvme Cheers, Kristian

2 1

python-httpcore 1.0.7-1 & python-httpx 0.28.1-1 pulled from testing
by Robin Candau 27 Dec '24

27 Dec '24

Hi all, Please note that I have just pulled python-httpcore 1.0.7-1 & python-httpx 0.28.1-1 from [extra-testing]. Python-httpx >= 0.28 introduces breaking changes preventing some reverse dependencies (meaning packages depending on it) to be built correctly. This will be worked on in a proper separate ToDo task [1]. Please downgrade python-httpcore & python-httpx to the version available in [extra]. [1] https://archlinux.org/todo/python-httpx-028-rebuild/ -- Regards, Robin Candau / Antiz

1 0

Do not change architecture of packages during rebuilds
by Jelle van der Waa 22 Dec '24

22 Dec '24

Hi All, As you might have noticed, Python 3.13 is moved to [core]. Just like with the move of staging to testing we can't move a package because it changed architectures and hits a dbscripts bug. [1] Please don't do this until the bug is fixed :) [1] https://gitlab.archlinux.org/archlinux/dbscripts/-/issues/57

1 0

TensorFlow packages incompatible with Python 3.13
by Torsten Keßler 20 Dec '24

20 Dec '24

Dear all, over the last weeks, Arch Linux Package Maintainers have been working on the Python rebuild for the new minor release 3.13. All but one package, TensorFlow, where successfully updated to work with Python 3.13. TensorFlow proved to be difficult to update [0]. As a large software stack with different python modules and low level C/C++ interfaces, we can't progress without upstream. Unfortunately, a new TensorFlow release with Python 3.13 is only expected for early next year [1]. We have evaluated different options. TensorFlow and related packages could be dropped from the official repositories. But we think that this step would cause too much confusion for users. Instead, we add a warning printed during the installation of a TensorFlow package that encourages users to use TensorFlow via pip or via the official docker images: WARNING: This version of the TensorFlow package is not compatible with Python 3.13 If you want to use TensorFlow, consider installing an older version of Python and use a virtual environment or use the official Docker image, https://www.tensorflow.org/install Best, Torsten [0] https://github.com/tensorflow/tensorflow/issues/78774#issuecomment-24395683… [1] https://github.com/tensorflow/tensorflow/issues/78774#issuecomment-24981485…

3 3

Sovereign Tech Agency funding for ALPM project
by David Runge 09 Dec '24

09 Dec '24

Hi all, I am happy to announce that the [ALPM][0] (Arch Linux Package Management) project receives funding from the [Sovereign Tech Agency][1] for work on the Arch Linux packaging ecosystem. > The Sovereign Tech Agency supports the development, improvement, and > maintenance of open digital infrastructure. > Its goal is to sustainably strengthen the open source ecosystem, focusing on > security, resilience, technological diversity, and the people behind the code. The investment from the Agency's Sovereign Tech Fund provides financing for four developers to work on the ALPM project in a part time capacity over the course of 15 months. The developers are [Arne Christian Beer][2], [Heiko Schäfer][3], [Orhun Parmaksız][4] and [David Runge (myself)][5]. Work on the project has started in October 2024 and the funding continues until the end of 2025. The ALPM project provides specifications, as well as Rust libraries and tools. Its goals are robust integration for all package creation, validation and installation tasks, repository management, as well as drop-in replacements or alternatives for some facilities provided by [pacman][6]. The investment through the Sovereign Tech Fund supports multiple milestones, which are explained below. ## Formal specifications for packaging data formats The Arch Linux packaging ecosystem uses underspecified/undocumented file and metadata types, yet we need to be able to use them reliably in other contexts such as package creation, build and package repository management tooling. Therefore this milestone involves developing versioned specifications for all low-level descriptor file and implementing Rust libraries based on them. These will be based on the existing ad-hoc reference implementations in [makepkg][7] and pacman. ## Basic OpenPGP verification of artifacts Signature verification in Arch Linux package management currently hinges on a stateful GnuPG keyring. This solution is brittle and has already caused various issues related to the Arch Linux keyring in the past. To simplify signature verification - while at the same time enabling the use of a more diverse set of cryptographic technologies - a specification for the [UAPI group][8] will be written. An accompanying Rust library will be provided as a simple and stateless integration, not limited to use in Arch Linux. ## Rust library for handling of individual packages The structure of Arch Linux package files is currently not explicitly defined. This milestone focuses on providing a formal specification of what an ALPM-based package contains, how it is created and handled. A dedicated Rust library and tool will facilitate package creation, validation and installation. These new Rust libraries will also expose a C API for possible integration into the C-based libalpm library. ## Rust library for system package management This milestone revolves around the use of the previously implemented components by providing a library for package download, validation, verification, installation and state handling similar to pacman's libalpm and will handle sets of individual packages on user systems. A C-API will be provided for compatibility with libalpm-based applications. One specific concern of this milestone is modernizing the OpenPGP integration. Current package management tooling does not allow for scoping signature verifiers (e.g. OpenPGP certificates) for a specific purpose, such as "only packages" or "only repository metadata". The new system will rely on a stateless approach such as the one to be proposed as specification to the UAPI group. ## Distribution-agnostic OpenPGP stack for the verification of distribution artifacts This milestone will focus on a set of foundational libraries, based on a UAPI specification from a previous milestone. These libraries will add support for PGPKI (aka the “Web of Trust”) in the generic directory structure for OpenPGP certificates used for the verification of distribution artifacts. The libraries mentioned above will be integrated into the ALPM context to allow for example the full verification of packages and repository metadata. A Rust-based solution will be provided as a modern alternative to the current GnuPG-based approach. # The outcome(s) The ALPM project strives to build a modern, sustainable, maintainable and memory-safe framework for the Arch Linux packaging ecosystem. This framework will enable robust and predictable integration for all package related tooling and libraries. The project goals are intentionally ambitious while being constrained to a relatively short period of time. The work is organized so that real world benefits will happen early and often. Several infrastructure related projects have already reached out with a concrete interest to make use of libraries created in the first phase of the project. The work will be done in the open, on the [Arch Linux GitLab][0]. Everyone and anyone is welcome to join in and help out! My sincerest thanks go to the Sovereign Tech Agency for commissioning dedicated work on the ALPM project. Best, David [0]: https://gitlab.archlinux.org/archlinux/alpm/alpm [1]: https://www.sovereign.tech/ [2]: https://gitlab.archlinux.org/nukesor [3]: https://gitlab.archlinux.org/heiko [4]: https://gitlab.archlinux.org/orhun [5]: https://gitlab.archlinux.org/dvzrv [6]: https://wiki.archlinux.org/title/pacman [7]: https://wiki.archlinux.org/title/Makepkg [8]: https://uapi-group.org

1 0

Highlights in the devtools 1.3.0 release
by gromit 06 Dec '24

06 Dec '24

Hello everyone, as we got the feedback on the Arch Linux Summit that not everyone is aware about all the new shiny things in devtools, we wanted to give a small overview about the latest developments. Apart from this effort every release has an easily digestable changelog attached (see [0] as example for 1.3.0), so if you want to stay up to date you can also follow the releases on the Gitlab repo or check the previous release notes for additional gems! # 🚀 Highlights in the 1.3.0 release 🚀 ## ✨ The 'pkgctl issue' subcommands Now all the functionality needed to work with issues is availiable directly on the commandline via pkgctl. A regular packager workflow might look something like this: Check open issues: $ pkgctl issue list --assigned-to-me --group Check details about an issue: $ pkgctl issue view --package linux 97 $ pkgctl issue view --package linux --web 97 $ pkgctl issue view --package linux --comments 97 React to the issue: $ pkgctl issue close --package linux --edit 97 $ pkgctl issue comment --package linux 97 There are way more options and things to do, but feel free to explore on you're own! ➡ Contributed by @anthraxx in [MR!255][1] 🎉 ## 🚧 Fixes to 'offload-build' There was a major refactoring effort for offload-build, which has the very neat consequence that the --inspect argument can now be used in combination with pkgctl build's --offload so that remote builds can be debugged more easily. ➡ Contributed by @lahwaacz in [MR!234][2] 🎉 ## 📦 nvchecker related changes - For packages without an upstream one can now create a special config: $ pkgctl version setup --no-upstream This is thought to be only used with packages that do not have a canonical upstream, like metapackages. If you have trouble setting up nvchecker integration for the more complicated packages feel free to get in touch! - On release there now is a warning when a package repository does not have a '.nvchecker.toml' - We no offer a way to retrieve machine-readable output from pktctl version check: $ pkgctl version check --json * ➡ Contributed by @antiz, @segaja and @anthraxx in [MR!273][3], [MR!275][4] and [MR!286][5] 🎉 --- Apart from the big changes/improvements there are of course a lot of minor bug fixes, documentation improvements and smaller features included. Thanks for everyone that helped to discuss & improve features! 🎉 Cheers, anthraxx & gromit [0]: https://gitlab.archlinux.org/archlinux/devtools/-/releases/v1.3.0 [1]: https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/255 [2]: https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/234 [3]: https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/273 [4]: https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/275 [5]: https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/286

1 0

Python 3.13 Rebuild
by Jelle van der Waa 16 Nov '24

16 Nov '24

Hi all, Leaves are falling, weather is getting colder and my apartment needs heating so clearly it is time to rebuild 1500+ packages. If no one objects or has any other pressing rebuilds, I'd like to kick off a Python rebuild bootstrap this weekend (latest Sunday). A To Do list will be created when we have bootstrapped setuptools, pytest and friends. Greetings, Jelle

1 2

RFC: Streamline the RFC writing process
by Robin Candau 15 Nov '24

15 Nov '24

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/43 Please visit the above link for discussion. Summary: Streamline the writing and publishing of RFCs by relying on markdown and dedicated spellcheckers and linters. -- Regards, Robin Candau / Antiz

3 4

RFC: Upstream Package Sources
by David Runge 14 Nov '24

14 Nov '24

A new RFC (request for comment) has been opened here: 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 also cryptographically verifiable upstream sources by default.

1 0

News Announcement: Licensing Package Sources
by Rafael Epplée 14 Nov '24

14 Nov '24

Hey all, after our previous email to ADP, some of you suggested a news post might be warranted in addition to the notification to ADP which we agree with. I'm happy to hear any feedback on the draft below. You can find a live version with incorporated feedback in a pad at [0]. --- Title: Providing a license for package sources Arch Linux hasn't had a license for any package sources (such as `PKGBUILD`s) in the past, which is potentially problematic. Providing a license will preempt that uncertainty. In [RFC 40](https://rfc.archlinux.page/0040-license-package-sources/) we agreed to change all package sources to be licensed under the very liberal [0BSD](https://spdx.org/licenses/0BSD.html) license. **This change will not limit what you can do with package sources.** Check out the RFC linked above for more on the rationale and prior discussion. Before we make this change, we will provide contributors with a way to voice any objections they might have. Starting on 2024-xx-xx, over the course of a week, contributors will receive a single notification email listing all their contributions. - If you receive an email and agree to this change, there is no action required from your side. - If you do not agree, please reply to the email and we'll find a solution together. If you contributed to Arch Linux packages before but didn't receive an email, please contact us at package-sources-licensing(a)archlinux.org. --- Cheers, Rafael [0]: https://md.archlinux.org/xMN1JFWIQm6qWb29aAblyQ#

1 0

Let's drop ollama-gemma2-2b and forbid GenAI models
by Sven-Hendrik Haase 14 Nov '24

14 Nov '24

Hey all, There's been some discussion about this via chat but no action has been taken. Some time ago, ollama-gemma2-2b was uploaded to [extra] which has caused some discussion for various reasons. I'm not writing this mail to address or open up the discussion for ethical or political concerns. This is about pragmatism. With the current state of things, I don't think we should have any LLMs or other GenAI models in official repos. I think it would be much more practical to offer downloaders such as huggingface-cli or ollama instead. GenAI models become out of date every other week and they tend to be rather large too. Downloaders allow users to download these models from specialized hosters at good speeds and to easily stay up to date. I don't think we're doing anyone a service by offering outdated GenAI models in the repos. This mail is explicitly NOT about other ML model types such as rnnoise. Those tend to be small and unchanging. They should stay in repos where it makes sense and if there's software that uses them (such as Mumble in this particular example). I propose this: - Drop ollama-gemma2-2b - Forbid other GenAI models from entering official repos for the time being What do you guys think? Cheers, Sven

5 5

Licensing Package Sources
by Rafael Epplée 12 Nov '24

12 Nov '24

Hey everyone, As part of the implementation of RFC 40 [0], we're about to start sending out emails to everyone who has previously contributed to any of our package sources in any capacity. We have gathered around 5000 unique emails and will space sending out over a few days to make sure we don't run into rate limits. Contributors will receive a single email listing all their contributions. Gathering the emails was done on a best-effort basis. If you have contributed to Arch before and didn't receive an email, please contact us at package-sources-licensing(a)archlinux.org. Cheers, Rafael and Sven [0] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/40

1 0

zlib-ng
by Jelle van der Waa 11 Nov '24

11 Nov '24

Hey All, I noticed Fedora is discussing switching from zlib to zlib-ng. zlib-ng is a fork of zlib, which seems to offer ~ 40% better performance and a new API. We have about ~ 1000 packages depending on zlib, zlib-ng does offer a compat option to keep zlib API compatibility. [1] # Proposal From a discussion in #archlinux-staff. It was determined that a possible plan would be to introduce zlib-ng as package in [extra] with the modern API enabled, we can then migrate packages over that are compatible to the new API. A zlib-ng-compat package can be provided, as proposed by Fedora, that activates the zlib API compatibility mode and directly provides libz.so. This package can provide/conflict the original zlib package, and potentially be target to replace zlib all together. In short: zlib-ng would provide libz-ng.so zlib-ng-compat would provide libz.so # Packages which might be able to use zlib-ng Alpine offers a package which has 6 required packages.[2] Debian's codesearch suggests a few packages seem to mention a possible zlib-ng compatibility. [3] These notes where written down last Thursday, in the meantime, Anthraxx uploaded zlib-ng to [extra], so we can start switching packages which use the modern API over. Replacing zlib with zlib-ng-compact is something we need to discuss, I've overheard so far that some test suites fail because they check the compressed test artifact's hash which with zlib-ng can be different. [1] https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.o… [2] https://pkgs.alpinelinux.org/package/edge/community/x86/zlib-ng [3] https://codesearch.debian.net/search?q=zlib-ng&literal=1&perpkg=1 Greetings, Jelle van der Waa & Anthraxx

3 3

Deprecating Fcitx 4.x
by Felix Yan 20 Oct '24

20 Oct '24

Hello, It appears all upstream repositories for Fcitx 4 have been archived since May. This indicates that the framework is no longer being developed or supported by upstream. I will not remove all Fcitx 4.x packages from Arch repositories now, but I encourage everyone to try out Fcitx 5.x and migrate your configuration. Fcitx upstream provides a migration guide at: https://fcitx-im.org/wiki/Upgrade_from_Fcitx_4 -- Regards, Felix Yan

1 0

Ruby 3.3.5
by Andreas 'Segaja' Schleifer 14 Oct '24

14 Oct '24

Hello, we have started today to update Ruby in Arch Linux to version 3.3.5 and for this we block staging from today on until it is completed. The progress can be watched on [0]. Best regards Segaja [0] https://archlinux.org/todo/ruby-33-rebuild/

1 3

Autumn packages cleanup
by Jelle van der Waa 14 Oct '24

14 Oct '24

Hi all, I'm going to orphan the following packages as I want to focus more time on maintaining Python. I'll orphan the following packages in [extra] in a week, please pick them up if you are interested. (Or else I should probably packages which are unrequired to the AUR). eslint_d esptool fsarchiver geckodriver hey meilisearch python-meilisearch intel-gpu-tools python-pyenchant unshield wabt bonnie++

1 0

Dropping python-spsdk and others
by David Runge 09 Oct '24

09 Oct '24

Hi all, with python-pynitrokey dropping the dependency on python-spsdk and others, I am able to drop a few packages. If you are interested in any of them, please make sure to adopt them, else I will drop the following packages to the AUR in a week from now (2024-10-16): python-spsdk python-bincopy python-argparse-addons python-python-click-command-tree python-python-click-option-group python-deepmerge python-hexdump python-libusbsio python-pylink-square python-pyocd python-cmsis-pack-manager python-sly python-pyftdi python-frozendict The python-fastjsonschema package is not used by any of the packages I maintain (but used by fusesoc, jupyter-nbformat, python-{poetry-core,validate-pyproject}) and I will orphan it. Best, David -- https://sleepmap.de

1 0

Future of salt in our repositories
by Morten Linderud 05 Oct '24

05 Oct '24

Yo, `salt` is a framework for server provisioning, change management and administrations tasks. It's based on Python and been a fairly popular framework over the years. It's been packaged in our repositories for over a decade now as it was originally written by Thomas Hatch, which was a package maintainer for many years. `salt` as of version `3007` does not support Python 3.12, and the release `3008` seems far away, which means they won't be ready for the eventual release of Python 3.13 early next year either. This is actively causing problems for the users depending on this package. https://github.com/saltstack/salt/milestone/120 Instead of aiming for compatability it seems like Salt is going for the vendor approach they call `onedir` and instead bundle *everyting*, including their own Python runtime, into a directory. This is going to be a mess to properly support for us as we would be fully reliant on salt to properly ship security updates, along with giving us a *very* hard time properly maintaing this package. https://gitlab.archlinux.org/archlinux/packaging/packages/salt/-/issues/4 I don't think the `onedir` thing belongs in our repositories and as the upstream won't be ready for Python 3.13 I don't see any other possibility but to drop package from our repositories. Salt does not provide their own pacman package for salt, so this is a headsup for anyone relying on the package for their server administration work so they can spend time figuring out how to migrate to another approach. As long as there are not any major issues I intend to drop this package ahead of our Python 3.13 release and prep work. Which might be December/Januar at it's earliest, and early summer at it's latest. I'll give a new update when the Python package maintainers start working on this. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

Re: Ruby 3.3.5
by Andreas 'Segaja' Schleifer 05 Oct '24

05 Oct '24

On 10/2/24 4:23 AM, Leandro Cunha wrote: > Some gems like Capybara seem to break in this version until the last > time I saw it. Being an important use software that I know breaks in > this version. > There seems to be more. Well there might always be a gem that needs updating, but ruby 3.3 has been released in December 2023 and so far I haven't encountered a single gem in our repos that wasn't compatible. Some we had to update to get compatible. For capybara I'm not sure what you are talking about. Their gemspec file says they are compatible with ruby > 3.3 and a simple rebuild against our extra-staging repo (which currently holds ruby 3.3.5) runs through, so at least it builds against ruby 3.3 I tried to get some tests working for this but it needs a lot of additional gems which I don't have time to dive too deep into right now, but as far as I can tell I see no issue that this is not ruby 3.3 compatible. If so you should report this upstream. Best regards Segaja

1 0

thunderbird 131.0 pulled from testing
by Leonidas Spyropoulos 02 Oct '24

02 Oct '24

Hi all, please note that I have just pulled thunderbird 131.0-1 from extra-testing. This is a release for testing purposes only and the confusion from my side came from the fact that the json file we monitor for updates has recently changed. Please downgrade to the extra version and execute thunderbird with `--allow-downgrade` parameter to downgrade your profile. thunderbird --allow-downgrade cheers -- Leonidas Spyropoulos Developer & DevOps PGP: 244740D17C7FD0EC

1 0

Dropping orphan Python packages
by Jelle van der Waa 02 Oct '24

02 Oct '24

Hi all, It's autumn and Python 3.13 is soon to be released, to not rebuild unrequired packages I propose to drop these orphan unrequired packages Sunday 6 October. If anyone wants to pick an orphan up please reply to this email. python-sphinx-typlog-theme python-requests-hawk python-pyvcd python-olm python-biopython python-flask-httpauth python-fxa python-ipyxact python-listparser Greetings, Jelle

1 0

RFC Final Comment Period: Mirror definition - Proposal for new mirror administration routines and mirror requirements
by pitastrudl 01 Oct '24

01 Oct '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/29 Please visit the above link for discussion. Summary: Before this proposal, all tasks surrounding mirrors were manual and in free-text form. This RFC therefore outlines the definitions and guidelines surrounding both becoming but also maintaining and decommissioning a mirrors in a new format using TOML and GitLab.

1 0

Arch Linux and Valve Collaboration
by Levente Polyak 27 Sep '24

27 Sep '24

We are excited to announce that Arch Linux is entering into a direct collaboration with Valve. Valve is generously providing backing for two critical projects that will have a huge impact on our distribution: a build service infrastructure and a secure signing enclave. By supporting work on a freelance basis for these topics, Valve enables us to work on them without being limited solely by the free time of our volunteers. This opportunity allows us to address some of the biggest outstanding challenges we have been facing for a while. The collaboration will speed-up the progress that would otherwise take much longer for us to achieve, and will ultimately unblock us from finally pursuing some of our planned endeavors. We are incredibly grateful for Valve to make this possible and for their explicit commitment to help and support Arch Linux. These projects will follow our usual development and consensus-building workflows. [RFCs] will be created for any wide-ranging changes. Discussions on this mailing list as well as issue, milestone and epic planning in our GitLab will provide transparency and insight into the work. We believe this collaboration will greatly benefit Arch Linux, and are looking forward to share further development on this mailing list as work progresses. [RFCs]: https://rfc.archlinux.page/

1 0

RFC Final Comment Period: License Package Sources
by Sven-Hendrik Haase 21 Sep '24

21 Sep '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/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.

2 3

Arch Linux in August 2024
by Levente Polyak 18 Sep '24

18 Sep '24

## Staff We would like to welcome [Quentin Michaud][0] as part of the Arch Linux Package Maintainer team. ## RFC A previously proposed [Distribution Developer Manual RFC][1] has been accepted with the intention to document how to run the distribution while leveraging GitLab's collaboration features and streamlined workflows for maintaining and evolving the resulting specifications. We have proposed an [RFC to license all Arch Linux package sources][2] under the terms of the Zero-Clause BSD license. We have proposed an [RFC to streamline the writing and publishing of RFCs][3] by relying on markdown and dedicated spellcheckers and linters. ## archinstall We have released [archinstall up to v2.8.6][4], featuring Limine configuration changes, optimized mirror listing including improved handling of speed tests, and several bug fixes. These updates also add support for Catalan translation. ## Infrastructure We have deployed Tempo as an APM (Application Performance Monitoring) within our infrastructure and connected it as a data source in Grafana. The first integration has been implemented in AURWeb, allowing us to trace individual requests and database queries for better performance insights. Furthermore we enabled the [body Sieve extension in Dovecot][5] for our staff, allowing for more advanced email filtering as well as rolled out HTTP/3 for several of our services. ## Packaging ### Ruby We have successfully rebuilt all relevant packages for Ruby 3.2.4 including collaborative effort to make packages ready for the new interpreter version. Ruby 3.2.4 is now available in the official repositories. ### Statistics In this month, we’ve successfully rolled out 4797 package updates addressing various enhancements and rebuilds, including 2354 package upgrades. Additionally, we’ve received 163 new package issues, while resolving a total of 131 issues. [0]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t… [1]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/21 [2]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/40 [3]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/43 [4]: https://github.com/archlinux/archinstall/releases/tag/v2.8.6 [5]: https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/862

1 0

Arch Linux in July 2024
by Levente Polyak 18 Sep '24

18 Sep '24

## Pacman [Pacman v7.0.0][0] has been released as a major feature version. A new `DownloadUser` configuration option allows for dropping privileges when downloading files to a temporary directory. On top of this security measure, the new Landlock sandbox also prevents writing outside the restricted download directory. Additionally, `makepkg` removes `GITFLAGS` support, as it required breaking changes to git source handling. Furthermore this release addresses unstable git checksumming influenced by specific user configuration. On top, it now prevents `PKGBUILD` from overriding `BUILDENV` to avoid undesired side effects. ## ArchWeb We have released [ArchWeb 2024-07-29][1], featuring improvements in rebuilderd integration for reproducible builds status, enhanced caching for several pages, and implementation of a Django Prometheus exporter for better monitoring inside our Grafana dashboards. ## ArchISO [ArchISO v79][2] is a minor update that introduces reproducibility for the ext4 image, thanks to improvements related to `tune2fs`. ## infrastructure ArchWeb now exports Prometheus metrics via the `/metrics` endpoint, including request duration data. We are now scraping the endpoint and added visualization in our Grafana dashboards. ## SPI We have drafted a project status update highlighting our major achievements and key focus areas for the [2023 Annual SPI Report][3]. ## Packaging ### Statistics In this month, we’ve successfully rolled out 6084 package updates addressing various enhancements and rebuilds, including 2476 package upgrades. Additionally, we’ve received 200 new package issues, while resolving a total of 143 issues. [0]: https://gitlab.archlinux.org/pacman/pacman/-/releases/v7.0.0 [1]: https://github.com/archlinux/archweb/releases/tag/release_2024-07-29 [2]: https://gitlab.archlinux.org/archlinux/archiso/-/tags/v79 [3]: https://www.spi-inc.org/corporate/annual-reports/2023.pdf

1 0

Arch Linux in June 2024
by Levente Polyak 18 Sep '24

18 Sep '24

## archinstall The [archinstall v2.8.1][0] update has been released, featuring several bug fixes and improvements to partitioning and desktop profiles, along with the introduction of experimental LVM support and the addition of Finnish translation. ## ArchWeb [ArchWeb 2024-06-12][1] has been rolled out, which includes an update to Django's latest major version, Django 5.0 as well as small improvements within our Ruff configuration used as our Python linter. ## devtools We have released [devtools v1.2.1][2], which includes several small bug fixes as well as the ability in `mkarchroot` to specify a file destination inside the chroot and support for bind mounting a tmpfs with `makechrootpkg`. ## bugbuddy We have released [bugbuddy v0.3.0][3], our GitLab bot, which now automatically assigns security team members when the `scope::security` label is set for any issues or merge requests. ## Packaging ### Ruby We have completed the bootstrapping of Ruby 3.2.4 and will now begin the initial migration work toward its full release. ### Statistics In this month, we’ve successfully rolled out 4054 package updates addressing various enhancements and rebuilds, including 2259 package upgrades. Additionally, we’ve received 197 new package issues, while resolving a total of 183 issues. [0]: https://github.com/archlinux/archinstall/releases/tag/v2.8.1 [1]: https://github.com/archlinux/archweb/releases/tag/release_2024-06-12 [2]: https://gitlab.archlinux.org/archlinux/devtools/-/releases/v1.2.1 [3]: https://gitlab.archlinux.org/archlinux/bugbuddy/-/releases/v0.3.0

1 0

Arch Linux in May 2024
by Levente Polyak 18 Sep '24

18 Sep '24

## Staff We would like to welcome [Bert Peters][0] (bertptrs) as well as [Giovanni Harting][1] (anonfunc) as part of the Arch Linux Package Maintainer team. ## RFC An [RFC has been accepted][2] to introduce "Arch Linux Ports" as testbed for unofficial architectures until they are integrated in the main Arch Linux repositories. ## devtools We have released [devtools v1.2.0][3], featuring several new enhancements and improvements. This release includes distro flag changes, notably the addition of `no-omit-frame-pointer` flags and `_FORTIFY_SOURCE` level 3. A new `pkgctl version setup` command has been implemented to automatically detect and configure nvchecker. We also added `pkgctl repo clean` which allows for the removal of untracked files. `arch-nspawn` now supports Pacman `CacheServer`, and offload building fetches logs from the remote server, making debugging easier for packagers. Additionally, `pkgctl release` now ensures split package uploads are released as a single batch, fixing a race condition when releasing in parallel. ## mkinitcpio We have released [mkinitcpio v39][4], featuring various improvements and fixes. The use of global variables for retrieving cmdline parameters is now deprecated, and hook authors should update their hooks to use the getarg function. This release also adds support for ARM zImage and introduces a new `acpi_override` hook for ACPI table upgrades and overrides. Additionally, `lsinitcpio` now supports listing, analyzing, and extracting UKIs. ## AurWeb We have released [AurWeb v6.2.10][5], which includes several improvements such as adding a maximum limit for comment length. Additionally, all application dependencies have been updated, and leftover mentions of `[community]` have been replaced with `[extra]`. ## ArchISO We have released [ArchISO v78][6], which includes several improvements and bug fixes. Notable changes include fixing the check for microcode update files in initramfs images and formatting the EFI system partition as FAT32 with a reduced size of 36 MiB, down from 512 MiB. ## Infrastructure We have added GitLab packages for pacman at [pacman.archlinux.page][7], which now serves as the new homepage for our package manager. ## ArchWeb We have released [ArchWeb 2024-05-02][9], featuring minor HTML fixes and an updated bootstrap tarball extension to align with ArchISO v77's switch from gzip to zstd compression. Additionally, this release includes compatibility dependency updates for Python 3.12. ## Gluebuddy [Gluebuddy v0.6.2][8], our infrastructure automation tool, now allows external contributors to remain part of our GitLab group without being automatically offboarded. ## Packaging ### Statistics In this month, we’ve successfully rolled out 5383 package updates addressing various enhancements and rebuilds, including 2604 package upgrades. Additionally, we’ve received 285 new package issues, while resolving a total of 323 issues. [0]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t… [1]:https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.or… [2]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/32 [3]: https://gitlab.archlinux.org/archlinux/devtools/-/releases/v1.2.0 [4]: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v39 [5]: https://gitlab.archlinux.org/archlinux/aurweb/-/tags/v6.2.10 [6]: https://gitlab.archlinux.org/archlinux/archiso/-/tags/v78 [7]: https://pacman.archlinux.page/ [8]: https://gitlab.archlinux.org/archlinux/gluebuddy/-/releases/v0.6.2 [9]: https://github.com/archlinux/archweb/releases/tag/release_2024-05-11

1 0

Arch Linux in April 2024
by Levente Polyak 18 Sep '24

18 Sep '24

## Staff ### Project Leader Election Recently, we held our [Arch Linux Project Leader][0] election, and the current Project Leader, Levente "anthraxx" Polyák, was the sole nominee. As per our election rules, he has been re-elected for another term. Congratulations to Levente, and we wish him continued success in his leadership! ## RFC An [RFC has been accepted][1] to grant all Arch Linux staff members, not limited to those in packaging roles, the privilege to initiate RFCs directly, aligning with the broad range of topics these documents encompass. ## archinstall [Archinstall v2.8.0][2] has been released, bringing various fixes and improvements, including enhancements in microcode handling, partitioning, and an increase in ESP size to 1 GiB. ## ArchISO We have released [ArchISO v77][3], which adds a Memtest86+ boot entry for systemd-boot. Additionally, this version now uses mkinitcpio's microcode hook instead of external microcode images and switches the UEFI boot loader from GRUB to systemd-boot. ## ArchWeb We have released [ArchWeb 2024-04-28][4], introducing the ability for packagers to easily add notes to Todo lists via our HedgeDoc instance. Additionally, references to external microcode images have been removed, as ArchISO v77 now includes microcode within the single initramfs. ## Packaging ### Python We have successfully bootstrapped Python 3.12 and rebuilt all relevant packages including collaborative effort to make packages ready for the new interpreter version. Python 3.12.3 is now available in the official repositories. ### Statistics In this month, we’ve successfully rolled out 7186 package updates addressing various enhancements and rebuilds, including 2335 package upgrades. Additionally, we’ve received 282 new package issues, while resolving a total of 265 issues. [0]: https://wiki.archlinux.org/title/DeveloperWiki:Project_Leader [1]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/31 [2]: https://github.com/archlinux/archinstall/releases/tag/v2.8.0 [3]: https://gitlab.archlinux.org/archlinux/archiso/-/tags/v77 [4]: https://github.com/archlinux/archweb/releases/tag/release_2024-04-28

1 0

Arch Linux in March 2024
by Levente Polyak 18 Sep '24

18 Sep '24

## Staff We would like to welcome [Carl Smedstad][0] as part of the Arch Linux Package Maintainer team. Furthermore, we would like to welcome svartkanin as Support Staff for the archinstall project, assisting with issue tracking and handling of merge requests. ### Project Leader Election The 2024 [Arch Linux Project Leader][1] election process has started, with the nomination period now officially open for candidate submissions. ## RFC A previously proposed [RFC has been accepted][2] to create a dedicated role for the moderation of the AUR that supports and eventually replaces the Package Maintainers as the current moderators. An [RFC has been proposed][3] to introduce "Arch Linux Ports" as testbed for unofficial architectures until they are integrated in the main Arch Linux repositories. An [RFC has been proposed][4] to grant all Arch Linux staff members, not limited to those in packaging roles, the privilege to initiate RFCs directly, aligning with the broad range of topics these documents encompass. ## mkinitcpio [mkinitcpio v38.1 has been released][5] as a bugfix update, addressing various regressions. Additionally, the encrypt and sd-encrypt hooks now always include the hid-generic module, which is required for FIDO tokens. ## Pacman [Pacman 6.1.0][6] introduces several key features and improvements. Cache server support has been added, allowing cache servers to be tried before non-cache servers, though they won't be used for database files. The update also replaces libdepends and libprovides with autodeps, enabling automatic addition of libraries to the depends and provides arrays. Additionally, a new `verify()` function has been implemented for custom source verification, allowing for the use of verification schemes not natively supported by makepkg. Lastly, checksum support for git, mercurial, and bzr sources has been added, enabling packagers to use simple refnames in the `PKGBUILD` while ensuring the security of immutable build inputs. ## ArchWeb The ArchWeb 2024-03-05 release includes several small changes, like ISO downloads are now linked exclusively via HTTPS mirrors, improving user security in certain scenarios. Additionally, the ability to add blogs to "ArchWeb Planet" has been restricted to official Arch Linux staff only. ## archinstall We have released [archinstall v2.7.2][7], featuring several improvements and fixes, including enhancements related to Unified Kernel Images (UKIs). ## Infrastructure We have made the "Geo Mirrors" dashboard and metrics [publicly available][8]. This offers valuable insights for mirror administrators and mirror owners, allowing them to monitor performance and distribution more effectively. ## Packaging ### Spring Cleanup We successfully completed our [annual spring cleanup][9], adopting orphaned packages and removing obsolete or unmaintained ones from the official repositories. This effort led to a significant reduction of abandoned packages, keeping our repositories well-maintained and relevant. ### Statistics In this month, we’ve successfully rolled out 7777 package updates addressing various enhancements and rebuilds, including 2684 package upgrades. Additionally, we’ve received 306 new package issues, while resolving a total of 303 issues. [0]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t… [1]: https://wiki.archlinux.org/title/DeveloperWiki:Project_Leader [2]: https://rfc.archlinux.page/0019-aur-moderator-role/ [3]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/32 [4]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/31 [5]: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v38… [6]: https://gitlab.archlinux.org/pacman/pacman/-/releases/v6.1.0 [7]: https://github.com/archlinux/archinstall/releases/tag/v2.7.2 [8]: https://dashboards.archlinux.org/d/EWz2Faunz/geo-mirrors [9]: https://lists.archlinux.org/hyperkitty/list/arch-dev-public@lists.archlinux…

1 0

Arch Linux in February 2024
by Levente Polyak 18 Sep '24

18 Sep '24

## Staff We would like to welcome Vincent Dahmen (wahrwolf) as Arch Linux Support Staff with their new role as Mirror Admin. On top we would like to welcome [andreymal and codingkoopa][0] to their new role as ArchWiki Maintainers. Additionally, we would like to congratulate Christian Heusel (gromit) on his promotion to a full DevOps member. ## Testing Team In early February, we issued a [call for participation][1] about joining the [Arch Testing Team][2] which was also shared on the [Forum][3], [Mastodon][4], [Reddit][5] and IRC. The response was overwhelmingly positive, with over 60 new testing accounts created, significantly extending our capacity for more reliable package update testing! For those who haven't joined yet, there's still time! 😉 ## ArchISO For the first time in history, the official Arch ISO [does not fit in a CD][6] as it now exceeds even the largest 900 MiB capacity CDs. Those few still using the coaster form factor instead of USB flash drives will need to switch to a DVD for burning the ISO. ## devtools We released [devtools 1.1.0][7], a major update packed with bug fixes, improvements, and new workflow commands. Notable additions include the `pkgctl version` subcommand, which uses nvchecker to check and apply newer upstream versions, the `pkgctl search` subcommand to search expressions across the entire packaging group, and the `pkgctl aur` subcommand to assist in transitioning packages from official repos to the AUR. Additionally, `makechrootpkg` now allows users to drop into a debug shell for inspecting failed builds within the chroot. All packaging repo clones also come with a default excludes file to ignore common artifacts. Further changes are listed in the [changelog][7]. ## mkinitcpio The latest [mkinitcpio release v38][8] introduces key changes, including the deprecation of `--microcode` option in favor of a new microcode hook for early microcode loading. mkinitcpio now supports creating an early CPIO image, with the `microcode` hook handling the integration of early microcode into this image. ## ArchWiki To enhance readability, [the color of visited links has been updated][9] from gray to the MediaWiki default purple. In addition to [welcoming CodingKoopa and Andreymal][0] to their new roles as ArchWiki Maintainers, we are also excited to [welcome Dybdeskarphet][0], who joins as a new Translator. ## RFC An [RFC has been accepted][10] to add `-fno-omit-frame-pointer` and `-mno-omit-leaf-frame-pointer` to the default compilation flags to improve the effectiveness of profiling and debugging tools. ## Packaging ### ghc We have successfully rolled out GHC 9.2 after resolving all outstanding issues, marking another step toward the latest GHC. ### Plasma 6 Plasma 6, KDE Frameworks 6 and KDE Applications 24.02 (mostly ported to Qt6) are now available in the repositories. ### Statistics In this month, we’ve successfully rolled out 8196 package updates addressing various enhancements and rebuilds, including 2612 package upgrades. Additionally, we’ve received 168 new package issues, while resolving a total of 216 issues. [0]: https://wiki.archlinux.org/title/ArchWiki:News#2024/02/29_-_New_maintainers… [1]: https://lists.archlinux.org/hyperkitty/list/arch-general@lists.archlinux.or… [2]: https://wiki.archlinux.org/title/Arch_Testing_Team [3]: https://bbs.archlinux.org/viewtopic.php?id=293464 [4]: https://fosstodon.org/@archlinux/111907965691846810 [5]: https://www.reddit.com/r/archlinux/comments/1aniloc/join_the_arch_testing_t… [6]: https://gitlab.archlinux.org/archlinux/archiso/-/issues/144 [7]: https://gitlab.archlinux.org/archlinux/devtools/-/releases/v1.1.0 [8]: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v38 [9]: https://wiki.archlinux.org/title/Special:Permalink/800562#Visited_links_are… [10]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/26

1 0

Enabling split debug for kernels?
by Jan Alexander Steffens (heftig) 14 Sep '24

14 Sep '24

Hi list, As of Pacman 7.0.0, we can have makepkg create debug packages for our kernels, however... Compressed modules are not scanned, meaning either we continue to use INSTALL_MOD_STRIP=1 (throwing away debuginfo for all modules), we disable compression, or we have to enhance makepkg further. For reference, without module compression, the package size of linux drops from 135 MiB to 98 MiB and its installed size rises from 135 MiB to 562 MiB. Debian has been compressing their kernel modules since last year. Instead of splitting debuginfo, they install unstripped modules into /usr/lib/debug/: https://salsa.debian.org/kernel-team/linux/-/commit/e8b64e4b4318aaaf7222f47… Fedora & RHEL do not compress kernel modules, for the same reason of incompatibility with split debuginfo: https://bugzilla.redhat.com/show_bug.cgi?id=1349651 In addition, with compression disabled, the split debuginfo step of packaging linux takes 1½ hours on our build server, which is less than optimal. From what I can tell, that time is spent in the # create any needed hardlinks loop, causing runtime to explode quadratically (amount of stripped files × amount of files in the package). When the kernel is built with module compression, it also adds support for decompressing modules with the selected compression without help from kmod. This seems to be needed in some edge cases, so reënabling compression wouldn't be as easy as adding a module compression stage to makepkg. Debian ran into problems when they missed enabling this support: https://salsa.debian.org/kernel-team/linux/-/merge_requests/980 The issue tracking split debug is at https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/2 The MR to test split debug is at https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/merge_req… It would be nice to have full debuginfo available. Greetings, Jan

1 0

News draft: Manual intervention for pacman 7.0.0 and local repositories required
by gromit 13 Sep '24

13 Sep '24

Hello everyone, with the move of pacman version 7.0.0 a few changes might require manual intervention from end users, which shall be described in the following news item! If you have feedback to it feel free to reply directly! ------ # Manual intervention for pacman 7.0.0 and local repositories required With the release of [version 7.0.0][0] pacman has added support for downloading packages as a separate user with dropped privileges, which we deem a good default for our distribution. For users with local repos however this might imply that the download user does not have access to the files in question, which can be fixed by assigning the files and folder to the "alpm" group. $ chown $USER:alpm -R /path/to/local/repo This is of course only relevant after you have successfully [merged the .pacnew][1] files. Pacman also introduced [a change][2] to improve checksum stability for git repos that utilize .gitattributes files. This might require a one-time checksum change for PKGBUILDs that use git sources. [0]: https://gitlab.archlinux.org/pacman/pacman/-/blob/master/NEWS?ref_type=heads [1]: https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave [2]: https://gitlab.archlinux.org/pacman/pacman/-/commit/9548d6cc765b1a8dcf933e8…

2 1

Replacing mlocate with plocate
by Morten Linderud 10 Sep '24

10 Sep '24

Yo! I'm going to drop `mlocate` from the repositories and provide `plocate` as the default locate in Arch Linux. mlocate is very much an abandoned project, while plocate is a modern implementation with a faster database implementation along with io_uring support. https://plocate.sesse.net/ The question is if people feel a strong desire to keep a locate implementation in `[core]` or if we are fine with this living inside `[extra]`. Adding `plocate` to `[core]` would mean we would need to move a `liburing` to `[core]` and I don't really know if we need that. Any opinions? -- Morten Linderud PGP: 9C02FF419FECBE16

4 4

Arch Linux public upload server
by Orhun Parmaksiz 03 Sep '24

03 Sep '24

Hey all! As some of you might already know, I maintain an upload server project called `rustypaste`: https://archlinux.org/packages/extra/x86_64/rustypaste/ I’ve been using it daily for a couple of years now and have been quite happy with it. I used to provide a public instance for free use, but due to some issues with the provider, I had to shut it down: https://github.com/orhun/rustypaste/issues/326 The other day, I started wondering why Arch Linux shouldn't support a similar public service, like https://paste.ubuntu.com, but powered by rustypaste. I believe we could configure rustypaste to allow public uploads with a retention period and necessary security measures in place. I was going to bring this up with the DevOps team, but I thought it might be better to get general opinions on the matter first. 🐻 Cheers, Orhun

5 5

ell 0.68-1 pulled from testing
by Andreas Radke 28 Aug '24

28 Aug '24

I have pulled ell 0.68-1 from testing because it breaks current iwd in extra and the new iwd release has not happened yet. Please downgrade to the ell version in extra repository. -Andy

1 0

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

Taking a break soon
by Orhun Parmaksiz 26 Jun '24

26 Jun '24

Hey! I will be taking a break from computers between the dates 29-06-2024 and 26-07-2024. During this period I won't have access to the internet so I will be pretty much unreachable. But if there is something hella urgent drop me a call on my cell - I might or might not call back. Let me know if there is anything (in the following days) and feel free to bump my packages. P.S. everything is fine, just need some time to reset :) Have a nice summer everyone!

2 1

glib2-devel split from glib2
by Jan Alexander Steffens (heftig) 11 Jun '24

11 Jun '24

Hi, Thanks to Fabian, as of 2.80.3-1, the development utilities requiring additional dependencies (*python*, *python-packaging*, *libelf*) have been split from *glib2* into *glib2-devel* with proper depends. You may need to add *glib2-devel* to the makedepends of your packages to get them to build again. At the same time, consider removing *python* or *python-packaging* from the makedepends if they were only added to run gdbus-codegen, glib-genmarshal or glib-mkenums. Greetings, Jan

1 0

pre-releases (for systemd & co) in core-testing
by Christian Hesse 08 Jun '24

08 Jun '24

Hello everybody, I used to push later pre-releases for essential core packages (for example systemd and util-linux) to core-testing. The idea was to have some extra testing even before building the final packages. For some time this worked quite well... Lately this broke, though. Our current tooling (pkgctl from devtools) builds packages (at least core ones) in core-testing. We then moved a package that was built with util-linux 2.40rc2. It's dynamic linking was ok, but it required the symbol MOUNT_2_40 from libmount.so, still breaking. We had to move the util-linux pre-release packages to core to solve this. Of course this had not been detected before, because packages in testing were ok in that combination. So wondering how to solve this, and have some extra testing anyway. The more people testing pre-release packages the better... Having said that - I have set up a custom repository for now with systemd 256rc2. To test that add these lines to your pacman.conf: [testing] Server = https://pkgbuild.com/~eworm/$repo/$arch/ Feedback welcome! -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

4 7

Adding Emil Velikov as maintainer of libudev0-shim
by Morten Linderud 05 Jun '24

05 Jun '24

Yo, `libudev0-shim` is a udev compat shim that some of our packages, most notably stream, and a few other downstreams utilize. It was written 8 years ago by Dave Reisner and has seen no development since then, but Valve/Steam has sent a couple of changes to this project. I originally asked on IRC if anyone wanted to maintain this, but after no response Emil replied on a PR that he would gladly take over maintainership of this project. Emil has been around for a few years on bugreports and misc patches to upstream projects, and generally is a nice guy. I can't see anyone objecting to this so I've asked devops to add them to the Github repository. This emailserves as a headsup that Emil is now the maintainer of the project. https://github.com/archlinux/libudev0-shim -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

Stepping down
by Maxim Baz 27 May '24

27 May '24

Hi everyone Life got busier than ever, and I find myself unable to give nearly as much attention to packaging that it deserves. As such, I believe the most respectful course of action would be for me to step down as package maintainer now, and re-apply in the future if this makes sense. There's no immediate action needed for any of my packages, I have updated them all today. But here's the list of packages where I'm the sole maintainer, it would be awesome if some of them would earn your interest to adopt them: aspell-da browserpass browserpass-chromium browserpass-firefox curlie gocryptfs goimapnotify grub-btrfs kitty libu2f-server pam-u2f python-black python-i3ipc rebuild-detector swappy ttf-joypixels wire-desktop wldash yubikey-touch-detector Best wishes Maxim Baz

6 5

Cleaning up some of my packages
by Filipe Laíns 24 May '24

24 May '24

Hi everyone, A while ago I wrote to the staff mailing list about my lack of activity. Thankfully, I think I am finally now slowly getting back up to speed with life and my open source commitments. If someone wants more details, I wrote a bigger explanation on [1] (tw: mental health). To help with this, I think I should do some cleaning up of my packages, I have disowned a bunch of them. Several of them, such as the Deepin, Budgie, and D packages, had a co-maintainer, so they should be alright. The ones that didn't are listed below. I tried to list the maintainers of the dependents to make it easier to identify. Packages with dependents: pyannotate (check dependency for python-py7zr, cc Caleb) python-dill (dependency for python-pylint, cc Caleb) python-future (dependency for a bunch of Felix's packages, and more) python-multipart (dependency for python-moto, cc Chih-Hsuan) python-py (dependency for python-pytest-forked, cc Felix) python-pypng (dependency for python-qrcode, cc Felix, Levente, Caleb) python-zc.lockfile (dependency for python-cherrypy and python-pytest-services, cc Thore and David) (check/optional dependencis for python-fastapi) python-aiomysql python-aiopg python-aiosqlite (also hard dependency for python-ypy-websocket, cc Antonio) python-asyncpg (also hard dependency for nominatim, cc Justin) python-databases D ecosystem packages without dependents: adrdox d-containers d-mir-core d-stdx-allocator gir-to-d glibd mustache-d General packages without dependents: bluefish budgie-extras dbxtool (deprecated — archived on Github, and replaced by fwupd) flterm fusesoc grub-theme-vimix log4cpp netcf pulseaudio-equalizer-ladspa python-biopython python-bitcoinlib python-edalize python-euclid3 python-ipyxact python-litevideo python-litedram python-liteeth python-liteiclink python-litejesd204b python-litepcie python-litesata python-litescope python-litesdcard python-litevideo python-litex python-litex-boards python-livereload python-kikit python-markdown2 python-migen python-occ-core python-okonomiyaki python-pybars3 python-pymeta3 python-pypubsub python-pyvcd python-simplesat python-solidpython python-sphinx-typlog-theme python-svgwrite python-watchgod thefuck This lists includes flatenned dependency trees, so if you adopt any of the packages listed as without dependents, please be keep in mind they might depend on other packages on the list. You might want to pick up those too. [1] https://ffy00.github.io/blog/03-state-of-things-2024-04/ Cheers, Filipe Laíns

1 0

Re: pre-releases (for systemd & co) in core-testing
by Christian Hesse 23 May '24

23 May '24

Genes Lists <lists(a)sapience.com> on Thu, 2024/05/23 06:27: > On Thu, 2024-05-23 at 09:16 +0200, Christian Hesse wrote: > > Christian Hesse <list(a)eworm.de> on Wed, 2024/05/15 11:08: > > > .. > > > Feedback welcome! > > > > Pushed systemd 256rc3-1 last night. All the same applies... > > Please keep testing! > > Hi Christian > > For feedback do you plan to make this visible in the package > signoffs page [1] or do you want a quick email with ack/nack? > > For now: > > mkinitcpio-39.1-1.1 - all good > systemd-256rc3-1 - all good > > gene > > [1] https://archlinux.org/packages/signoffs/ Good point! I would have to push to core-testing repository for the packages to be visible for signoffs. That's what I tend to avoid now with pre-releases. So short notice via mail or messaging is fine. Thanks! -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 0

Re: pre-releases (for systemd & co) in core-testing
by Christian Hesse 15 May '24

15 May '24

Randy DuCharme <radio.ad5gb(a)gmail.com> on Wed, 2024/05/15 05:06: > Suggestion (s). This is open source real life comes first, always. > > People that volunteer to help are genuinely real but being ignored wins > ZERO.... even if they have 27 years of C C++ No idea what you want to tell me... Really. Please try again if this is a serious suggestion related to the topic. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 0

Mesa pulled from testing
by Jan Alexander Steffens (heftig) 08 May '24

08 May '24

I've removed Mesa 1:24.0.7-1 from testing as the radeonsi driver crashes immediately, somewhere deep in LLVM. This concerns the following packages: • libva-mesa-driver • mesa • mesa-vdpau • opencl-clover-mesa • opencl-rusticl-mesa • vulkan-intel • vulkan-mesa-layers • vulkan-nouveau • vulkan-radeon • vulkan-swrast • vulkan-virtio • lib32-libva-mesa-driver • lib32-mesa • lib32-mesa-vdpau • lib32-opencl-clover-mesa • lib32-opencl-rusticl-mesa • lib32-vulkan-intel • lib32-vulkan-mesa-layers • lib32-vulkan-nouveau • lib32-vulkan-radeon • lib32-vulkan-swrast • lib32-vulkan-virtio

1 0

Orphaning some packages
by Chih-Hsuan Yen 04 May '24

04 May '24

Hi all, I'm going to orphan some packages that I no longer need or depend on, so that I can better focus on my other packages. Here is the package list: * fcitx-chewing * nextcloud-client * python-nbdime * python-nbval * python-openpyxl * python-pg8000 * python-prctl * python-scramp * python-sure * python-testing.postgresql (may be dropped - depends on python-nose, no upstream commits since 2017) * scim-chewing * web-ext Please adopt packages you need, thanks! Best Regards, Chih-Hsuan Yen (yan12125)

1 0

time64 ABI fix coming to upstream glibc
by Florian Weimer 02 May '24

02 May '24

The <utmp.h> and <utmp.h> headers had a bug that the on-disk structures defined there could change size on some targets when _TIME_BITS was set to 64. This is obviously wrong because the files are not going to magically change their layout because the application accessing them was built in a specific way. We're going to fix this in glibc upstream on the stable release branches, going all the way back to glibc 3.34 (the first release with this kind of time64 support). After the fix, the _TIME_BITS definition will no longer impact struct layout. Usually, that means epoch fields are 32-bits wide, to match co-installable architectures. To extend the usable life-time of these interfaces somewhat, glibc 2.40 changes epoch fields to unsigned types in these structures. This change is specific to the upcoming glibc 2.40 release, I do not plan to backport it. Thanks, Florian

1 0

Archweb ToDo Notes
by Jelle van der Waa 28 Apr '24

28 Apr '24

Hi all, Archweb ToDo's now have a link called "Todo Notes" this links to an md.archlinux.org pad based on the todo slug (prefixed with archweb) to avoid conflicts. Hopefully this helps collaboration on todo's which are a bit more complicated or require additional information. So for example for: https://archlinux.org/todo/drop-python-exceptiongroup/ There is now automatically: https://md.archlinux.org/archweb-drop-python-exceptiongroup Hopefully this helps with sharing why something is not rebuild/finished in a todo with links to issues. Archweb cannot detect if soemone has written to the pad, so maybe the body should have a *note* about it :-) Greetings, Jelle

1 0

Python 3.13 specific packaging issues
by Jelle van der Waa 27 Apr '24

27 Apr '24

Hi all, We are almost ready to drop Python 3.12 in testing, hopefully tensorflow can be pursued-ed to recompile against [staging] soon. This Python release dropped the `imp` module, but the next release (3.13) which is slated for October this year will drop more Python batteries, some methods and some unittest invocations. [1] I already scanned a part of the Python packages and the mailcap and cgi deprecation will be a bit painful. (And logger.warn usage but that is easy to patch to logger.warning) I want to propose to open issues per package for Python 3.13 compatibility, it would point out what is not compatible and ideally link to an upstream issue or let the package maintainer create this issue. Once we are ready to start thinking about a Python 3.13 rebuild we can go through the list of issues with a `python-3.13` label. [2] Finding issues now will hopefully: a) convince packages we maintain to get a new release b) a happier rebuild c) find packages which are issues and should likely not be maintained in the repos There is one caveat, the changelog is draft. I am not sure if Python has a history of reverting breaking changes in an alpha release. But as far as I know these things have been deprecated for quite a while. We have a history of not opening upstream issues in our packaging repository, but I think for this scenario it would make sense and actually help us deliver Python sooner in the repos. [1] https://docs.python.org/3.13/whatsnew/3.13.html [2] https://gitlab.archlinux.org/groups/archlinux/packaging/packages/-/issues Greetings, Jelle van der Waa

4 6

RFC Final Comment Period: Arch Linux Ports
by David Runge 25 Apr '24

25 Apr '24

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/32 Please visit the above link for discussion. Summary: Introduce "Arch Linux Ports" as testbed for unofficial architectures until they are integrated in the main Arch Linux repositories. This integration is meant to provide infrastructure and community-based support for architectures until they are fully supported by the main distribution.

1 0

Python 3.12
by Jelle van der Waa 21 Apr '24

21 Apr '24

Hi all, We should get started on Python 3.12, 3.13 alpha is already getting released! To be 100% honest, I am not super looking forward to it as it's a ton of work due to our lack of automated tooling. In basics a plan would be to first tackle low hanging fruit to-do's: * https://archlinux.org/todo/pytest-runner-removal/ * https://archlinux.org/todo/imp-module-removal-in-python-312/ * https://archlinux.org/todo/use-pyprojecttoml-for-building-if-supported/ * drop unused python modules in our repo https://archlinux.org/devel/reports/unneeded-orphans/ We've finished python-bootstrap, and can bootstrap the required build packages (python-setuptools, build, etc.). And figuring out the rebuild order. (Big thanks to david, for the help here!) [1] [2] So soon we can start the rebuild which will probably take a while to complete as we have no good automated tooling yet for mass rebuilds. This rebuild will likely block [staging] for a good 2 or more weeks, so when would be a good time to schedule this? I expect two things to break our package builds in 3.12: * The removal of distutils see the snippet below, adding python-setuptools to makedepends should resolve this. For example: GISCAN ZBar-1.0.gir Traceback (most recent call last): File "/usr/bin/g-ir-scanner", line 99, in <module> from giscanner.utils import dll_dirs File "/usr/lib/gobject-introspection/giscanner/utils.py", line 385, in <module> import distutils.cygwinccompiler ModuleNotFoundError: No module named 'distutils' * The removal of the imp module, the todo list above has been open for a while, but not all packages have been fixed. * The usual failing tests, missing sources you know it :) [1] https://gitlab.archlinux.org/archlinux/python-bootstrap/-/merge_requests/3 [2] https://notes.vdwaa.nl/arch/python.html Greetings, Jelle

2 6

News draft: Arch Linux Leader Election Results
by gromit 12 Apr '24

12 Apr '24

Hello everyone, a few people have asked for the election results to be published as a News announcement. If you have any feedback regarding the draft below feel free to send it as a response or ping me on IRC. I will post the announcement at the beginning of next week. ^_^ Cheers, gromit === Recently we held our leader election, and the previous Project Leader Levente "anthraxx" Polyák ran again while no other people were nominated for the role. As per [our election rules](https://wiki.archlinux.org/title/DeveloperWiki:Project_Leader#Electi… he is re-elected for a new term. The role of of the project lead within Arch Linux is connected to [a few responsibilities](https://wiki.archlinux.org/title/DeveloperWiki:Project_Le… regarding decision making (when no consensus can be reached), handling financial matters with SPI and overall project management tasks. **Congratulations to Levente and all the best wishes for another successful term!** ===

1 0

Re: Arch Linux Rust packaging licensing problem
by Jan Alexander Steffens (heftig) 07 Apr '24

07 Apr '24

On Sat, Apr 6, 2024 at 10:42 PM Arvid Norlander <arvid(a)vorpal.se> wrote: > Hi, > > After talking to people on Arch Linux IRC channels (mpan in particular) > about this, they recommended I contact you directly about this, since it > affects many packages (so filing a bug on any specific package wasn't > really > appropriate). > > Arch only packages the final binary crates for Rust (as opposed to separate > packages for every single Rust dependency, which would rightfully drive > people crazy). As a result, you only get one single package that contains > many libraries. > > Lets take an example: ripgrep, which links to ~53 dependencies (maybe less, > not all dependencies are used on all platforms, etc). Many of these > dependencies use MIT license or similar that requires: > > > The above copyright notice and this permission notice shall be included > in > > all copies or substantial portions of the Software. > > Looking in /usr/share/licenses/ripgrep I only see the copyright notice > for ripgrep itself. This is a bit of a problem. > > Similarly, one of it's dependencies is unicode-ident which uses > "Unicode-DFS-2016" as it's license. That is missing. encoding_rs is > "(Apache-2.0 OR MIT) AND BSD-3-Clause" (which may collapse down to MIT, not > sure, I am not a lawyer). > > So I can see two problems here: > > 1. Copyright notices that need to be included for dependencies, aren't. > 2. The SPDX expression may be incorrect (missing some things from > dependencies that should be included). > > Looking at some other packages (not just ripgrep) I see similar issues > across all of those packages. > > Now, for something like rust it would be impossible to require the > maintainers to handle this by hand. So lets talk solutions. > > * There is cargo-about (already packaged in Arch, also has suspect > license/copyright info). It doesn't do quite what you want: Given a > config and a handlebar template it will generate an HTML page with all > the licenses you use. It will collapse "OR" in the license info based on > a priority list of which licenses you prefer. > > You could perhaps wrangle the handlebar template to generate a text > file instead of a HTML file, not sure. It can also output a JSON file > instead though (I have used that at my dayjob for license compliance). > > While it is a good solution, it is not a drop-in solution without > additional scripting on top (and you need to specify accepted licenses > for your project). > > * I believe Fedora has some automated tooling based on this comment by a > Fedora packager: > https://users.rust-lang.org/t/psa-check-if-your-cargo-crates-are-clean-and-… > > That is for the SPDX expression. I have not looked into the details of > their tooling. > > * Debian probably have thought about this too, they tend to be rather > careful (some may say up-tight even) about this sort of issues. It might > be worth checking out what they did. > > I'd like some automated tooling that works for AUR too, I maintain some > Rust packages there (some of which I'm also the upstream for). For that > reason, I'd be happy to stay "in the loop" on this issue as well as > possibly help (time and energy permitting, due to recently recovering from > burnout, energy tends to vary on a day to day basis), rather than treating > it as a one-off issue report. > > Is it a high priority issue? No. > Should it be solved eventually? Yes, for legal reasons. > > Best regards, > Arvid Norlander > (Arch Linux user and Rust / C++ software developer) > Hi Arvid, Thanks for bringing this issue to my attention and your detailed email about it. I'm CCïng our public development mailing list in this response so our other maintainers get informed, too. I agree that Arch needs a solution for this eventually. Unlike Fedora we do not package Rust libraries so I think we need some help from Cargo for this. Preferably from upstream, but a third-party tool would work as well. Ideally, I think there we would create a SPDX license expression from the entire crate tree and then simplify it, e.g. to turn `(MIT) AND (MPL-2.0 OR MIT) AND (MIT AND BSD-2-Clause) AND (MPL-2.0 OR BSD-3-Clause)` into `MIT AND BSD-2-Clause AND (MPL-2.0 OR BSD-3-Clause)`. Or perhaps even simpler if the tool had knowledge about which licenses are covered by others. We could call such a tool in the `package()` function to set the `license` for the package. I'm not sure how feasible this would be. Are crates required to use SPDX expressions? Greetings, Jan

1 0

News draft: Increasing the default vm.max_map_count value
by Robin Candau 05 Apr '24

05 Apr '24

MD pad available at https://md.archlinux.org/xl4oBGN9SDWRXnfvHuLhgg?both ---- # Increasing the default vm.max_map_count value As per [this proposal](https://lists.archlinux.org/archives/list/arch-dev-public@lists.a…, we decided to increase the [vm.max_map_count](https://docs.kernel.org/admin-guide/sysctl/vm.html#max-ma… value from the default `65530` to `1048576`, based on the same change that multiple distributions already did on their respective side. This change should help addressing performance, crash or start-up issues for some memory intensive applications, particularly for (but not limited to) [some Windows games](https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792/comment… played through Wine/Steam Proton. Overall, it goes forward a smoother user experience out of the box with no expressed concerns about potential downsides in the related proposal. This `vm.max_map_count` increase is introduced in the `2024.04.07` release of the [filesystem package](https://archlinux.org/packages/core/any/filesystem/) and will be effective right after the upgrade. Before upgrading, in case you're already providing your own value for that parameter in a `sysctl` config file, either remove it (to switch to the new default value) or make sure your config file will be read [with a higher priority](https://man7.org/linux/man-pages/man8/sysctl.8.html#SYSTEM_FILE_P… than the `/usr/lib/sysctl.d/10-arch.conf` file (to supersede the new default value). -- Regards, Robin Candau / Antiz

1 0

New supply-chain security tool: backseat-signed
by kpcyrd 03 Apr '24

03 Apr '24

Hello, I'm going to keep this short, I've been writing a lot of text recently (which is quite exhausting, on top of my dayjob and all the code I wrote today afterwards. Apologies if you're still waiting for a reply in one of the other threads). I figured out a somewhat straight-forward way to check if a given `git archive` output is cryptographically claimed to be the source input of a given binary package in either Arch Linux or Debian (or both). I believe this to be the "reproducible source tarball" thing some people have been asking about. As explained in the README, I believe reproducing autotools-generated tarballs isn't worth everybody's time and instead a distribution that claims to build from source should operate on VCS snapshots instead of tarballs with 25k lines of pre-generated shell-script. Building from VCS snapshots is already the case for a large number of Arch Linux packages (through auto-generated Github tarballs). Some packages have been actively converted to VCS snapshots by Arch Linux staff in response to the xz incident. This tool highlights the concept of "canonical sources", which is supposed to give guidance on what to code review. This is also why I think code signing by upstream is somewhat low priority, since the big distros can form consensus around "what's the source code" regardless. https://github.com/kpcyrd/backseat-signed The README shows how to verify Arch Linux and Debian build cmatrix from the same source code - they may both still apply patches (which would be considered part of the build instructions), but the specified source input is the same. This tarball can also be bit-for-bit reproduced from VCS by taking a `git archive` snapshot of the v2.0 tag in the cmatrix repository. (If somebody ever tells you programming in Rust is slower, I wrote the entirety of this codebase within a few hours of a single day) Let me know what you think. 🖤 Happy feet, kpcyrd

1 0

Re: Proposal to increase the default vm.max_map_count value
by Robin Candau 02 Apr '24

02 Apr '24

> On April 1, 2024 12:09:47 PM UTC, Robin Candau <antiz(a)archlinux.org> wrote: > > On 3/25/24 9:10 AM, Robin Candau wrote: > > Hi everyone, > > I'm writing this mail as proposal to increase the default > `vm.max_map_count` value in Arch Linux. > > > It's been a week since this proposal thread [1] was made. For now it > only received a few but all positives feedback (both from staff > members and users in a related thread on arch-general [2]). > > Do we have any more thoughts anyone wants to share? > > Also, if we are to implement this change, anyone has an opinion > about which package should provide it? So far, the following > packages have been mentioned: > - systemd (as Fedora did) > - procps-ng (as Ubuntu did) > - filesystem > > Given that the proposal goes through, I'll create the MR to the > chosen package accordingly. Also, despite this change being > impact-free (as far as we can tell), I think a related news item to > inform users about this change would be a great idea (I'll write > that as well). > > Please, share your opinion about the change itself or the best > package to provide it if you have any :) > > [1] > https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… <https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o…> > [2] > https://lists.archlinux.org/archives/list/arch-general@lists.archlinux.org/… <https://lists.archlinux.org/archives/list/arch-general@lists.archlinux.org/…> > On 4/1/24 11:11 PM, Ehalls wrote: > I would keep it out of systemd. Do you think it is the approproate place? > > (Copying the above response I received from someone off-list, as it is staff only) Since the change consists of shipping a sysctl file and that sysctl is provided by procps-ng, I personally think procps-ng is the appropriate place. -- Regards, Robin Candau / Antiz

1 2

Proposal to increase the default vm.max_map_count value
by Robin Candau 01 Apr '24

01 Apr '24

Hi everyone, I'm writing this mail as proposal to increase the default `vm.max_map_count` [1] value in Arch Linux. The default `vm.max_map_count` 65530 value is making some Windows games crash (or even prevent them to start at all) while being played through Wine or Steam Play (Proton). Examples are (but not limited to) Star Citizen, THE FINALS, Hogwarts Legacy, DayZ or Counter-Strike 2 (see [2] for a list of bug reported to Valve for these games on that matter). In that regard, SteamOS is shipping an increased `vm.max_map_count` default value to address the above issue and numerous distributions have since then decided to implement that change on their side as well, such as Fedora [3], NixOS [4] and, more recently, Ubuntu [5]. While I'm aware that Arch is a user centric/DIY distro and everyone can set their own `vm.max_map_count` value fairly easily, shipping an increased value on our side would be a beneficial change to make in my opinion as it would result in a smoother gaming experience out of the box for our users without representing any downside/side effect (as far as I'm aware). In terms of implementation, the change basically consists of shipping the following sysctl file: ``` # Increase the number of virtual memory areas that one process may request vm.max_map_count=1048576 ``` For reference, Fedora added it to their systemd package [6], while Ubuntu handled it at the procps level [7]. I personally don't have a strong opinion on the implementation way/place. To sum up, I think this would be a reasonable and positive change to make to our distro. I'd be happy to read your thoughts (or eventual objection)! 😊 [1] https://docs.kernel.org/admin-guide/sysctl/vm.html#max-map-count [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792/comments/5 [3] https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount [4] https://github.com/NixOS/nixpkgs/pull/238459 [5] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792 [6] https://src.fedoraproject.org/rpms/systemd/blob/f39/f/10-map-count.conf [7] https://git.launchpad.net/ubuntu/+source/procps/commit/?h=applied/2%254.0.4… -- Regards, Robin Candau / Antiz

3 4

Mirror hardening - complementing RFC 29
by pitastrudl 28 Mar '24

28 Mar '24

Hi, A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/35 Please visit the above link for discussion. Summary: Before this proposal, there were a lack of security definitions and measures on mirrors within the Arch Linux community. This RFC therefore outlines the requirements, definitions and guidelines surrounding not only hardening but also maintaining proper security of a mirror. Best regards, Arun

1 0

RFC Final Comment Period: Allow all staff to create RFCs
by Kristian Klausen 23 Mar '24

23 Mar '24

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/31 Please visit the above link for discussion. Summary: Grant all Arch Linux staff members, not limited to those in packaging roles, the privilege to initiate RFCs directly, aligning with the broad range of topics these documents encompass.

1 0

Arch Linux minimal container userland 100% reproducible - now what?
by kpcyrd 21 Mar '24

21 Mar '24

hello, in last week's email to the reproducible-builds email list[1] about reproducible Arch Linux I mentioned there's only one unreproducible package left in docker.io/library/archlinux. [1]: https://lists.reproducible-builds.org/pipermail/rb-general/2024-March/00329… Due to amazing work by dvzrv and Foxboron this package is now also reproducible! INFO arch_repro_status > All packages are reproducible! INFO arch_repro_status > Your system is 100.00% reproducible. To try for yourself use: podman run --rm -t archlinux sh -c 'pacman -Suy arch-repro-status --noconfirm && arch-repro-status' However: Where do we go from here? It would be cool if the OCI container image itself could also be reproduced (bit-for-bit), but I'm not sure if there's any prior work (specifically for images listed as 'official' on Docker Hub)? Specifically what I mean - given a line like this: FROM archlinux@sha256:2dbd72d1e5510e047db7f441bf9069e9c53391b87e04e5bee3f379cd03cec060 I want to reproduce the artifact(s) that are pulled in by this, with the packages our Arch Linux rebuilders have reproduced from source code. From what I understand this hash points to a json manifest that is not contained in the container image itself and was generated by the registry (should we archive them?), and this manifest then points to the sha256 of the tar containing the filesystem (I'm possibly missing an indirection here). Hopefully one of the many SBOM formats can help with this. :P I know the container image is built from these two repositories but I don't have any in-depth knowledge: - https://github.com/docker-library/official-images/blob/master/library/archl… - https://gitlab.archlinux.org/archlinux/archlinux-docker The only work towards reproducible container images I'm aware of is by Akihiro Suda: https://github.com/reproducible-containers/repro-get#are-container-images-b… I'm suspecting the current scripts used by Arch Linux would still be prone to mirror changes[2] though, meaning new package uploads would end up in our reproduced artifacts (causing mismatches) and the container image could only be reproduced for a short amount of time. [2]: https://gitlab.archlinux.org/archlinux/archlinux-docker/-/blob/98cd79111dd5… I'm also not sure if there's a missing puzzle piece with reproducible containers in regards to this manifest json that is generated by the registry. The image digest being unpredictable has also been mentioned in a cosign github issue[3]. [3]: https://github.com/sigstore/cosign/issues/2516 Input much appreciated! ## Caveats Probably worth mentioning, at the time of writing there's no consensus across multiple orgs yet, the https://reproducible.archlinux.org instance reports this status, two other rebuilders don't report the full 100% yet. $ arch-repro-status -r https://reproducible.crypto-lab.ch [...] INFO arch_repro_status > 3/118 packages are not reproducible. INFO arch_repro_status > Your system is 97.46% reproducible. $ arch-repro-status -r https://wolfpit.net/rebuild [...] INFO arch_repro_status > 3/118 packages are not reproducible. INFO arch_repro_status > Your system is 97.46% reproducible. The packages in question are part of this rebuild todo (specifically gcc-libs, glibc, ncurses): https://archlinux.org/todo/rebuild-core-with-reproducible-pacman/ Meaning there's currently some luck involved for these 3 packages, e.g. using btrfs currently increases your chances to get an exact match (after a few tries). We're obviously trying to get rid of this caveat though. --- If you appreciate this flavor of supply-chain security you may be interested in repro-env[4] that I'm currently trying to land[5] in ubuntu 24.04 LTS, but is blocked by Debian's libnettle[6]. [4]: https://github.com/kpcyrd/repro-env [5]: https://tracker.debian.org/pkg/rust-repro-env [6]: https://tracker.debian.org/pkg/nettle cheers, kpcyrd

3 2

Revising Go packaging guidelines (2024)
by kpcyrd 21 Mar '24

21 Mar '24

hello, the Arch Linux Go packaging guidelines[0] currently suggest this for building software written in Go: > export CGO_CPPFLAGS="${CPPFLAGS}" > export CGO_CFLAGS="${CFLAGS}" > export CGO_CXXFLAGS="${CXXFLAGS}" > export CGO_LDFLAGS="${LDFLAGS}" > export GOFLAGS="-buildmode=pie -trimpath -ldflags=-linkmode=external -mod=readonly -modcacherw" > > # or alternatively you can define some of these flags from the CLI options > go build \ > -trimpath \ > -buildmode=pie \ > -mod=readonly \ > -modcacherw \ > -ldflags "-linkmode external -extldflags \"${LDFLAGS}\"" \ > . [0]: https://wiki.archlinux.org/title/Go_package_guidelines There's also section "2.2.2 Supporting debug packages" which contradicts the previous section. ## Suggestion I'd like to propose changing this to something like: > prepare() { > cd ${pkgname}-${pkgver} > go mod download > } > > build() { > cd ${pkgname}-${pkgver} > go build . > } > > package() { > cd ${pkgname}-${pkgver} > install -Dm0755 -t "${pkgdir}/usr/bin/" "${pkgname}" > } Plus any extra flags (for example for debug packages to work, if any are needed at all - there's a note about this towards the end of this essay). Instead of suggesting two (three) different approaches, the packaging guidelines should endorse argv over environment variables (how to set them with environment variables can still be documented in a later section of the guideline). The reason I'm suggesting this: ## Passing flags over argv Setting these options through environment variables is for cases when `go` isn't executed directly by our PKGBUILD, but instead by some indirection like a Makefile. Makefiles are more popular in Go projects than they are in e.g. Rust projects, but presumably because for many years (10+) there was no analogous to `env!("CARGO_PKG_VERSION")` to embed a version string into the binary for --version output. Since almost exactly two years ago, in Go 1.18 released March 2022, there's now `runtime/debug.ReadBuildInfo` which gives you a reference to an embedded struct that contains a version string[1]. [1]: https://pkg.go.dev/runtime/debug#ReadBuildInfo Hopefully more Go projects are going to favor this in the future over custom build scripts and passing `-X main.Version=...` with output from `git describe --tags`. If this catches on, people might think of `go build` more like they currently think of `cargo build` and I think the Go package guideline should encourage this. Not just for Go but for software in general, using `git describe` should be considered an anti-pattern. In the way the Arch Linux build system currently works, only the checked out files are authenticated and pinned by sha256sums= and friends, but `git describe` explicitly works on unauthenticated git objects in `.git/`. I've published a writeup on how to take advantage of this on the reproducible builds list in September 2023[2]. [2]: https://lists.reproducible-builds.org/pipermail/rb-general/2023-September/0… ## Using the Go native Linker Binaries built by the Go compiler have been reproducible for a long time, however Go binaries built by Arch Linux usually aren't. This has led to some confusion, with bug reports to upstreams of Go software because it wasn't obvious that the package not being reproducible in this case isn't a problem in upstream's source code, but the way Arch Linux compiles it. Arch Linux generally prefers binaries with hardening flags enabled[3] and therefore explicitly opts into a non-default linker (Cgo), but it seems to be the unpopular choice. Cgo seems to have less support than normal Go on Linux (evidently, since Cgo has been known to have reproducible build issues for years now). Other Linux distributions seem to stick to normal Go too, Nix has Cgo off by default[4] and searching through nixpkgs for "buildGoModule" yields about 2k results, searching for "CGO_ENABLED" has 105 results, with more than half being "CGO_ENABLED=0" though. Alpine Linux only sets GOFLAGS globally[5] (which Arch Linux currently doesn't), searching for `rg -l --multiline '\tgo.*build'` in aports matches 356 files, `rg -l CGO_ENABLED=0` matches 23 files and `rg -l CGO_ENABLED=1` matches 18 files. [3]: https://github.com/jvoisin/compiler-flags-distro [4]: https://github.com/NixOS/nixpkgs/blob/b081342f1c16e4cbe4f40f139bbdda1475ea3… [5]: https://git.alpinelinux.org/abuild/tree/default.conf?h=3.12.0#n5 The global GOFLAGS as specified in Alpine Linux are: > export GOFLAGS="-buildmode=pie -modcacherw -trimpath -buildvcs=false" Which we could consider setting globally too, like we do with RUSTFLAGS. Figuring out what Debian does was somewhat challenging, their integration with the go build system is called dh-golang[6], they seem to set CGO_ENABLED=1 only when cross-compiling, with go >= 1.13 (released 2019) they seem to build with `go install -trimpath ...` and no further GOFLAGS environment variable. [6]: https://salsa.debian.org/go-team/packages/dh-golang/-/blob/debian/sid/lib/D… I understand the concern of Go possibly being more prone to ROP-style exploits when 1) built with the native linker and 2) used with e.g. a vulnerable version of libgit2, however, as of 2024, there have been barely any memory-corruption based exploits for Go software. ## Motivation - Most of our Go software is currently not reproducible due to Cgo, including core/libcap, which is the last unreproducible package in docker.io/library/archlinux - The barrier for packaging Go in Arch Linux is currently somewhat high (compared to e.g. packaging Rust), the guideline requires too much interpretation and could be improved - Quirks that are only needed for old Go projects (like 2.1.1) should be listed towards the end instead of being the first code block in the guideline --- cheers, kpcyrd

2 1

Spring cleanup '24
by gromit 20 Mar '24

20 Mar '24

Hello everyone, the amount of birds that are chirping in front of my flat make it clear that spring is coming (at least to Heidelberg). :p Therefore it is time to do our annual spring cleanup and free the repos from any leftovers. Please head to https://archlinux.org/devel/reports/unneeded-orphans/ and adopt packages that you'd like to keep in the repos. The devs among us should maybe also have a look at the (few) [orphans in [core]][0]. This is maybe also a good time to re-evaluate the current package set you maintain and disown anything that you've lost interest in so others can properly maintain it either in the repos or the AUR. Feel free to drop a message here if its anything major. I will start dropping packages on 2024-03-17, so please try to have a look at the lists in the next few days. Cheers, gromit [0]: https://archlinux.org/packages/?sort=&repo=Core&q=&maintainer=orphan

5 7

RFC Final Comment Period: Create new AUR moderator role
by Torsten Keßler 16 Mar '24

16 Mar '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/19 Please visit the above link for the discussion. Summary: Create a dedicated role for the moderation of the AUR that supports and eventually replaces the Package Maintainers as the current moderators.

1 1

pacman in testing can cause some issues for packagers
by Morten Linderud 15 Mar '24

15 Mar '24

Yo, With `pacman` in testing `[core-testing]` there might be some issues for packagers that use `makepkg --geninteg` or `updpkgsums` and submitting the source packages to build.archlinux.org. As the *sums=() array will contain an integrity check for git sources in pacman 6.1 and beyond the older pacman version on build.a.o is not going to understand this and fail the build. Just set the array to 'SKIP' as usual and it should build fine. I'm not aware of any other packager issues as of writing. -- Morten Linderud PGP: 9C02FF419FECBE16

2 2

RFC: Arch Linux Ports
by David Runge 11 Mar '24

11 Mar '24

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/32 Please visit the above link for discussion. Summary: Introduce "Arch Linux Ports" as testbed for unofficial architectures until they are integrated in the main Arch Linux repositories. This integration is meant to provide infrastructure and community-based support for architectures until they are fully supported by the main distribution.

1 0

pacman 6.1.0 and libalpm.so.14 rebuild
by Morten Linderud 09 Mar '24

09 Mar '24

Yo, pacman 6.1.0 is now in staging and I've made a gitlab epic and a todo for the rebuild. https://archlinux.org/todo/libalpmso-rebuild/ https://gitlab.archlinux.org/groups/archlinux/packaging/packages/-/epics/2 Currently a Rust and some C stuff is failing to build. -- Morten Linderud PGP: 9C02FF419FECBE16

2 1

Future of libdepends and libprovides
by Balló György 09 Mar '24

09 Mar '24

Hi all, Since the support for libdepends and libprovides has been removed from the recently released pacman 6.1, [1] we need to do something before adopting it to Arch Linux. Many our packages rely on libdepends and libprovides, and if makepkg would not fill the soname version and architecture, those dependencies would be broken. I mentioned this one year ago, but no further discussions happened. [2] In short term, we should revert this commit [3] at distribution level to avoid breakages. In long term, we have to decide via RFC what to do with libdepends and libprovides. We could probably make a slow, manual transition to the new 'autodeps' feature in pacman, but it still does not support optional autodeps, [4] which means that would be impossible to mark any binary deps as optional. [1] https://gitlab.archlinux.org/pacman/pacman/-/releases/v6.1.0 [2] https://lists.archlinux.org/hyperkitty/list/arch-dev-public@lists.archlinux… [3] https://gitlab.archlinux.org/pacman/pacman/-/commit/354a300cd26bb1c7e655147… [4] https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/58 -- György Balló Package Maintainer

2 1

RFC: Allow all staff to create RFCs
by Kristian Klausen 05 Mar '24

05 Mar '24

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/31 Please visit the above link for discussion. Summary: Grant all Arch Linux staff members, not limited to those in packaging roles, the privilege to initiate RFCs directly, aligning with the broad range of topics these documents encompass.

1 0

Consolidating our mkinitcpio hooks
by Morten Linderud 03 Mar '24

03 Mar '24

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

5 10

Announcing pacquery
by Jelle van der Waa 03 Mar '24

03 Mar '24

Hi all, One of the things I've been missing for a long time is the ability to easily query package information. Pacman -S --print-format lacks some options and more importantly does not support json output. I've had a small rust utility locally which helped a lot with getting ready for the pacman rebuild. This weekend I spend some time refining it and releasing it to the repos as pacquery. An example, finding all packages which have make/check/depends on python-tomli [jelle@natrium][~/projects/pacquery]%pacquery python-tomli | jq -r '.[].required_by | join(" ")' python-flake8-black python-ipdb python-setuptools-gettext python-setuptools python-responses python-tomli-w python-fsspec sip mdformat repod mypy autopep8 python-diff-cover python-pep621 python-versioningit python-pylint python-pdm-pep517 python-sphinx-theme-builder python-pytest-cov towncrier python-isort Note that this tool uses the syncdb's so these need to be up to date and it defaults to core,extra,multilib. Greetings, Jelle van der Waa

1 0

GHC 9.2.8 enters [extra-testing]
by Felix Yan 26 Feb '24

26 Feb '24

Hi all, The long delayed GHC 9.2.x updates have been done and moved to [extra-testing]. There are a few notable changes regarding our GHC packaging: - Codegen backend has been switched back to NCG for multiple reasons: = GHC doesn't support latest LLVM and was using llvm14 in Arch. This adds up to our maintenance burden of LLVM. (IIRC LLVM 15 support was fixed only recently.) = LLVM backend actually generates slower code. We have evaluated the changes during the past years and noticed as large as 50% slower results in some benchmarks. I also got similar information from other distribution people. = LLVM backend sometimes deadlocks on compile-time. I hit this from time to time and it's not easy to reproduce reliably. (There are similar issues that are always reproducible, but got fixed already.) All `--ghc-option=-fllvm` has been removed from PKGBUILDs during the rebuild. - Build system of GHC itself has been switched to Hadrian. - Some obsolete packages have been retired from the distribution, and will be removed once the batch enters [extra]: haskell-bytestring-show haskell-random-source haskell-brittany haskell-hls-brittany-plugin haskell-hls-tactics-plugin haskell-hls-haddock-comments-plugin A lot of thanks to @Vekhir who helped me a lot for preparing this so that it's done much earlier and smoother than I expected :) As always, please report any issues and have fun! -- Regards, Felix Yan

1 0

RFC: Distribution Developer Manual
by Levente Polyak 24 Feb '24

24 Feb '24

A new RFC (request for comment) has been opened here: 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 content in the Wiki. This request for comments is superseding `RFC-0005 <https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/5>`_ by extending its scope to handle all distro specifications coherently instead of handling a single sub section (packaging guidelines) differently to others.

1 0