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

Arch Linux in August 2023
by Levente Polyak 10 Sep '23

10 Sep '23

## Staff We would like to welcome Tomaz Canabrava (tcanabrava) as part of the Arch Linux Package Maintainer team. ## AURWeb In [AURWeb v6.2.7][0], we primarily focused on bug fixes while revamping Prometheus metrics. We introduced new measures like request tracking and cache-hit/miss ratios for search queries, enhancing our ability to make development decisions and aiding the AUR moderation team in identifying trends. Collaborating with the DevOps team, we introduced a CI/CD feature called [Review Apps][1]. This feature enables us to create virtual machines running AURWeb for each merge request, facilitating change showcases, manual testing, and involving a wider audience for performance, stress-testing, and UI verification. ## RFC We [proposed and accepted an RFC][2] to define the default of not using `PyPI` for Python package sources and only use the platform if there is no other alternative. You can find more details about [this RFC][2] on GitLab. By making this change, we ensure to have a more reliable and less cumbersome default. ## Trademark Policy We've [relocated our Trademark Policy][3] from the Developer area of the ArchWiki to the [service-agreements GitLab repository][4], which is published at [`terms.archlinux.org`][5]. This move centralizes all legal documents, ensuring consistent collaboration across our service agreement materials. [0]: https://gitlab.archlinux.org/archlinux/aurweb/-/tags/v6.2.7 [1]: https://docs.gitlab.com/ee/ci/review_apps/ [2]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/20 [3]: https://gitlab.archlinux.org/archlinux/service-agreements/-/merge_requests/… [4]: https://gitlab.archlinux.org/archlinux/service-agreements/ [5]: https://terms.archlinux.org/docs/trademark-policy/

1 0

RFC: Add -Wl,-z,pack-relative-relocs
by Jan Alexander Steffens (heftig) 03 Sep '23

03 Sep '23

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/23 Please visit the above link for discussion. Summary: Add -Wl,-z,pack-relative-relocs to our LDFLAGS in order to reduce the size of relocations.

1 0

News Draft: ansible-core >= 2.15.3-1 update may require manual intervention
by Robin Candau 17 Aug '23

17 Aug '23

# ansible-core >= 2.15.3-1 update may require manual intervention As of ansible-core version `2.15.3`, upstream moved documentations and examples to a separated [dedicated repository](https://github.com/ansible/ansible-documentation) (see the [related changelogs](https://github.com/ansible/ansible/blob/v2.15.3/changelogs/CHAN…) This means that, starting from version `2.15.3` the `ansible-core` package will stop shipping documentations and a default configuration example under `/etc/ansible/ansible.cfg`. Regarding the documentation, it is available online: <https://docs.ansible.com/> As for the configuration file, as explained in the [wiki](https://wiki.archlinux.org/title/Ansible#Configuration), a base config can be generated with the following command: ```sh ansible-config init --disabled > ansible.cfg ``` After updating from ansible-core <= `2.15.2-1` to >= `2.15.3-1`, everyone using a global Ansible configuration file stored under `/etc/ansible/ansible.cfg` will have their configuration saved as a `pacsave` file. To re-instore it, run the following command: ```sh mv /etc/ansible/ansible.cfg.pacsave /etc/ansible/ansible.cfg ``` -- Regards, Robin Candau / Antiz

1 2

Arch Linux in July 2023
by Levente Polyak 09 Aug '23

09 Aug '23

## Staff We would like to welcome Mario Oenning (moson) as new Arch Linux Support Staff Member. ## devtools arch-nspawn is now utilizing a distinct scope name instead of the previous `--keep-unit` approach. This allows for the creation of a dedicated scope, placing the container within a slice hierarchy which allows a more precise resource control. This enhancement will be part of the next release. Additionally, we've released version [v1.0.3][0], featuring several enhancements and bug fixes. This version enables the building of unofficial packages containing unsupported architectures and implements measures to ensure the `PKGBUILD` file is version controlled for new repositories. ## gluebuddy Gluebuddy, in its latest release [v0.5.6][1], brings an enhancement by automatically providing tag protection for the entire Arch Linux namespace. This feature ensures that all tags are safeguarded, contributing to the integrity and security of our repositories. ## Bugtracker migration Building upon the successful migration of packaging sources to Git, we are now focused on transferring our bug tracking from Flyspray to GitLab. Our progress can be monitored through [`archlinux/infrastructure#522`][2]. We have made substantial advancements in this process, including the preparation of labels for efficient bug management, the initial implementation of bugbuddy to streamline assignment of maintainers and labels, and a thorough revamp of the Flyspray to GitLab conversion tool `flyspray2gitlab`, with preliminary tests carried out in separate namespaces. # SPI We've completed and submitted the Software in the Public Interest (SPI) [annual project update report for the year 2022][3]. This brief report outlines our achievements, developments, and contributions over the past year. [0]: https://gitlab.archlinux.org/archlinux/devtools/-/releases/v1.0.3 [1]: https://gitlab.archlinux.org/archlinux/gluebuddy/-/commit/be32986196f0268bc… [2]: https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/522 [3]: https://gitlab.archlinux.org/archlinux/project-management/-/issues/10

1 0

NEWS DRAFT: Budgie upgrade requires manual intervention
by arch＠serebit.com 04 Aug '23

04 Aug '23

When upgrading from budgie-desktop 10.7.2-5 to 10.7.2-6, the package mutter43 must be replaced with magpie-wm, which currently depends on mutter. As mutter43 conflicts with mutter, manual intervention is required to complete the upgrade. First, remove mutter43 via "pacman -Rdd mutter43", then immediately perform the upgrade via "pacman -Syu". Do not relog or reboot between these steps. This will bypass the conflict.

2 1

Mailing list arch-commits
by Leonidas Spyropoulos 28 Jul '23

28 Jul '23

Hello, The arch-commits ML is back with diffs from Gitlab Packages group. Subscribe as normal from https://lists.archlinux.org State repo is not included. No archive is kept. Cheers, -- Leonidas Spyropoulos Developer & DevOps PGP: 59E43E106B247368

1 0

RFC Final Comment Period: Sources for Python packaging
by David Runge 28 Jul '23

28 Jul '23

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/20 Please visit the above link for discussion. Summary: Default to not using PyPI for Python package sources and only use the platform if there is no other alternative.

1 0

systemd: 254rc2 -> 253.7 -> 254rc3
by Christian Hesse 20 Jul '23

20 Jul '23

Hello everybody, we already had a pre-release of systemd in out testing repositories when I was surprised with another bugfix release in stable branch. Thus pulling the pre-release (254rc2-1) for now, and pushing 253.7-1. Once that is signed-off (please do!) and moved we can continue with pre-releases - probably 254rc3. -- 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

Arch Linux in June 2023
by Levente Polyak 15 Jul '23

15 Jul '23

## packaging We have now enabled all packagers to have default access to the multilib and unstable desktop (GNOME/KDE) repositories. This decision removes artificial gates and simplifies the process for packagers to contribute to different aspects of the distro's packaging. By granting wider access by default, we encourage easier participation and collaboration within our distro packaging team. ## devtools We released version `v1.0.3` of devtools which focused on bug fixes. This release addresses the issue of broken packaging repos for newly added packages by ensuring that the actual PKGBUILD is always version controlled. Additionally, we implemented the functionality to skip unofficial architectures, providing better support for building AUR packages with `pkgctl`. ## arch-boxes Starting with the `v20230601` release, arch-boxes images now include x64 UEFI support in addition to legacy BIOS. The GRUB boot loader is used for both UEFI and BIOS systems, ensuring a consistent implementation across different hardware configurations. This is a great enhancement that allows using arch-boxes images on UEFI-based systems. ## ArchISO In the `archlinux-2023.06.01-x86_64.iso` release, the mDNS responder of systemd-resolved is now enabled by default. This improvement enhances the user experience by simplifying network connections during the installation process. This enables convenient connectivity to the live environment via SSH from the local network without the need to know the IP address. Users can simply use the mDNS hostname `archiso.local`. The ArchWiki article ["Install Arch Linux via SSH"][0] has been updated to include a helpful tip with the appropriate command. ## container images Arch Linux's container images are now published to multiple registries. In addition to DockerHub, the images are also pushed to [Quay.io][1] and [GitHub Container registry][2]. This wider distribution ensures availability of the image across multiple platforms and helps mitigate the risk of a single point of failure. Users can now access the Arch Linux container images from their preferred registry, offering greater flexibility and redundancy. ## Specification effort for .BUILDINFO files With the [alpm-buildinfo][3] project, a Rust-based specification effort for the `.BUILDINFO` files found in ALPM packages has been started. The implementation for version 1 of the file is currently in review. [0] https://wiki.archlinux.org/title/Install_Arch_Linux_via_SSH#On_the_local_ma… [1] https://quay.io/repository/archlinux/archlinux [2] https://github.com/archlinux/archlinux-docker/pkgs/container/archlinux [3] https://gitlab.archlinux.org/archlinux/alpm/alpm-buildinfo

1 0

RFC Final Comment Period: Use of SPDX license identifiers in PKGBUILDs
by Morten Linderud 15 Jul '23

15 Jul '23

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/16 Please visit the above link for discussion. Summary: Change to using SPDX license identifiers in the PKGBUILD `license` value for packages in all repositories. Cheers, Morten

2 1

RFC: Sources for Python packaging
by David Runge 14 Jul '23

14 Jul '23

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/20 Please visit the above link for discussion. Summary: Default to not using https://pypi.org for Python package sources and only use the platform if there is no other alternative. -- https://sleepmap.de

1 0

Stepping down
by Jerome Leclanche 04 Jul '23

04 Jul '23

Hi folks I've not been able to update any of my packages in a couple of months and unfortunately I don't see the situation resolving itself any time soon with my life being busier than ever. I'd rather officially step down and re-apply in the future if it makes sense. I'd sign this email but I can't even find my updated arch GPG key. Bleh. Jerome Leclanche

2 2

Vacation until August
by Morten Linderud 03 Jul '23

03 Jul '23

Yo! I'll be taking a break in July. Have a couple of weeks vacation before starting new work in August and need a bit of time to reset. I'm not going to look at package updates, bugreports, respond to stuff and misc other responsebilities I have during this time. However, if I'm blocking someone on something please do reach out. I'm still terminally online and reachable :) Cheers and have a nicer summer people! -- Morten Linderud PGP: 9C02FF419FECBE16

2 1

icu rebuilds - only couchdb/erlang pending
by Andreas Radke 27 Jun '23

27 Jun '23

The icu rebuild are finished except for couchdb. This package won't build since erlang has been bumped to v26.x release. I couldn't get any response from Bruno (couchdb) or Alexander (erlang). Please consider downgrading erlang or add some compatibility erland-25 package to the repos to get the icu list done. -Andy

1 1

RFC: Moderator role for the AUR
by Torsten Keßler 27 Jun '23

27 Jun '23

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/19 Please visit the above link for 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 0

NEWS DRAFT: TeX Live package reorganization
by Antonio Rojas 17 Jun '23

17 Jun '23

Starting from version 2023.66594-9, TeX Live packages have been reorganized to mirror upstream collections. Even though the new texlive-basic replaces the old texlive-core, many of the texlive-core contents (including language specific files) are now split between different packages. To find out which Arch package contains a specific CTAN package, you can use the tlmgr utility, eg. $ tlmgr info euler | grep collection collection: collection-latexrecommended which means the euler CTAN package is contained in texlive-latexrecommended. You may also use 'pacman -F' to query for specific files. A new metapackage texlive-meta is available to install all subpackages (except for language specific ones), and the new texlive-doc package provides the full documentation for offline use.

2 1

Arch Linux in May 2023
by Levente Polyak 13 Jun '23

13 Jun '23

## Staff We would like to welcome Anton Hvornum (torxed) and Christian Heusel (gromit) among the Arch Linux Package Maintainers. On top we would like to welcome Leonidas Spyropoulos (artafinde) to their new additional duties as Arch Linux Developer ## Git packaging We are thrilled to announce the successful migration [0] of our packaging ecosystem to Git, with package sources now accessible on GitLab [1]. As part of this transition, we have developed a powerful new tool called `pkgctl` [2], available through `devtools`, offering a user-centric design and streamlined user experience for interacting with all aspects of Arch Linux packaging for users and packagers alike. Please note that our bugtracker remains on Flyspray, and we are not currently accepting merge requests. However, opening the issue tracker and accepting merge requests on GitLab package repositories is a top priority for us, and we are actively working towards making this transition in the near future. ## Infrastructure ### security-tracker We implemented nginx caching for the feed and API endpoints of the security-tracker, effectively reducing server resource consumption. This heavily improved server efficiency and the ability to handle a much higher volume of requests. ### GitLab In preparation for the migration of our packaging infrastructure to GitLab, we successfully transferred the GitLab instance from a VPS to a harder, better, faster, stronger bare metal server. This move not only provided a more responsive user experience but also eliminated bottlenecks that occured during peak times. To enhance the search capabilities across our GitLab instance, we've set up an OpenSearch instance. This allows us to enable advanced search functionality [3], facilitating faster and more efficient searches across the entire GitLab platform. Users can now benefit from improved search accuracy and speed, allowing for a more streamlined and productive experience when locating specific content within GitLab. ## Open Technology Fund Our official application to the Open Technology Fund for a comprehensive audit of Pacman and its integration in Arch Linux has been approved. As the package manager plays a central role in fetching software updates over the network, it is vital for us to prioritize the safety and security of our user base. By undertaking this audit, we aim to enhance the overall reliability and protection of our distribution, ensuring a secure environment for our users. The timeline for the audit is yet to be determined, and further planning on both sides is underway. ## ArchISO We have removed [4] the PGP-based signature for the root file system (`/arch/x86_64/airootfs.sfs.sig`) within the ISO. Its replacement is an OpenSSL CMS based signature which is available since the 2022.10.01 ISO. The signature is made using the same code signing certificate as already used for netboot images. The `verify=y` kernel command line option will stop working and must be replaced with `cms_verify=y`. The official netboot [5] and ISO's PXE menu entries have already been adjusted. Any custom PXE setups will need to update their boot menu entries manually. This is done because GPG integrates poorly in the ISO build process. This only concerns PXE booting, the PGP signature for the ISO itself is still there and that will not change. ## mkinitcpio We have released mkinitcpio v36, which brings a lot of improvements and several noteworthy changes [6]. These include support for kernel command line drop-ins for UKIs in `/etc/cmdline.d/` and `mkinitcpio.conf` drop-in files in `/etc/mkinitcpio.conf.d/`. To utilize the `mkinitcpio.conf` drop-in files, existing presets in `/etc/mkinitcpio.d/*.preset` must have `ALL_config` commented out. Additionally, a new `run_emergencyhook` function has been added for busybox-based hooks, running before the emergency shell is launched. ## alpm-types We started development on the Rust based alpm-types project [7], which is meant to provide low-level types for working with Arch Linux Package Management (ALPM). This library strives to provide all underlying types for writing ALPM based software. ## AURWeb We have released AURWeb 6.2.4 [8], which includes a number of bug fixes and improvements. Notably, we have incorporated important dependency updates to ensure compatibility with the latest software libraries. Additionally, we have implemented a new package name filter option for the "Requests" feature and support for the new repository layout for the git migration. ## bash 5.2 Preparations for the bash 5.2 upgrade are underway, including compatibility fixes in various projects such as pacman, devtools, and others. These proactive measures ensure a seamless transition to the new version while minimizing any compatibility issues and disruptions within our ecosystem. [0] https://archlinux.org/news/git-migration-completed/ [1] https://gitlab.archlinux.org/archlinux/packaging/packages [2] https://man.archlinux.org/man/pkgctl.1 [3] https://docs.gitlab.com/ee/user/search/advanced_search.html [4] https://github.com/pierres/archiso-manager/pull/17 [5] https://github.com/archlinux/archweb/pull/436 [6] https://lists.archlinux.org/archives/list/arch-projects%40lists.archlinux.o… [7] https://gitlab.archlinux.org/archlinux/alpm/alpm-types [8] https://gitlab.archlinux.org/archlinux/aurweb/-/tags/v6.2.4 [9] https://gitlab.archlinux.org/archlinux/devtools/-/commit/0365edb264c08b6520… [10] https://gitlab.archlinux.org/pacman/pacman/-/commit/0e938f188692c710be36f9d…

1 0

pulling grub from core-testing
by Christian Hesse 12 Jun '23

12 Jun '23

Hello everbody, grub 2:2.06.r557.gac560966d-1 was reported to be bad... Looks like it results in stalled boot and black screen (on some systems). No idea what caused this for now. Pulling from core-testing so it can not cause more harm... -- 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

OpenSSL 3.1 Update
by Pierre Schmitz 10 Jun '23

10 Jun '23

Hi all, I am about to push version 3.1 of OpenSSL into the core-testing repository. This time it is an actual minor update which is compatible with 3.0. That means there is no soname change and no rebuild should be required. However, packages might do runtime checks and ask for the specific version they were built with. OpenSSH is such a case. So far I have not noticed any other package having this check, but I guess we have to figure this out in [testing]. If you notice an issue, please let me know so I can add it to the todo list: https://archlinux.org/todo/openssl-31/ Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

2 3

NEWS DRAFT: OpenBLAS >= 0.3.23-2 update requires manual intervention
by Felix Yan 05 Jun '23

05 Jun '23

The openblas package prior to version 0.3.23-2 doesn't ship optimized LAPACK routine and CBLAS/LAPACKE interfaces for compatibility. This decision has been reverted now, and the ability to choose a different default system BLAS/LAPACK implementation while keeping openblas installed is now provided to allow future co-installation of BLIS, ATLAS, etc. The default BLAS implementation will be used for most packages like NumPy or R. Please install "blas-openblas" and "blas64-openblas" to make OpenBLAS the default BLAS implementation, just like the old behavior. Unfortunately you will get errors on updating if you currently have OpenBLAS installed as the default BLAS implementation: error: failed to prepare transaction (could not satisfy dependencies) :: installing openblas (0.3.23-2) breaks dependency 'blas' required by cblas :: installing openblas (0.3.23-2) breaks dependency 'blas' required by lapack Please append your preferred default BLAS implementation to the regular -Syu command line to get around it. For example: # pacman -Syu blas-openblas or # pacman -Syu blas -- Regards, Felix Yan

1 0

Git migration completed
by Levente Polyak 03 Jun '23

03 Jun '23

We are proud to announce that the migration to Git packaging succeeded! 🥳 Thanks to everyone who has helped during the migration! Package sources are now available on GitLab[0]. Note that the bugtracker is still flyspray[1] and that merge requests are not accepted as of now. We intend to open the issue tracker and merge requests on the Gitlab package repos in the near future. Mirrors are syncing again, but it may take a bit of time until your mirror of choice has caught up. ## For users Update your system and merge the pacman pacnew `/etc/pacman.conf.pacnew` file. This is required as we have moved the `[community]` repository into `[extra]`. $ pacman -Syu "pacman>=6.0.2-7"` For users of the now deprecated `asp` tool, you will need to switch to `pkgctl`: $ pacman -Syu "devtools>=1:1.0.0-1" $ pkgctl repo clone linux For some more detailed instructions on how to obtain PKGBUILDs see the corresponding wiki article[2]. ## For packagers Before starting, first uninstall `devtools-git-poc` and remove any repos from your filesystem that you cloned during the git proof-of-concept testing. Make sure you have both, an updated devtools and pacman on your system: $ pacman -Syu "devtools>=1:1.0.0-1" "pacman>=6.0.2-7"` Additionally clean up old chroots in `/var/lib/archbuild/` $ rm -rf /var/lib/archbuild/ # or optionally, use the --clean option for pkgctl build *ONCE* $ pkgctl build --clean For instruction on how to use `pkgctl`, please take a look at the "How to be a packager" wiki article[3] and also consult the man page of each subcommand for further information: $ man pkgctl-build $ man pkgctl-repo-clone [0] https://gitlab.archlinux.org/archlinux/packaging/packages [1] https://bugs.archlinux.org [2] https://wiki.archlinux.org/title/Arch_build_system#Retrieve_PKGBUILD_source [3] https://wiki.archlinux.org/title/DeveloperWiki:HOWTO_Be_A_Packager

2 1

Flyspray migration plan
by Jelle van der Waa 02 Jun '23

02 Jun '23

Hey all, We discussed shutting down flyspray during the DevOps meeting. The plan is to migrate all open issues to Gitlab and close them on Flyspray with a comment to the newly created Gitlab issue. All closed bugs will be archived and will most likely become available on https://bugs-old.archlinux.org/ Before we start a migration, we need some time to write a migration script. We would really appreciate it if all packagers can verify if their open bugs are still valid, can be fixed or closed. All packagers (previously known as TU) have been granted access to the Arch Linux project so can assign/close and resolve issues. As of writing we have: Arch Linux: 1072 open tasks Community: 851 open tasks On Gitlab, packagers will get auto-assigned on issues for packages they are the maintainer of in Archweb (https://archlinux.org/devel) A bot will periodically scan issues and automatically assign them. We are also looking into creating a generic global issue template for features/bugs. The bot will also set an “unconfirmed” label to new issues so bug wranglers and packagers alike can see and filter whether a bug has already been reproduced. Migrating the issues to Gitlab implies that we will open Gitlab issues for everyone. There is no timeline set yet for the migration, the main blocker is writing a migration script for our open issues. Greetings, Jelle van der Waa

3 2

[multilib] access
by Jelle van der Waa 28 May '23

28 May '23

Hey all, I would like to propose to allow everyone to upload to [multilib], currently it's restricted to a small set of packagers. This already caused some confusion because a packager could not upload mangohud. Let's just give everyone access by default. Greetings, Jelle van der Waa

3 2

GitLab bug: Your push has been rejected....
by Kristian Klausen 27 May '23

27 May '23

Hi all, As pointed out by multiple staff at IRC, there is currently a bug in GitLab, resulting in the following error on some git push: remote: ======================================================================== remote: remote: Your push has been rejected, because this repository has exceeded remote: its size limit of 0 Bytes by 25 GB. Please contact your GitLab remote: administrator for more information. remote: remote: ======================================================================== This is a harmless bug in GitLab[1] and the push succeeds. GitLab will fix it eventually. [1] https://gitlab.com/gitlab-org/gitlab/-/issues/409953 Cheers, Kristian Klausen

1 0

FrOSCon 2023
by Jelle van der Waa 22 May '23

22 May '23

Hey all, FrOSCon 2023 has been announced and is held on 5-6 of August. FrOSCon is a small (usually ~ 250) conference near Bonn, Germany. In the past we had devrooms there and hacking sessions. [1] I haven't made plans yet for attending but likely will, it would be nice if we had a small meetup there, hack together on some fun things and enjoy a Kölsch. Is anyone in the team thinking of attending? Greetings, Jelle [1] https://lists.froscon.org/hyperkitty/list/newsletter@lists.froscon.org/thre…

2 1

Git migration started
by Jelle van der Waa 20 May '23

20 May '23

Hi all, I got my morning coffee ready and will now start disabling ssh/svn access and stop our rsync endpoint. For more details of the migration please read the announcement email. [1] [1] https://lists.archlinux.org/archives/list/arch-announce@lists.archlinux.org… Knocking on wood that this all goes smoothly, Jelle

3 3

Git packaging rollout 🚀
by Levente Polyak 17 May '23

17 May '23

Hi everyone! We're excited to announce that the rollout for our Git packaging implementation is scheduled for Friday, May 19th. Please note that packaging and mirror sync will not be possible during the rollout as we'll need to shut down the services. We expect the services to be available and the rollout to be finished on Sunday, May 21th. This release date allows you for 17 more days to test pkgctl and prepare for the announced changes. We highly recommend that you take advantage of this time to ensure a smooth transition to the new implementation. Background information about the changes can be found in the two previous Git packaging threads on arch-dev-public [0][1]. Once the rollout is completed, we'll be sending out email notifications and a news entry with precise instructions and information for packagers as well as users. The primary feature and rollout owners are Foxboron and me (anthraxx). We will also be available to provide extended help and guidance to ensure that everyone can use the new tooling and workflow. Please don't hesitate to reach out to us, we're happy to help in any way we can. A detailed runbook for the whole rollout can be found here [2]. A heavily shortened version roughly looks as follows: ## 1. Pre-Rollout (Thursday 18. May) - news entry and announcement about the downtime - convert all SVN packages to Git repositories - trigger a fresh borg backup (6h) ## 2. Rollout (Friday 19. May) - shut down mirror and packaging services - update all changed package repositories - setup the new repo layout - import the pacman database state into a Git repository - deploy the new dbscripts version - release new devtools and pacman packages - deploy archweb and security-tracker ## 3. Validation (Saturday 20. May) - test the complete packaging workflow - test archweb and security-tracker features - hand out access to early access packagers ## 4. Opening (Sunday 21. May latest) - restart mirror and packaging services - send news post with detailed instructions - Party time Cheers [0] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [1] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [2] https://md.archlinux.org/utjjQ-bQTsipIKntPrpf8g

2 2

Git migration announcement
by Jelle van der Waa 15 May '23

15 May '23

This Friday morning (2023-05-19) the Git packaging migration will start until Sunday (2023-05-21). The Arch Linux packaging team will not be able to update packages in any of the repositories during this period. Notification when the migration starts, and when it is completed, will be published on the [arch-dev-public] mailing list. # How does this impact Arch Linux users? The [testing] repository will be split into [core-testing] and [extra-testing], the [staging] repository will be split into [core-staging] and [extra-staging]. The [community] repository will be merged into [extra] and will therefore be empty after the migration. All affected repositories will be provided as empty repositories for a transition period after the migration. For regular users, this means that everything works as before. Note: After the migration is done, users that have the testing repositories enabled need to include the new repositories ([core-testing] and [extra-testing] instead of [testing]) in their pacman.conf before updating their system. Other changes: - SVN access is discontinued and will disappear. [1] - The svn2git mirror will no longer be updated. - asp, which relies on the svn2git mirror, will stop working. It is replaced by pkgctl repo clone. [2] # How does this impact Arch Linux tier 1 mirrors? During the migration rsync and HTTP access will be shut down. We will send an email notification to arch-mirrors once everything has been finished. # How does this impact Arch Linux packagers? Packagers will not be able to patch and update their packages. The internal Tier 0 mirror is also going to be disabled for the duration of this migration. [1] https://archlinux.org/svn/ [2] https://lists.archlinux.org/archives/list/arch-mirrors@lists.archlinux.org/

1 0

Arch Linux in April 2023
by Levente Polyak 07 May '23

07 May '23

## project management We've create a GitLab Board [0] to track all tasks related to project management and project leadership. This Board allows us to visualize the exact state of tasks using different lanes and labels, making it easier to keep track of ongoing progress. Additionally, tasks will receive comments and lane updates to reflect the latest developments. This is another step towards providing increased transparency, structure, and visibility for our staff and users alike. The Board will continuously include an issue for next month's monthly report pad, streamlining the process for staff to add noteworthy bulletpoints about their progress. ## RFC We proposed and accepted an RFC to change our packaging build flags from _FORTIFY_SOURCE=2 to _FORTIFY_SOURCE=3 for better fortification coverage. Once rolled out, this change provides enhanced buffer size detection and improves the overall fortification coverage. You can find more details about this RFC on GitLab [1]. By making this change, we will be able to further strengthen the security of our distro and better protect our users. ## infrastructure We've set up an official crates.io service account [2] and assigned ownership of relevant projects such as various alpm and arch-audit related crates. This allows us to better manage and control access. In the future we will be able to use this service account to extend release automation via GitLab. ## Python This month we've focused on the Python ecosystem and have successfully upgraded the Python interpreter and relevant packages to version 3.11. As part of this process, we've rebuilt all packages that were dependent on Python and have fixed numerous issues in the process. We're pleased to report that we've completed these upgrades by the end of April and have since moved all relevant packages over to our binary repositories. ## Docker We applied and were accepted into the Docker-Sponsored Open Source Program with our Arch Linux organization. In addition to the monthly updated Docker Official Images, being part of this program provides us with several benefits for the images distributed through our organization. One of the key benefits is that users pulling public images from our project namespace will receive access to unlimited pulls and unlimited egress. [0] https://gitlab.archlinux.org/archlinux/project-management/-/boards [1] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/17 [2] https://crates.io/users/archlinux-github

1 0

dropping retired X.Org Packages
by Andreas Radke 04 May '23

04 May '23

Following this reminder post[1]+[2] I'm going to remove the following packages soon from the repos: xf86-input-elographics xf86-input-synaptics xf86-input-vmmouse xf86-input-void Any objections? -Andy [1]https://lore.kernel.org/distributions/1ea25603-171c-062e-bc02-bcdfc3acd01… [2]https://gitlab.freedesktop.org/xorg/doc/xorg-docs/-/blob/master/MAINTAINE…

2 2

Call for participation: Git packaging POC 🚀🎉
by Morten Linderud 01 May '23

01 May '23

Hi everyone! Levente and I have been busy preparing a test environment for the new git package workflow, which is going to replace the svn repository. To test the new git package setup install `devtools-git-poc` from the [community] repository and use the new `pkgctl` utility. Please check each time if there is a new upgrade before playing around. The goal of the testing is to figure out UX issues, bugs and larger issues that would need to be dealt with before a git migration can happen. It's therefor very important that people sit down and play around with the tools :) Support and feedback will be dealt with in the #archlinux-projects channel. Report bugs in GitLab with the following additional information: - devtools-git-poc package version - full PKGBUILD or pkg repo including the Git hash - terminal input and output The workflow should be the following: Basic setup ----------- ### setup packager Make sure your personal `makepkg.conf` contains your packager identity and gpg key. ### authenticate to gitlab pkgctl auth maintain existing packages -------------------------- ### clone an existing package pkgctl repo clone existing-package ### build a package pkgctl build ### release a package pkgctl release pkgctl db update ### combined UX The last three steps can also be expressed as: pkgctl build --release --db-update ### rebuild into staging vim PKGBUILD pkgctl build --staging pkgctl release --staging pkgctl db update This can be completely condensed by: pkgctl build --rebuild --staging --release --db-update maintain new packages --------------------- ### create a new package repo without history pkgctl repo create new-pkgbase pkgctl repo clone new-pkgbase ### add existing AUR repo cd packagerepo pkgctl repo create pkgctl repo configure ### first official build/release Specify the target repo on first run, as the tool can't know it's destination automatically yet pkgctl build --repo extra pkgctl release --repo extra --db-update --- The packages are uploaded into a test group here: https://gitlab.archlinux.org/bot-test/packages This test also includes junior developer and junior packagers. They can only push packages into staging and testing, and not release into the stable repositories. We currently have a couple of people with these permissions to try and figure out issues on that part of the setup. If anyone is interested helping out on this please reach out on the #archlinux-projects IRC channel on Libera. Background on the changes can be found here: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… Cheers!

6 8

Python 3.11 in [staging]
by Jelle van der Waa 29 Apr '23

29 Apr '23

Early Easter suprise, After some delay Python 3.11 rebuilds are happening in [staging], so please don't start any rebuild. Thanks to felixonmars for starting and rebuilding! Thanks, Jelle van der Waa

4 3

Away for several weeks
by Laurent Carlier 24 Apr '23

24 Apr '23

Last week I fell from my bike and was diagnosed with a broken pelvis/ankle. So for weeks I must stay on a bed for some weeks - and away from my main computer. I was not able to build amdvlk with last releases, so if some can fix it, it'll be awesome. I hope to be back asap, so take care of you and see you soon. NB: this eMail is not signed because is sent with my phone.

3 2

Arch Linux in March 2023
by Levente Polyak 11 Apr '23

11 Apr '23

## Git packaging sources We have improved a lot of pieces in `pkgctl` according to the feedback from the sandbox environment. Most notably it is possible to provide GitLab tokens via the `DEVTOOLS_GITLAB_TOKEN` environment variable, pass nocheck to the build command for bootstrap builds, handle subrelease pkgrels as well as several bugfixes. We are doing another round of testing and would like to proceed with the rollout afterwards. ## devtools A new version 20230307 has been released adding support for architecture-specific mount config. Furthermore `sogrep` now uses the first mirror that is configured for each repo in `pacman.conf` with a fallback to https://geo.mirror.pkgbuild.com. Additionally we added checks to not allow package releases of `PKGBUILD` sources with only weak cryptographic hashing algorithms. ## namcap A new version 3.4.0 has been released with a huge amount of cleanup and codebase improvements. Furthermore new checks have been added like optdepends and sodepends as well as improved pydepends. ## archiso Starting with `archlinux-2023.03.01-x86_64.iso`, the official ISO supports what is called *file system transposition* (**only on UEFI**). This means the ISO can be simply extracted (using an archiver or by mounting and copying) to the root of a FAT formatted partition and it will work™. Messing with boot loader configuration files is not required anymore. The documentation in [0] and [1] have been updated with the new simplified instructions. # mkinitcpio mkinitcpio version 35 followed by bugfix releases 35.1 and 35.2 are out! A major new feature is support for post-generation hooks a.k.a post hooks. These hooks get run after the initramfs generation and can be used to sign the generated images for Secure Boot. Examples are provided in [2] and [3]. Thanks to improvements in xz reproducibility, mkinitcpio can now use multi-threaded xz compression. [0] https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/docs/README.tr… [1] https://wiki.archlinux.org/title/USB_flash_installation_medium#UEFI_only [2] https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secu… [3] https://wiki.archlinux.org/title/Unified_kernel_image#Signing_the_UKIs_for_…

1 0

mate 1.27 pulled from community-testing
by Alexander Epaneshnikov 25 Mar '23

25 Mar '23

Hello! By mistake, I released version 1.27 of the mate desktop environment, which is an unstable version. ref[1] I now removed mate packages from community-testing if you upgraded to mate 1.27 please downgrade to mate stack from community. [1]: https://bugs.archlinux.org/task/77918 -- Sincerely, Alexander | Trusted User

1 0

Spring cleanup '23
by Antonio Rojas 22 Mar '23

22 Mar '23

Hello, It is that time of the year again: time for our yearly orphans cleanup. Please head to https://archlinux.org/devel/reports/unneeded-orphans/ and adopt packages that you'd like to keep in the repos. This is also a good opportunity to disown any packages you no longer want to maintain, so others can adopt them or they can be properly maintained in AUR if nobody is interested. If any non-dev TU wants to maintain some orphan in [extra], reply here and I'll move it to [community]. I will start dropping the leftovers to AUR on April 1st.

1 0

squashfs-tools 4.6 dropped from testing
by David Runge 20 Mar '23

20 Mar '23

Hi all, squashfs-tools 4.6 has been dropped from testing due to a regression [1]. Please make sure to downgrade. Best, David [1] https://bugs.archlinux.org/task/77914 -- https://sleepmap.de

1 0

Arch Linux in February 2023
by Levente Polyak 18 Mar '23

18 Mar '23

## Git packaging sources All major workflow and usability requirements for the `pkgctl` tooling have been finished and a experimental `devtools-git-poc` package has been put into the repositories. Furthermore the proof of concept sandbox environment has been set up and rolled out to anyone interested in testing. In the current phase we will collect feedback to catch bugs and further usability improvements [0]. We are still very eagerly seeking for more testers. ## what can I do for Arch Linux Our new contributor website https://whatcanidofor.archlinux.org has been announced [1]. We would like to express gratitude towards the current, past as well as initial contributors for getting the ball on the road. There have been some changes since the announcement, including the Arch navbar more or less being implemented and a decent amount of work in general. ## FOSDEM 2023 A lot of arch staff has visited FOSDEM 2023 in Brussels, where we exchanged ideas, hacked on projects and participated in the open-source conference shenanigans. Overall it was a great event that yet again improved our team spirit. Foxboron held a talk at FOSDEM [2], he showcased how Arch Linux implemented support for debug packages in 2022, the improvement that was made to the pacman package manager, the infrastructure changes that were needed and how debug packages are distributed through debuginfod. [0] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [1] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [2] https://fosdem.org/2023/schedule/event/debug_packages/

1 0

Orphan keenerd packages
by Jelle van der Waa 14 Mar '23

14 Mar '23

Hey all, All of these packages have no maintainer and are not required by anything. they should either find a new maintainer or be dropped: * armagetronad * bbe * bochs (gtk2.. ideally dropped) * bwm-ng * calc * cataclysm-dda-tiles and cataclysm-dda * cpuburn * curseofwar * dietlibc * dina-font * emelfm2 (gtk2 so will be dropped) * epdfview (gtk2) * ps_mem * pinfo * pcb * pacmatic (usefulish?) * pacgraph (useful!) * ngircd * nethogs * multitail * mg * memconf * mathomatic * lwm * keynav * jwm * hiawatha * hd-idle * gprolog * gnu-apl * gftp (gtk2) * gerbv * galculator * freedroid * fbv * fbgrab * fbdump * python-blessings I might have missed a few, but those will shown up when we drop the package/keenerd relationship in Archweb. As usual packages will be dropped after ~ 2 weeks. Greetings, Jelle

3 3

Orphaning packages
by Tobias Powalowski 14 Mar '23

14 Mar '23

Hi guys, early spring cleanup on my adopted packages: - b43-fwcutter - dmraid (not maintained upstream anymore) - facile - edac-utils - mp3splt - mp3wrap - libmp3splt - libksba - libiscsi - libifp - libraw1394 - linux-atm - mdadm - testdisk - xinetd - Samba stack: I would be really really happy, if someone, who also is using this piece of software would adopt it. Volunteers please go ahead. - samba - smbclilent - libwbclient - iniparser - ldb - tdb - tevent Thanks. greetings tpowa -- Tobias Powalowski Arch Linux Developer & Package Maintainer (tpowa) https://www.archlinux.org <http://www.archlinux.org> tpowa(a)archlinux.org Archboot Developer https://bit.ly/archboot

1 0

Dependencies from pkg-config files
by Balló György 06 Mar '23

06 Mar '23

Hi all, I implemented a new rule for namcap [1] to check if dependencies from pkg-config .pc files are satisfied. These are used by the 'pkg-config - -cflags --libs <library name>' command to set the appropriate CFLAGS and LDFAGS when building any dependent (direct and indirect) packages. If any of dependencies specified in 'Requires' or 'Requires.private' fields are missing, pkg-config throws an error. These dependencies are mostly covered by link-level dependencies, but there are some exceptions. Some packages already aware about this (e.g. glib2 -> libsysprof-capture; libx11 -> xorgproto), so we only need to fix a few others. I checked 590 core packages, and I found 13 packages with missing dependencies. [2] I propose the following solutions: - Some missing dependencies (gobject-introspection, systemd, util- linux) are caused because the pkg-config files are packaged separately from the libraries. This shouldn't happen in our distribution, because we don't split development packages. pkg-config files and the related header files should be in the same package where the library is found. - Some packages depend on specific header or data files (xorgproto, wayland-protocols) without linked library in it. Sometimes just a struct is needed from a header file in another package (libxi -> libxfixes). [3] Sometimes a library is used by dlopen() instead of linking (libepoxy -> libglvnd). [4] These should be added as dependencies if defined in a pkg-config file. - If you are sure that the dependency is unnecessarily, then contact with upstream. If no objections, I'll open tasks in Flyspray for these issues. [1] https://gitlab.archlinux.org/pacman/namcap/-/merge_requests/28 [2] https://md.archlinux.org/s/iXr206Xb1 [3] https://gitlab.freedesktop.org/xorg/lib/libxi/-/blob/08431d0684f9a1edf199f6… [4] https://github.com/anholt/libepoxy/blob/8db879f810e2dbc63824c43c17eeea0d3db… #L547-L559 -- Balló György Package Maintainer / Trusted User

4 10

Cython packages need rebuild on all Python interpreter updates
by Filipe Laíns 01 Mar '23

01 Mar '23

Hi, It has recently come to my attention that Cython uses CPython's private API, which is unstable, see [1]. From https://docs.python.org/3/c-api/stable.html: > Names prefixed by an underscore, such as _Py_InternalState, are private API > that can change without notice even in patch releases. Meaning that packages that ship Cython modules are dependent on the interpreter version, and need to be rebuilt on all python release updates, including patch releases. [1] https://github.com/cython/cython/issues/5275 Cheers, Filipe Laíns

1 1

RFC Final Comment Period: Increase _FORTIFY_SOURCE level to 3
by Levente Polyak 27 Feb '23

27 Feb '23

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/17 Please visit the above link for discussion. Summary: Adjust packaging CFLAGS from -D_FORTIFY_SOURCE=2 to -D_FORTIFY_SOURCE=3 for better fortification coverage Cheers, Levente

1 0

Arch Linux in January 2023
by Levente Polyak 27 Feb '23

27 Feb '23

## Git packaging sources We have announced the state of the art of the Git packaging migration to `arch-dev-public` [0] including a first item on our distro roadmap to track the remaining effort [1]. We have prepared most of the necessary settings, configurations and the corresponding machine for the new test environment for the Git package workflow. The test phase is expected to start at the beginning of February. ## base-devel We have implemented the `base-devel` and `multilib-devel` meta-package orthogonal to our already existing `base` meta-package [2][3]. Lately we added `debugedit` to `base-devel` in order to provide debug packages via makepkg. This lead to a couple of followup issues with installations missing the new package as changes in a package group are not automatically reflected on system upgrades. ## RFC We are formalizing an RFC [4] to increase `_FORTIFY_SOURCE` level to 3 in our default build flags. For a long time, we have been using `-D_FORTIFY_SOURCE=2` to detect C memory management problems at build time. Recently, glibc (2.34) added `_FORTIFY_SOURCE=3` to add extra checking. This has been supported in clang for some time, and is now available in GCC with the release of version 12. The gains are enhanced buffer size detection and better fortification coverage. ## Staff We would like to welcome Robin Candau (Antiz) among the Arch Linux Package Maintainers [5]. Due to extended inactivity, Kyle Keen (keenerd) has been removed from the Arch Linux Package Maintainers [6]. We would like to express our gratitude to Kyle for many years of packaging work. [0] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [1] https://gitlab.archlinux.org/groups/archlinux/-/epics/7 [2] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [3] https://archlinux.org/news/switch-to-the-base-devel-meta-package-requires-m… [4] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/17/ [5] https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t… [6] https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t…

1 0

Automate adding library provides
by Balló György 14 Feb '23

14 Feb '23

Hi all, I looked various packages in the [core] repository to check if they specify their external shared libraries in provides=(). I opened several task on Flyspray [1], but it was turned out that still many packages don't specify them. It was turned out also that adding these libraries to provides=() can be easily automated in makepkg, so we don't actually need to add these entries manually. Allan already implemented it [2] for the next pacman release, but in an incompatible way, he changed the naming e.g. from 'libglib-2.0.so=0-64' to 'lib:libglib-2.0.so.0'. I think we should decide if we want to keep the current naming schema, or deprecate it and switch to the new one, and then make a migration plan. Switching to the new naming schema will be more complicated. == Keep the current naming schema == In this case we can simply add and enable a new option for makepkg to add shared libraries to provides=() automatically during build, and then mass remove the existing *.so entries from provides=() in every packages. Dependencies are no need to be updated, since we keep the current naming schema. == Use the new naming schema == In this case we have to keep the existing *.so entries in provides=() for a while, because removing them would cause missing dependencies in other packages. 1. We have to add and enable a new option for makepkg to add shared libraries to provides=() automatically, following the new naming schema. 2. We also have to update each package manually to replace *.so entries in depends=(), and adapt changes to automate library dependencies (see below). 3. Once all dependent packages are updated, we can remove the *.so entries from provides=(), and rely on the new naming schema entirely. == Automate library dependencies == Allan's implementation will also add library dependencies to packages automatically. I think we should enable adding libraries to provides=(), but disable adding libraries to depends=() by default, because the latter needs manual changes in each PKGBUILD. It does not support to mark dependencies optional yet, but I sent a merge request [3] to make it possible via a new optbinaries=() entry in PKGBUILD. This feature is completely optional if we keep the existing naming schema. But if the new naming schema adopted, there is no easy way to avoid it, because the new name will contain the major version of the library, so manually specified library entries in depends=() would need to be updated manually on each soname bump. What are your opinions? Which naming schema we should follow? Is there any other issues? [1] https://bugs.archlinux.org/index.php?string=Add+libraries+to+provides%3D%28… [2] https://lists.archlinux.org/archives/list/pacman-dev@lists.archlinux.org/th… [3] https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/58 -- György Balló Package Maintainer / Trusted User

1 0

PyTorch with ROCm in [community]
by Torsten Keßler 12 Feb '23

12 Feb '23

Hi! I'm excited to announce that the full ROCm stack moved from [testing] to [community] today. To celebrate this, PyTorch packages with ROCm support are now in [community]! A simple code to check if the ROCm backend works on your machine is if torch.cuda.is_available() and torch.version.hip: d = torch.device('cuda') a = torch.rand(1, 2).to(d) print(a + 0) print("TESTS PASSED!") else: print("ROCm not supported with PyTorch installation") After you installed python-pytorch-rocm or the optimized python-pytorch-opt-rocm from [community], save the code snippet as rocm.py and run python rocm.py The output should be similar to tensor([[0.9949, 0.5596]], device='cuda:0') TESTS PASSED! Cheers, Torsten

1 0

[News draft] Switch to the base-devel meta-package requires manual intervention
by Robin Candau 10 Feb '23

10 Feb '23

Hi everyone, People that installed the base-devel group-package (before it became a meta-package) won't get the actual "base-devel" package itself installed on their machine until they explicitly (re-)install it. This may cause some regressions. For instance, since the "base-devel" package isn't /listed as/ installed on the system, pacman won't prevent users to remove packages it depends on. I draft a news about this, don't hesitate to give me your thoughts :) --- # Switch to the base-devel meta-package requires manual intervention The `base-devel` group-package has recently been replaced by a meta-package of the same name. People that had the `base-devel` group-package installed (meaning people that installed `base-devel` before February 2nd) have to explicitly re-install it to get the new `base-devel` package installed on their system: ``` pacman -Syu base-devel ``` -- Regards, Robin Candau

1 0

Arch Linux in December 2022
by Levente Polyak 08 Feb '23

08 Feb '23

## The wiki went dark 🌗 Thanks to the effort of Blake Wilson in completing the process [0][1] previously attempted [2] by killertofus to add Extension:DarkMode [3], it's lights out for ArchWiki! All you creatures of the dark can now click on "Dark mode" in the user menu to experience the soothing darkness. The preference is stored in the database, so it is only remembered for logged-in users and sadly there is no `prefers-color-scheme` support. Persistent people can probably find some ways to append a `usedarkmode=1` query parameter to wiki URLs. ## Decommission patchwork We have decommissioned patchwork.archlinux.org and replaced it with a static copy. As announced on the mailing list [4] pacman has been migrated to gitlab and there is no real use for patchwork left. A static copy is kept around for the time being to avoid link rot [5]. ## Debug packages by default We have enabled the debug package option globally in devtools [6]. Any subsequently built packages will package debug symbols by default. Currently the debug packages are only exposed via debuginfod and will be exposed to our mirrors in the future. ## Git packaging sources A huge amount of time has went into the ongoing development and iteration of the new `pkgctl` tooling [7]. We are currently focusing on stability and a fluent user experience. Some work has been started to be able to provide a proof of concept environment in January. ## The state of ruby After a few month of trying to de-vendor the ruby 3.0 stdlib gems we have decided to stop the effort as we ran into more problems and ruby itself highly recommends to not do this. This also means that with the de-vendored setup we would get no support from upstream for any issues we have with the ruby interpreter. We have now started to update ruby to 3.1 and will proceed afterwards with 3.2. [0] https://github.com/archlinux/archwiki/pull/63 [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/664 [2] https://github.com/archlinux/archwiki/pull/59 [3] https://www.mediawiki.org/wiki/Extension:DarkMode [4] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [5] https://gitlab.archlinux.org/archlinux/patchwork-archive [6] https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/123 [7] https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/126

1 0

glibc 2.37 release
by Frederik Schwan 04 Feb '23

04 Feb '23

Glibc 2.37 is about to be released to [testing]. Please be aware that any package that links against the 2.37 libc has to stay in testing for as long as glibc stays there. Otherwise breakage will be imminent. Best regards, Frederik

1 0

Announcing whatcanidofor.archlinux.org
by Daniel M. Capella 04 Feb '23

04 Feb '23

Glad to finally announce a new contribution landing page for Arch Linux: https://whatcanidofor.archlinux.org It's a modern take on the asknot family, see the README for more details: https://gitlab.archlinux.org/archlinux/neoasknot/-/blob/main/README.md The Arch Linux theme and navbar we all know and love /will/ be implemented, don't you worry, and maybe even a search bar: https://gitlab.archlinux.org/archlinux/neoasknot/-/issues -- Best, Daniel <https://danielcapella.com>

1 0

Re: ROCm in [community]
by Torsten Keßler 29 Jan '23

29 Jan '23

Hi Sefa, thank you very much for your interest in the ROCm stack. I've just added ROCm meta packages to [community-testing], see [1] for a complete list. For instance, if you would like to use the full stack, install rocm-hip-sdk. Best! Torsten [1] https://docs.amd.com/bundle/ROCm-Installation-Guide-v5.4.2/page/Meta-packag… On 06.01.23 13:08, Sefa Eyeoglu wrote: > Hi Torsten, > > thanks a lot for your work! I am here to ask if it's planned to create > a group for these packages. That would make it a lot easier to install > all of the (currently available) toolchain at once. > > Best, > Sefa > > > On Fri, 2022-12-23 at 16:20 +0100, Torsten Keßler wrote: >> Hi all! >> >> I'm excited to announce that basic ROCm support was added to >> [community-testing] yesterday! >> >> What is ROCm? >> ROCm is AMD's open source framework for GPU programming. It comprises >> an >> OpenCL implementation, HIP (AMD's CUDA) and OpenMP offloading. >> >> Which GPUs are supported? >> Official support is limited, see [1]. >> >> Which parts were added to [community-testing]? >> The low level components (rocminfo, rocm-smi-lib), the OpenCL runtime >> (rocm-opencl-runtime) and the HIP runtime / compiler (hip-runtime- >> amd). >> >> How can I use it? >> Install (hip-runtime-amd rocm-smi-lib rocm-opencl-runtime) to use all >> currently available packages. First check if the amdgpu kernel module >> is >> loaded and add your login user to the video and render groups. Run >> /opt/rocm/bin/rocminfo to validate that the HSA runtime correctly >> detects your hardware. You can also check the output of clinfo for >> OpenCL support. >> >> Use case: blender >> First, install hip-runtime-amd and add /opt/rocm/bin to PATH. Open >> blender, go to Edit -> Preferences and select "HIP" in "System / >> Cycles >> Render Devices". Open your favorite scene and select "GPU compute" in >> "Render Properties". You can monitor the GPU load with >> >> watch -n.1 rocm-smi >> >> if you've installed rocm-smi-lib. >> >> What's next? >> Add the ROCm math libraries (rocblas, rocsparse, rocfft, ..) that are >> needed for Machine Learning and many other applications. >> >> Best! >> Torsten >> >> [1] >> https://docs.amd.com/bundle/Hardware_and_Software_Reference_Guide/page/Hard…

1 0

FOSDEM 2023 Dinner
by Morten Linderud 26 Jan '23

26 Jan '23

Yo! The previous years at FOSDEM we have held a dinner with around 15-20 people. Some maintainers from Arch, and some users that wanted to join. It has been great events and with FOSDEM 2023 happening I thought it was a good idea to do it again :) The dinner will be held Saturday, 4th of February, around 20:00. The dinner is sponsored by the Arch and should cover a drink and a main course. We will cap the attendees to 20 people. Priority for members of the Arch team (developers, trusted users and support staff). Any free spots after this can be taken by anyone interested. Send me an email *offlist* if you want to attend. 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. Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

1 1

Looking for maintainer of kodi-addon-game-libretro
by Ike Devolder 20 Jan '23

20 Jan '23

Hi, Since I only build these related extensions and never test or use them myself I'm looking for someone who wants to take care of the "gaming" part of Kodi. As part of the update to Kodi 20 I'll rebuild them but if nobody is interested I will drop all of kodi-addon-game-libretro to AUR. -- Ike

1 0

RFC: Increase _FORTIFY_SOURCE level to 3
by Levente Polyak 19 Jan '23

19 Jan '23

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/17 Please visit the above link for discussion. Summary: Adjust packaging CFLAGS from -D_FORTIFY_SOURCE=2 to -D_FORTIFY_SOURCE=3 for better fortification coverage

1 0

base-devel and multilib-devel meta-package
by Levente Polyak 16 Jan '23

16 Jan '23

Hi all, I'd like to inform upfront that now would finally be a good time to implement the `base-devel` meta-package orthogonal to our already existing `base` meta-package. We haven't really pushed it for quite some time as nothing in `base-devel` changed in the past. Now the situation looks slightly different as we lately added `debugedit` in order to provide debug packages via makepkg. This lead to a couple of followup issues with missing installations and people running into such an issue on multiple occasions. Hence I've prepared the `base-devel` meta-package and will put it into [testing] soon. I'll also add a TODO list to remove the group declaration once its available in [core]. This will ensure any changes to the `base-devel` set will automatically be reflected on hosts that need that set available like chroots, AUR build environments or dev machines. Cheers, Levente

1 0

Upcoming PHP 8.2 update and introduction of legacy packages
by Pierre Schmitz 16 Jan '23

16 Jan '23

With the release to PHP 8.2 I will introduce a new set of packages to solve most of the issues with PHP updates. There are two valid requirements: On one hand people need the latest version to use its features or to develop new applications. And on the other hand users want to run third party applications that might not yet be compatible with the latest PHP runtime. I'll make the following changes to support both use cases while still keeping the rolling release model: The php package we already provide will be updated to 8.2 and be kept up-to-date with the latest upstream releases. php7 packages will be removed as this version is end-of-life and will no longer receive security updates. A new set of php-legacy packages will be introduced which always provide the oldest version actively supported by upstream*. This version is usually one year behind the latest release, but still receives bug and security fixes. It will be possible to install and use this version alongside the latest php packages. The binaries and configuration path will have a suffix named "-legacy", which will require configuration changes if you want to switch between legacy and non-legacy versions. In contrast to e.g. the php7 package, this version will also follow a rolling release model and will receive minor and even major updates. In the end this would result in the following release schedule: php: currently 8.1 soon 8.2 December 2023: 8.3 php-legacy: currently: 8.1 December 2023: 8.2 (upstream provides security updates till December 2024; so we have some room to postpone when issues arise.) I will provide a news item once all these changes are ready for the stable repositories. For packaging: I'll take care of the module rebuilds. Most modules are already compatible or at least have patches. Similar to php7 I'll make use of split packages to build a module for both PHP branches. One exception is the uwsgi plugin which is known for being a less active project. For now it would only be possible to provide it for php-legacy. Application packages might use the virtual php-interpreter dependency which provides the minor version. As stated above switching between legacy and non-legacy versions will require user interaction. For some packages that are known for almost never being compatible with latest PHP versions, it might be easier to depend on php-legay right away. Greetings, Pierre *) https://www.php.net/supported-versions.php -- Pierre Schmitz, https://pierre-schmitz.com

3 11

Need help testing pacman 6.0.2 debug packages
by Morten Linderud 15 Jan '23

15 Jan '23

Yo! With the release of pacman 6.0.2 we have now support for debug packages through `debugedit` as opposed to the awk hack used previously. https://gitlab.archlinux.org/pacman/pacman/-/commit/ae2f506ddfd1 This should resolve several issues we have had with the existing debug packages and I want people to test this support. Please recreate your build chroots and/or reinstall base-devel locally. Enable debug in a diverse set of packages you maintain. And help validate the current assumptions: * Debug packages for Rust, Go* and Julia should work * Weird /build directories should not exist * We should have header files * The source files should be located in `/usr/src/debug/${pkgbase}-${pkgver}` You can list them easily with `bsdtar -tf *.pkg.tar.zst` Note pacman is currently in [testing]. In the case for Go we need to disable compressed dwarf headers with `-ldflags=-compressdwarf=false`. It should be the case for any binaries with these headers as well. They can be recognized with the weird "DWARF version 0 unhandled" error string during stripping. Please report back if things look good, or you are looking at weird debug package structures :) If everything looks fine I intend to write an RFC for blanket enabling debug packages in devtools! -- Morten Linderud PGP: 9C02FF419FECBE16

6 14

[news draft] PHP 8.2 update and introduction of legacy branch
by Pierre Schmitz 12 Jan '23

12 Jan '23

Hi all, after some time in [testing] and the first patch release I think it is time to move the PHP 8.2 rebuild into the stable repositories. I would like to add a brief news item to describe the introduction of the legacy PHP version. This might be a bumpier update but I believe this should make future updates a lot smoother. Any input on improving this news item is very welcome: (I'll include some links to the packages and upstream version page when actually posting this) --- The php packages have been updated to the latest version 8.2. In addition to this, a new set of php-legacy packages have been introduced. These will follow the oldest but still actively supported PHP branch. This enables users to install the latest version but also introduces the option to use third party applications that might rely on an older version. Both branches will be kept up to date following our rolling release model. php and php-legacy can be installed at the same time as the latter uses a "-legacy" suffix for its binaries and configuration files. In addition to this, the php7 packages have been removed as they reached end of life. The imap extension will no longer be provided as it relies on the c-client library which has been abandoned for many years. -- Pierre Schmitz, https://pierre-schmitz.com

1 1

Git packaging sources: state of the art
by Levente Polyak 10 Jan '23

10 Jan '23

# Introduction Behold, ~~winter~~ Git is coming. We've been working on and off to get Git packaging sources ready for a while now. Today I'd like to outline the final proposal regarding the action plan, workflow, tooling and also the reason for a couple of decisions. Consider this as a late xmas gift to our distro 🎁😻 # Timeline We started with a proof-of-concept from Foxboron and are now closing in with a bunch of production ready changes finished by me in various components such as dbscripts, devtools, svn2git - including the great help of several other contributors related to infrastructure, repo converter and other components. The current plan is to finally get all this rolled out around end of January or most likely right after FOSDEM 2023 where we could hack together on the last outstanding bits. Shortly, we'll also notify a couple of downstream projects so they can prepare themselves. After finishing all followup tasks and feedback loops, we'll communicate the exact migration window. Please look at the Roadmap item for more detailed steps. The plan for the migration window is to have multiple people from different areas block time for a full weekend and start with the rollout on Friday. This would give us the freedom and flexibility to handle all kind of unforeseen issues that may pop up during the rollout. Throughout the main rollout phase, packaging would be shut down completely and packagers will need to update their devtools and local checkouts. # Roadmap The Git packaging sources will be the very first item on our future Roadmap. We'll soon see more cleanup and Epics on our Roadmap for all the bigger changes and improvements we want to prioritize and outline for our distro. The overall idea is to greatly increase transparency, have a better way to visualize and track progress, dependencies as well as action items. https://gitlab.archlinux.org/groups/archlinux/-/epics/7 As I only started this Epic while we were already near the finish line, it mainly consists of a couple of condensed issues with sub-tasks in dependent projects such as infrastructure, dbscripts, devtools, as well as a list of general tasks tied to the Epic. In the future we want to utilize it better by breaking it down into sub-issues in a very early stage. However, the currently available Epic should be a good starting ground that everyone can subscribe to and comment on. # Git repo layout Lets get technical. The Git repo layout is related to RFC-14 (Merge package repositories) and most of its aspects were discussed during that proposal. However, let's summarize what that actually means for the packaging repositories and how all this looks like. Every `pkgbase` will have its own dedicated repository that is stored in a single combined GitLab group called `packages` (e.g. https://gitlab.archlinux.org/archlinux/packaging/packages/foo) This allows us to have a well structured and simple layout, which provides the grounds for a per `pkgbase` issue board on GitLab (note: dealing with the issue boards is not part of the migration). Package maintainers will receive write access to the entire GitLab group. Whenever we completely remove a `pkgbase` from our distro, we will archive the corresponding GitLab repository instead of deleting it. Being able to physically delete the GitLab repository would effectively circumvent force-push and tag protection rules. On top, preserving an auditable history of former packaging sources is actually a good thing. # Git tag format Because of Git tag format limitations (man `git-check-ref-format`), we convert certain characters such as `~` to dots `.` and the epoch delimiter will be a simple dash `-`. All Git tags are expected to be signed using valid packager keys available in archlinux-keyring. Some example pkgver with their matching Git tags: - 1.0-1 ➡ 1.0-1 - 2:1.0-1 ➡ 2-1.0-1 - 1.0~rc2 ➡ 1.0.rc2 # dbscripts The way dbscripts currently works will be simplified: Instead of having two separate checkouts for `packages` and `community`, we will instead only have a single dbscripts instance on repos.archlinux.org managing all packages. https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/37 ACLs will be done on the application level using checks against Unix groups, as described in RFC-14. Once we rolled out the Git migration, we will have `junior-packager` and `junior-dev` Unix groups available for limited interaction with testing/staging repositories. https://gitlab.archlinux.org/archlinux/rfcs/-/blob/master/rfcs/0014-merge-p… The current state of the pacman repository will not be stored alongside the `PKGBUILD` anymore as we did with svn (the `repos` directory next to `trunk`). Instead we will use a single state repository, that will keep track of all the information and mapping between git-tags, hashes and repositories. The canonical source of the state repository is repos.archlinux.org and will be mirrored by our GitLab. This way we keep it very simple and get rid of any kind of exfiltrate secrets lying around on repos.archlinux.org just to be able to push directly to GitLab. For consistency checks, dbscripts maintains and updates read-only clones of all packaging source repositories. To reduce cache miss and transfer times, the infra will perform scheduled cache warming. This will be fast enough for most everyday usage. To further speed up huge rebuild sets like haskell or openssl, where this will be noticeable, we may add some complexity to dbscripts in the future that uses parallel with some smart error handling. Any interaction with scripts such as `db-update` will be globally available in `$PATH`. However, interaction that requires to ssh into repos.archlinux.org (or setup local aliases) will be superseded by the new `pkgctl` tooling (more on `pkgctl` in the following sections). # devtools To handle new functionality (e.g. package source repository management, GitLab authentication, etc.) a new unified tooling named `pkgctl` has been created. The old scripts such as `commitpkg` have been reworked into a smarter and more convenient unified interface (the old scripts will remain available for a while). As packagers will need to adapt workflows for Git anyway, now was the best time so everyone only needs to adapt once. https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/126 ## repo management The command `pkgctl repo` will provide a couple of functions to work with our package source repositories. First and foremost the `clone` subcommand allows to conveniently clone and configure a package source repository from our GitLab: > pkgctl repo clone libfoo It is also possible to clone all packages of a maintainer for convenient initial setup and a dedicated flag for mass edits: > pkgctl repo clone --maintainer yourlovelynickname To clone a read-only checkout without a valid ssh setup, simply pass `--unprivileged` to the command: > pkgctl repo clone --unprivileged libfoo Cloning will implicitly call the `repo configure` subcommand, which sets up some git repo settings and author information read from `makepkg.conf`. This for example ensures we use our archlinux identities for packaging even if another one is configured globally. This setup is also important as we will enforce git release tags to be signed by trusted keyring keys. To re-configure existing clones, a simple wildcard can be used in the repo's root directory: > pkgctl repo configure * Use the `repo create` subcommand to create a new repository in GitLab. Due to GitLab limitations, this requires to setup a valid auth token (more about it in the next section): > pkgctl repo create linux-is-awesome ## authentication Certain subcommands such as `repo create` require a valid GitLab token which can be managed with the `auth` command. To let the CLI guide you through the creation and setup: > pkgctl auth login To verify the current token and its validity: > pkgctl auth status This will save the token in `${XDG_CONFIG_DIR}/devtools/gitlab.conf`. ## package release This is one of the workflow steps that will get dramatically smarter and supersedes the `commitpkg` (which is usually used through symlinks such as `communitypkg`) and the `archrelease` scripts, while providing more convenient dbscripts interaction. The commitpkg/archrelease scripts will remain available for now, but should be considered a deprecated interface available during a transition period. The `pkgctl release` command unifies the steps to commit, tag and upload build artifacts. It stages modified version controlled files for commit, creates a Git tag matching the `pkgver` and finally uploads all build artifacts. Before trying to create a new Git tag, the tooling will ensure that the local clone is up-to-date. This should avoid inconsistencies when a package maintainer tries to upgrade and locally tag an already released version. By default the target binary package repository will be auto-detected by querying the repo it is currently released in. When initially adding a new package to the repositories, the target repo must be specified manually. By passing either the `--testing` or `--staging` option, the matching repository such as `multilib-testing` will be resolved. This smart interface obsoletes all the `commitpkg` symlinks (e.g. `extrapkg`, `community-testingpkg`, etc.): > pkgctl release --staging libfoo > pkgctl release --repo extra-testing newpkgthingie By default the `pkgctl release` command will only commit, tag and upload the artifacts to the staging area on repos.archlinux.org. To update the binary package repository as the final step, either pass `--db-update` to the `release` command, or use the dedicated `pkgctl db` command: > pkgctl release --db-update The `pkgctl db` command provides all required subcommands to interact with dbscripts such as move, remove and update. This obsoletes the requirement to setup local shell aliases or ssh directly to repos.archlinux.org to manage the repository sync database state: > pkgctl db update > pkgctl db move extra-staging extra-testing libfoo libbar ## package build The `pkgctl build` command will follow the same principles as `pkgctl release` by providing a smart interface to automatically detect which build target to use and will also provide `--testing` and `--staging` options to build against those special repositories. This will obsolete the need to directly call the currently used build scripts (e.g. `extra-x86_64-build`): > pkgctl build --testing --release --db-update The build command will start as an incubating feature and may change in the future when we wire up a build service to the pkgctl interface. The build command will also receive more convenience options such as setting pkgver without the need to manually adjust the `PKGBUILD` with an editor.

4 4

RFC for using standard SPDX license expressions in PKGBUILDs
by arch＠serebit.com 06 Jan '23

06 Jan '23

Hello all! I've opened an RFC for transitioning the license field in PKGBUILDs from our existing format to the SPDX license expression specification. This is my first RFC, and I want to thank Foxboron for his help with the process so far. You can find the MR here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/16 Please visit the above link for discussion. Best, Campbell

2 1

python-packaging 22.0 removed from [testing]
by Felix Yan 03 Jan '23

03 Jan '23

Hi all, python-packaging 22.0 was removed from [testing] due to incompatibility with setuptools [1]. [1] https://github.com/pypa/setuptools/discussions/3722 -- Regards, Felix Yan

1 0

Decommissioning patchwork.archlinux.org
by Morten Linderud 28 Dec '22

28 Dec '22

Yo, Arch has been hosting a patchwork instance for many years and the time has come to retire this service. Most project has been moving to Gitlab, with pacman moving at the end of this year, and there is no real use for this anymore to my knowledge. https://patchwork.archlinux.org/ Project maintainers should take a look over the projects and collect up any patch links they want to work on in the future. I have posted a small script on the pacman issue if people want to pull old patches from the mailing list. https://gitlab.archlinux.org/pacman/pacman/-/issues/1#note_83181 The EOL date is 1st of January 2023. We will probably make a static archive of patchwork as a backup incase we need it, but this probably won't be hosted anywhere. https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/487 -- Morten Linderud PGP: 9C02FF419FECBE16

1 1

ROCm in [community]
by Torsten Keßler 23 Dec '22

23 Dec '22

Hi all! I'm excited to announce that basic ROCm support was added to [community-testing] yesterday! What is ROCm? ROCm is AMD's open source framework for GPU programming. It comprises an OpenCL implementation, HIP (AMD's CUDA) and OpenMP offloading. Which GPUs are supported? Official support is limited, see [1]. Which parts were added to [community-testing]? The low level components (rocminfo, rocm-smi-lib), the OpenCL runtime (rocm-opencl-runtime) and the HIP runtime / compiler (hip-runtime-amd). How can I use it? Install (hip-runtime-amd rocm-smi-lib rocm-opencl-runtime) to use all currently available packages. First check if the amdgpu kernel module is loaded and add your login user to the video and render groups. Run /opt/rocm/bin/rocminfo to validate that the HSA runtime correctly detects your hardware. You can also check the output of clinfo for OpenCL support. Use case: blender First, install hip-runtime-amd and add /opt/rocm/bin to PATH. Open blender, go to Edit -> Preferences and select "HIP" in "System / Cycles Render Devices". Open your favorite scene and select "GPU compute" in "Render Properties". You can monitor the GPU load with watch -n.1 rocm-smi if you've installed rocm-smi-lib. What's next? Add the ROCm math libraries (rocblas, rocsparse, rocfft, ..) that are needed for Machine Learning and many other applications. Best! Torsten [1] https://docs.amd.com/bundle/Hardware_and_Software_Reference_Guide/page/Hard…

1 0

RFC - thoughts about Arch and init freedom?
by Andreas Radke 22 Dec '22

22 Dec '22

The older Arch developers may remember vaguely how Arch has introduced [1] and migrated to systemd [2] becoming the new and only supported init system. Back in these days we had some developers in our team being part of upstream systemd developers. Not much discussion happened about supporting any alternative init system. Other alternative init systems have become niche in Arch and faded out over time. Nowadays systemd has become much more than a plain init system and plans to grow further. This may leadd to problems from a user and system administrator perspective once you are hit by some bug. Systemd as a whole thing doesn't care about the Unix philosophy to do only one thing but well. Many and often highly skilled users left and leave Arch therefor or choose some different distribution or an Arch fork because there's no init choice in Arch Linux. I suggest to fix this lack of init choice/alternative. I'd like to implement it into the official Arch Linux repos allowing to choose some different init replacement. We can either just add a 2nd init system in the most simple way or allow real init-freedom[3] offering full choice and leave it up to be further filled by the community. Arch Linux could take advantage of this bringing back some lost parts of the community. With more choice and better portability Arch could become a better base for porting to new architectures. And freedom and alternatives is always good in the open source world. The clear drawback would become some added complexity allowing to choose either systemd or its replacement parts and to make all of them to work with existing packages especially daemon services. I'm willing to do most of the packaging implementations when a majority of the team think it's good idea and worth the effort. It's a rather huge effort and imho not a task for some personal custom repo as it may affect devtools, infrastructure and maybe more of our core distro. If you want to check how some init choice can be implemented I suggest to start looking at Parabola[4], Hyperbola[5] and [6] Artix Linux forks first. These are all rather small projects but we being the mother and true Arch community should have the resources to implement it in a proper way without any major drawbacks. PS: Please leave out all emotions about hating or loving systemd. I'm trying to do so as well. -Andy [1]https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux… [2]https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux… [3]https://www.devuan.org/os/init-freedom [4]https://wiki.parabola.nu/Repositories#nonsystemd [5]https://wiki.hyperbola.info/doku.php?id=en:philosophy:systemd_denial [6]https://wiki.artixlinux.org/Main/Installation [6]

13 15

Removing the imap,c-client and php-imap packages
by Pierre Schmitz 16 Dec '22

16 Dec '22

While preparing updates to our PHP packages I think it's now time to retire the abandoned imap package: https://archlinux.org/packages/extra/x86_64/imap/ The last upstream version was from 2007 and the upstream website is gone for many years now. I doubt anyone actually uses the imap server; its main use is probably to compile the php-imap extension (which also might get removed by upstream in the future). Redhat and Fedora removed the library last year. Therefore I'd like to remove imap, c-client and php-imap. php-imap is currently optionally required by nextcloud and postfixadmin; likely to authenticate against a third party IMAP server. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

1 0

Re: [arch-dev-public] openssl 3.0
by Pierre Schmitz 15 Dec '22

15 Dec '22

Hi Jelle, (also forwarding to dev-public) definitely yes, OpenSSL 3.0 is on my wish list! :-) I did not want to jump on it at day one though. Even the last minor updates were quite painful and we still have packages requiring version 1.0 and are still not compatible with 1.1. While they claim that most packages should work with a recompile, it would be nice to actually know which packages are not compatible. This should help whether we need another compatibility package are would be able to just replace openssl 1.1 with version 3. I know about foutrelis' awesome rebuilder script, but I wonder if we have something similar that I just could run for half a day to get an idea which package would break and which wont? Like a dry run that wont commit anything. If no such thing exists yet, I might have a look myself. Greetings, Pierre On Wed, Nov 3, 2021 at 9:14 PM Jelle van der Waa <jelle(a)vdwaa.nl> wrote: > > Hi Pierre, > > Shall we start an openssl 3.0 rebuild soon? Fedora/Debian/Alpine seens > to have already started. > > https://fedoraproject.org/wiki/Changes/OpenSSL3.0 > > Greetings, > > Jelle -- Pierre Schmitz, https://pierre-schmitz.com

10 19

db6 license concerns
by Andreas Radke 14 Dec '22

14 Dec '22

I have noticed freswa has bumped BerkeleyDB to v6 (again) and started pushing rebuilds to staging repo. Arch Linux had made this update already in August 2013 and discussions lead us to revert this back quickly: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… Here you can find some thoughts why 3rd party applications may not be legally compatible to use the AGPLv3 licensed BDB v6: https://lwn.net/Articles/557820/ https://fedoraproject.org/wiki/Changes/BerkeleyDB_6 It's pretty questionable if someone is allowed to build and redistribute packages against the newly AGPLv3 licensed BDB version without checking and probably changing related application licenses. But I'm not a lawyer. Most major Linux distributions still stick with BDB v5 therefore. So we did back then in 2013 until now. Some distributions have added v6 along v5 and only use it carefully when upstream projects declare their license AGPLv3 compatible to be usable with later BDB versions. Two major concerns I have here: 1) No public discussion happened here or somewhere else before such a major change. The packager will have known there's something special with such a long flagged package in core. All major changes affecting the core repo should really go through some discussion before they happen. 2) I've immediately raised my concerns pinging freswa at IRC and only see today the rebuilds went ahead and keep going on. That's not how our team should deal such maybe critical step. I don't want to imagine Arch spending all funded money for some curt fights we could easily avoid here. Please start some public discussion why this change happened and why the concerns of other distributions and our own developers are not worth to take a small break to think about it again. -Andy

4 6

Arch Linux in November 2022
by Levente Polyak 11 Dec '22

11 Dec '22

## Git packaging sources We made huge progress towards finally being able to migrate from SVN to Git for package sources. The core projects responsible for our package build, workflow and release, namely dbscripts and devtools reached production grade adjustments to achieve the transition [0][1]. Furthermore we have started to document and outline our Roadmap with the Git packaging as its first item [2]. This Epic can be followed to outline the full dependencies including child issues and child epics for everything that needs to be handled or adjusted afterwards. The next stop in this journey will be to propose the migration with all workflow details to arch-dev-public in the following days. ## infrastructure We have migrated our Keycloak 17 intance [3] to the recommended Quarkus distribution [4] which removes the /auth from the context-path. This change required all OAuth clients to be adjusted. Furthermore we are now monitoring our Keycloak intance with UptimeRobot [5]. ## arch-install-scripts A new version v28 has been released [6] which mostly contains bugfixes. ## mkinitcpio Development has moved to the Arch Linux GitLab instance [7]. A new version v33 has been released [8] with a lot of improvements. Furthermore the existing test suite has been heavily extended and migrated to bash bats. ## keyringctl We have started splitting out the keyringctl [8] python code from our archlinux-keyring repository so we can independently develop and release the tooling. Furthermore we have started testing and will soon integrate a streamlined way to create new main key signatures including automatic uid verifications. ## archlinux-keyring We have replaced one of our main signing key as follows [9][10]: - added: 69E6 471E 3AE0 6529 7529 832E 6BA0 F5A2 037F 4F41 demize(a)master-key.archlinux.org - revoked: 159F 3A43 AEB2 46C5 746C 0338 14BC 4F30 B3B9 2EBA grazzolini(a)master-key.archlinux.org ## pacman Some time ago it was decided to migrate the pacman development from the Mailing List to the Gitlab instance hosted by Arch Linux [11]. We have now outlined a plan [12] for the next steps to finally complete the GitLab migration. ## repod A talk about the current state of things will be held during HIP [13] between 27th - 30th December 2022: "Pacman can have the cookies and eat the ghosts too" [14] ## RFC We are formalizing an RFC [15] to declare SPDX license identifiers in PKGBUILDs. SPDX, or Software Package Data Exchange, was formed by the Linux Foundation as a well- defined standard for software bill of material information. ## Staff We would like to welcome tpkessler among the Arch Linux Package Maintainers [16]. [0] https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/37 [1] https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/126 [2] https://gitlab.archlinux.org/groups/archlinux/-/epics/7 [3] https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/655 [4] https://www.keycloak.org/migration/migrating-to-quarkus [5] https://status.archlinux.org/ [6] https://github.com/archlinux/arch-install-scripts/releases/tag/v28 [7] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio [8] https://lists.archlinux.org/archives/list/arch-projects@lists.archlinux.org… [8] https://gitlab.archlinux.org/archlinux/keyringctl [9] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/merge_requests/1… [10] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/merge_requests/1… [11] https://gitlab.archlinux.org/pacman/pacman [12] https://lists.archlinux.org/archives/list/pacman-dev@lists.archlinux.org/th… [13] https://hip-berlin.de [14] https://pretalx.c3voc.de/hip-berlin-2022/talk/HCNL3V/ [15] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/16 [16] https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t…

1 0

Bash 5.2 removed from [testing]
by Felix Yan 03 Dec '22

03 Dec '22

Hello, I was informed that a new feature (patsub_replacement) is enabled by default in the new release, which breaks makepkg. bash 5.2.0-1 is now removed from [testing] until this is fixed. -- Regards, Felix Yan

1 0

Updating ruby package guideline to only build gems and extensions once
by Andreas 'Segaja' Schleifer 29 Nov '22

29 Nov '22

Hello, in July David (dvzrv), Tim (bastelfreak) and I had a jitsi session in which we reworked the old ruby packaging guidelines [1] to make it more reflecting the current wishes and standards we already used when packaging ruby (like building from source, adding tests, ...). After it was pubslihed Felix (felixonmars) approached us and mentioned that there is a flaw in our logic as gems and extensions are now build twice. Once in the build() step which is then used for testing and once in the package() step. Recently Felix found a way to only build the gem and possible extensions once and use them for both testing and packaging. To reflect these changes I would propose that we update our ruby package guidelines with the new way that Felix found. I took the liberty of updating them on my personal space [2]. If there is no objection, then I would like to push the changes to the main page. Best regards Andreas [1] https://wiki.archlinux.org/title/Ruby_package_guidelines [2] https://wiki.archlinux.org/title/User:Segaja/Ruby_package_guidelines

3 4

Virtual package naming
by Jan Alexander Steffens (heftig) 29 Nov '22

29 Nov '22

Hello list, We're planning to make PipeWire the default PulseAudio sound server, and for that we need to change some dependencies around. Notably, we want a virtual "pulseaudio server" package that is fulfilled by both pipewire-pulse and pulseaudio, with preference for the former. However, we weren't sure what to name it. We don't seem to have a consistent naming scheme for virtual packages besides soprovides (libfoo.so). Most virtual packages look like normal ones (e.g. java-runtime, d-compiler). Some packages use SCREAMING-KEBAB-CASE to clearly separate "virtual" from "normal" dependencies (e.g. WIREGUARD-MODULE), which makes their weirdness (pacman -Si fails) less surprising. I'm not sure that's a pattern we want to continue, but I still would like a consistent scheme. Looking forward to your input, Jan

4 3

Away for a while
by Konstantin Gizdov 25 Nov '22

25 Nov '22

Hi all, I've not taken a break since officially joining the Arch team long ago. With the pressure of taking care of my newborn and the holidays approaching, it is time for a long one. I plan to be away until Jan 2023. I've finished all my relevant urgent Todos and updated the packages that have the most impact. That should give some buffer and allow people to react while I'm gone. I won't be entirely offline, but I won't be easily reachable or have time to spend on Arch. Only for quick questions. Most of my packages have co-maintainers, so that should not be a big problem overall. If you need me urgently, feel free to contact me on my Telegram or Matrix. All the best, happy holidays and a joyful new year to all! -- Regards, Konstantin

1 0

Dropping qtwebkit
by Antonio Rojas 21 Nov '22

21 Nov '22

Hi, Qtwebkit has been unmaintained for a long time (last release from annulen's fork was almost 3 years ago) and is plagued with security issues by now. Most consumers are either dead upstream, of they use it to provide optional functionality that can be disabled at build time. I propose to drop it from our repos, together with all packages which use it non-optionally. Other distros such as Opensuse and Gentoo have done it already. If there are no objections, I will open a todo list to disable the dependency in all packages where it's possible, and otherwise drop them.

4 6

Archiving all package sources
by Jelle van der Waa 17 Nov '22

17 Nov '22

Hey all, For packaging we now rely on external parties to keep the source code hosted which can be a problem and some packagers want to search through all our packages code. [1] Currently we already archive sources using `sourceballs` on repos.archlinux.org for GPL licensed packages, this is limited to a subset of all packages and done after the fact (A timer which runs every 8 hours and part of dbscripts). sourceballs calls `makepkg --nocolor --allsource --ignorearch --skippgpcheck`. This can be a problem as it runs after the package has been committed and it other network issues which might occur specific to the server. (ie. source cannot be downloaded where server is hosted) To make this more robust, when committing a package using communitypkg or equivalent we also rsync the sources to a location on repos.archlinux.org (Gemini). This means the sources are consistent, and this opens the ability to implement a fallback or to change devtools to look at our sources archive when building a package. That would benefit reproducible builds as well and automated rebuilds. Searching through our source code would be a next nice to have, most solutions such as sourcegraph/hound require a Git repository. [3] [4] So maybe we can hack up a repository which just git adds all directories and keeps one git commit? That should probably be not too much of a waste. But the first proposal is to first archive all our code in a way it can be consumed by a search solution. Questions: * How do we deal with archiving patches, PKGBUILD's etc. for GPL compliance (just save it next to the code?) * How do we determine when sources can be removed / cleaned up (we can't store things forever). DBscripts hooks? * Do we have enough disk space for archiving? $ du -hs 111G /srv/ftp/sources/ [jelle@gemini ~]$ df -h / Filesystem Size Used Avail Use% Mounted on /dev/sdb2 19T 6.3T 12T 35% / [1] https://gitlab.archlinux.org/archlinux/ideas/-/issues/2 [2] https://sources.archlinux.org/sources/ [3] https://github.com/sourcegraph/sourcegraph [4] https://github.com/hound-search/hound/

5 5

New community wide idea pool
by Levente Polyak 11 Nov '22

11 Nov '22

Hello everyone, Several times in the past I was thinking about a better and more central way to keep track of ideas and suggestions. We've encountered multiple times that good ideas got lost because we never properly kept track of them and only recognized after coming up with the very same idea much later. I'd like to address this issue and setup an actual community-wide place for this [0]. The GitLab repository is an incubating idea pool useful to keep track of early stage suggestions and brainstorming before they get picked up and implemented eventually. We will use an issue template [1] and various labels to classify ideas with rough t-shirt sized estimates. This will help volunteers to look out for ideas they would be interesting to invest time on. Cheers, Levente [0] https://gitlab.archlinux.org/archlinux/ideas [1] https://gitlab.archlinux.org/archlinux/ideas/-/blob/main/.gitlab/issue_temp…

2 2

Realtime kernels moved to [extra]
by David Runge 05 Nov '22

05 Nov '22

Hi all, today I have moved the realtime kernels to [extra]: https://archlinux.org/packages/extra/x86_64/linux-rt/ https://archlinux.org/packages/extra/x86_64/linux-rt-lts/ I have been maintaining these kernels in the AUR via a custom repository [1] for a couple of years now and believe that quit a few people actually make use of them (in various contexts). The effort to get the realtime kernel patchset [2] merged in its entirety has been going on for about 15 years already and the patchset is shrinking with every kernel release. In the future users will be able to configur the kernel build without a separate patchset. That all being as it is, historically there have been two repositories tracking the ongoing work: One for the work on the most recent Linux versions, while the other tracks all LTS branches that are supported. I am intending to follow both the most recent and the highest LTS version, while consolidating with core/linux and core/linux-lts wherever it makes sense. For that purpose we have moved the kernel repositories (with distribution specific patches), mirroring their respective upstream to: https://gitlab.archlinux.org/archlinux/packaging/upstream/linux-rt https://gitlab.archlinux.org/archlinux/packaging/upstream/linux-rt-lts This allows for easy collaboration and cherry-picking of patches (which I do currently already for linux-rt, using core/linux) and my hopes are, that the knowlegde in our developer and packager team grows in how to configure kernel builds and maintain the packages. The https://gitlab.archlinux.org/archlinux/packaging/upstream/ group location is meant for all projects that have to maintain custom patches on top of what upstream does (that is also why shadow lives there currently). In case there are developers or package maintainers interested in collaborating on the builds and maintenance of the kernels, please reach out! Best, David [1] https://pkgbuild.com/~dvzrv/repos/realtime/x86_64/ [2] https://wiki.archlinux.org/title/Realtime_kernel_patchset -- https://sleepmap.de

1 0

Arch Linux in October 2022
by Levente Polyak 02 Nov '22

02 Nov '22

## mkinitcpio mkinitcpio v32 has been released [0] which adds support for zst compressed firmware for future kernel versions as well as various fixes and adjustments. ## pacman pacman 6.0.2 has been released [1] which fixes multiple issues with debug packages. On top pacman-key has been adjusted to do a single gpg trustdb check instead of one after each key revocation. Furthermore various fixes have been added related to clang lto, reproducible packages containing sparse files and other fixes. ## python-bootstrap To build python-setuptools for Python 3.11 one needs python-setuptools. The same bootstrapping issue exists for other Python packages, which provide (PEP517) build backends and are required for building the remaining ecosystem from scratch. In the future we want to rely on python-bootstrap [2] to allow us to transparently bootstrap the Python ecosystem on a new release and document the workflow. Not all initially required packages are defined yet, but a first attempt at bootstrapping has been completed [3]. ## OpenSSL 3 The OpenSSL 3 rebuild started with the latest version 3.0.7 which will hopefully land soon in the [testing] repository. [0] https://github.com/archlinux/mkinitcpio/releases/tag/v32 [1] https://gitlab.archlinux.org/pacman/pacman/-/commits/v6.0.2 [2] https://gitlab.archlinux.org/archlinux/python-bootstrap [3] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o…

1 0

Re: [arch-dev-public] openssl 3.0
by Pierre Schmitz 01 Nov '22

01 Nov '22

Alright, I have updated openssl-1.1 (the one in staging) to the latest version and both include libprovides now. In addition to this openssl-1.1 provides openssl=1.1.1 On Tue, Nov 1, 2022 at 7:01 PM Luna Jernberg <droidbittin(a)gmail.com> wrote: > > 1.1.1r is just bugfixes and no critical security fix as in the 3.0x series > > On Tue, Nov 1, 2022 at 6:57 PM David Runge <dave(a)sleepmap.de> wrote: > > > > On 2022-11-01 18:27:23 (+0100), Pierre Schmitz wrote: > > > I updated to 3.0.7 in staging. I had libprovides in my branch. Do you > > > guys think this might be handy to define versioned dependencies when > > > we have potentially three different openssl verions to maintain? > > > > > > provides=('libcrypto.so' 'libssl.so') > > > > Always a fan! Please add! :) > > > > > At the same time 1.1.1s was released which mainly fixes a regression > > > from 1.1.1r (we are on 1.1.q). Do you guys think it is worth to > > > release that 1.1.1 update in the meantime? > > > > If it is not critical, maybe better to let the openssl 3 rebuild roll > > through. > > > > Best, > > David > > > > -- > > https://sleepmap.de -- Pierre Schmitz, https://pierre-schmitz.com

1 0

Bootstrapping Python
by Jelle van der Waa 01 Nov '22

01 Nov '22

Hey All, Yesterday we had a successful meeting [1] on bootstrapping Python. For those who might wonder what this is about: To build python-setuptools for Python 3.11 one needs python-setuptools. The same bootstrapping issue exists for other Python packages, which provide (PEP517) build backends and are required for building the remaining ecosystem from scratch. Filipe has created a project to tackle this issue, it uses python-installer to temporarily create wheels for setuptools, pep517, installer and other packages. [2] These can then be packaged using a PKGBUILD [3] and replace the existing python-setuptools package temporarily to build the "real" python-setuptools. Bootstrapping these tools will be a multiple stage bootstrap (and assumes an already available interpreter package such as python 3.11): 1. Build python-bootstrap 2. Build python-setuptools and co. (without tests) 3. Build all makedepends and depends of the bootstrapped packages (without tests) 4. Build "real" packages (those that have been bootstrapped) and replace the initial bootstrapped packages with them (without tests). 5. Build the ecosystem using the available packages (without tests) 6. Rebuild the ecosystem with tests In the future we want to rely on python-bootstrap to allow us to transparently bootstrap the Python ecosystem on a new release and document the workflow there. Not all initially required packages are defined yet, but a first attempt at bootstrapping can be found in a custom repository already [4]. This has been a quick PoC, we still need to put in a lot of work to get this to work out of the box - Get a full bootstrap working using python-bootstrap - Figure out how we deal with sphinx being a build requirement of python-installer/builder blocking bootstrapping - Figure out how to bootstrap setuptools - Create a script to determine the bootstrap order (using our repository database) - Better tooling for creating custom repositories / devtools chroots for these rebuilds - Automatically update python-bootstrap's git submodules to the repository version - Add documentation about the entire process If you have time to help testing and developing, please come join us in #archlinux-python on libera.chat. [1] https://md.archlinux.org/s/rBZYhg_fE# [2] https://gitlab.archlinux.org/archlinux/python-bootstrap [3] https://gitlab.archlinux.org/archlinux/python-bootstrap/-/blob/PKGBUILD/PKG… [4] https://pkgbuild.com/~jelle/python3.11/

1 0

Git submodules in PKGBUILDs are broken as of git 2.38.1 update
by Orhun Parmaksiz 27 Oct '22

27 Oct '22

Hey! As of git 2.38.1 [0], the handling of submodules in PKGBUILDS is broken due to CVE-2022-39253 [1]. This situation affects the packages that use the following command for updating the submodules: > git submodule update This will result in "fatal: transport 'file' not allowed" error since the value of `protocol.file.allow` is changed to be "user" by default. It means that `file://` clones are considered unsafe by default. Currently, there are two possible fixes available: 1. git -c protocol.file.allow=always submodule update 2. git submodule--helper update The latter seems to be an internal command which does not have any public facing documentation whereas the former option is more explicit. There is a related bug report [2] and a TODO list draft [3] for updating the affected packages. I will be updating the VCS guidelines [4] to use the first proposed solution if it all looks good. [0] https://lore.kernel.org/lkml/xmqq4jw1uku5.fsf@gitster.g/ [1] https://www.cve.org/CVERecord?id=CVE-2022-39253 [2] https://bugs.archlinux.org/task/76255 [3] https://md.archlinux.org/YVwV_wIKQfG5obcNLNlCjg [4] https://wiki.archlinux.org/title/VCS_package_guidelines#Git_submodules Let's make some gains, Orhun

2 1

mkinitcpio and arch-install-scripts hackathon 22nd of October
by Morten Linderud 21 Oct '22

21 Oct '22

Yo, On the 22nd of October (tomorrow) there is going to be a small hackathon on minitcpio and arch-install-scripts! mkinitcpio needs some love before a new release can be made, the goal would also be to work on the open pull-requests before moving the project too our Gitlab instance. https://github.com/archlinux/mkinitcpio/ The current ideas is to do scope out a bugfix release and then a larger release, and we would love some help to do that. Beyond that we want to look at improving the general status of the systemd hooks in mkinitcpio, there are several projects that implements parts of this better than mkinitcpio and it would be neat to figure out how we should work on that. For ideas see issue 121 in the repo; https://github.com/archlinux/mkinitcpio/issues/121 I'm also maintaining arch-install-scripts but that is mostly out of necessity :) I'd love to find a new maintainer for the project, so any ideas or issues can also be worked on tomorrow! https://github.com/archlinux/arch-install-scripts This is a great opportunity for new people to get involved with some Arch project development :) The only requirement is to not be afraid to dive into bash/ash scripts. Join `#archlinux-projects` on the libera.chat network or through matrix if you are interested :)! -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

git 2.38.0: Change in `git archive` output
by kpcyrd 16 Oct '22

16 Oct '22

hello, multiple people in Arch Linux noticed the output of our `git archive` command doesn't match the tarball served by github anymore. First I suspected an update in our gzip package until I found this line in the git 2.38.0 release notes: > * Teach "git archive" to (optionally and then by default) avoid > spawning an external "gzip" process when creating ".tar.gz" (and > ".tgz") archives. I've then found this commit that could be considered a breaking change in `git archive`: https://github.com/git/git/commit/4f4be00d302bc52d0d9d5a3d4738bb525066c710 I don't know if there's some kind of gzip standard that could be used to align the git internal gzip implementation with gnu gzip. I'm not saying this is necessarily a bug or regression but it makes it harder to reproduce github tar balls from a git repository. Just sharing what I've debugged. :) cheers, kpcyrd

1 0

Public release: updlockfiles 0.1.0
by kpcyrd 16 Oct '22

16 Oct '22

ohai! I released a new tool called updlockfiles that attempts to help manage dependency lockfiles like Cargo.lock, composer.lock, go.mod and friends. Hopefully this helps with reproducible builds in Arch Linux, but also if you want to manage your own downstream lockfile to override vulnerable dependencies. Announcement blog post: https://vulns.xyz/2022/10/updlockfiles/ Repository: https://github.com/kpcyrd/updlockfiles cheers, kpcyrd

1 0

Arch Linux software projects: Request for participation
by David Runge 16 Oct '22

16 Oct '22

Hi all, we have recently cleaned up parts of the developer wiki a bit and moved the list of internal projects to a more prominent location: https://wiki.archlinux.org/title/Getting_involved#Software_projects As you can see, we have quite a few projects and some of them would be happy about more participation from members of the Arch Linux staff as well as users. Help in fixing and extending the software is much appreciated, but testing and opening tickets that describe flaws or usability problems are equally important! If you are familiar with writing documentation, Ash, Bash, C, JavaScript, Python, or Rust and always wanted to get involved with one of the Arch Linux projects: Look no further! :) As mentioned in the wiki, we have a central mailing list [1] and IRC channel [2] for discussing most of the projects (unless they provide other means of communication). We hope to spark people's enthusiasm, as healthy projects ensure a flexible distribution and allow us to tackle larger goals (e.g. move to a git based workflow for packaging, effortlessly providing several architectures, automating our infrastructure and releases, etc.). Best, David [1] https://lists.archlinux.org/mailman3/lists/arch-projects.lists.archlinux.or… [2] ircs://irc.libera.chat/archlinux-projects -- https://sleepmap.de

1 0

[core] cleanup
by David Runge 13 Oct '22

13 Oct '22

Hi all, we need to do a bit of [core] repository cleanup. In this MD [1] (publicly visible readonly link [2]) we have a list of packages that should leave [core], some maybes that need discussion before moving them and some that should be moved to [core] from the other repositories. If you have more packages, that should not be in [core] anymore or should be moved to it, please add them to the list(s). The general rules for inclusion in [core] are, that we want to - preserve base-devel as a group there - preserve base as a meta-package there - preserve makedepends and depends of a [core] package there The checkdepends and also optdepends of a package may reside in other repositories. As we have a few removals of packages in the list that concern packages only in [core] for historical (or other) reasons, please keep the discussion about them focused on technical reasons as to why they should potentially remain there. Additionally, we have a few orphan packages in [core] that need adoption. Please adopt packages (if you can)! Best, David [1] https://md.archlinux.org/nrXL0ay5Tp6wP-f5M7N8bA# [2] https://md.archlinux.org/s/MliseALTG# -- https://sleepmap.de

6 11

GeoIP mirror of archboot?
by Tobias Powalowski 05 Oct '22

05 Oct '22

Hi guys, would it be possible to link the archboot directory to GeoIP too: archboot.mirror.pkgbuild.com/ ? Thanks. greetings tpowa -- Tobias Powalowski Arch Linux Developer & Package Maintainer (tpowa) https://www.archlinux.org tpowa(a)archlinux.org Archboot Developer https://bit.ly/archboot St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de info(a)st-martin-apo.de

2 2

Arch Linux in September 2022
by Levente Polyak 03 Oct '22

03 Oct '22

## RFC We entered the final discussion period for the RFC [0] to merge the pacman repository `[community]` into `[extra]` as well as the packaging VCS location `community` into `packages`. The `[core]` repository remains limited to Developers. One the RFC is accepted, we will implement the proposal during the migration to Git packaging. ## devtools Changes were prepared to account for the repo merger RFC and its resulting workflow. We are slowly approaching a state of Git packaging that could be used productively. Once the final bits haven been finalized, we will present the proposal and discuss the migration and switch over. ## mailman3 migration We have finished the full migration to mailman3 [1]. Rewriting of the "From" header and subject (to prepend the list name) have been disabled to keep the DKIM signature intact. This means "reply to mailing list" must be used when replying to the list and you may need to update your filters and rules matching the "From" header. All existing subscriptions are migrated and you do not need to re- subscribe. ## python2 removal Python 2 went end of life January 2020. Since then we have been actively cutting down the number of projects depending on python2 in our repositories, and we have finally been able to drop it from our distribution [2]. ## RISC-V mirror We started hosting [3] our latest efforts of the yet unofficial RISC-V port. In the past year, we have a boost in progress and currently ~87.5% of Arch x86_64 packages are available in the riscv64 repository [4]. [0] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/14 [1] https://archlinux.org/news/arch-linux-mailing-list-changes/ [2] https://archlinux.org/news/removing-python2-from-the-repositories/ [3] https://riscv.mirror.pkgbuild.com/ [4] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o…

1 0

Discussion around archlinux-keyring and pacman-key
by David Runge 30 Sep '22

30 Sep '22

Hi all, I've started a discussion [1] around a potential improvement for dealing with archlinux-keyring and pacman-key. Lately we have been facing quite a few issues (e.g. initialization and ordering issues in archiso and arch-boxes) again, that emerge from how gnupg is used in the context of pacman-key. The discussion linked to above is a bit more midterm in regards to what the proposed idea represents, but it tries to draw out a possible scenario of using key data in the future. When looking at pacman-key I noticed, that it does not do locking of the gnupg keyring data [2]. This means, that in environments in which we bootstrap the system (e.g. archiso/arch-boxes) we may run into inconsistent state if we use pacman too early, or generally if we modify the keyring concurrently. Unfortunately, (to my knowledge) there is no way of telling when is "too early" or whether we are already using the keyring, due to the missing locking mechanism. In the past days there have also been a multitude of reports of people with keyring issues on reddit. While some of theme have been due to initialization issues in archiso with pacman < 6.0.1-8, there is apparently also a set of issues on existing systems where it is unclear why pacman-key would have issues validating keys that are already present on the user system (trying to get more info from the users). Overall this is a bit worrying and I think we should work towards addressing the problem that we have with signing and verifying packages. The discussion in archlinux-keyring is only one possible solution, others are implementing a locking mechanism (;_;) or working towards a signing enclave for our packages and databases to minimize the keys in use. IMHO, removing the use of gnupg as proposed in the linked discussion could reduce complexity quite a bit, but it of course also requires implementation in archlinux-keyring and pacman. I'd be happy to get more input and thoughts on this entire topic. Best, David [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/199 [2] https://gitlab.archlinux.org/pacman/pacman/-/blob/546433b4fd8a3ede5d04d56b3… -- https://sleepmap.de

1 0

Finding a new home for a bunch of my packages
by Pierre Schmitz 29 Sep '22

29 Sep '22

Hi all, I have been thinking about refocusing my contributions on Arch. As Andreas rightfully asked about openssl it's probably best to go ahead. I have been maintaining a couple of packages simply because they where orphaned a long time ago. They are all maintained but maybe someone could be found who is more knowledgeable or is even an active user of these packages. Here is a list of all the packages I care or know less about; just answer to this list if you like to maintain any of these. * archiso, archlinux-keyring, devtools: These already have other people working on it, so I probably can safely remove myself as maintainer. * aspell-de * imap: This is a dead package and should not be used by anybody. I just maintain it as dependency of php/c-client. If nobody is interested I might look into removing it * grml-zsh-config, hefur, lighttpd, lynx: I am no longer using these packages * logrotate * openssl, openssl-1.0, openssl-1.1: An update to Openssl 3.0 is prepared and packaged. Though I lack the knowledge to fix the packages depending on it and I do not feel confident to apply random patches. This is also better handled by someone who knows more about C; especially about handling different library versions and symbols. * run-parts * xz * zlib: Someone with a deeper knowledge might be advisable as this needs custom patches due to difficult upstream. Someone might also consider switching to a more maintained zlib-ng. * zsh I am not orphaning any of these if nobody could be found; ideally there is someone with a sense of passion for some of these more important packages. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

3 3

RFC Final Comment Period: Merge package repositories
by Levente Polyak 26 Sep '22

26 Sep '22

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/14 Please visit the above link for discussion. Summary: Merge the pacman repository `[community]` into `[extra]` as well as the packaging VCS location `community` into `packages`. The `[core]` repository remains limited to Developers. New Package Maintainers will be restricted to publish packages solely to `[testing]` for the first two months of their active packaging actions. Cheers, Levente

1 0

News post draft: Dropping python2 from the repositories
by Morten Linderud 22 Sep '22

22 Sep '22

Yo, We are just missing a couple of packages before we can fully remove python2 from the repositories. Thanks to Jelle for all the hard work<3 Here is a suggestion for a news entry for the removal itself Subject: Removing python2 from the repositories We have removed python2 from the main repositories. If you still require the python2 package you need to build it from the AUR, or use an [unofficial user repository](https://wiki.archlinux.org/title/Unofficial_user_repositories). -- Morten Linderud PGP: 9C02FF419FECBE16

4 4

Remove ipw2100-fw and ipw2200-fw from [core]?
by Tobias Powalowski 22 Sep '22

22 Sep '22

Hi, while cleaning up archboot: https://fedoraproject.org/wiki/Changes/RemoveWirelessExtensions Those 2 firmware package can be removed, it's only for very old Intel boards which I guess are not even x86_64. Any objections? greetings tpowa -- Tobias Powalowski Arch Linux Developer & Package Maintainer (tpowa) https://www.archlinux.org tpowa(a)archlinux.org Archboot Developer https://bit.ly/archboot St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de info(a)st-martin-apo.de

2 2

Experimental RISC-V port
by Felix Yan 19 Sep '22

19 Sep '22

Hi, As you may or may not have noticed, I have started an unofficial RISC-V port attempt targeting 64-bit RISC-V ISA (riscv64gc) since 2019. There is a simple intro page currently hosted at: https://archriscv.felixc.at/ In the past year, we have a boost in progress and currently ~87.5% of Arch x86_64 packages are available in the riscv64 repository. IMHO The current patch amount is still too high to consider adding riscv64 as an official supported architecture, but we are trying hard on upstreaming them. Yesterday I noticed that Manjaro has imported packages from this port and formed a Manjaro RISC-V port. Their repository is now available at https://repo-riscv.manjaro.org/ This reminds me that we should probably make the port more visible to get more hands on it. Would you consider adding a subdomain at pkgbuild.com or archlinux.org? -- Regards, Felix Yan

5 6

New main key holder (replace Giancarlo)
by Levente Polyak 13 Sep '22

13 Sep '22

Hi all, I've had some chats with Giancarlo and he is currently unexpectedly very busy and stuffed with a lot of work. Thew new MK did not proceed currently to fill in the missing slot. Together we concluded that it would be the best to adapt to the current situation, revoke the newly created key and proceed with a new MK holder. This would allow him to spend his available time on the current responsibilities and projects. After some talks with David, we thought Johannes (demize) would be a good fit. I've approached him and after his careful consideration and review of the responsibilities he would happily fill in the slot. Therefore I'm proposing we replace Giancarlo's key and pass on the duties to Johannes. -- Many thanks to Giancarlo that he intended to help us out and to Johannes for jumping in. cheers, Levente

4 3

The future of arch-commits
by Kristian Klausen 12 Sep '22

12 Sep '22

Hi all, I'm in the process of migrating our mailing lists from mailman2 to mailman3[1]. Migrating arch-commits could be a challenge though (+1 million mails) and just deprecating it would be easier :) So, is there any reasons for not deprecating it? How are you using it and could that need be met in some other (and perhaps better) way? [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/59 Cheers, Kristian Klausen

4 5

Arch Linux in August 2022
by Levente Polyak 07 Sep '22

07 Sep '22

## devtools The code and repository has been restructured [0] as it got out of hand over time. Now it follows a clear distinction and structure with improvements in the build system. The incubating tool `diffpkg` received a lot of new features [1] that will be released shortly. The new tool helps to print differences of the current package build against the last release including file listing, pkginfo, buildinfo, diffoscope. Now it provides additional features for colored output, terminal column width and switch between side-by-side and unified output. ## archlinux-keyring The Web Key Directory (WKD) data for Arch Linux is now automatically generated from the archlinux-keyring repository upon tagging of a new version. This allows for the data to be up-to-date right after a release has been made directly from the source of truth. ## RFC We are formalizing an RFC [2] to merge the pacman repository `[community]` into `[extra]` as well as the packaging VCS location `community` into `packages`. The `[core]` repository remains limited to Developers. New Package Maintainers will be restricted to publish packages solely to `[testing]` for the first two months of their active packaging actions. ## repod The 0.2.0 release as well as subsequent patch-level releases have been made. The new releases introduce rudimentary import of package files and the writing of repository sync databases in configurable repository directories. Upcoming work will focus on establishing a framework for dealing with required steps in common packager workflows. ## buildbot A first workable proof of concept has been created which we continue to iterate over. The current state and an outline of ideas has been posted to `arch-dev-public` [3]. ## Staff We would like to welcome serebit and blakkheim among the Trusted Users [4][5]. On top we would like to welcome kgizdov to their new additional duties as Arch Linux Developers [6]. [0] https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/100 [1] https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/111 [2] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/14 [3] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [4] https://lists.archlinux.org/pipermail/aur-general/2022-August/036929.html [5] https://lists.archlinux.org/pipermail/aur-general/2022-September/036964.html [6] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o…

1 0

Dropping some packages
by Filipe Laíns 03 Sep '22

03 Sep '22

Hey all, I am doing some house cleaning on my packages. I am planing to drop some, the list is below, if you want to maintain any of them, feel free to adopt and let me know. The leftovers will probably be dropped next weekend. ghld monkeytype pcbdraw python-connexion python-covdefaults python-flake8-typing-imports python-libcst python-litedram python-liteeth python-liteiclink python-litejesd204b python-litepcie python-litesata python-litescope python-litesdcard python-litex python-litex-boards python-nmigen python-nmigen-boards python-pony python-pydecor python-pyproject2setuppy python-pythondata-cpu-lm32 python-pythondata-cpu-mor1kx python-pythondata-cpu-picorv32 python-pythondata-cpu-vexriscv python-pythondata-software-compiler_rt python-swagger-ui-bundle Cheers, Filipe Laíns

2 2

Future build infrastructure for Arch Linux
by Morten Linderud 02 Sep '22

02 Sep '22

Yo! We decided on supporting the x86_64-v3 microarchitecture but not that much have happened since then. Allan did the legwork to get some basic support into `devtools`, and suggested we start rebuilding some packages. This is a bit tedious because we don't have any infrastructure in place to do this job. Supporting two architectures would end up having us package maintainers do two builds per package that needed the support. After brooding a bit on this personally I wound up taking a stab at creating some build infrastructure for Arch. I have two personal goals: 1. Allow automatic builds and personalized staging repositories. 2. Allow rebuilds of different architectures. I have currently written a POC which does *almost* fulfill both of these goals. It uses `devtools` to build packages, and serves them over HTTP in temporary staging repositories. I decided to go with buildbot as I created something similar many years ago, and it allows us to have a flexible, programmable and independent build infrastructure which is decoupled from our VCS services. https://github.com/buildbot/buildbot The source code for our project can be found on gitlab. https://gitlab.archlinux.org/foxboron/archlinux-buildbot You can visit the buildbot instance on https://buildbot.pkgbuild.com/#/. It is also currently hooked up with keycloak so if you have a staff account you can log inn and mess around with the system. To try things out and build a list of packages, or a todo list, you can visit the "Build Package List" builder and hit the blue button: https://buildbot.pkgbuild.com/#/builders/4 Same thing for "Build Package". https://buildbot.pkgbuild.com/#/builders/1 *Please* keep in mind the builders are running on two small VMs under my TV. Do not build obscene and resource intensive packages :) If we decide we want to move forward with this we'll hook this up with more beefy hardware, but until we get there the builders are going to be some ad-hoc best effort stuff. I also need help developing these things, so please continue to read on if you are interested. It would also be great with feedback from people that have features, ideas or issues that would need to be addressed. # Architecture rebuilds To support rebuilds I have implemented a build thing which currently watches a limited set of packages on svn. An example build of vim can be found here: https://buildbot.pkgbuild.com/#/builders/12/builds/19 If you want to look at the artifacts you can visit here: https://buildbot.pkgbuild.com/srv/ftp/extra/x86_64_v3/ If you want to add packages for rebuilds you can send changes to this file: https://gitlab.archlinux.org/foxboron/archlinux-buildbot/-/blob/master/mast… The same notice applies here and I won't accept huuggee packages to be rebuilt. In the future this restriction won't be there. If anyone reading this want to try hook up risc-v builders, ARM builders or 32 bit builders it would be interesting to try that. Please reach out off-list or on #archlinux-projects @ libera. The hosting is going to be ad-hoc and best effort so there isn't any expectations of uptime :) # Building packages For general package builds I have some ideas on how to do this. But nothing is written and I need help to accomplish this. I don't expect us to deal with the buildbot interface directly, and would much rather have some abstractions in front of this to help us submit builds. Currently I have started a blank repository for `buildctl` where I want to experiment with some easy-to-use build tooling for rebuilds, so-name builds and general package bumps. https://gitlab.archlinux.org/foxboron/buildctl The mock-ups for `buildctl` is on this markdown pad: https://md.archlinux.org/NNgk9PN8QmanxElQsYBxwg It would be great to get more hands these two projects :) Please reach out to me on #archlinux-projects @ libera, or off list for questions. Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

Orphaning packages
by Jelle van der Waa 02 Sep '22

02 Sep '22

Hey, To reduce my amount of maintained packages, I'm orphaning and maybe dropping it to the AUR if no one picks it up: # Orphans * python-pyaudio * timew * python-pyenchant * rdesktop * tidy # Orphans and unrequired (can be safeuly dropped) * vim-pastie * vim-align * ccd2iso Greetings, Jelle

2 1

RFC: Merge package repositories
by Levente Polyak 01 Sep '22

01 Sep '22

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/14 Please visit the above link for discussion. Summary: Merge the pacman repository [community] into [extra] as well as the packaging VCS location `community` into `packages`. The [core] repository remains limited to Developers.

1 0

Dropping Cura from the repositories
by Jelle van der Waa 01 Sep '22

01 Sep '22

Hi, I've maintained Cura (3d printing slicer) for a while but I no longer find the energy to maintain it and keep it updated. If anyone is interested in adopting it feel free, otherwise I will drop it to the AUR in 2 weeks. Note that there is a flatpak available as alternative https://flathub.org/apps/details/com.ultimaker.cura Greetings, Jelle

1 1

Konstantin Gizdov is now a developer
by Sven-Hendrik Haase 31 Aug '22

31 Aug '22

Hey everyone, I internally proposed Konstantin Gizdov to become a developer for his sustained good work on Arch Linux and the need to touch some [extra] packages sometimes. I'm pleased to announce that he has now become a full developer. All the relevant steps have been completed and he should now already be fully onboarded. Welcome aboard, Konstantin! Sven

4 3

repod 0.2.0 release - call for testing and participation
by David Runge 22 Aug '22

22 Aug '22

Hi all, I've just released repod 0.2.0 [1] (it is available as "repod" in our repositories). There are some significant changes in this release which allow for rudimentary handling of binary package repositories in configurable directory structures. For further information please refer to the documentation [2]. I would like to take the time and invite *everyone* (people involved with any distribution making use of pacman as well as their users - especially those with private package repositories) to participate in testing and improving repod. The project is actively maintained (although admittedly currently I am the main developer working on it and additional contributions - although present and valuable - are rare) and does bi-weekly meetings. Repod aims at generically offering the ability to maintain binary package repositories of alpm based packages. As such it transcends Arch Linux as its only client - the software is meant for Arch Linux, downstream distributions and private users alike! TL;DR: Please help the development of repod and associated tooling as it is important for all pacman based distributions and their users. Historically we have had quite a few distribution driven projects which allow us to do the things we do today (e.g. mkinitcpio, archiso, archweb, aurweb, dbscripts, arch-install-scripts, devtools, etc.). All of them have in common, that they lack dedicated development from time to time or are so large/old/deep that they require more than one person to "have the hat on". This being said: I do not feel comfortable being the only/ main person currently developing repod. The project is entwined with our pursuit of moving our packaging infrastructure to a more modern, git based setup in which package sources are separated from the binary packages that are built from them (opposite to how it is currently handled with dbscripts). This process is a gradual one in which we try to decouple the source repositories from the binary package repository state, while offering certain stability guarantees when consuming and handling packages. Upcoming work will entail dealing with necessary checks required for basic movement operations, which will consolidate a lot of (partially unused) code in the dbscripts project. For a more detailed overview for further topics, please have a look at the milestones [3]. Working on the upcoming features could use many more eyes and helping hands! Another piece of the puzzle when looking at moving to a git based workflow and improving our tooling, is the automation for builds/rebuilds (the road between our package source repositories and the binary package repository management software - e.g. repod). For this some solutions exist, some of which are VCS agnostic and some of which we use in larger rebuilds all the time. Morten has started to look at a buildbot based system which could be used for rebuild scenarios and also for building different architectures in the future. To my knowledge this is still very much a WIP, but if you are interested, idle in #archlinux-projects on libera.chat to get exposed to more information (this is also the case for repod btw!). I hope I was able to give a brief overview of what is the current state of things, where we want to go from here and spark some enthusiam about the above projects. There is still a lot of work left to be done for us and any help is much appreciated! :) Best, David [1] https://gitlab.archlinux.org/archlinux/repod/-/tags/0.2.0 [2] https://repod.archilnux.page [3] https://gitlab.archlinux.org/archlinux/repod/-/milestones -- https://sleepmap.de

1 0

Away till end of August
by Leonidas Spyropoulos 12 Aug '22

12 Aug '22

Hello, I will be off till the end of August traveling and taking some time off. While I will have matrix on my phone for IRC communication I won't be having resonably stable internet and easy access to the key for packaging updates. Feel free to update any of my packages along with the ones below which have no co-maintainers except myself. # Packages $ pkgsearch -m artafinde -l 1 corectrl freeplane gdu gitlab-exporter keycloak-archlinux-theme makedumpfile memray polybar prometheus-systemd-exporter vulture Thank you, -- Leonidas Spyropoulos PGP: 59E43E106B247368

1 0

Arch Linux in July 2022
by Levente Polyak 09 Aug '22

09 Aug '22

## archlinux-keyring The archlinux-keyring package gained a systemd service and timer unit which updates existing PGP keys used by pacman on user systems by default on a weekly basis from Arch Linux's web key directory (WKD)[0]. This service is meant to remove the necessity for most cases of "first upgrade your archlinux-keyring and then do a system upgrade" until pacman itself will be able to deal with this scenario natively. A new main signing key 75BD80E4D834509F6E740257B1B73B02CC52A02A was added to the keyring. Efforts to sign all active packager keys with it are ongoing, currently around 85% of the existing keys have been signed already. ## pacman Extend --print-format with all expac format strings which can be easily added without conversions and through a simple C macro. ## Wiki After almost three years, the Lockdown extension is finally disabled and the recent changes page, page history and others are once again visible without having to log in. [1] ## repod A first release has been made, which supports rudimentary validation, inspection of package files and is available in the official repositories (see this blog post [2] for an overview). Help with the development of the project would be much appreciated. [0] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/commit/e5a2665a4… [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/597 [2] https://sleepmap.de/2022/managing-binary-package-repositories/

1 0

TU resignation
by Nicola Squartini 09 Aug '22

09 Aug '22

Dear all, Due to my involvement in other projects I'm unable to dedicate the time it deserves to Arch Linux, therefore I decided to resign from my role of Trusted User. I thank György Balló for sponsoring me 6 years ago, and everybody else who supported me during this time. It's been an honor and pleasure for me working with you. Best regards, Nicola

2 1

Configure mailing lists to automatically reject mails by non-members
by David Runge 09 Aug '22

09 Aug '22

Hi all, I'm currently partly moderating mailing lists for Arch Linux. Since we've switched to mailman3 I receive *a lot* of info from the system, that mails are being held in the moderation queue due to being sent by non-members of the respective lists. IMHO, we should configure all of our mailing lists to be subscription only (i.e. automatically reject all mail by non-members). It makes no sense for anyone to moderate these emails and is a huge waste of time for people dealing with the moderation of the lists (I get enough spam everyday as it is... ;-)). While at it: To my knowledge, we are currently still allowing HTML emails to be sent to the lists and I think those should be automatically rejected as well, as it is unnecessary bloat and is not fitting our context at all (we are not trying to click-track users on a commercial info list). Best, David -- https://sleepmap.de

5 6

Postponing August ISO due to kernel bug
by Pierre Schmitz 05 Aug '22

05 Aug '22

Hi all, nl6720 informed me about a recent kernel bug that prevents some older CPU models to boot*. While a simple workaround exists, I agree that this issue might be quite unexpected and frustrating for users. Especially since releasing a new install media on the 1st each month is more a tradition than an actual need. Therefore I'll wait for a fixed linux package. (the July ISO is still pretty recent :-)) Greetings, Pierre *) https://bugs.archlinux.org/task/75478 -- Pierre Schmitz, https://pierre-schmitz.com

3 5

Systemd service and timer for refreshing archlinux-keyring keys via WKD
by David Runge 26 Jul '22

26 Jul '22

Hi all, I currently have a MR open against archlinux-keyring [1], that adds a systemd service and timer, which would automatically refresh valid and existing keys on user systems. For people without access to the repository's ticket and merge request features, it is possible to browse the commits in question on the respective branch [2]. To quote from the accompanying ticket [3]: ``` For situations in which we do have new signatures which have been released, we may want a service on user systems that update existing keys via WKD to have an updated set of keys before updating archlinux-keyring. Rationale: Keys are updated in WKD after a release of archlinux-keyring (currently this is still done in the https://gitlab.archlinux.org/archlinux/wkd repo). User systems may upgrade any time after that and pacman will pull new keys from WKD automatically, however it will not pull updates for existing keys. Packages that are signed with a key that still had marginal trust in release A (and therefore already existed on the user system since release A) and gained full trust in release B will not be updated before the user does a system upgrade. This leads to the requirement of installing archlinux-keyring before doing a system upgrade, as otherwise the key will still have marginal trust on the user system and the signatures of other updated packages using the key in question will fail to validate. To remedy this situation I think it would be helpful to have a service update existing keys from WKD twice daily on a timer. I am not 100% sure whether this has side-effects in regards to revocations, but as we only ever update WKD after issuing a release and not when updating the default branch, this should be fine(?). ``` In short: The service in question will update any valid keys in the pacman keyring on user systems, that use Arch Linux's relevant domains as UID to retrieve updated keys (e.g. extended expiration, additional signatures). Invalid keys and those of other domains are ignored. This feature is implemented to circumvent (some, but not all) cases of "update archlinux-keyring before doing a system upgrade". Cases not covered are (in no particular order): * *long* outdated system is updated * new main signing key is required for a packager key to gain full trust for the packages about to be updated * local system's archlinux-keyring does not yet offer this feature * local system's pacman does not yet offer the feature of downloading package signatures for new keys from WKD * packager key on local system does not yet have any main key signatures and would gain full trust with an update of archlinux-keyring Currently the timer which triggers this service is supposed to be vendor enabled (i.e. symlink in /usr/lib/systemd/system/timers.target.wants/) and run daily with a deviation of up to 12h. Members of the DevOps team have raised concerns about the interval as we do not really have a clear picture about how many Arch Linux installations there are world-wide to get numbers on expected median load for this. If you have ideas for improvement or general questions, please direct them at the merge request. Best, David [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/merge_requests/1… [2] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/tree/wkd_sync_se… [3] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/184 -- https://sleepmap.de

8 13

default gems in ruby deployment
by Andreas 'Segaja' Schleifer 16 Jul '22

16 Jul '22

Hello everyone, | | | || while trying to package the ruby framework rails [0] I stumbled over the fact that ruby itself is shipping an assortment of "default gems" which they call "Standard Library" [1] [2] || and something called "Bundled Gems" [3], which is another set of "default gems". || The problem I see in these gems is that they are pulled into the ruby source repo [4] from their dedicated original sources before a ruby release and then get used in the release. || Furthermore ruby itself does not release a new version of itself whenever a gem of this standard library updates, which means that over time sooner or later most of these gems in the bundle || will be out-of-date. || Now apparently ruby has a general solution for that. You can have multiple versions of one gem installed, the "default" versions do show up with a default prefix in the `gem list` output. || | | || So much for the actual ruby state. Now I would like to highlight some points I found out about how Arch Linux is packaging ruby and the issues I see with it. || | | || Our ruby package [5] is currently removing a total of nine pre-shipped gems from the main ruby release with the comment that they are shipped in seperate packages [6]. || I recently checked and found out that three of these removed gems are not provided as packages (anymore?). Namely rbs, typerof and erb. || Furthermore the PKGBUILD has code in there which states that it removes *all* bundled gems to avoid conflicts [7], but when I run a `gem list | grep 'default'` I still see the default gems. || After some research I found out the reason is because the path in which the default gems are located are not the path that we are removing with these three lines of code. || It could be that the location of these default gems changed in some version and was never updated. || | | || The problem I see in the current situation is that we have most of the default gems still installed and then some of them get upgraded (sometimes even to a higher major version) by dedicated packages. || This can potentially break dependency changes if one of the not upgraded default gems is requiring the gem that was upgraded to a new major version. || | | || From my point of view the only real fix for this is to make sure that we again remove all the default gems so that they can be packaged seperatly. Whether or not we want to provide all gems from the || "standard library" and "bundled gems" is then a different question and would in the end require more ruby packages. || Also I would recomment to add a comment to the PKGBUILD file of these gems stating that they are part of the "standard library" / "bundled gems" and such shouldn't be dropped from the repos in the future. || | | || We also could think about putting all the "standard library" gems (and maybe even the "bundled gems") in a package group called "ruby-stdlib" or a meta-package (which I think is better). || That way users could easily install all of them with one command and we also know which packages belong to the "ruby standard library". || | | || One side effect I see with this approach is that we currently have "hidden dependencies" on some of the standard library gems like in case of ruby-nokogiri [8], which is depending on ruby-racc which is not listed in the PKGBUILD file. || Currently this package only works because racc is one of the gems in the standard library [9] and such pre-installed. If we now cleanup the ruby package we need to fix such issues. || | | || | | || Best regards || Segaja || | | || | | || [0] https://rubyonrails.org/ || [1] https://rubyreferences.github.io/rubyref/stdlib.html || [2] https://ruby-doc.org/stdlib-3.1.2/ || [3] https://rubyreferences.github.io/rubyref/stdlib/bundled.html || [4] https://github.com/ruby/ruby/tree/master/lib || [5] https://archlinux.org/packages/extra/x86_64/ruby/ || [6] https://github.com/archlinux/svntogit-packages/blob/packages/ruby/trunk/PKG… || [7] https://github.com/archlinux/svntogit-packages/blob/packages/ruby/trunk/PKG… || [8] https://bugs.archlinux.org/task/71500 ||[9] https://rubyreferences.github.io/rubyref/stdlib/string-utilities/racc.html|

4 16

Blockers for release of archlinux-keyring
by David Runge 12 Jul '22

12 Jul '22

Hi all, if you are a main signing key holder or a packager for Arch Linux, please read this mail very carefully! We are currently blocked from releasing a new version of archlinux-keyring, as a release would imply demoting a few packager keys to marginal trust (aka. not enough signatures from our signing keys to be allowed to package). Some of these marginal trust keys still (or again...) have packages in the repositories. All in all the keyring is not in very good shape due to missing revocations or signatures (and broken keys that block us from updating to a newer gnupg version, but that is for another email). Blocking the release of archlinux-keyring for this long is problematic in several ways: * existing keys that need to be updated are blocked from being released to the users and packages may need to be rebuilt if keys expire on user systems (which leads to manual action to install the keyring first, etc.) * new keys can not be released to the users (blocking packagers from packaging, leading to many outdated packages that need to be taken over by other packagers) * the updated trust status of revoked keys can not be released to the users (allowing old keys to still package) # Marginal trust keys There are currently 25(!) marginal trust keys in the keyring, some of which are old and superseded by new keys (I had to manually assign which of the keys are old/new/current for the below overview). ``` alucryd 9437DD3815A7A9169E3D3946AFF5D95098BC6FF5 ~ marginal - old andrewSC 601F20F1D1BBBF4A78CF5B6DF6B1610B3ECDBC9F ~ marginal - current arodseth 8A9BC5819C54FEB3DC2A9B48C32217F6F13FF192 ~ marginal - old arodseth 962855F072C7A01846405864FCF3C8CB5CF9C8D4 ~ marginal - new cbehan 6EA3F3F3B9082632A9CBE931D53A0445B47A0DAB ~ marginal - old coderobe 54EB4D6DB209862C8945CACCED84945B35B2555C ~ marginal - current dbermond 3FFA6AB7B69AAE6CCA263DDE019A7474297D8577 ~ marginal - old djgera 0F334D8698881578F65D2AE55ED514A45BD5C938 ~ marginal - old escondida CB33B736591A9CA06098A9A5FCAC9CF5A6EE1209 ~ marginal - old farseerfc 4B1DE545A801D4549BFD3FEF90CB3D62C13D4796 ~ marginal - old ibiru F4DDD6DDCEC320B665F502AAE8F18BA1615137BC ~ marginal - old jlichtblau 38EDD1886756924E1224E49524E4CDB0013C2580 ~ marginal - current jsteel 8742F7535E7B394A1B048163332C9C40F40D2072 ~ marginal - current juergen 355BDB97ED4724E6B3A450E7A3D9562A589874AB ~ marginal - old kgizdov 4BE61D684CB4E31741614E7089AA27231C530226 ~ marginal - old kkeen 48C3B1F30DDD0FE67E516D16396E3E25BAB142C1 ~ marginal - current maximbaz EB4F9E5A60D32232BB52150C12C87A28FEAC6B20 ~ marginal - old mtorromeo 2C118C620F02DB9AC1D0F9FA94DD2393DA2EE423 ~ marginal - old muflone C521846436D75A3294795B27B4360204B250F0D3 ~ marginal - old nicohood 97312D5EB9D7AE7D0BD4307351DAE9B7C1AE9161 ~ marginal - current spupykin 3E518BF2526FD1979E8AAE4965C110C1EA433FC7 ~ marginal - old tensor5 A9B6710D760F6617C530746EC847B6AEB0544167 ~ marginal - old thomas A314827C4E4250A204CE6E13284FC34C8E4B1A25 ~ marginal - old wild 0E87D6C3F9AF7FDED0C8588D22E3B67B4A86FDE7 ~ marginal - old xyne EC3CBE7F607D11E663149E811D1F0DC78F173680 ~ marginal - old ``` # Revoking "old" marginal trust keys Revoking these "old" keys is *very important* so that `keyringctl` properly assigns trust to the packager keys (no old key should be fully trusted or have marginal trust) and helps a lot in figuring out which keys need immediate attention going forward (because they are new or current keys!). As I have gotten mostly no reply from signing key holders in regards to this, I hereby ask Florian, Pierre and Levente to please revoke keys that need revoking [1] *now* and make sure that the revocation certificates are merged into the archlinux-keyring repository. The amount of open tickets is increasing and it makes working with the keyring more and more difficult if no action is taken! # Rebuilding packages of "old" marginal trust keys For some packager keys the process of rebuilding their packages has already been started more than four months ago [2], some of which are completed, but there are still some left [3][4][5]. I have checked the list of "old" marginal keys to see whether there are any packages in the repositories signed by them ([6]) and have created rebuild TODOs for any that needed them. # **IMPORTANT**: Rebuilding packages of "current" marginal trust keys If by Friday, 2022-07-15 20:00 CEST the marginal trust status of the "current" keys is not improved to fully trusted, the packages in the repositories signed by them will be rebuilt and a new version of archlinux-keyring will be released as soon as that is done (2022-07-16 or 2022-07-17 depending on availability). Help with any upcoming rebuilds will be very much appreciated! This means those "current" keys can not be used for packaging anymore. If you are the holder of an affected key or a main signing key holder, please communicate this accordingly, so that the key can be signed and a signature be merged in time! # Setting up packager keys for archweb If you are the holder of a packager key, please make sure to select your "current" or "new" packager key in your archweb profile, so that the signature status [7] is displayed correctly. We have *a lot* of keys that are not setup correctly. # New main signing key: Jonas Witschel Last but not least, I would like to thank Jonas for stepping up and taking on the responsibility of main signing key for Arch Linux [8]. Most, if not all packagers should by now have received a verification email by him :) Best, David [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/?label_na… [2] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [3] https://archlinux.org/todo/rebuild-packages-signed-by-48c3b1f30ddd0fe67e516… [4] https://archlinux.org/todo/rebuild-packages-signed-by-9437dd3815a7a9169e3d3… [5] https://archlinux.org/todo/rebuild-packages-signed-by-4b1de545a801d4549bfd3… [6] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/… [7] https://archlinux.org/master-keys/ [8] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/commit/42ca7f2c5… -- https://sleepmap.de

2 1

NEWS DRAFT: wxWidgets 3.2 update may need manual intervention
by Antonio Rojas 12 Jul '22

12 Jul '22

wxWidgets 3.2 provides a Qt frontend in addition to the GTK3 one, so packages have been renamed from wxgtk-* to wxwidgets-*. The GTK2 frontend is no longer provided. If you have wxgtk2 installed, the upgrade will fail with error: failed to prepare transaction (could not satisfy dependencies) :: removing wxgtk-common breaks dependency 'wxgtk-common' required by wxgtk2 In such case, uninstall wxgtk2 first with # pacman -Rc wxgtk2 and then proceed with the upgrade.

2 1

Arch Linux in June 2022
by Levente Polyak 08 Jul '22

08 Jul '22

## devtools The new devtools release brings in several new additions. First and foremost the `export-pkgbuild-keys` script in combination with `commitpkg` ensures we export all validpgpkeys into the source tree. The local keys cache will allow us to operate without remote PGP keyservers for the most part [0]. Furthermore the new `diffpkg` tool allows to automatically diff a package file against the current repository version or another package file. Multiple diff modes allow comparing archive listings, the whole content via diffoscope or the .PKGINFO and .BUILDINFO metadata [1]. Last but not least we have added `x86_64_v3` builders as a first step towards more optimized architectures. The scripts and configs can be used for testing purposes [2]. ## archlinux.page In cooperation with SPI and Gandi a new domain has been acquired to host the documentation of projects related to Arch Linux: https://archlinux.page First deployments are already available on the following subdomains: - https://repod.archlinux.page/ - https://monthly-reports.archlinux.page/ ## archiso The official installation ISO image can now boot on IA32 UEFI [3]. ## SPI The annual SPI report for member projects updates has been submitted and will be available shortly through SPI. ## glibc The glibc package ships with the `C.UTF-8` locale available by default. [0] https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/98 [1] https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/99 [2] https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/86 [3] https://gitlab.archlinux.org/archlinux/archiso/-/merge_requests/216

1 0

Gone until August
by Morten Linderud 27 Jun '22

27 Jun '22

Yo, I'll be gone from the start of July until the start of August! Vacation time along with starting a new job over the summer. I also need to recharge some batteries. If you need anything from me please tell me so we can sort it asap. Else I will be reachable if there is something important, but I won't be prioritizing it. The only exception will be a few days at May Contain Hacker in Netherlands next month where I'll be doing a self-organized session and distributing some stickers :) I've included a list of packages I'm the sole maintainer of. Feel free to co-maintain or update it when there are new releases available. Note the list contains core/extra/community packages. -- Morten Linderud PGP: 9C02FF419FECBE16 # Packages $ pkgsearch -m Foxboron -l 1 archlinux-contrib archlinux-repro asp b4 barrier bmusb bucklespring catatonit cni-plugins debugedit docker-scan dqlite flatpak-xdg-utils fsverity-utils fuse-overlayfs gopls go-tools grobi hy i3-gaps influx-cli influxdb jgmenu jq libmd mlocate mopidy nageru nano-syntax-highlighting pass-otp patatt pdfjs perl-data-perl perl-gnupg-interface perl-moox-handlesvia perl-moox-late perl-search-xapian perl-strictures perl-sub-handlesvia perl-type-tiny plocate podman-dnsname protege public-inbox python2-docs python2-typing python-adblock python-babel python-docs python-dotty-dict python-flask-babel python-formencode python-guzzle-sphinx-theme python-halo python-hid python-hjson python-jsonrpclib-pelix python-keyutils python-ldap python-log_symbols python-m2crypto python-milc python-nbxmpp python-nltk python-pew python-pydbus python-pydocstyle python-pydrive python-pyflakes python-pygame python-pykka python-pypeg2 python-pywal python-reportlab python-rope python-send2trash python-shutilwhich python-speaklater python-sphinx-autorun python-spinners python-sqlobject python-sqlparse python-typed-ast python-xlib qmk qprint raft screenkey signing-party staticcheck step-ca tailscale toolbox vim-ultisnips wpa_supplicant xdp-tools

5 4

Arch Linux in May 2022
by Levente Polyak 14 Jun '22

14 Jun '22

## Staff We would like to welcome Slithery [0] among our Forum Admins. Furthermore fukawi2 has stepping down [1] as Forum Admin. We would like to express appreciation for all the work through the years. Last but not least we held our first Mediator election where Andrea Denisse Gómez-Martínez (denisse), David Runge (dvzrv) and Morgan Adamiec (morganamilo) were elected. This has implemented the previously ratified RFC-0009 [2]. An official mediation program in our organization helps to settle disputes and provides a clear escalation path. ## gnome boxes Gnome boxes now supports installing Arch Linux from an ISO using our GeoIP mirror. ## mailman3 We started migrating our mailing lists from mailman2 to mailman3. The migration is handled list by list by DevOps. All mailman3 lists will have their From header kept unmangled, preserving the sent mail as is hence allowing to validate DKIM signatures. [0] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/454 [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/456 [2] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/9

1 0

auth-tarball-from-git: verifying signed git tags without sha256sums=(SKIP)
by kpcyrd 29 May '22

29 May '22

ohai! I blogged about a new tool that can be used to verify a tarball from a signed git tag, while still pinning the sourcecode with >= sha256sum: https://vulns.xyz/2022/05/auth-tarball-from-git/ Let me know what you think - that's all, kpcyrd

6 7

News draft: qmk>=1.1.0-1 update may require manual intervention
by Morten Linderud 29 May '22

29 May '22

The qmk package prior to version 1.1.0-1 was missing the compiled python modules. This has been fixed so the upgrade may need to overwrite any untracked pyc files created. If you get errors like these qmk: /usr/lib/python3.10/site-packages/qmk_cli/__pycache__/__init__.cpython-310.pyc exists in filesystem qmk: /usr/lib/python3.10/site-packages/qmk_cli/__pycache__/git.cpython-310.pyc exists in filesystem qmk: /usr/lib/python3.10/site-packages/qmk_cli/__pycache__/helpers.cpython-310.pyc exists in filesystem qmk: /usr/lib/python3.10/site-packages/qmk_cli/__pycache__/script_qmk.cpython-310.pyc exists in filesystem when updating, use pacman -Syu --overwrite /usr/lib/python3.10/site-packages/qmk_cli/\* to perform the upgrade. -- Morten Linderud PGP: 9C02FF419FECBE16

3 2

Arch Linux in April 2022
by Levente Polyak 24 May '22

24 May '22

## Keyring We have started phasing out sha1 keyring signatures and replace some existing keys with more modern variants. Furthermore we have started to enforce @archlinux.org UIDs so we can control the retrieval via wkd in a single place and also allow externals to just trust one official wkd domain. ## Security Team We would like to welcome djerun and raa who will help us in the security team to keep track of all vulnerabilities. ## Wiki We would like to welcome Erus Iluvatar as an ArchWiki Maintainer and Translator [0]. ## Infrastructure We now have a GeoIP based mirror https://geo.mirror.pkgbuild.com for docker images and arch-boxes. After a MR lands in osinfo-db this will allow users on all distro's with an update osinfo-db to use gnome-boxes to install Arch Linux with the "download operating system" option. [0] https://wiki.archlinux.org/title/ArchWiki:News#2022/04/13_-_New_maintainer_… [1] https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/444

1 0

Mailman3 migration and news draft
by Kristian Klausen 17 May '22

17 May '22

Hi all, As hinted in my last message, I'm in the process of migrating our mailing lists from mailman2 to mailman3[1]. We are migrating away from mailman2 as it is basically unmaintained and requires Python 2 which is EOL. At the time of writing the following active lists haven't been migrated: - arch-commits - arch-general - arch-security - aur-dev - aur-general - aur-requests - pacman-contrib - pacman-dev I'm planning to migrate the remaining lists soon and likely migrating arch-general and aur-general as the last two lists. As part of the migration I'm disabling the "mangling" of the mails to keep the DKIM signature intact (i.e. no rewrite of the "from" header nor prefixing the subject with the list name), this means "reply list" must be used when replying to the list. For that reason I think the change is worth a news item, so the users know they must use "reply list" and that they may need to update their filters. I have created a draft here[2] which I hope to post after migrating the remaining lists (feel free to edit). [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/59 [2] https://md.archlinux.org/mDhhaF0WRaOPMmyYqifn2Q Cheers, Kristian Klausen

2 1

[arch-dev-public] News draft: Undone replacement of pipewire-media-session with wireplumber
by Jan Alexander Steffens (heftig) 12 May '22

12 May '22

Hi all, I would like to post the following post-mortem to inform our users about the recent mishap with wireplumber. ``` Two days ago the `wireplumber` package was made to replace `pipewire-media-session` as the latter session manager for PipeWire is considered dead upstream and will see no more releases. Unfortunately, this step was premature. Our pipewire audio packages (`pipewire-alsa`, `pipewire-jack` and `pipewire-pulse`) ship configuration that prompt media-session to activate PipeWire's audio features. Without this configuration, PipeWire can be used without interfering with ALSA or PulseAudio when these packages are not installed. Unlike media-session, WirePlumber disregards this mechanism and will always configure PipeWire to grab audio devices. The replacement has been reverted while we attempt to look for a better solution switching to WirePlumber. If you are currently not using PipeWire for audio and `wireplumber` got installed on your system, please reinstall `pipewire-media-session` and reboot to restore audio functionality. pacman -Syu pipewire-media-session ``` Greetings, Jan

1 0

[arch-dev-public] keenerd unresponsiveness
by Jelle van der Waa 12 May '22

12 May '22

Hi All, I've tried to reach out to keenerd a couple of times about dropping some packages of him such as geda-gaf (which lets us drop guile2.0, gtk2 in the future etc.). But I haven't heard back about these mails. David has also tried to contact him about his key expiring and being unable to package after allan's master key will be revoked. Keenerd did vote in recent TU proposals and still committed in May. [1] [2] So with this email I hope keenerd responds to the keyring issue and responds to the inquiries about his old packages. [1] https://aur.archlinux.org/tu/137 [2] https://github.com/archlinux/svntogit-community/commit/dd3ec59e66ede524c5bf… Greetings, Jelle van der Waa

1 0

[arch-dev-public] possible mkinitcpio-31-3 package
by Tobias Powalowski 09 May '22

09 May '22

Hi folks, I would like to bring a new mkinitcpio package to [testing], to finally cleanup my archboot initcpio workaround hacks. Adressing the following issues on FS: - Adding NEW parameter MODULES_DECOMPRESS to mkinitcpio.conf: https://bugs.archlinux.org/task/72882 The old behaviour of decompressing modules stays the default - Adding full symlink support: https://bugs.archlinux.org/task/73493 - Allow reproducable builds in case of /var/cache exists in initramfs: https://bugs.archlinux.org/task/73817 - Added zst firmware compression support for future kernel versions The proposed patch to add is located here: https://pkgbuild.com/~tpowa/symlink-compression.patch Thanks for your feedback. greetings tpowa -- Tobias Powalowski Arch Linux Developer & Package Maintainer (tpowa) https://www.archlinux.org tpowa(a)archlinux.org St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de info(a)st-martin-apo.de

3 6

[arch-dev-public] Upcoming PHP 8.1 update
by Pierre Schmitz 25 Apr '22

25 Apr '22

Hi all, a little heads up as it takes longer than expected. I'll start the PHP 8.1 update and the required rebuilds soon. I noticed some unexpected incompatibilities and I'd like to look into these first. I'll also evaluate if we could drop the php7 packages at the same time. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

7 28

[arch-dev-public] News draft: QEMU >= 7.0.0 may need manual intervention
by David Runge 23 Apr '22

23 Apr '22

Hi all, with qemu 7.0.0 now in [staging] we have a more extensive split package setup (see accompanying TODO [1]). Under certain circumstances this will require manual intervention (or rather a specific upgrade) to regain the previous functionality: ``` With the update to qemu 7.0.0 the package has been turned into a more fine grained split package. The `qemu` package now only carries a few common files and tracks all of its leaf packages as optional dependencies. Much of the previous summarized functionality is now available via meta packages: * The functionality of `qemu` prior to 7.0.0 is replaced by `qemu-desktop` (**the transition to this package is manual**!) * The functionality of `qemu-headless` prior to 7.0.0 is replaced by `qemu-base` (the transition to this package is automatic). * The functionality of `qemu-arch-extra` and `qemu-headless-arch-extra` prior to 7.0.0 is replaced by `qemu-emulators-full` (the transition to this package is automatic). Furthermore, the meta package `qemu-full` provides all qemu related packages (excluding `qemu-docs`). As such, users that relied on the functionality of the `qemu` package prior to 7.0.0 should update using `sudo pacman -Syu qemu-desktop`. ``` Best, David [1] https://archlinux.org/todo/qemu-700-packaging-changes/ -- https://sleepmap.de

2 4

[arch-dev-public] Spring cleanup '22
by Antonio Rojas 08 Apr '22

08 Apr '22

Hello, Spring (in the northern hemisphere) is here and with it our yearly orphans cleanup. Please head to https://archlinux.org/devel/reports/unneeded-orphans/ and adopt packages that you'd like to keep in the repos. This is also a good oportunity to disown any packages you no longer want to maintain, so others can adopt them or they can be dropped if nobody is interested. If any non-dev TU wants to maintain some orphan in [extra], reply here and I'll move it to [community]. I will start dropping the leftovers to AUR in about 10 days.

4 6

Re: [arch-dev-public] Bi-weekly arch-repo-management meeting
by David Runge 06 Apr '22

06 Apr '22

On 2022-04-06 15:49:54 (+0200), Luna Jernberg wrote: > Hey! > Will miss the meeting today, and missed the one 2 weeks ago (if there was > one?) > But would gladly read the writeup or see a recording when i have time Hi! Yes, see the mail on archlinux-projects [1]. However, I might be a few minutes late myself. :) Best, David [1] https://lists.archlinux.org/pipermail/arch-projects/2022-March/005435.html -- https://sleepmap.de

1 0

[arch-dev-public] Arch Linux in March 2022
by Levente Polyak 05 Apr '22

05 Apr '22

## Staff We would like to welcome sudoforge among the Trusted Users [0]. ## RFC We have ratified a RFC to store upstream signing keys alongside the packaging sources [1]. This will allow easier successive builds without the need to continuously rely on remote keyservers to retrieve the upstream signing keys. ## security-tracker After a lot of work and with the amazing help of multiple people we have finally finished the SSO integration of our security tracker [2][3]. This is one step closer to a uniform authentication and role management across our services. Furthermore several incompatibility changes have been resolved which finally allowed us to upgrade to SQLAlchemy 1.4. [0] https://lists.archlinux.org/pipermail/aur-general/2022-March/036842.html [1] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/11 [2] https://github.com/archlinux/arch-security-tracker/pull/181 [3] https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/545

1 0

[arch-dev-public] Disowning Atom
by Nicola Squartini 30 Mar '22

30 Mar '22

Hi, I'm disowning the following packages: apm atom electron9 Atom is basically a rotten project, it gets minimal updates and relies on obsolete dependencies, so it has become a burden to maintain. Let me know if you intend to adopt it. Thanks. Regards, Nicola

2 3

[arch-dev-public] RFC Final Comment Period: Store PGP keys for source file signatures alongside PKGBUILDs
by Allan McRae 27 Mar '22

27 Mar '22

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/11 Please visit the above link for discussion. Summary: Store the PGP signing keys listed in a PKGBUILDs `validpgpkeys` array alongside the PKGBUILD in our VCS. Motivation: The PGP keyserver infrastructure has become increasingly brittle over recent years. This can make helping with updates or rebuilds of packages difficult due to lack of access to the valid signing key. Having the signing key exported alongside the PKGBUILD would allow for anybody to import the key into their keyring and verify the source.

1 1

[arch-dev-public] RFC: Forbid dummy packages from AUR
by Brett Cornwall 24 Mar '22

24 Mar '22

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/12 Please visit the above link for discussion. Summary: Reject AUR packages that fulfill package dependencies without providing the files/binaries of the package in question.

3 4

[arch-dev-public] sdl12-compat
by Jelle van der Waa 18 Mar '22

18 Mar '22

Hi all, SDL1 has been deprecated for a while now but we still have some games and programs which depend on it. Fedora started using SDL's compatbility library sdl12-compat which implements sdl1 using sdl2 which means you can run games under wayland, get better controller support and an actual maintainer library. [1] I've packaged sdl12-compat in [community-testing] and it replaces sdl, it was tested with chromium-bsu, caph and dwarffortress which all runs fine under the compatibility layer. Virtualbox and caph were successfully recompiled to test if we can still rebuild SDL1 programs. Please go forth and test :) [1] https://fedoraproject.org/wiki/Changes/SDL12onSDL2 Greetings, Jelle van der Waa

1 0

[arch-dev-public] Disowning some packages
by Felix Yan 17 Mar '22

17 Mar '22

Hi, I am disowning the following packages as an attempt to shorten my TODO and focus on packages I still use. certbot certbot-apache certbot-dns-cloudflare certbot-dns-cloudxns certbot-dns-digitalocean certbot-dns-dnsimple certbot-dns-dnsmadeeasy certbot-dns-gehirn certbot-dns-google certbot-dns-linode certbot-dns-luadns certbot-dns-nsone certbot-dns-ovh certbot-dns-rfc2136 certbot-dns-route53 certbot-dns-sakuracloud certbot-nginx dart python-acme python-jaraco.envs python-pkginfo python-readme-renderer python-sqlalchemy python-telegram-bot python-tqdm ruby-bundler treefrog-framework twine Please consider adopting what you or your packages use. Thanks. -- Regards, Felix Yan

4 3

[arch-dev-public] Arch Linux in February 2022
by Levente Polyak 08 Mar '22

08 Mar '22

## Staff sudoforge has applied [0] to become a Trusted User and the vote is currently in progress. On top we would like to welcome freswa and Foxboron to their new additional duties as Arch Linux Developers. Furthermore we have onboarded the project maintainers Torxed (archinstall) and kevr (aurweb) as Arch Linux support staff. Last but not least we held our bi-yearly Arch Linux Project Leader election where Levente Polyák was re-elected [1]. Further details about future plans, priorities and discussed topics will be posted to our arch-dev-public mailinglist. ## Aurweb With the v6.0.0 release [2], aurweb now runs on Python using the Starlette/FastAPI framework. A complete list of changes from v6.0.0 up to the current patch (v6.0.6) can be viewed at gitlab [3]. Regarding there have been some modifications to the RPC API endpoints which have broken some clients in AUR helpers. ## Toolchain A new toolchain has been released to our stable repositories including gcc 11.2.0, binutils 2.38 and glibc 2.35. Frederik has joined forces with Giancarlo as an additional toolchain maintainer and helps to reduce the workload. ## archlinux-keyring Giancarlo Razzolini has been added as a new main key holder [4] and will provide trust to our packaging keys by verifying and signing them. [0] https://lists.archlinux.org/pipermail/aur-general/2022-January/036781.html [1] https://archlinux.org/news/arch-linux-leader-election-results/ [2] https://lists.archlinux.org/pipermail/aur-general/2022-February/036786.html [3] https://gitlab.archlinux.org/archlinux/aurweb/-/tags [4] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/commit/bae4859fd…

1 0

[arch-dev-public] News draft: Keycloak 17.0.0-3 update requires manual reconfiguration
by Leonidas Spyropoulos 07 Mar '22

07 Mar '22

The `keycloak` package prior to version 17.0.0-3 was running with WildFly server. Since upstream moved to Quarkus, Arch Linux follows this approach. This means current configurations need to be migrated. The new config location needs to be adjusted from the old `.xml` format to the new `.conf` ``` /etc/keycloak/keycloak.conf ``` The new $HOME of Keycloak is in `/usr/share/java/keycloak` See Keycloak [migration docs](https://www.keycloak.org/migration/migrating-to-quarkus) and Keycloak Quarkus [server docs](https://www.keycloak.org/server/configuration) -- Leonidas Spyropoulos PGP: 59E43E106B247368

1 1

[arch-dev-public] Moving base-devel dependencies to [core]
by Allan McRae 04 Mar '22

04 Mar '22

Hi all, I notice when using devtools, the following packages from [extra] get pulled into our clean build root: extra/gc extra/guile extra/libcroco extra/libsysprof-capture extra/libxml2 These are all dependencies of base-devel packages. I'd like to move them to [core] so they are captured by the signoff process. Thank you for your lack of objection. :) Allan

2 3

[arch-dev-public] Away for most of March
by David Runge 03 Mar '22

03 Mar '22

Hi all, I'll be away for most of March and beginning of April. I still have time sporadically over the next week but will likely not be available for packaging or other things afterwards until the beginning of April. Feel free to upgrade packages that are out-of-date while I'm away. Best, David -- https://sleepmap.de

1 0

[arch-dev-public] RFC: Store PGP keys for source file signatures in SVN
by Allan McRae 02 Mar '22

02 Mar '22

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/11 Please visit the above link for discussion. Summary: Store the PGP signing keys listed in a PKGBUILDs `validpgpkeys` array in the trunk directory of SVN. Motivation: The PGP keyserver infrastructure has become increasingly brittle over recent years. This can make helping with updates or rebuilds of packages difficult due to lack of access to the valid signing key. Having the signing key exported along side the PKGBUILD would allow for anybody to import the key into their keyring and verify the source.

1 0

[arch-dev-public] Urgent reminder about packager PGP keys and packages
by David Runge 24 Feb '22

24 Feb '22

Hi all, as mentioned mid January [1] we are currently en-route to deprecating Allan's main signing key [2]. For this purpose I have added 11 rebuild TODOs for packages signed by packager keys that have been superseded by newer ones (and should then also be removed). These packages need to be rebuilt using the new packager key (or any other valid packager key, that is not explicitly mentioned in any of the TODOs), as they block the removal of Allan's main signing key. You can do so with the help of rebuild-todo (which is part of archlinux-contrib). Have a look at its help output for all available options. Please also make sure to setup your current PGP key ID in your archweb profile, so that the information on the website [3] is correct and up-to-date. The following packagers have not yet created a new key and block the effort towards deprecating Allan's signing key as well: - bgyorgy (CE0BDE71A759A87F23F0F7D8B61DBCE10901C163) - archange (69DA34D78FE0EFD596AC6D049D893EC4DAAF9129) - arodseth (962855F072C7A01846405864FCF3C8CB5CF9C8D4) - kylekeen (48C3B1F30DDD0FE67E516D16396E3E25BAB142C1) - farseerfc (4B1DE545A801D4549BFD3FEF90CB3D62C13D4796) Please make sure to create new packager keys, have them signed by at least three main signing keys and rebuild all packages signed by the old packager key until the beginning of April. After that we will start mass-rebuilds of the remaining packages in question and commence with the revocation of Allan's key (which means that the above packager keys can not be used for packaging anymore) unless other blockers come up. If you have questions, please reach out via e-mail, or in #archlinux-staff on libera.chat. Best, David [1] https://lists.archlinux.org/pipermail/arch-dev-public/2022-January/030617.h… [2] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/148 [3] https://archlinux.org/master-keys/ -- https://sleepmap.de

1 0

[arch-dev-public] Looking for co-maintainers for AWS-related packages
by Chih-Hsuan Yen 20 Feb '22

20 Feb '22

Hi all, Recently I have less and less spare time, and keeping packages related to the AWS ecosystem becomes harder as AWS is a fast moving target. I'm looking forward to co-maintainers for the following packages: python-aiobotocore python-aws-sam-translator python-aws-xray-sdk python-cfn-lint python-moto python-pynamodb Below are my packages used by packages above. Feel free to also adopt them: python-aioitertools (dependency of python-aiobotocore) python-django-fake-model (dependency of python-aws-xray-sdk) python-jschema-to-python (dependency of python-cfn-lint) python-jsondiff (dependency of python-moto) python-junit-xml (dependency of python-cfn-lint) python-nose-random (dependency of python-jsondiff) python-pg8000 (dependency of python-testing.postgresql, python-aws-xray-sdk) python-pytest-env (dependency of python-aws-sam-translator and python-pynamodb) python-sarif-om (dependency of python-cfn-lint) python-scramp (dependency of python-pg8000) python-sshpubkeys (dependency of python-moto) python-sure (dependency of python-moto) python-testing.common.database (dependency of python-testing.postgresql) python-testing.postgresql (dependency of python-aws-xray-sdk) Please reply or ping me on IRC if you adopted something, thanks! Cheers, Chih-Hsuan Yen

1 0

[arch-dev-public] Python packaging future (PEP 517 & removal of setup.py calls)
by Filipe Laíns 19 Feb '22

19 Feb '22

Hi all, As some of you might know, the Python packaging ecosystem is changing. If you have noticed a lack of setup.py or its replacement with pyproject.toml then you already ran into issues I want to discuss today. I will a bit in-depth when explaining the motivation and current state of affairs, feel free to jump directly to the "What should we do?" and "Usage summary" sections if you do not care about that. What is happening? Up until now, the de-facto build system for Python has been setuptools. This forced setuptools to try and meet every single need from users. If you are unlucky enough to need something too different, well, you are out of luck. Your options are to try to hack around by adding custom handling to your setup.py or simply to create your own tooling. To prevent this, PEP 517[1] and PEP 518[2] were proposed. PEP 517 and 518 standardize the use of different backends. PEP 517 defines a standard interface for build tools to call the backends (AKA build hooks) and PEP 518 a way for users to declare which backend to use, in a new pyproject.toml file. TL;DR: PEP 518 introduces a pyproject.toml file where people can define the backend entrypoint and requirements [3] and PEP 517 defines the interface hooks for build tools to be able to interact with them [4]. Some extra info that might be relevant: PEP 517 suggests that build tools default to the setuptools.build_meta:__legacy__ backend if no backend is specified, making them compatible with projects that have not moved to pyproject.toml. setuptools.build_meta:__legacy__ will essentially call the same setuptools hooks as invoking setup.py directly. There are several resources available that explain this much better, please have a look at them if you need a better/more in-depth explanation. I am also available for questions if anyone is having trouble understanding how all this works, I understand it's very involved :P What are the current issues? The more pressing issue is that some project are already adopting this scheme, and our current `setup.py build && setup.py install` approach is simply not compatible. There is also the issue that `setup.py install` is deprecated, and will be removed soon. We have had very extensive conversations with the setuptools upstream about this. See [5] and [6]. The available tooling PEP 517 does not support direct installs, which is what we currently via `setup.py install`. Instead it allows us to build a wheel (a Python binary package file), which we can then install to the system. So the solution is to use PEP 517 to build a wheel file for the package, and then install that file to $pkgdir. For the building step, I have written python-build[7] which provides a Python API and a CLI tool to access the PEP 517 build hooks. The project is under the Python Packaging Authority (PyPA)[8] umbrella. For the install step, there is pradyunsg/installer[9] which provides a Python API to develop Python installers, and a CLI with a simple install tool. The project is currently in the process of being moved under the Python Packaging Authority (PyPA)[8] umbrella[10]. Our current approach For project that have adopted PEP 517, in most of the cases we use dephell. dephell is a tool that reads the metadata from pyproject.toml and generates a setup.py file. For setuptools this approach is okay, it's a direct translation, which is simple enough, but there are several other backends that are starting to being used (flit, poetry, etc.). When this different backends are used, dephell tries to translate their metadata to setuptools metadata to write to setup.py. I don't think this approach is sound, it's just a hack IMO. With things evolving, the backends will introduce quirks, or completely new features not available in setuptools. This is actually happening right now, we have at least one backend in the repos that is so simply not compatible with setuptools and the dephell approach is not an option, maturin[11]. In this case we rely on maturin providing a front end (CLI) to build the wheel file. What should we do? 1) Adopt python-build/python-installer for PEP 517 projects The Python packaging guidelines have already been updated to replace the dephell approach with the new standard tooling. I'd also like to see projects like maturin being built this way, instead of using their custom CLI tool, but that is not very pressing right now. 2) Drop setup.py install in favor of python-build and python-installer We should really move a way from setup.py calls. There are several reasons for this, the main one being that direct setup.py calls are deprecated. They don't issue a deprecation warning because of technical difficulties and lack of maintainer time. Other reason is that setup.py install will generate old-style basically undocumented, or implementation-driven, Python metadata, also known as "eggs". By moving to wheels, we will be installing proper standardized metadata (.dist- info) instead of egg metadata (.egg-info). I have filled RFC 10 [12] with a formal proposal for this, as it is a fairly big change. Feel free to give feedback there. Usage summary By default, python-build will build the package in a isolated environment, as recommended by PEP 517. We don't want this behavior in our packaging so we should disable it with the --no-isolation/-n flag. By default, it will also build a source distribution (sdist), basically a release tarball, and then use it to build a wheel file, which we probably want to avoid, thus we should pass the --wheel/-w flag too. $ python -m build --wheel --no-isolation or $ python -m build -wn This will generate a wheel in dist/. Build backends can also take arguments, they can be passed with --config-setting/-C arguments. You can find out more about the python-build CLI here[13]. After that, we will want to install the wheel file into $pkgdir. That can be done by running python-installer with the --destdir/-d argument. By default, it will compile the Python bytecode for the 0 and 1 levels, matching our old behavior, so we don't need to pass any extra flag. $ python -m installer --destdir="$pkgdir" dist/*.whl or $ python -m installer -d="$pkgdir" dist/*.whl Please also check the Python packaging guidelines[14], which should be up-to- date with the new workflow. Thank you for hanging out until the end! Feel free to ping me on IRC or by email if you have any questions. [1] https://www.python.org/dev/peps/pep-0517/ [2] https://www.python.org/dev/peps/pep-0518/ [3] https://www.python.org/dev/peps/pep-0517/#source-trees [4] https://www.python.org/dev/peps/pep-0517/#build-backend-interface [5] https://github.com/pypa/setuptools/pull/2080 [6] https://github.com/pypa/setuptools/issues/2088 [7] https://github.com/FFY00/python-build [8] https://github.com/pypa/ [9] https://github.com/pradyunsg/installer [10] https://discuss.python.org/t/moving-installer-under-the-pypa-umbrella/13778 [11] https://www.archlinux.org/packages/community/x86_64/maturin/ [12] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/10 [13] https://python-build.readthedocs.io/en/latest/ [14] https://wiki.archlinux.org/title/Python_package_guidelines#Standards_based_… Cheers, Filipe Laíns

2 1

[arch-dev-public] Bi-weekly arch-repo-management meeting
by David Runge 16 Feb '22

16 Feb '22

Hi all, as announced on arch-dev-public, we would like to do bi-weekly meetings for arch-repo-management [1]. I misjudged the (current) use-case for the arch-projects mailing list though and therefore am doing the meeting announcement here. I will send another mail to discuss the current/future scope of the arch-projects mailing list. The next meeting takes place on Jitsi on 2022-02-16 at 19:00 CET (UTC+01:00): https://meet.jit.si/20220216-arch-repo-management An ics file for calendar software is attached to this mail. Best, David [1] https://lists.archlinux.org/pipermail/arch-dev-public/2022-February/030711.… -- https://sleepmap.de

2 1

[arch-dev-public] Do not release packages built against [testing] to stable repos
by Allan McRae 11 Feb '22

11 Feb '22

Hi all, Just a reminder with the toolchain in [testing] that you need to be careful when building packages for the stable repos. If you build the package using the [testing] toolchain and release it to [extra] or [community] it will fail to run with errors like: /usr/lib/libc.so.6: version `GLIBC_2.34' not found Either build the package against [testing] and leave it in [testing] until the toolchain moves, or build against the stable repos. Allan

1 0

[arch-dev-public] removed mariadb from testing
by Christian Hesse 10 Feb '22

10 Feb '22

Hello everybody, a problem has been found in MariaDB 10.6.6 and upstream decided to withdraw the release. We do the same, just removed mariadb (and galera) packages from testing. https://jira.mariadb.org/browse/MDEV-27789 -- 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

[arch-dev-public] On the toolchain current status
by Giancarlo Razzolini 09 Feb '22

09 Feb '22

Hi All, Most of you are aware that our toolchain is currently outdated. We always had very few people working on it through the years and I took over once Barth left, because it was needed. However, I have been having very little time to work on Arch related stuff lately and the toolchain is the most noticeable victim, given it is one of the most time consuming. In this meantime, a few things also happened that compounded to the issue, among them, we enabled LTO. Right now I'm working on bringing new glibc 2.35 and also waiting on binutils release so we can bring the toolchain up to date. I'm aware we also have a GCC release coming out soon, and the toolchain will need a new rebuild then. For the future, we are trying to bring more people to work with the whole toolchain, so it is not too much of a bus factor. We should have at least two toolchain maintainers, not just one. I hope this serves to assuage the concerns over the current status of our toolchain, both present and going future. Regards, Giancarlo Razzolini

2 1

[arch-dev-public] Starting x86_64_v3 port
by Allan McRae 08 Feb '22

08 Feb '22

Hi all, You may remember long in the past we discussed adding an x86_64_v3 port. From memory, pkgstats shows this will benefit ~2/3 (or 3/4?) of our users! So lets get this underway! Apart from tooling (devtools/dbscripts), we need to make some decisions. My plan is to seed the x86_64_v3 repos with x86_64 packages and then they get replaced as updates/rebuilds happen (potentially supplemented with a rebuild party). Pacman 6.0 can handle this. This is not a perfectly clean new port, but is substantially less of a burden than releasing a pure x86_64_v3 port. Our .BUILDINFO files do record the package architecture, so this mixture should not affect (e.g.) our reproducible builds etc. The decision to be made is who will package for this repo? I think these are the options: A) packagers upload both x86_64 and x86_64_v3 to the repos. Our build server will help those without x86_64_v3 machines. B) we recruit some packagers to build the x86_64_v3 packages. C) Some combination of A+B. My understanding is our x86_64 port started with B, then C, then A. I think with our build infrastructure now, we can start with A, but that is more of a burden for packagers. I doubt it will be much of a burden as x86_64_v3 specific build issues are unlikely. Is there any particular objection to requiring packagers upload both architectures? Allan

14 27

[arch-dev-public] [RFC] archweb nvchecker integration
by Jelle van der Waa 07 Feb '22

07 Feb '22

We’ve wanted automatic flagging packages out of date for a while and currently every packager has to come up with it’s own solution. Let’s solve this centralized by integrating nvchecker into archweb. nvchecker is a program which can monitor versions upstreams, github, pypi, haskell, crates.io or custom provided for updates. Various packagers already use nvchecker in some form. [1] The idea is that every package in svn has a .NVCHECKER file (linux/trunk/.NVCHECKER) which contains the package specific settings i.e.: [go] source = “github” github = “golang/go” prefix = “go” use_max_tag = true exclude_regex = “.(release|weekly|rc|alpha|beta).” Archweb will have a systemd service which regularly goes through the pkgbases, check if the file exists, runs nvchecker and if required flags the package out of date automatically. For Github sources a token is required so we can do 5000 requests per hour, Arch Linux already has a Github account so this is no issue. Felix already has a script which converts a subset of packages to nvchecker. This could be extended to apply to more packages. [2] The question is if anyone object to checking these small .NVCHECKER files into our svn repository. If there are no real objections, I'll start implementing this functionality into archweb in two weeks. [1] https://nvchecker.readthedocs.io/en/latest/usage.html#check-crates-io [2] https://github.com/felixonmars/archlinux-futils/blob/master/arch-to-nvcheck… Greetings, Jelle van der Waa

12 17

[arch-dev-public] build automation discussions
by Xyne 07 Feb '22

07 Feb '22

Hi, In the recent discussions about possibly adding support for x86_64-v3 the general consensus seemed to be that we need to first work on our packaging infrastructure (build pipelines, reproducible builds, etc.). Who's currently working on that and where I can get involved? Are there already any tools in development? Aside from some helper tools such as arch-rebuild-order I didn't find anything in the list of official projects on our Gitlab. Regards, Xyne

2 1

[arch-dev-public] Arch Linux in January 2022
by Levente Polyak 06 Feb '22

06 Feb '22

## Staff We have on-boarded wiki maintainers as part of our official staff [0] and wish a warm welcoming. We would also like to welcome BrainDamage among the Arch IRC op team. ## Debug packages The required devtools release is live, which handles debug packages and makes sure to release them when available. Currently we have a debuginfod service which is capable of delivering source listings and debug symbols to users with gdb, delve and other debuggers. This can be enabled by installing the `debuginfod` package and setting the environment variable `DEBUGINFOD_URLS="https://debuginfod.archlinux.org"`. The `debuginfod` package is also going to be providing this variable. ## devtools The devtools project has migrated to GitLab as well including all currently open merge requests and issues. Unfortunately the migrated merge requests are just a branch, in case the original authors want to update them, please resubmit the patches. ## Keyring Our new keyring tooling has completely replaced the old usage and data storage. We have merged the new curated keyring data and released the first few keyrings using the new curated tooling and data. Furthermore we have added more packager keys with @archlinux.org uids so we can make sure all important keys will be reachable through our own WKD. ## Gluebuddy A new helper tool named gluebuddy has been released [1] and successfully rolled out. Gluebuddy helps devops to maintain certain aspects of our on and off-boarding with automation by syncing GitLab groups and project settings. This reduces the required manual work and ensures we have quicker on-boarding as well as do never forget to remove permissions for former staff. ## linux-firmware The linux-firmware package has been split up to reduce download and installation size for most setups. ## OpenSearch We have replaced the elasticsearch package stack with OpenSearch. On top we have started [working towards adding Arch Linux to the official OpenSearch download page[2]. Furthermore some progress has been made to allow reproducible builds[3] [0] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/375 [1] https://gitlab.archlinux.org/archlinux/gluebuddy [2] https://github.com/opensearch-project/project- website/pull/642 [3] https://github.com/opensearch-project/OpenSearch /pull/1995

1 0

[arch-dev-public] Debug packages for Arch Linux
by Morten Linderud 05 Feb '22

05 Feb '22

I'm very happy to announce that debug packages in Arch Linux has been deployed :) This work began after FOSDEM 2020 and was announced in November 2020. However because of time constraints it took quite a while before we managed to deploy it. Currently we have a debuginfod service which is capable of delivering source listings and debug symbols to users with gdb, delve and other debuggers. This can be enabled by installing the `debuginfod` package and setting the environment variable `DEBUGINFOD_URLS="https://debuginfod.archlinux.org"`. The `debuginfod` package is also going to be providing this variable :) The debug package repositories themself are not publicly accessible nor distributed to our mirrors. This is because there is a general concern around the repository size increase. The goal is to take a look at distributing them and/or making them accessible in the future. Packages are being rebuilt for debug symbols where deemed needed by the packager and I suspect we should have a discussion around enabling the debug option by default or not. However see the section below around creating debug packages as there are some caveats of the current approach. I have added some links to the work that has been done to accomplish all of this at the bottom of this email. For general information about the instance one can look at the service itself: https://debuginfod.archlinux.org/ Previous emails on this topic: * https://lists.archlinux.org/pipermail/arch-dev-public/2020-November/030222.… * https://lists.archlinux.org/pipermail/arch-dev-public/2021-December/030583.… # archlinux.org news announcement Suggestion for the news announcement on archweb. I'll post it in a day or two unless there are any objections. Subject: Debug packages and debuginfod We are very happy to announce that debug packages are now available in Arch Linux. Debug symbols and source listing are provided through our debuginfod instance which can be utilized by debuggers such as gdb and delve. In the future we are planning to make these repositories public on our mirrors. For more information on this please visit the [archwiki](https://wiki.archlinux.org/title/Debuginfod) article, Or the debuginfod service. https://debuginfod.archlinux.org/ # Creating debug packages Currently with pacman 6.0.1-3 debug package only works on C/C++ projects. This is mostly because pacman utilizes a fairly ugly awk hack to extract sources and if it encounters a binary from Go or Rust (as an example) it is simply unable to deal with them and produces invalid packages. This is fixed with a patch i wrote which replaces the AWK hack with debugedit. https://gitlab.archlinux.org/pacman/pacman/-/commit/ae2f506ddfd11d9becda721… Until this patch is backported, or a pacman release is done, I would advise us to not build debug packages for anything that isn't using gcc/clangd. Saying that, I'm unsure how we should be documenting debug packages across our distro. They probably belong in package guidelines sections of each package, or we make a common wiki page for this. Generally Rust needs a environment variable and Golang needs a bit of work to disable decompressed DWARF headers. We can probably work something out as we go along, currently I think we should try enable debug packages on our [core] packages. When we have pacman with the above patch I can try compile a list of available methods to get debug packages from Rust, Go and other languages. Obviously I'd need some help with that :) Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16 # infrastructure https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/168 # dbscripts https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/21 https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/33 # devtools https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/78

6 9

[arch-dev-public] Scope of arch-projects mailing list
by David Runge 04 Feb '22

04 Feb '22

Hi all, while trying to use the arch-projects mailing list for an announcement I realized, that it is (probably?) not really supposed to be used for that at the moment. It explicitly states to be used for development discussion and providing patches for dbscripts, devtools, mkinitcpio, namcap, netctl, archweb and pyalpm. It seems that apart from netctl none of the above really make much use of this anymore though when it comes to development, as the projects have pivoted towards merge/pull requests on their respective VCS forges. Unless there are any objections, I propose to * add arch-repo-management and arch-release-promotion to it * change arch-projects to *also* become a general discussion list around the above mentioned Arch Linux projects * extend mailing list "about" section with information on how each project prefers to receive patches (e.g. I do not want to use the mailing list for that, but others may) Rationale: We lack a mailing list that revolves around our internal projects and which can also be used by non "elevated users" (such as Trusted Users and Developers) for more general discussion. Given the very low traffic on the arch-projects mailing list I see no issue with it becoming a per-project discussion list as well (as in our case mailing lists seem to be mainly used for discussion and not so much for development anymore these days). Best, David -- https://sleepmap.de

3 3

[arch-dev-public] arch-repo-management walkthrough 2022-02-02 19:00 CET (UTC+01:00)
by David Runge 03 Feb '22

03 Feb '22

Hi all, given recent topics for build automation and work on internal projects I would like to announce a code walkthrough for arch-repo-management [1]. I would like to give an overview of the scope of the project, its current features and which features I would like to see implemented (some of which are still in a discussion phase). I will try to add a few more tickets beforehand to track open features and to outline them better. This way I hope that it becomes easier for interested people to follow up on them. The meeting will take place on Jitsi https://meet.jit.si/20220202-arch-repo-management on 2022-02-02 starting around 19:00 CET (UTC+01:00). Any changes to the date and/or location will be announced in this mail thread. Best, David [1] https://gitlab.archlinux.org/archlinux/arch-repo-management/ -- https://sleepmap.de

4 7

[arch-dev-public] Arch Linux Secure Boot support, get it done ;)
by Tobias Powalowski 02 Feb '22

02 Feb '22

Hi guys, next topic to step up: Secure Boot support I wanted to bring this up to the mailing list to collect all info about the status of SB support. There are different approaches on how to implement SB. My question first: Do we want a signed shim for Arch Linux? If yes, how to achieve this? We should make a process in our infrastructure and document what needs to be done and who does it. Morten would you please add your thoughts about this topic on the ML, i think you are most into SB on linux. Thanks. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) https://www.archlinux.org <http://www.archlinux.org> tpowa(a)archlinux.org St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de info(a)st-martin-apo.de

3 2

[arch-dev-public] mkinitcpio some improvements and question on how kernel modules should be treated
by Tobias Powalowski 01 Feb '22

01 Feb '22

Hi guys, did some initcpio optimizing lately and implemented correct symlink handling. This saves already some space. https://bugs.archlinux.org/task/73439 Now one major problem left in recent initcpio, uncompressed modules: https://github.com/archlinux/mkinitcpio/pull/25 https://bugs.archlinux.org/task/72882 At the moment modules are uncompressed during initcpio creation. This leads to bigger RAM usage during boot, makes it a bit smaller on storage, due to not recompress compressed modules. On small initrds for normal boot this is not a big matter. My measurement with all patches added: Ramdisk size uncompressed modules: 13261677 Ramdisk size compressed modules: 13112083 (Note the compressed one is smaller due to the symlink patches added) Unpacked initramfs uncompressed modules: 35 MB Unpacked initramfs compressed modules: 26 MB Using this on the biggest "initramfs testsuite" archboot shows the most advantages. If you like to test it on your own initramfs setup you can use: https://gitlab.archlinux.org/tpowa/archboot/-/blob/master/usr/share/archboo… for /usr/lib/initcpio/functions and recreate your initramdisk. Now my question to the list, what should be the default how arch handles modules in initramfs? - Shall we leave the modules at compression level used during kernel build? --> This means the uncompression should be optional. - Shall we still uncompress the modules always? (Status now) --> Then using modules as is needs to be optional. Thanks for you input. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) https://www.archlinux.org <http://www.archlinux.org> tpowa(a)archlinux.org St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de info(a)st-martin-apo.de

3 3

Re: [arch-dev-public] Debug packages for Arch Linux
by Morten Linderud 30 Jan '22

30 Jan '22

On Sun, Jan 30, 2022 at 08:59:34PM +0100, sL1pKn07 SpinFlo wrote: > El dom, 30 ene 2022 a las 20:54, Morten Linderud (<foxboron(a)archlinux.org>) > escribió: > > > On Sun, Jan 30, 2022 at 08:49:29PM +0100, sL1pKn07 SpinFlo wrote: > > > hi > > > > > > thanks for the work! > > > > Thanks! > > > > > one question. This thing works, for example, if I build one of the > > packages > > > with debug package in the arch debuginfod site with my custom flag for > > > disable an option/feature. the debug package stored in the debuginfod > > site > > > still works? or i need to create a debug package locally? > > > > The buildid would be different so our debuginfo won't work with your > > packages. > > > > You can check with: readelf -n /bin/ls | grep -A4 build.id > > > > > If I need to build a local debug package and I want to use it > > > with debuginfod, is it possible add the link of the custom debuginfod > > site > > > in the DEBUGINFOD_URLS variable? how? is , separate? or ;? > > > > Yes, space is the seperator. See > > https://man.archlinux.org/man/debuginfod-find.1#ENVIRONMENT_VARIABLES > > > > You can also add a file under /etc/debuginfod/*.urls like we did with our > > `debuginfod` package. > > > > -- > > Morten Linderud > > PGP: 9C02FF419FECBE16 > > > > Hi > > thanks for the reply > > is here documented the file/directory structure of debuginfod "repo"? > > greetings I recommend reading the documentation frankly. debuginfod just recursively scans a set of directories which is polling our package repositories. The implementation is linked in the email. https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/168/… -- Morten Linderud PGP: 9C02FF419FECBE16

1 1

Re: [arch-dev-public] Debug packages for Arch Linux
by Morten Linderud 30 Jan '22

30 Jan '22

On Sun, Jan 30, 2022 at 08:49:29PM +0100, sL1pKn07 SpinFlo wrote: > hi > > thanks for the work! Thanks! > one question. This thing works, for example, if I build one of the packages > with debug package in the arch debuginfod site with my custom flag for > disable an option/feature. the debug package stored in the debuginfod site > still works? or i need to create a debug package locally? The buildid would be different so our debuginfo won't work with your packages. You can check with: readelf -n /bin/ls | grep -A4 build.id > If I need to build a local debug package and I want to use it > with debuginfod, is it possible add the link of the custom debuginfod site > in the DEBUGINFOD_URLS variable? how? is , separate? or ;? Yes, space is the seperator. See https://man.archlinux.org/man/debuginfod-find.1#ENVIRONMENT_VARIABLES You can also add a file under /etc/debuginfod/*.urls like we did with our `debuginfod` package. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

[arch-dev-public] Signing enclave
by Kristian Klausen 29 Jan '22

29 Jan '22

Hi all The lack of package database signing was mentioned yet again and I think it is time to get the "Signing enclave" project rolling. A design was sketched two years ago[1], and based on that design I'm proposing a new design, without a HSM, which should be implementable today. The initial goal would be setting up the necessary infrastructure for us to be able to implement package database signing. Afterwards we can iterate and adapt the solution for more use-cases (ex: releng signing). Hosting: - Hosted on a Hetzner cloud VM as most of our infrastructure - Managed by the DevOps team Key management: - A master key is generated and stored encrypted in the infrastructure repository[2] - A subkey for signing is generated and stored encrypted in the infrastructure repository[2] and unencrypted on the signing server Signing: - SSHing to a restricted UNIX user with ForceCommand=signing-script - All signing operations are logged - Only signing requests from gemini's WireGuard IP address is allowed [1] https://gitlab.archlinux.org/archlinux/signstar [2] https://gitlab.archlinux.org/archlinux/infrastructure Best regards Kristian Klausen

3 2

[arch-dev-public] packager key revokation
by Andrzej Giniewicz 27 Jan '22

27 Jan '22

Hi all, my away time got longer than I expected (announced October 2020). Due to pandemic I still have no access to my Arch machine. I will get back access to it mid July, so this is not a resignation from my TU role! This notice is due to revocation of Bartłomiej Piotrowski's main key. Together with David Runge we decided, that best approach would be to remove my current key, and add a new one when I have access to my Arch machine. We will transfer the trust to a new key then. Hope to get back to packaging stuff soon, I have a lot of ideas I want to try and being stuck with Windows laptop from work is getting on my nerves. See you soon! Cheers, Andrzej Giniewicz (giniu).

4 3

[arch-dev-public] Packages seeking Maintainers
by Jelle van der Waa 21 Jan '22

21 Jan '22

Hello, Noticing that I don't really have time and energy to maintain a part of my packages. I think it's better to disown them and let others take care of them, the list is: chromium-bsu guetzli hey (can be dropped as it's not really maintained anymore and oha is much nicer) podofo rdesktop tidy python-pytest-qt leptonica bonnie++ asciidoctor acpi gsmartcontrol ccd2iso avrdude avr-libc vim-pastie vim-align I've also disowned tesseract* which already has a maintainer, but maybe someone is interested in co-maintaining it. Greetings, Jelle van der Waa

4 3

[arch-dev-public] News draft: linux-firmware 20220119.0c6a7b3-2 requires kernel >=5.3 and package splitting
by Andreas Radke 21 Jan '22

21 Jan '22

The linux-firmware package 20220119.0c6a7b3-2 implements kernel firmware compression. Linux kernel from 5.3 on support loading from xz compressed firmware. CONFIG_FW_LOADER_COMPRESS kernel option must be enabled. All official Arch Linux kernel support this for a long time. [1] The linux-firmware package has been split into smaller packages to further reduce required disc space. Some big firmware files of rarely used hardware have been split into separate packages. This affects firmware for Mellanox Spectrum switches, Marvell devices, Qualcomm SoCs, Cavium LiquidIO server adapters, QLogic devices, Broadcom NetXtreme II 10Gb ethernet adapters. Make sure to install additional firmware packages if needed. [2] [1] https://bugs.archlinux.org/task/72899 [2] https://bugs.archlinux.org/task/72559 + https://github.com/archlinux/svntogit-packages/commit/a12e069d0cae39a87f003…

1 0

[arch-dev-public] Update to asciidoc 10.x
by Caleb Maclennan 17 Jan '22

17 Jan '22

The update from asciidoc 9.x to 10.x has been a long standing fiasco. The initial release had quite a few bugs that completely blocked our usage and (as is the case for many Python projects) packaging has gotten harder as upstream tooling is less distro friendly. After an upstream minor release and several patch releases most of the major issues are resolved and I've cobbled together packaging that works. It has been in the [community-testing] repository for a while now and has a couple signoffs. I've also mentioned some of the differences in IRC, but I thought I would give a warning here — I'm about to move it to [community]. Many Arch packages have asciidoc as a makedepends=(). Most of these do not require it as a library and thus the API changes in 10.x will not be relevant, but they do use the CLI script for converting documentation to man pages. One of the major changes in 10.x relevant to other Arch packages is that these CLI scripts /usr/bin/{a2x,asciidoc}.py are no longer distributed with the .py extension, they are just plain /usr/bin/{a2x,asciidoc}. Many upstream projects have adopted this already, but there may be some that have not and will need patching. If you do run into trouble building anything, that is the most likely culprit and the first thing to search for and patch out of upstream code. Caleb

1 0

[arch-dev-public] Updates to archlinux-keyring and signatures for packager keys
by David Runge 15 Jan '22

15 Jan '22

Hi all, in the past days there have been a few releases of our archlinux-keyring package, which contains the root trust of our distribution. We have successfully switched to using keyringctl [1] to manage the keyring. From now on all changes to the keyring are done via merge requests towards the archlinux-keyring repository, as it now serves as the source of truth, whereas in the past we have been relying on the dying SKS infrastructure or the Ubuntu keyserver (which may or may not support all key types in use). I have contacted all of you over the past months and either requested the addition of an @archlinux.org UID, the creation of a new PGP keypair or the verification of your PGP key by means of a clearsigned token. To all that have added a new @archlinux.org UID or have created a new key, please make sure that all signatures you have received from main signing keys are also present in the current keyring (`pacman-key --list-sigs <nick>@archlinux.org`) or in the current HEAD of archlinux-keyring (`./keyringctl inspect <nick>` in a clone of the archlinux-keyring repository). If you have signatures that are not yet in the keyring, you can add them yourself [2] and do not have to wait on a main signing key holder to do it. To all that have created a new key, please make sure to setup the correct PGP key ID in your archweb profile so that the website displays the signatures correctly [3]. If you have gained more than or equal to three main key signatures for your new PGP key and the key as well as those signatures are already available in the keyring in [core] please rebuild all of your packages using your new key and start the process of having your old key removed [4]. For the purpose of mass package rebuilding you may create a TODO [5] and use `rebuild-todo` (in the archlinux-contrib package) which makes use of our build server infrastructure. I have not yet gotten a response from or have not yet been able to resolve my request with the following packagers (nickname in the archlinux-keyring repository): - bgyorgy - archange - arodseth - kylekeen - daurnimator - pierre - farseerfc Please make some time to create a new key/ UID/ or get signed, as Allan would like to revoke his signing key in the near future (which may mean the inability to sign packages and mass rebuild of packages in question) as soon as the above packager signature situation has stabilized. In case you have questions, feel free to reach out in #archlinux-staff on libera.chat or via mail. If you are interested in helping further develop keyringctl, have a look at the relevant open tickets [6]. Best, David [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/#usage [2] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/… [3] https://archlinux.org/master-keys/#master-sigs [4] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/… [5] https://archlinux.org/todo/add/ [6] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues?scope=all… -- https://sleepmap.de

4 5

[arch-dev-public] Arch Linux in December 2021
by Levente Polyak 09 Jan '22

09 Jan '22

## Staff We are happy to welcome Segaja among the Trusted Users [0]. ## Monthly Report We have switched the format of the monthly report to specifically report the progress of the whole previous month. ## Debug packages The dbscripts repository handling for debug packages has successfully been merged [1] and deployed. Successive integration has been submitted to devtools [2] as well as pacman improvements related to PKGINFO [3] and debugedit [4][5]. ## Keyring As the last step of migrating our keyring to a new tooling and a local source of truth we have re-boostrapped the trust with an initial import of the old trust data into the new curated data structure [6]. We are still inviting people to look at the current trust data and cross verify the results. ## pacman A new library dependency feature has been submitted to makepkg [7]. At the end of package building, makepkg will look in the library directories and auto add a library provide that packages can auto depend on. Patches were submitted to alternatively choose asignify for package signatures [8] while keeping gnupg as default in place. ## LTO With the availability of the latest devtools release a lot of freshly updated packages were built with LTO. We have encountered different set of issues that needed to be tackled. Some language specific problems have popped up including but not limited to Go and Rust that require some documentation and adjustments. ## ArchWiki After being broken for almost four months, ArchWiki is once again readable on small screens. [0] https://www.mail-archive.com/aur-general@lists.archlinux.org/msg00635.html [1] https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/21 [2] https://github.com/archlinux/devtools/pull/78 [3] https://lists.archlinux.org/pipermail/pacman-dev/2022-January/025464.html [4] https://sourceware.org/debugedit/ [5] https://lists.archlinux.org/pipermail/pacman-dev/2022-January/025471.html [6] https://gitlab.archlinux.org/archlinux/archlinux-keyring [7] https://lists.archlinux.org/pipermail/arch-dev-public/2021-December/030582.… [8] https://lists.archlinux.org/pipermail/pacman-dev/2022-January/025439.html

1 0

[arch-dev-public] Elastic stack packages have been replaced by OpenSearch
by Justin Kromlinger 08 Jan '22

08 Jan '22

Due to the licence change of Elasticsearch and Kibana from Apache 2.0 to SSPL [0] both packages have been stuck on the last Apache 2.0 version for a while. For this reason both have now been moved to the AUR and are replaced by OpenSearch and OpenSearch Dashboards in community [1]. Please refer to the official migration guide [2] and consider providing any insights on the ArchWiki page [3]. While the beats agents [4] are still on Apache 2.0 newer versions suffer compatibility issues [5] with ElasticSearch OSS and OpenSearch. Thus those have been moved to the AUR as well. Please note that the AUR packages are now orphans, feel free to adopt them. [0] https://www.elastic.co/pricing/faq/licensing [1] https://archlinux.org/packages/?sort=&q=opensearch [2] https://opensearch.org/docs/latest/upgrade-to/upgrade-to/ [3] https://wiki.archlinux.org/title/OpenSearch#Upgrading_from_Elasticsearch_OSS [4] https://github.com/elastic/beats [5] https://wiki.archlinux.org/title/OpenSearch#Compatibility_with_Beats_OSS -- hashworks Web https://hashworks.net Public Key 0x4FE7F4FEAC8EBE67

1 0

[arch-dev-public] RFC Final Comment Period: Rename the Trusted User role
by Konstantin Gizdov 05 Jan '22

05 Jan '22

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/7 Please visit the above link for discussion. Summary: It is shown in some cases that the Trusted User role naming leads to some confusion and misunderstanding in broader contexts outside Arch Linux. This RFC aims to remedy that with a better suited term to reflect more accurately upon TUs' roles and responsibilities as well as their position in the Arch Linux Organisation. -- Regards, Konstantin

1 0

[arch-dev-public] OpenSearch released to Community
by Justin Kromlinger 05 Jan '22

05 Jan '22

Hello everyone, As mentioned in a previous mail [0] I've taken some time to bring the ElasticSearch fork OpenSearch to Community [1]. I've also added twelve plugin packages, a package for the Kibana fork OpenSearch Dashboards and eight plugin packages for that. Additionally I packaged the opensearch-cli Go binary which currently conflicts with the opensearch package. More plugins will follow, but most of them can be installed manually as well (f.e. ingest-attachment). I've tested both opensearch and opensearch-dashboards with my old node data, but some plugins are untested because I have no experience with them (primarily the security plugin), so I would be happy if someone could test them out. Please note that opensearch doesn't use the upstream-included JRE and opensearch-dashboards doesn't use the upstream-included NodeJS but the ones provided by our repositories. Please keep that in mind for any bug reports towards upstream. This brings up the elastic-question: What should we do with the elasticsearch and kibana packages? If we keep them, someone would need to adopt them - I will orphan them since I won't be using them anymore. Do we want to update them to their newest version with the new Elastic license? Or drop them to the AUR? If we update them to a newer version the beats packages versions are complicated as well. The 7.X versions already need additional configuration in opensearch and versions >=7.13 won't work at all [2]. I would recommend new packages for the beats-oss version 7.12.1 or even 7.10.2 as recommended by opensearch. Euch einen guten Rutsch ins neue Jahr or a Happy New Year, hashworks [0] https://lists.archlinux.org/pipermail/arch-dev-public/2021-August/030496.ht… [1] https://archlinux.org/packages/?sort=&q=opensearch [2] https://opensearch.org/docs/latest/clients/agents-and-ingestion-tools/index/ -- hashworks Web https://hashworks.net Public Key 0x4FE7F4FEAC8EBE67

2 2

[arch-dev-public] RFC Final Comment Period: add an official mediation program to our organization
by Levente Polyak 27 Dec '21

27 Dec '21

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/9 Please visit the above link for discussion. Summary: Add an official mediation program to our organization consisting of elected mediators to help settle disputes and provide a clear escalation path. Best, Levente

1 0

[arch-dev-public] Fun with LTO and stripping
by Allan McRae 25 Dec '21

25 Dec '21

With the latest devtools, LTO is enabled by default. This causes an issue with .a and .o archived when stripping. Look out for output like: strip: ./usr/lib/st4RPjCb/libsyslog_ng_native_connector_a-native-grammar.o: plugin needed to handle lto object That file is now nicely mangled! Turns out this is a very well known issue in other distros, and has not been fixed in binutils since reported in 2017. There are a couple of workarounds: 1) disable LTO for that package 2) add -ffat-lto-objects to the C{,XX}FLAGS for those packages I can see how to fix this in makepkg, but that will take a few days to push out. In the meantime, pay attention to your build output! Cheers, Allan

6 7

[arch-dev-public] News draft: libxml2>=2.9.12-6 update may require manual intervention
by Jan Alexander Steffens (heftig) 24 Dec '21

24 Dec '21

The libxml2 package prior to version 2.9.12-6 was missing the compiled python modules. This has been fixed in 2.9.12-6, so the upgrade may need to overwrite any untracked pyc files created. If you get errors like these libxml2: usr/lib/python3.10/site-packages/__pycache__/drv_libxml2.cpython-310.opt-1.pyc exists in filesystem libxml2: usr/lib/python3.10/site-packages/__pycache__/drv_libxml2.cpython-310.pyc exists in filesystem libxml2: usr/lib/python3.10/site-packages/__pycache__/libxml2.cpython-310.opt-1.pyc exists in filesystem libxml2: usr/lib/python3.10/site-packages/__pycache__/libxml2.cpython-310.pyc exists in filesystem when updating, use pacman -Suy --overwrite /usr/lib/python3.10/site-packages/__pycache__/\* to perform the upgrade.

2 1

[arch-dev-public] community.files pacman database corrupt
by Pierre Schmitz 21 Dec '21

21 Dec '21

Hi all, Since Aug 30 07:17:11 CEST the "community.files" database (repos.archlinux.org/community/os/x86_64/community.files) seems to be corrupted. The package "ipguard-1.04-6" has an empty "desc" file. The "files" file has content though. Also the regular "community.db" file does seem fine. I also do not see that package being updated or moved. I did not try to regenerate the file yet to not make it harder to find the issue. Greetings, Pierre

4 5

[arch-dev-public] Arch monthly report December 2021
by Levente Polyak 21 Dec '21

21 Dec '21

## Report The pad for the next January 2022 report is available at [0]. ## Staff We are happy to welcome artafinde [1] among the Trusted Users. Additionally Segaja has applied [2] to become a Trusted User and the vote is currently in progress. ## mkinitcpio A new mkinitcpio version v31 has been released [3]. Besides various nice improvements the biggest highligh of this release is support for efi stub generation [4]. There is also a new wiki page for Unified kernel images [5]. ## Keyring The new keyringctl tooling has been finalized and merged. The next steps are to convert the keyring data using the new tooling to a curated source of truth. Additionally we have started to replace packager keys that were not meeting our latest strength requirements [6] and to ensure that each key has a dedicated @archlinux.org UID. The goal is that for packaging purpose we only sign @archlinux.org UIDs with the main keys but still allow web-of-trust cross-sigs issued from packager keys. ## Devtools A new devtools version 20211129 has been released [7]. The new devtools package is waiting in [staging] for the python 3.10 rebuild to finish in order to avoid additional hassle with an already cumbersome rebuild. LTO has additionally been enabled is this release as the issues should be easy to spot and extremely simple to work around by just setting an `options` knob inside the PKGBUILD. Once devtools has been moved out of [testing], a wide ranged rebuild is planned to make use of the new flags on a broad scale. ## Python The process to upgrade to Python 3.10 has started and we are currently rebuilding [8] all Python packages. Packagers are also actively working on removing Python 2 from the repositories. Packages used for development, like python2-virtualenv and python2-pip, was recently removed [9] and there is work under way to clear out rest of the python2 packages. ## archinstall A new archinstall version 2.3.0 has been released [10] with a lot of new functionality and improvements. Most notably it contains: * GRUB and Disk Encryption now properly works and supports multiple encrypted volumes. * BTRFS subvolumes *(beta only supports a nested structure [11] and has some known issues [12])* * A rudimentary plugin-support [13], allowing users to create their own plugins. * swap [14] has been added into the mix using zram [15] and zram-generator [16]. ## Reproducible Builds A new rebuilderd version has been released that supports build groups, meaning it's now possible to have one build reproduce multiple artifacts at once. This aids being able to check split packages more efficiently instead of building the whole group multiple times for every single split artifact. archlinux-repro has also had a new bugfix release [17]. [0] https://md.archlinux.org/Hu6IMKXCTLa9bv0yh-WCrg [1] https://lists.archlinux.org/pipermail/aur-general/2021-October/036617.html [2] https://lists.archlinux.org/pipermail/aur-general/2021-November/036672.html [3] https://github.com/archlinux/mkinitcpio/releases/tag/v31 [4] https://linderud.dev/blog/mkinitcpio-v31-and-uefi-stubs/ [5] https://wiki.archlinux.org/title/Unified_kernel_image [6] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/best-pract… [7] https://github.com/archlinux/devtools/releases/tag/20211129 [8] https://lists.archlinux.org/pipermail/arch-dev-public/2021-November/030564.… [9] https://lists.archlinux.org/pipermail/arch-dev-public/2021-November/030555.… [10] https://gitlab.archlinux.org/archlinux/archinstall/-/tags/v2.3.0 [11] https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Nested [12] https://github.com/archlinux/archinstall/issues/718 [13] https://github.com/archlinux/archinstall/blob/master/archinstall/lib/plugin… [14] https://wiki.archlinux.org/title/Swap [15] https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html [16] https://wiki.archlinux.org/title/Swap#zram-generator [17] https://github.com/archlinux/archlinux-repro/releases/tag/20211205

3 2

[arch-dev-public] Library dependencies
by Allan McRae 17 Dec '21

17 Dec '21

Hi all, I submitted a patchset to pacman that I would like some packager feed-back on. [1] Essentially this replaces the old libdepends/libprovides system into something akin to that used by APK. In short, makepkg.conf will have a variable like: LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32') At the end of package building, makepkg will look in the library directories and add a provide. E.g. for pacman: provide = lib:libalpm.so.13 Note the prefix matches the prefix given to the relevant directory in LIB_DIRS. Similarly, makepkg can add dependencies on libraries. E.g. pacman may have: depends = lib:libgpgme.so.11 Note, to help with bootstrapping this system, or if packages just do not want to add libprovides, the depends entries are only added if a package actually provides them. This is different to the APK system for libraries which uses "so" as the prefix and is not configurable. But Alpine used musl, which has no concept of multilib, so we need to be a bit more flexible. Note the "lib" and "lib32" prefixes are just for discussion. Arch can configure how they want. The dependency/provides additions can all be disabled in pacman.conf with the '!autodeps' option. Note that APK has similar things for binaries and pkg-config files. e.g. provides = cmd:pacman provides = pc:libalpm These can now be readily be added as dropins to libmakepkg. Any opinions on this would be greatly appreciated. Is this a better system than the current one? Is adding automatic dependencies against the spirit of makepkg where everything is in the PKGBUILD? Thanks, Allan [1] https://gitlab.archlinux.org/pacman/pacman/-/commits/allan/autodeps

3 6

[arch-dev-public] Debug package support in dbscripts
by Jelle van der Waa 16 Dec '21

16 Dec '21

Hi All, Foxboron has been working on support for debug packages in dbscripts the past year. The progress has been slow but we are at a stage where we want to deploy the dbscripts portion of this. That means that on Thursday 17:00 until 20:00 UTC+1 we will close down repos.archlinux.org for any package updates. The idea is to try limit any potential unforseen bugs and have a small testing phase before opening it like normal. If we do find bugs we will rollback any changes and work out the bugs. If everything goes according to plan we’ll work on a devtools patch that would allow debug package updates. Then it is up to us if we enable debug for all packages or make it opt in. If people are curious about the introduced changes, they can be found here: https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/21 The original proposal from November last year can be found here: https://lists.archlinux.org/pipermail/arch-dev-public/2020-November/030222.… Cheers, Foxboron & Jelle

2 3

[arch-dev-public] Python 3.10 rebuilds
by Evangelos Foutras 12 Dec '21

12 Dec '21

For the next few days we'll be doing (semi-automated) rebuilds for Python 3.10. Please avoid adding new Python packages and starting other rebuilds during this time. *This is a strong suggestion in order to minimize the pain of this huge rebuild.* Some PKGBUILDs were modified in /trunk to use the Python 3.10 site-packages path (among other tweaks). Building those against Python 3.9 might fail or produce incorrect packages. The affected packages are listed in the following two commits and care should be taken when updating them while the Python rebuild is ongoing. https://lists.archlinux.org/pipermail/arch-commits/2021-November/1084956.ht… https://lists.archlinux.org/pipermail/arch-commits/2021-November/1084957.ht…

2 4

[arch-dev-public] RFC: add an official mediation program to our organization
by Levente Polyak 08 Dec '21

08 Dec '21

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/9 Please visit the above link for discussion. Summary: Add an official mediation program to our organization consisting of elected mediators to help settle disputes and provide a clear escalation path. Best, Levente

1 0

[arch-dev-public] RFC: Rename the Trusted User role
by Konstantin Gizdov 02 Dec '21

02 Dec '21

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/7 Please visit the above link for discussion. Summary: It is shown in some cases that the Trusted User role naming leads to some confusion and misunderstanding in broader contexts outside Arch Linux. It is furthermore recently been discussed that it also led to similar confusion among members of Arch Linux as well internally. This RFC aims to remedy that with a better suited term to reflect more accurately upon TUs' roles and responsibilities as well as their position in the Arch Linux Organisation. -- Regards, Konstantin

1 0

[arch-dev-public] Arch Monthly Report - November
by Jelle van der Waa 01 Dec '21

01 Dec '21

Hi All, This is the first of hopefully a monthly mail on the first day of the month on the progress of important parts of our distribution. If have something which should be included, please pm / mail me. Or add it to the pad. https://md.archlinux.org/ejoz5fgLTzaSxlBBZcgphA Now for the news: ## Devtools A new devtools release is being prepared with it's most notable changes: [0] * Now licensed to GPLv3 * devtools now records the used BUILDTOOL / BUILDTOOLVER in BUILDINFO, this is required for when we need to reproduce an old package which was build with a different devtools version then the current. (And devtools changed the CFLAGS, etc.) * makerepropkg now supports reading BUILDTOOL / BUILDTOOLVER from a BUILDINFO file and use the makepkg.conf from the correct devtools version. * pacman's makepkg.conf is synced with new hardening CFLAGS such as `-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection` * More missing man pages have been added for archbuild, makechrootpkg, arch-nspawn. ## DBScripts There has been great progress on debug support for dbscripts , review and testing is very much appreciated. [1] Dbscripts was moved to Gitlab with Gitlab CI coverage integration. ## Keyring The archlinux-keyring project gained new tooling called keyringctl to more easily handle the distribution's chain of trust, identify problems with packager keys and allow for a git-based workflow around addition, signing and revocation of packager and main signing keys. The keyring will become a curated source of truth and removes dependency on remote keyservers. [2] archlinux-keyring is now also moved to Gitlab with Gitlab CI coverage integration. ## aurweb Aurweb is being rewritten in Python using FastAPI, an announcement has been posted that the new port can be tested on https://aur-dev.archlinux.org [3] The AUR now provides metadata archives of all AUR packages, to offload requests from the AUR RPC interface. https://aur.archlinux.org/packages-meta-v1.json.gz https://aur.archlinux.org/packages-meta-ext-v1.json.gz For more information see the post on aur-general. [4] ## Arch Linux website A MR has been made to make our navbar responsive and in the future archweb (archlinux.org) responsive in this PR. Moving to SASS also makes it easier to get a working dark mode. [5] [6] Additionally a new archweb release should have a feature to add a note to a package to show why it's outdated. [7] ## releng The monthly release artifacts (i.e. installation medium, bootstrap image, iPXE images) can now be built in GitLab CI and are released automatically on a monthly basis in the releng project. [8] To further automate the release process on the main repository server, arch-release-promotion is about to be tested for the promotion and synchronization of release artifacts in the relevant projects (i.e. releng or arch-boxes). This will enable for a streamlined and automated update of the Arch Linux website with new release information. [9] A related ticket tracks the work on restructuring the output directory to offer a unified approach to non-package releases on the main repository server in the future. [10] [0] https://github.com/archlinux/devtools/compare/20210202...master [1] https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/21 [2] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/merge_requests/24 [3] https://lists.archlinux.org/pipermail/aur-general/2021-October/036614.html [4] https://lists.archlinux.org/pipermail/aur-general/2021-November/036659.html [5] https://gitlab.archlinux.org/archlinux/archlinux-common-style/-/merge_reque… [6] https://github.com/archlinux/archweb/pull/382 [7] https://github.com/archlinux/archweb/issues/269 [8] https://gitlab.archlinux.org/archlinux/releng [9] https://gitlab.archlinux.org/archlinux/arch-release-promotion [10] https://gitlab.archlinux.org/archlinux/releng/-/issues/11

4 7

[arch-dev-public] Dropping python2 as a development environment
by Jelle van der Waa 29 Nov '21

29 Nov '21

Hi All, I would like to propose that we start deprecating python2 and only allowing to exists for: * Make dependencies where required (js68, grafana-zabbix, etc.) * Runtime dependencies such as (john, displayical, etc.) This would basically imply that we drop python2-pip and python2-virtualenv from our repositories and with them tons of python2 modules. A follow up step is to consider dropping check() from python2 modules but I'd prefer to drop python2-virtualenv and python2-pip first and see what's left. Another option is dropping all python2 optional dependencies, but this list is getting smaller every day. Postgresql should drop it's python2 optional dependency by now. Greetings, Jelle van der Waa

2 2

[arch-dev-public] RFC: Rename the Trusted User role
by Konstantin Gizdov 12 Nov '21

12 Nov '21

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/7 Please visit the above link for discussion. Summary: It is shown in some cases that the Trusted User role naming leads to some confusion and misunderstanding in broader contexts outside Arch Linux. It is furthermore recently been discussed that it also led to similar confusion among members of Arch Linux as well internally. This RFC aims to remedy that with a better suited term to reflect more accurately upon TUs' roles and responsibilities as well as their position in the Arch Linux Organisation. -- Regards, Konstantin

4 5

[arch-dev-public] Netboot of 2021.11.01 ISO image is broken
by Pierre Schmitz 01 Nov '21

01 Nov '21

Hi all, I did have some trouble build the current ISO image. As archiso requires to be run as root I had to work around some issues with GPG. As those did no longer work I thought I manually sign the artifacts. This did work fine, but later on I noticed that when using Netboot (PXE), mkinicpio-archiso is no longer able to verify the FS due to lack of any public key for GPG to use. In the meantime I moved the arch folder from the release directory. Note: just using Netboot is broken; the regular ISO image is fine. The whole PXE boot setup is weird though. It starts with a openssl signature for which I am the only one to sign it. We then verify the airootfs using gpg for which we provide the public key (the part which is currently broken). Wouldn't it be enough to instead verify the integrity using the sha checksums we already have, if it was already contain in the ssl signed image? Before diving deeper into the issue in oder to solve it, I was wondering if it wouldn't be better to ditch the whole netboot setup. It is quite complex and hard to test. What do you think? I have to admit that I do not know of any use case where you could not use a regular ISO image and had to use PXE boot. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

2 3

[arch-dev-public] Call for review: keyringctl as tooling for a curated keyring
by Levente Polyak 26 Oct '21

26 Oct '21

Hi all, to mitigate different issues with the current status of PGP keyservers and to simplify the management of our keyring we worked towards exploring a new way to handle our keyring: The idea is to have a curated keyring whose source of truth is the repository itself without relying on external component to collect the WoT. The repository will consist of atomic files representing PGP packets which a directory structure logically combines into individual certificates. The advantage is that a new signature is literally just a new independent file as a merge request against the repository which is also very easy to audit. David and me have spent quite some time to develop keyringctl [0]. This tool will provide a convenient UX to work with, and inspect the decomposed certificates. Furthermore it will also be responsible to join all certificates into a keyring and export ownertrust and revocation status as pacman requires. For now bootstrap the keyring directory from the old PGP data by: > ./keyringctl import --main master master-revoked > ./keyringctl import packager packager-revoked We are calling for review and testing specifically for the following: - Try to find bugs by bench testing the commands with real world use cases and files. Some usage examples: [1] - have individual people verify the pacman compatible artifacts created by the `build` command. cheers, David & Levente [0] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/merge_requests/24 [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/blob/feature/cur…

1 0

[arch-dev-public] RFC Final Comment Period: Adoption of a distribution-wide Code of Conduct
by David Runge 11 Oct '21

11 Oct '21

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/6 Please visit the above link for discussion. Summary: The adoption of a distribution-wide Code of Conduct (CoC) helps to describe the social contract by which communication takes place on the various communication channels offered by Arch Linux. This document describes the current CoC, its purpose and location and how to interact with it. Best, David

7 20

[arch-dev-public] New archweb release
by Jelle van der Waa 29 Sep '21

29 Sep '21

Hi all, Today archlinux.org was updated to the latest version with some notable changes: * Port more jQuery code to vanilla JavaScript, saves a wopping 30 kB of network data for the package detail view. * Fixed a bug in the importing of rebuilderd data with packages which contain an epoch. * Full GPG fingerprint are now shown in Developer Profiles * Reporead (imports repository databases) now supports falling back to reading package signatures from disk. This work is done in preparation for when pacman no longer embeds signatures in the repository database saving some bandwidth when fetching the repo databases. Greetings, Jelle van der Waa

1 0

[arch-dev-public] linux-firmware package, some thoughts
by Tobias Powalowski 28 Sep '21

28 Sep '21

Hi guys, lately did a lot of archboot hacking and stumbled over our firmware package. It needs installed 750 MB, download size is 130 MB. I tried to get it smaller and uploaded the archboot-linux-firmware package for my purposes. Our linux kernel needs only 180 MB installed size, download size is about 37 MB. Wouldn't it make sense to provide for each kernel we ship, a separate firmware package? Just my 2 cwnts, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

6 7

Re: [arch-dev-public] Packages added to todo list 'libgexiv2 0.14.0'
by Jan de Groot 20 Sep '21

20 Sep '21

Arch Website Notification schreef op 2021-09-20 14:05: > Todo list information: > Name: libgexiv2 0.14.0 > URL: https://archlinux.org/todo/libgexiv2-0140/ > Creator: Alexander Rødseth > Description: > libgexiv2.so.2.0.0 → libgexiv2.so.2.14.0 > > Rebuilds go to [staging]/community-staging]. Thanks. There is no major soname bump in 0.14 (.so.2), release notes don't mention an ABI break, so why this rebuild?

1 0

[arch-dev-public] Go 1.17 released - to rebuild or not to rebuild
by Morten Linderud 15 Sep '21

15 Sep '21

Yo, I packaged up the new Go release yesterday and moved it over to stable earlier today. Usually new Go minor releases frequently include new compiler improvements and some assorted runtime changes. Previous releases I have done complete rebuilds of Go packages in our repositories but the reception for these rebuilds have been a bit mixed. People do not really see the need to rebuild $goWorld when packages a compiled and nothing inherently breaks unless there is a rebuild. We don't do this for GCC, Rust and so on. However I do think it's nice to group up these ecosystem changes in one swoop as it spares me from having to repeat myself for the next few months as people occasionally update their Go packages. But on the other hand I'm not super eager to be alone rebuilding all of this either. So what are peoples thoughts on the subject? Go 1.1 release notes: https://golang.org/doc/go1.17 Previous rebuild: https://archlinux.org/todo/go-116-rebuild/ -- Morten Linderud PGP: 9C02FF419FECBE16

5 4

[arch-dev-public] Formal Objection to Adopting the Code of Conduct
by Allan McRae 15 Sep '21

15 Sep '21

We appear to be reaching the point where a formal code of conduct will be officially adopted. What is that I hear you say? We have had a Code of Conduct for a long time? And you are incorrect. The history of the Code of Conduct is poorly documented. But it started out as a forum guidelines written by one of the forum admins. As far as I can ascertain, this document had no input from the project leadership. At some stage this was moved to the wiki and became titled as a Code of Conduct as more general points were added to cover aspects of Arch beyond the forums. At no point has this code of conduct ever been formally adopted by the distribution. In fact, our distribution has no constitution detailing what the purpose of this distribution is and how it will be governed. So there is no formal process for officially adopting a Code of Conduct. Why does this matter now? The Code of Conduct is moving from being a random wiki page, to a "binding" document that users must agree to in order to access our services. Before this can happen, Arch Linux needs to adopt a formal governance structure in order to approve such a binding change. Take a look at other distributions governance structures and constitutions: https://www.debian.org/devel/constitution https://docs.fedoraproject.org/en-US/council/ I formally object to adopting a formal Code of Conduct until we have a clear governance structure who can develop the policies and procedures that are formally needed to enforce a Code of Conduct. Currently the Code of Conduct states the Project Leader is responsible for enforcement, although that is not listed as one of their duties as approved when developing the Project Leader election procedure: https://wiki.archlinux.org/title/DeveloperWiki:Project_Leader This once again demonstrate the lack of formal governance within the distribution. We can not proceed with a Code of Conduct (or the Terms of Service and Privacy Policy), until a formal governance structure and procedures are developed to approve such documents. Again, until such a governance structure has been developed, I formally object to the official adoption of the Code of Conduct. Kind regards, Allan

3 5

[arch-dev-public] RFC: Adoption of a distribution-wide Code of Conduct
by David Runge 15 Sep '21

15 Sep '21

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6 Please visit the above link for discussion. Summary: The adoption of a distribution-wide Code of Conduct (CoC) helps to describe the social contract by which communication takes place on the various communication channels offered by Arch Linux. This document describes the current CoC, its purpose and location and how to interact with it. Best, David

1 0

[arch-dev-public] namcap maintainership
by Jelle van der Waa 29 Aug '21

29 Aug '21

Hi All, I find a bit unfortunate to write this email, but I've emailed keenerd one month ago about git.archlinux.org being deprecated and namcap which he maintains being moved to Gitlab. So far I have not received a reply from keenerd. It also seems that namcap has not seen commits in a year and there are patches on the mailing list (arch-projects) for it. [2] [3] I would love to see someone from our team pick up namcap maintainership, take a look at all the pending patches, bugs on the tracker and keep it in shape. Is anyone interested in potentially picking up this task? [1] https://gitlab.archlinux.org/pacman/namcap [2] https://lists.archlinux.org/pipermail/arch-projects/2021-January/005411.html [3] https://lists.archlinux.org/pipermail/arch-projects/2020-December/005403.ht… Kind regards, Jelle van der Waa

6 6

[arch-dev-public] 2FA credentials backup
by Kristian Klausen 29 Aug '21

29 Aug '21

Hi all In the past week two staff members have lost their phone and thereby their 2FA credential for accounts.archlinux.org. The DevOps team can remove 2FA if they are provided with a GPG signed mail, but we would prefer not spending time on that. So please consider backing up your 2FA credentials. On Android the following apps support backup: * https://github.com/andOTP/andOTP * https://getaegis.app/ Authy is also worth mentioning although it is proprietary: * https://authy.com/ Best regards Kristian Klausen - DevOps

1 0

[arch-dev-public] Regarding Elasticsearch/Kibana and OpenSearch/OS Dashboards
by Justin Kromlinger 25 Aug '21

25 Aug '21

Hello everyone, I've recently taken a look at Elasticsearch and the Amazon OpenSearch fork. Since the ES and kibana packages has been orphaned on 7.10.1 for a while I've adopted and bumped them to 7.10.2, which is the last version before the license change. Doing so required switching to jdk11 and the included gradle wrapper for builds (if someone wants to maintain gradle6 in community, feel free to contact me about it). I'm going to keep it on <7.11.0 for now so we can provide a FOSS version, which means the beats package should stay on 7.10.2 as well for compatibility reasons. That will change when we push OpenSearch (including it's plugins and OpenSearch Dashboards) to community, since this gives users a FOSS alternative. The reasons for why I don't package OpenSearch right now is that OpenSearch plugins currently can't be installed using the plugin manager and are a PITA to build [0] until the build-tools and other dependencies are published to Maven Central [1]. [0] https://github.com/opensearch-project/opensearch-plugins/blob/main/BUILDING… [1] https://github.com/opensearch-project/opensearch-build/issues/20 Best Regards hashworks -- hashworks Web https://hashworks.net Public Key 0x4FE7F4FEAC8EBE67

1 0

[arch-dev-public] Away for two weeks
by David Runge 20 Aug '21

20 Aug '21

Hi all, I'll be away for about two weeks and likely not be super active packaging. There are a few TODOs for rebuilds [1][2][3] that I have started, which I may be able to move, but probably not be able to further help rebuild at the moment. Feel free to rebuild out-of-date packages. Note, that juce is still out of date because I wanted to look into applying a few useful things for lv2 compatibility from the distrho fork [4][5] but never really had the time to spend on it. In case anyone is interested in looking into that, it would be much appreciated, too! :) Best, David [1] https://archlinux.org/todo/libiio-022/ [2] https://archlinux.org/todo/capnproto-090/ [3] https://archlinux.org/todo/libnsl-200/ [4] https://github.com/DISTRHO/juce [5] https://github.com/DISTRHO/DISTRHO-Ports/tree/master/libs/juce-current/patc… -- https://sleepmap.de

1 0

[arch-dev-public] RFC: Move distribution guidelines to a Git repo
by Filipe Laíns 13 Aug '21

13 Aug '21

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/5 Please visit the above link for discussion. Summary: Put distribution guidlelines in a Git repository and enforce a review process.

1 0

[arch-dev-public] Away for a week
by Jelle van der Waa 24 Jul '21

24 Jul '21

Hi All, I'll be away for a week without access to my packaging key, feel free to update any packages of mine which are out of date. Greetings, Jelle van der Waa

1 0

[arch-dev-public] Accidental todo for fluidsynth
by David Runge 23 Jul '21

23 Jul '21

Hey all, I made a dodo this morning by accidentally adding a TODO for a fluidsynth rebuild [1]. The rebuild can only be done after the hdf5 rebuild [2] is done, due to overlap. I will re-open it once we can proceed. Sorry for the noise. Best, David [1] https://archlinux.org/todo/fluidsynth-220-rebuild/ [2] https://archlinux.org/todo/netcdf-480-hdf5-1121-rebuild/ -- https://sleepmap.de

3 4

[arch-dev-public] Changes to the Code of Conduct
by David Runge 21 Jul '21

21 Jul '21

Dear all, Jonas and I have been working on changes to our Code of Conduct, which are represented in the following merge request: https://gitlab.archlinux.org/archlinux/service-agreements/-/merge_requests/… While most changes are based on e.g. merging sections or moving topics to separate documents to make the text more concise and allow easier changes in the future, there are also a few changes and omissions explained in more detail in the respective commits of the merge request. Best, David -- https://sleepmap.de

4 5

[arch-dev-public] Gone for the next couple of weeks
by Morten Linderud 10 Jul '21

10 Jul '21

Yo! Sunday evening I'm heading for a cabin trip where we don't have water and electricity is all solar power my dad rigged up a couple of years ago :) It's going to be great. I'm also moving from Bergen to Oslo next weekend! I need to spend some time to settle inn I expect I'll do less upkeep on my regular package maintaining as a result (also getting vaccinated 🥳). I should still be reachable on Matrix or Signal if there is anything urgent, but might not keep that much up with email! I have attached a list of packages I'm the sole maintainer of, but there is nothing here which should require anything urgent while I'm gone 😃. Have a lovely summer! If you want to adopt and need nvchecker stuff, please do check my repo: https://github.com/Foxboron/archlinux-pkgbuilds/blob/master/.repo/packages.… λ ~ » /usr/bin/pkgsearch -m Foxboron archlinux-contrib archlinux-repro b4 barrier bmusb bucklespring catatonit cni-plugins conmon crun dqlite flatpak-xdg-utils fuse-overlayfs gopls go-tools hy i3-gaps influxdb jgmenu libmd libslirp mopidy nageru nano-syntax-highlighting pass-otp pdfjs perl-data-perl perl-gnupg-interface perl-moox-handlesvia perl-moox-late perl-strictures perl-sub-handlesvia perl-type-tiny plocate podman-dnsname protege python2-docs python2-typing python-adblock python-babel python-docs python-dotty-dict python-flask-babel python-guzzle-sphinx-theme python-halo python-hid python-hjson python-jsonrpclib-pelix python-keyutils python-ldap python-log_symbols python-m2crypto python-milc python-nbxmpp python-nltk python-pew python-pydbus python-pydocstyle python-pydrive python-pygame python-pykka python-pypeg2 python-pywal python-reportlab python-rope python-send2trash python-shutilwhich python-speaklater python-sphinx-autorun python-spinners python-sqlobject python-sqlparse python-typed-ast python-xlib qmk qprint raft runc screenkey signing-party skopeo slirp4netns staticcheck step-ca tailscale toolbox vim-ultisnips -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

[arch-dev-public] deprecating git.archlinux.org
by Jelle van der Waa 01 Jul '21

01 Jul '21

Hi All, Today mailman was moved to a dedicated vps, making git.archlinux.org the last service to run on luna which we intend to retire as it's an old expensive box and GitLab is our replacement for Git hosting. If your project has not been migrated to Gitlab yet please contact devops for help migrating it. A list of known to require migration is listed in this ticket. [1] As the invoice date comes up the 8th, it would be awesome if we can cancel the box before that date. [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/6 Greetings, Jelle van der Waa

5 5

[arch-dev-public] Mailing list migration (Luna->VPS)
by Kristian Klausen 23 Jun '21

23 Jun '21

Hi all The time has finally come to migrate lists.al.org away from Luna and to a Hetzner Cloud VPS. I will do the final testing today and if all goes well the migration will be handled tomorrow (23th of June) between 16-24UTC. A mail will be sent shortly before starting the migration and I don't expect more than 1-2 hours downtime (at worst). If you experience any issues after the migration, please reach out by mail or #archlinux-devops on Libera Chat. As part of the migration there are a few technical changes (draft MR here [1]): * The arch-x(a)archlinux.org -> arch-x(a)lists.archlinux.org aliasing[2] will be dropped * SpamAssassin and OpenDKIM are replaced by Rspamd * postfix_to_mailman.py[3] is replaced by Postfix aliasing [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/424 [2] https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/a2b8682316e32e… [3] https://wiki.list.org/DOC/How%20do%20I%20configure%20postfix_to_mailman.py%… Best regards Kristian Klausen - DevOps

2 3

[arch-dev-public] Away until 2021-06-28
by David Runge 20 Jun '21

20 Jun '21

Hey all, I'll be away for about a week for holidays. If anything urgent comes up, feel free to bump or fix my packages. Best, David -- https://sleepmap.de

1 0

[arch-dev-public] Looking for co-maintainers (and proposal to join cross toolchain packages)
by Filipe Laíns 16 Jun '21

16 Jun '21

Hi all, Over the past few weeks, perhaps months(?), I have been struggling a little bit with mental health and that has made it a bit harder to keep up-to-date with packaging. For this reason, I would like find co-maintainers for my packages, so that it eases things in times like this. Feel free to adopt any of my packages, just let me know via email or IRC that you have done so. https://archlinux.org/packages/?maintainer=FFY00 Some of the packages that give me the most work are the cross toolchains, not because they are difficult to maintain, they aren't, they just take some work. I was wondering if perhaps we could maybe join them together in one single PKGBUILD? Anatol, Eli, NicoHood and Felix maintain the rest of the cross toolchains, so if they agree maybe we could join all architectures into a single PKGBUILD for each component? Cheers, Filipe Laíns

2 1