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

[core] cleanup
by David Runge 13 Oct '22

13 Oct '22

Hi all, we need to do a bit of [core] repository cleanup. In this MD [1] (publicly visible readonly link [2]) we have a list of packages that should leave [core], some maybes that need discussion before moving them and some that should be moved to [core] from the other repositories. If you have more packages, that should not be in [core] anymore or should be moved to it, please add them to the list(s). The general rules for inclusion in [core] are, that we want to - preserve base-devel as a group there - preserve base as a meta-package there - preserve makedepends and depends of a [core] package there The checkdepends and also optdepends of a package may reside in other repositories. As we have a few removals of packages in the list that concern packages only in [core] for historical (or other) reasons, please keep the discussion about them focused on technical reasons as to why they should potentially remain there. Additionally, we have a few orphan packages in [core] that need adoption. Please adopt packages (if you can)! Best, David [1] https://md.archlinux.org/nrXL0ay5Tp6wP-f5M7N8bA# [2] https://md.archlinux.org/s/MliseALTG# -- https://sleepmap.de

6 11

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

Arch Linux in September 2022
by Levente Polyak 03 Oct '22

03 Oct '22

## RFC We entered the final discussion period for the RFC [0] to merge the pacman repository `[community]` into `[extra]` as well as the packaging VCS location `community` into `packages`. The `[core]` repository remains limited to Developers. One the RFC is accepted, we will implement the proposal during the migration to Git packaging. ## devtools Changes were prepared to account for the repo merger RFC and its resulting workflow. We are slowly approaching a state of Git packaging that could be used productively. Once the final bits haven been finalized, we will present the proposal and discuss the migration and switch over. ## mailman3 migration We have finished the full migration to mailman3 [1]. Rewriting of the "From" header and subject (to prepend the list name) have been disabled to keep the DKIM signature intact. This means "reply to mailing list" must be used when replying to the list and you may need to update your filters and rules matching the "From" header. All existing subscriptions are migrated and you do not need to re- subscribe. ## python2 removal Python 2 went end of life January 2020. Since then we have been actively cutting down the number of projects depending on python2 in our repositories, and we have finally been able to drop it from our distribution [2]. ## RISC-V mirror We started hosting [3] our latest efforts of the yet unofficial RISC-V port. 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 [4]. [0] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/14 [1] https://archlinux.org/news/arch-linux-mailing-list-changes/ [2] https://archlinux.org/news/removing-python2-from-the-repositories/ [3] https://riscv.mirror.pkgbuild.com/ [4] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o…

1 0

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