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

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