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

[arch-dev-public] Call for review: keyringctl as tooling for a curated keyring
by Levente Polyak 26 Oct '21

26 Oct '21

Hi all, to mitigate different issues with the current status of PGP keyservers and to simplify the management of our keyring we worked towards exploring a new way to handle our keyring: The idea is to have a curated keyring whose source of truth is the repository itself without relying on external component to collect the WoT. The repository will consist of atomic files representing PGP packets which a directory structure logically combines into individual certificates. The advantage is that a new signature is literally just a new independent file as a merge request against the repository which is also very easy to audit. David and me have spent quite some time to develop keyringctl [0]. This tool will provide a convenient UX to work with, and inspect the decomposed certificates. Furthermore it will also be responsible to join all certificates into a keyring and export ownertrust and revocation status as pacman requires. For now bootstrap the keyring directory from the old PGP data by: > ./keyringctl import --main master master-revoked > ./keyringctl import packager packager-revoked We are calling for review and testing specifically for the following: - Try to find bugs by bench testing the commands with real world use cases and files. Some usage examples: [1] - have individual people verify the pacman compatible artifacts created by the `build` command. cheers, David & Levente [0] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/merge_requests/24 [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/blob/feature/cur…

1 0

[arch-dev-public] RFC Final Comment Period: Adoption of a distribution-wide Code of Conduct
by David Runge 11 Oct '21

11 Oct '21

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/6 Please visit the above link for discussion. Summary: The adoption of a distribution-wide Code of Conduct (CoC) helps to describe the social contract by which communication takes place on the various communication channels offered by Arch Linux. This document describes the current CoC, its purpose and location and how to interact with it. Best, David

7 20

[arch-dev-public] New archweb release
by Jelle van der Waa 29 Sep '21

29 Sep '21

Hi all, Today archlinux.org was updated to the latest version with some notable changes: * Port more jQuery code to vanilla JavaScript, saves a wopping 30 kB of network data for the package detail view. * Fixed a bug in the importing of rebuilderd data with packages which contain an epoch. * Full GPG fingerprint are now shown in Developer Profiles * Reporead (imports repository databases) now supports falling back to reading package signatures from disk. This work is done in preparation for when pacman no longer embeds signatures in the repository database saving some bandwidth when fetching the repo databases. Greetings, Jelle van der Waa

1 0

[arch-dev-public] linux-firmware package, some thoughts
by Tobias Powalowski 28 Sep '21

28 Sep '21

Hi guys, lately did a lot of archboot hacking and stumbled over our firmware package. It needs installed 750 MB, download size is 130 MB. I tried to get it smaller and uploaded the archboot-linux-firmware package for my purposes. Our linux kernel needs only 180 MB installed size, download size is about 37 MB. Wouldn't it make sense to provide for each kernel we ship, a separate firmware package? Just my 2 cwnts, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

6 7

Re: [arch-dev-public] Packages added to todo list 'libgexiv2 0.14.0'
by Jan de Groot 20 Sep '21

20 Sep '21

Arch Website Notification schreef op 2021-09-20 14:05: > Todo list information: > Name: libgexiv2 0.14.0 > URL: https://archlinux.org/todo/libgexiv2-0140/ > Creator: Alexander Rødseth > Description: > libgexiv2.so.2.0.0 → libgexiv2.so.2.14.0 > > Rebuilds go to [staging]/community-staging]. Thanks. There is no major soname bump in 0.14 (.so.2), release notes don't mention an ABI break, so why this rebuild?

1 0

[arch-dev-public] Go 1.17 released - to rebuild or not to rebuild
by Morten Linderud 15 Sep '21

15 Sep '21

Yo, I packaged up the new Go release yesterday and moved it over to stable earlier today. Usually new Go minor releases frequently include new compiler improvements and some assorted runtime changes. Previous releases I have done complete rebuilds of Go packages in our repositories but the reception for these rebuilds have been a bit mixed. People do not really see the need to rebuild $goWorld when packages a compiled and nothing inherently breaks unless there is a rebuild. We don't do this for GCC, Rust and so on. However I do think it's nice to group up these ecosystem changes in one swoop as it spares me from having to repeat myself for the next few months as people occasionally update their Go packages. But on the other hand I'm not super eager to be alone rebuilding all of this either. So what are peoples thoughts on the subject? Go 1.1 release notes: https://golang.org/doc/go1.17 Previous rebuild: https://archlinux.org/todo/go-116-rebuild/ -- Morten Linderud PGP: 9C02FF419FECBE16

5 4

[arch-dev-public] Formal Objection to Adopting the Code of Conduct
by Allan McRae 15 Sep '21

15 Sep '21

We appear to be reaching the point where a formal code of conduct will be officially adopted. What is that I hear you say? We have had a Code of Conduct for a long time? And you are incorrect. The history of the Code of Conduct is poorly documented. But it started out as a forum guidelines written by one of the forum admins. As far as I can ascertain, this document had no input from the project leadership. At some stage this was moved to the wiki and became titled as a Code of Conduct as more general points were added to cover aspects of Arch beyond the forums. At no point has this code of conduct ever been formally adopted by the distribution. In fact, our distribution has no constitution detailing what the purpose of this distribution is and how it will be governed. So there is no formal process for officially adopting a Code of Conduct. Why does this matter now? The Code of Conduct is moving from being a random wiki page, to a "binding" document that users must agree to in order to access our services. Before this can happen, Arch Linux needs to adopt a formal governance structure in order to approve such a binding change. Take a look at other distributions governance structures and constitutions: https://www.debian.org/devel/constitution https://docs.fedoraproject.org/en-US/council/ I formally object to adopting a formal Code of Conduct until we have a clear governance structure who can develop the policies and procedures that are formally needed to enforce a Code of Conduct. Currently the Code of Conduct states the Project Leader is responsible for enforcement, although that is not listed as one of their duties as approved when developing the Project Leader election procedure: https://wiki.archlinux.org/title/DeveloperWiki:Project_Leader This once again demonstrate the lack of formal governance within the distribution. We can not proceed with a Code of Conduct (or the Terms of Service and Privacy Policy), until a formal governance structure and procedures are developed to approve such documents. Again, until such a governance structure has been developed, I formally object to the official adoption of the Code of Conduct. Kind regards, Allan

3 5

[arch-dev-public] RFC: Adoption of a distribution-wide Code of Conduct
by David Runge 15 Sep '21

15 Sep '21

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6 Please visit the above link for discussion. Summary: The adoption of a distribution-wide Code of Conduct (CoC) helps to describe the social contract by which communication takes place on the various communication channels offered by Arch Linux. This document describes the current CoC, its purpose and location and how to interact with it. Best, David

1 0

[arch-dev-public] namcap maintainership
by Jelle van der Waa 29 Aug '21

29 Aug '21

Hi All, I find a bit unfortunate to write this email, but I've emailed keenerd one month ago about git.archlinux.org being deprecated and namcap which he maintains being moved to Gitlab. So far I have not received a reply from keenerd. It also seems that namcap has not seen commits in a year and there are patches on the mailing list (arch-projects) for it. [2] [3] I would love to see someone from our team pick up namcap maintainership, take a look at all the pending patches, bugs on the tracker and keep it in shape. Is anyone interested in potentially picking up this task? [1] https://gitlab.archlinux.org/pacman/namcap [2] https://lists.archlinux.org/pipermail/arch-projects/2021-January/005411.html [3] https://lists.archlinux.org/pipermail/arch-projects/2020-December/005403.ht… Kind regards, Jelle van der Waa

6 6

[arch-dev-public] 2FA credentials backup
by Kristian Klausen 29 Aug '21

29 Aug '21

Hi all In the past week two staff members have lost their phone and thereby their 2FA credential for accounts.archlinux.org. The DevOps team can remove 2FA if they are provided with a GPG signed mail, but we would prefer not spending time on that. So please consider backing up your 2FA credentials. On Android the following apps support backup: * https://github.com/andOTP/andOTP * https://getaegis.app/ Authy is also worth mentioning although it is proprietary: * https://authy.com/ Best regards Kristian Klausen - DevOps

1 0