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

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