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

Public release: updlockfiles 0.1.0
by kpcyrd 16 Oct '22

16 Oct '22

ohai! I released a new tool called updlockfiles that attempts to help manage dependency lockfiles like Cargo.lock, composer.lock, go.mod and friends. Hopefully this helps with reproducible builds in Arch Linux, but also if you want to manage your own downstream lockfile to override vulnerable dependencies. Announcement blog post: https://vulns.xyz/2022/10/updlockfiles/ Repository: https://github.com/kpcyrd/updlockfiles cheers, kpcyrd

1 0

Arch Linux software projects: Request for participation
by David Runge 16 Oct '22

16 Oct '22

Hi all, we have recently cleaned up parts of the developer wiki a bit and moved the list of internal projects to a more prominent location: https://wiki.archlinux.org/title/Getting_involved#Software_projects As you can see, we have quite a few projects and some of them would be happy about more participation from members of the Arch Linux staff as well as users. Help in fixing and extending the software is much appreciated, but testing and opening tickets that describe flaws or usability problems are equally important! If you are familiar with writing documentation, Ash, Bash, C, JavaScript, Python, or Rust and always wanted to get involved with one of the Arch Linux projects: Look no further! :) As mentioned in the wiki, we have a central mailing list [1] and IRC channel [2] for discussing most of the projects (unless they provide other means of communication). We hope to spark people's enthusiasm, as healthy projects ensure a flexible distribution and allow us to tackle larger goals (e.g. move to a git based workflow for packaging, effortlessly providing several architectures, automating our infrastructure and releases, etc.). Best, David [1] https://lists.archlinux.org/mailman3/lists/arch-projects.lists.archlinux.or… [2] ircs://irc.libera.chat/archlinux-projects -- https://sleepmap.de

1 0

[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