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

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

16 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

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

13 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

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

02 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

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

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 17 Jul '22

17 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 09 Jul '22

09 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