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

[arch-dev-public] Mkinitcpio replacement with Dracut
by Giancarlo Razzolini 19 Feb '21

19 Feb '21

Hi All, Recently, Dave announced his intention to step down as mkinitcpio maintainer. I have been handling a few things on it, made some small changes to our mkinitcpio-busybox [0], closed a few old bugs, while also made sure some of the other bug reports are still valid. [1] I have been testing a few patches to mkinitcpio for a while to fix those bugs, but last week Dave and I had a discussion on IRC and we agreed that we could spend better time contributing somewhere else than keeping working with mkinitcpio. Currently mkinitcpio cannot boot from NFS properly, mknitcpio-nfs-utils [2] uses very old code. Even though ipconfig works, it has several drawbacks compared to using more modern tools. Not to mention that we have two use cases for mkinitcpio, which are base and systemd enabled initramfs. Even though we use by default our base enabled initramfs, we have to support systemd related issues and we have to keep developing our systemd hooks. I have been looking into dracut for some time now, I copied some stuff from them on a few of my own scripts and they also have an actual test suite, that we currently can't use on Arch, but I plan to change that. With this in mind, I have packaged dracut for Arch and put it on Extra [3]. I have been using a dracut initramfs for a while now to boot my encrypted partition. Surprisingly, I only had to create a small patch to one of the dm-crypt module scripts [4] In this initial phase I want to ask as many of you to test this as a replacement to mkinitcpio in your setups, as many as possible, and in as many scenarios as possible. We will probably have to keep both packages on our repos for a long time, but once we are confident it's a good fit, we can replace mkinitcpio on our iso and base, so new installs get dracut by default. Please, drop in your comments as well. Regards, Giancarlo Razzolini [0] https://git.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=pac… [1] https://bugs.archlinux.org/index.php?string=mkinitcpio&project=0 [2] https://git.archlinux.org/mkinitcpio-nfs-utils.git/ [3] https://www.archlinux.org/packages/extra/x86_64/dracut/ [4] https://git.archlinux.org/svntogit/packages.git/tree/trunk/0001-90crypt-Cha…

4 7

[arch-dev-public] Call for Participation - Arch Conf 2020 Online
by Morten Linderud 18 Sep '20

18 Sep '20

Hello everyone! We are super excited to announce that the Arch Linux Conference 2020 is going to be held online on the 10th and 11th of October. The CFP has been published and everyone is free to submit talks and lightning talks from today until the 18th of September. If you have other ideas please do reach out! https://pretalx.com/arch-conf-online-2020/cfp # Pre-recorded talks All talks should be pre-recorded and sent to the team by the video submission deadline. You will be notified if the talk has been accepted shortly after the submission deadline has passed. # Important Dates * Conference date: 10th - 11th of October * Submission deadline: 18th of September * Video submission deadline: 5th of October # Streaming Streaming details are going to be published through September as there is still some more planning required for this part :) # Contributing We are still going to hold regular meetings over mumble and general planning in #archlinux-conf @ freenode until the conference starts in October. If you want to get involved and help out please do reach out and join the meeting :) Cheers from the Conference Team!

1 2

[arch-dev-public] Bug tracker migration
by Frederik Schwan 30 Aug '20

30 Aug '20

Hi folks, I'd like to migrate the beloved Flyspray bug tracker to our new Gitlab instance. TLDR: - Bug wrangling day on the 13th of September; see 1) - Flyspray will be read-only after we rewrite the Archweb URLs - new bug tracker -> Gitlab 1) I'd like to hold a bug wrangling day, where our goal is to close as many bugs as possible. Any TU, Reporter and bug wrangler is invited to help out :) Unfortunately I can't offer any cookies that day :/ Rules: a) Bug with no reply for at least 6 months which has been submitted for a different version than the current one in the repos shall be closed with a message that a reopen request may be filled if this issue is still present. b) Any infrastructure ticket shall not be touched. This will be handled by $DevOps. 2) Afterwards we will point the bug tracker links in the Archweb to the new location and opening new tickets in Flyspray will be disabled. The project structure of the future Gitlab bug tracker will be discussed in a seperate mail and is not part of this mail(thread). 3) When enough tickets are closed or when $DevOps is tired enough of Flyspray, we'll migrate the rest of the tickets to Gitlab. We seek to keep Flyspray as a static homepage to allow the reference in the new bug tracker to old tickets and to keep the integrity of search engine results. Please make sure you all have a working account at our Gitlab instance. Cheers, Frederik

5 7

[arch-dev-public] [RFC] Removing maintainer/contributor lines from PKGBUILDs
by Evangelos Foutras 25 Aug '20

25 Aug '20

I am not sure these serve any purpose. The maintainer line duplicates information available from the archweb or aur interfaces and could also be outdated. The contributor lines are mostly redundant with svn or git history, can take up several lines in the PKGBUILD and can become irrelevant after significant refactoring. What are your thoughts on dropping all these seemingly unnecessary lines from our official PKGBUILDs? Anyone feel strongly about keeping them (and why)?

5 5

[arch-dev-public] Ciao
by Gaetan Bisson 20 Aug '20

20 Aug '20

Dear all, I've joined the Arch team in 2010 and spent a decade as a developer; it's been a great privilege to be a part of such an awesome community and also a lot of fun. However I felt the ten-year mark was a good opportunity for me to move on since I recognize the majority's views on the future of the distro have of late steadily been diverging from mine. And thus I hereby resign my position of Arch Linux Developer. All the best in your future endeavors! -- Gaetan

3 3

[arch-dev-public] Holidays 2020-08-20 -- 2020-09-01
by David Runge 18 Aug '20

18 Aug '20

Hey all, I will be on holidays between 2020-08-20 and 2020-09-01 and very likely not be able to do packaging. Feel free to bump my packages. Note, that audacity would require a lot of work.. so only get on to that one if you're really up for it :-P Juce is another such candidate (but also because it currently makes the build for iempluginsuite fail). Best, David -- https://sleepmap.de

1 0

[arch-dev-public] Mail server migration
by Giancarlo Razzolini 14 Aug '20

14 Aug '20

Hi Guys, Continuing with our migration efforts, we're now going to migrate the last running service on orion which is the mail server and all the software related to it. This is also getting migrated to a VPS [0]. We plan on making this as transparent as possible, so all the mailboxes, sieve filters and .forward files and anything else mail related will be copied from the home directions each user has on orion. We also plan on syncing /etc/shadow, to make sure all the passwords remain the same. However, the SSH Host keys will also be changed on the process. These keys will be documented beforehand on [1] as well as sent to this thread. SSH access will only be used for password changing and for putting/editing .forward files and/or sieve filters. Eventually the mail server will not support SSH access anymore, as we plan on transitioning authentication to keycloak in the future. But for foreseeable future, things won't change. Also, with this change, since mail is the last thing on orion, that machine will be decommissioned. So, please, everyone make sure that you don't have anything on your home directory that you wish to keep. We'll take a backup, but the only things getting moved to the new mail server are mail related files. There's no date yet for both the migration and for orion's decommissioning, but the mail migration will happen next week, and orion's decommission following that and provided the mail migration is successful. There will be a period of time where the pop and imap services will be unavailable, as well as sending emails. We plan on not disrupting the incoming of emails, and I'll sync the queue between the machines, to avoid any lost email, while the DNS records are changing. Regards, Giancarlo Razzolini [0] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/92 [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/docs/ss…

1 0

[arch-dev-public] Anatol is inactive due to situation in Belarus
by Anatol Pomozov 14 Aug '20

14 Aug '20

Hello folks My name is Anatol Pomozov and I am an Arch Linux developer. I've been quiet for a couple of weeks now and will probably stay away from my Arch Linux/pacman (+bcc:pacman-dev@) duties for a bit more. Please feel free to take care of my packages if it's needed. The reason for this decision is a situation that happens in my home country. I am a belarusian. My home country, my beautiful Belarus is essentially taken hostage by a usurpator Lukashenko. He has been "ruling" the country for 26 years already. Lukashenko cancelled results of the last election (where he took ~10% of votes) and declared that he is going to stay in power for another 5 years. All his political opponents were put into a jail or hiding from him abroad. Anyone who demands fair elections is terrorized by his personal army. Many people are tortured in jail. You can see what happens in Belarus in these clips https://www.youtube.com/watch?v=XG3D6881AXY https://www.youtube.com/watch?v=-6tCGnM0xiQ https://www.youtube.com/watch?v=E0VLjQvCxcc I live abroad and I am safe now. But my parents and relatives are in Belarus and they were essentially taken hostage by the Lukashenko's government. The last few weeks were stressful for me and I want to focus on my extended family as much as possible. I understand that Arch maillist might not be the place for political statements but this is something personal and something important for me. There is no place for such violence and there is no place for dictators in Europe of the 21st century. Please support Belarusian people in their fight against the usurpator. Talk to your governor/mayor/deputy/..., ask them to contact Belarusian government to stop the violence. Talk to the press, explain to them what is going on in Belarus right now. Anything that brings peace to Belarus will be helpful. Thank you. Жыве Беларусь!

2 1

[arch-dev-public] Online Arch Linux Conference
by Morten Linderud 11 Aug '20

11 Aug '20

Yo! Because of COVID-19 I assume most people have had some conference plans cancelled this year. FroSCon has had an Arch Linux devroom the past years, but as we are not meeting physically I guess that isn't happening either. Thus I want to try rally some people and have an online Arch Linux conference/devroom. There are not any major ambitions really. This can be a few hours an evening, or a weekend event. We will see what we figure out :) # Ideas Some of the ideas I have had so far is as roughly: * Team Q&A * Talks/presentations * team member and the wider community * Interactive streams * See how packagers do their work? * Arch Linux installation speedruns(?) * Workshops? Feel free to email me offlist, or poke me on other platforms, if you have other great ideas that could work! # Organization To organize we would need some help and might need some roles filled. This is a shortlist of the ones I can come up with. But I'm sure there are more tasks and roles needed: * Art-work/graphics * Help figuring out streaming * Planning and handling CFP There is no requirement to be on the Arch team to contribute. If you think you have anything to contribute, please do come talk with me! Need every help one can get :) # Meeting Below is a suggested meeting date for interested parties to attend. I'm unsure if it's going to be mumble or purely text based. Date of meeting: 4th of August 19:00 CEST (UTC+2) - https://everytimezone.com/s/a5112249 IRC: #archlinux-conf @ freenode Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

1 3

[arch-dev-public] Use detached package signatures by default
by Anatol Pomozov 10 Aug '20

10 Aug '20

TLDR; let’s start using detached package signatures to make system updates faster. Hi folks, Some time ago there was a discussion at IRC where someone (Allan maybe?) proposed to stop using embedded PGP signatures in favor of detached signature files. I would like to bring this idea here and quantify it with some numbers. Here is a bit of technical details on this topic. Pacman has the ability to verify authenticity of package files with PGP signatures. PGP signatures add protection against undesired package modifications by a third-party and it improves security aspects of the package management. This feature can be configured per repository and the official Arch Linux repos have it enabled. Package signatures have been used by Arch Linux successfully for a couple of years now. Package signatures are stored as a part of a pacman database file (it is called “embedded signatures”). One issue with embedded signatures is that they represent a quite large chunk of database file. What is worse, a PGP signature is high-entropy data and does not compress well. I was mildly shocked to learn how much of the *.db files signatures consume. I ran experiments and repackaged extra, community databases without PGP data. For uncompressed “extra” repository size drops to 83% of its original size (though uncompressed size is not that interesting). Arch uses GZIP compressed database and in this case removing signatures reduces the “extra” database to 36.8% of its original size. To emphasize it one more time - removing PGP signatures makes this repo only 1/3 of its original size. The change is even more dramatic in case of “zstd -19” compression where the final database file is only 31% of its original size. For community.db the numbers are: uncompressed file gets 79.8% of its original size, “gzip -9” gets 33.4%, and with “zstd -19” it gets 27.51% of its original size. A database gets modified with every package update. Users need to re-download the databases where 2/3 of it are package signatures that are used only when a specific package is installed. An alternative to embedded signatures are detached signatures. These are signatures stored in a separate file next to the package itself (in a <pkg>.sig file to be specific). Instead of downloading *all* signatures every time a database is updated, detached signatures are downloaded only when a specific package is installed/updated. If Arch could switch to this model then database files become 3 times smaller that saves users bandwidth and system update time. I looked through pacman code and most components have detached signatures support already. Most of the places have a logic like this: if(pkg->embedded_sig) { use(pkg->embedded_sig) } else { sig = load_detached_sig(pkg) use(sig) } I found only 2 places where pacman does not fallback to a detached signature: 1) Keyring key check. Pacman was using embedded signatures only. This has been fixed in pacman’s commit b01bcc7d3d680 and it will be available in pacman version 6.x 2) dump_pkg_full() that dump package information. If a package uses detached signatures only then it prints “None”. I think this is fine as this function displays database entries and it does not affect the package verification process. I disabled the embedded signatures at my testing machine to use detached signatures only and things look great so far. ‘pacman --debug’ confirms that detached signatures are correctly downloaded and used to verify the package content. Given this information I would like to propose to stop using embedded signatures and move to detached signatures by default. This will require pacman 6.x or as alternative backport the fix(es) to 5.x branch. It will help to make system updates even faster, something that me and many other Arch users really love.

5 7