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

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

GeoIP mirror of archboot?
by Tobias Powalowski 05 Oct '22

05 Oct '22

Hi guys, would it be possible to link the archboot directory to GeoIP too: archboot.mirror.pkgbuild.com/ ? Thanks. greetings tpowa -- Tobias Powalowski Arch Linux Developer & Package Maintainer (tpowa) https://www.archlinux.org tpowa(a)archlinux.org Archboot Developer https://bit.ly/archboot St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de info(a)st-martin-apo.de

2 2

Discussion around archlinux-keyring and pacman-key
by David Runge 30 Sep '22

30 Sep '22

Hi all, I've started a discussion [1] around a potential improvement for dealing with archlinux-keyring and pacman-key. Lately we have been facing quite a few issues (e.g. initialization and ordering issues in archiso and arch-boxes) again, that emerge from how gnupg is used in the context of pacman-key. The discussion linked to above is a bit more midterm in regards to what the proposed idea represents, but it tries to draw out a possible scenario of using key data in the future. When looking at pacman-key I noticed, that it does not do locking of the gnupg keyring data [2]. This means, that in environments in which we bootstrap the system (e.g. archiso/arch-boxes) we may run into inconsistent state if we use pacman too early, or generally if we modify the keyring concurrently. Unfortunately, (to my knowledge) there is no way of telling when is "too early" or whether we are already using the keyring, due to the missing locking mechanism. In the past days there have also been a multitude of reports of people with keyring issues on reddit. While some of theme have been due to initialization issues in archiso with pacman < 6.0.1-8, there is apparently also a set of issues on existing systems where it is unclear why pacman-key would have issues validating keys that are already present on the user system (trying to get more info from the users). Overall this is a bit worrying and I think we should work towards addressing the problem that we have with signing and verifying packages. The discussion in archlinux-keyring is only one possible solution, others are implementing a locking mechanism (;_;) or working towards a signing enclave for our packages and databases to minimize the keys in use. IMHO, removing the use of gnupg as proposed in the linked discussion could reduce complexity quite a bit, but it of course also requires implementation in archlinux-keyring and pacman. I'd be happy to get more input and thoughts on this entire topic. Best, David [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/199 [2] https://gitlab.archlinux.org/pacman/pacman/-/blob/546433b4fd8a3ede5d04d56b3… -- https://sleepmap.de

1 0

Finding a new home for a bunch of my packages
by Pierre Schmitz 29 Sep '22

29 Sep '22

Hi all, I have been thinking about refocusing my contributions on Arch. As Andreas rightfully asked about openssl it's probably best to go ahead. I have been maintaining a couple of packages simply because they where orphaned a long time ago. They are all maintained but maybe someone could be found who is more knowledgeable or is even an active user of these packages. Here is a list of all the packages I care or know less about; just answer to this list if you like to maintain any of these. * archiso, archlinux-keyring, devtools: These already have other people working on it, so I probably can safely remove myself as maintainer. * aspell-de * imap: This is a dead package and should not be used by anybody. I just maintain it as dependency of php/c-client. If nobody is interested I might look into removing it * grml-zsh-config, hefur, lighttpd, lynx: I am no longer using these packages * logrotate * openssl, openssl-1.0, openssl-1.1: An update to Openssl 3.0 is prepared and packaged. Though I lack the knowledge to fix the packages depending on it and I do not feel confident to apply random patches. This is also better handled by someone who knows more about C; especially about handling different library versions and symbols. * run-parts * xz * zlib: Someone with a deeper knowledge might be advisable as this needs custom patches due to difficult upstream. Someone might also consider switching to a more maintained zlib-ng. * zsh I am not orphaning any of these if nobody could be found; ideally there is someone with a sense of passion for some of these more important packages. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

3 3

RFC Final Comment Period: Merge package repositories
by Levente Polyak 26 Sep '22

26 Sep '22

An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/14 Please visit the above link for discussion. Summary: Merge the pacman repository `[community]` into `[extra]` as well as the packaging VCS location `community` into `packages`. The `[core]` repository remains limited to Developers. New Package Maintainers will be restricted to publish packages solely to `[testing]` for the first two months of their active packaging actions. Cheers, Levente

1 0

News post draft: Dropping python2 from the repositories
by Morten Linderud 22 Sep '22

22 Sep '22

Yo, We are just missing a couple of packages before we can fully remove python2 from the repositories. Thanks to Jelle for all the hard work<3 Here is a suggestion for a news entry for the removal itself Subject: Removing python2 from the repositories We have removed python2 from the main repositories. If you still require the python2 package you need to build it from the AUR, or use an [unofficial user repository](https://wiki.archlinux.org/title/Unofficial_user_repositories). -- Morten Linderud PGP: 9C02FF419FECBE16

4 4

Remove ipw2100-fw and ipw2200-fw from [core]?
by Tobias Powalowski 22 Sep '22

22 Sep '22

Hi, while cleaning up archboot: https://fedoraproject.org/wiki/Changes/RemoveWirelessExtensions Those 2 firmware package can be removed, it's only for very old Intel boards which I guess are not even x86_64. Any objections? greetings tpowa -- Tobias Powalowski Arch Linux Developer & Package Maintainer (tpowa) https://www.archlinux.org tpowa(a)archlinux.org Archboot Developer https://bit.ly/archboot St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de info(a)st-martin-apo.de

2 2

Experimental RISC-V port
by Felix Yan 19 Sep '22

19 Sep '22

Hi, As you may or may not have noticed, I have started an unofficial RISC-V port attempt targeting 64-bit RISC-V ISA (riscv64gc) since 2019. There is a simple intro page currently hosted at: https://archriscv.felixc.at/ In the past year, we have a boost in progress and currently ~87.5% of Arch x86_64 packages are available in the riscv64 repository. IMHO The current patch amount is still too high to consider adding riscv64 as an official supported architecture, but we are trying hard on upstreaming them. Yesterday I noticed that Manjaro has imported packages from this port and formed a Manjaro RISC-V port. Their repository is now available at https://repo-riscv.manjaro.org/ This reminds me that we should probably make the port more visible to get more hands on it. Would you consider adding a subdomain at pkgbuild.com or archlinux.org? -- Regards, Felix Yan

5 6

New main key holder (replace Giancarlo)
by Levente Polyak 13 Sep '22

13 Sep '22

Hi all, I've had some chats with Giancarlo and he is currently unexpectedly very busy and stuffed with a lot of work. Thew new MK did not proceed currently to fill in the missing slot. Together we concluded that it would be the best to adapt to the current situation, revoke the newly created key and proceed with a new MK holder. This would allow him to spend his available time on the current responsibilities and projects. After some talks with David, we thought Johannes (demize) would be a good fit. I've approached him and after his careful consideration and review of the responsibilities he would happily fill in the slot. Therefore I'm proposing we replace Giancarlo's key and pass on the duties to Johannes. -- Many thanks to Giancarlo that he intended to help us out and to Johannes for jumping in. cheers, Levente

4 3

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

12 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