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

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