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

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

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

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