July 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] 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

[arch-dev-public] AUR migration
by Giancarlo Razzolini 28 Jul '20

28 Jul '20

Hi All, In continuing with the improvements being done to our infrastructure, we're planning to migrate the AUR to another machine. This means that, during the migration, there *will* be downtime of the whole AUR. I expect the migration to take around two hours and happen either tomorrow (Friday) or on Saturday, depending on availability. Regards, Giancarlo Razzolini

7 15

[arch-dev-public] Orphaning signing-party and dependencies
by Archange 27 Jul '20

27 Jul '20

Hi there, I’ve never went far into using signing-party, and do not have time to maintain it anymore. Thus, I’m going to orphan it as well as its dependencies (nothing else requires them), and move them to the AUR unless someone steps in to maintain them within ~two weeks. The full packages list: libmd perl-data-perl perl-gnupg-interface perl-moox-handlesvia perl-moox-late perl-strictures perl-type-tiny qprint signing-party Regards, Bruno/Archange

1 0

[arch-dev-public] News draft: AUR migration
by Giancarlo Razzolini 27 Jul '20

27 Jul '20

Hi guys, Given that the SSH host keys were changed during the AUR migration, and, due to the fact that not everyone will see this on the home page for the AUR or on aur-general, I propose the following news draft: ----> AUR migration: New SSH Host keys Due to the fact the AUR was migrated to a new server, the SSH HostKeys used to pushed packages were changed in the process. These are the new keys fingerprints: Ed25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4 ECDSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI RSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8 They can also be found on the AUR home page when not logged in. <---- Given this is somewhat urgent and the migration was done on Friday, I'll not wait the full 24 hours before posting this, but I'll probably post this by the end of the day, today, instead. Let me know if anyone has any objections. Regards, Giancarlo Razzolini

2 1

Re: [arch-dev-public] [aur-general] AUR migration
by Giancarlo Razzolini 27 Jul '20

27 Jul '20

Em julho 27, 2020 9:35 Henry-Joseph Audéoud escreveu: > On 24/07/2020 21:24, Giancarlo Razzolini via aur-general wrote: >> The migration is almost done. Since we are moving to a new machine, it will >> have new host keys. They are: >> >> Ed25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4 >> ECDSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8 >> RSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI > > You swapped the fingerprints of keys ECDSA and RSA. From my computer, I > get that fingerprints (and Ricardo Band has the same for ECDSA): > > ED25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4 > ECDSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI > > RSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8 > Yes, this is correct. The configuration is with the keys swapped. I'm going to fix it and also create a news post about this. Regards, Giancarlo Razzolini

1 0

[arch-dev-public] loop device in container
by Tobias Powalowski 18 Jul '20

18 Jul '20

Hi guys, is it possible to get loop devices working in a container? I need this in archboot script. Thanks. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 2

[arch-dev-public] Abandoning all my vim-* plugin packages
by Sven-Hendrik Haase 13 Jul '20

13 Jul '20

I've started using a vim plugin manager and don't use my packages anymore. They need a new home. Please show these packages some love: * vim-a * vim-colorsamplerpack * vim-doxygentoolkit * vim-guicolorscheme * vim-minibufexpl * vim-omnicppcomplete * vim-project * vim-taglist * vim-vcscommand * vim-workspace The packages are pretty low maintenance but I'd prefer if someone who actually uses them maintained them. Anything that's not taken within 2 weeks will be dropped to AUR.

1 1

[arch-dev-public] help wanted / IPP based printing/scanning
by Andreas Radke 13 Jul '20

13 Jul '20

There's some major effort going on to move from driver based scanning and printing to driverless scanning and printing both based on IPP specifications offered by newer devices. While IPP based printing is already there for some time and usable with cups+cups-filters [1] there's more work going on recently for IPP based scanning lately. There are a few projects we should probably support and add to our repos. I'm thinking about adding Sane-airscan [2][3] to extra. There's also a new ipp-usb proxy to allow IPP protocol access with USB connected printers and scanner as well [4][5]. I've prepared a simple package here of this one. Sadly my own printer is has a broken IPP implementation and thus can't be used with driverless printing [6]. My scanner is an old extra devices with plain usb connection. Both devices keep working well and I have no plan to replace them. So I cannot test anything of the new IPP stuff. If there's desire to have the new IPP stack fully available form our repos I can do the packaging because it's heavily related to recent multidevices and openprinting.org projects. But any help is welcome and I would prefer someone to become a backup and co-maintainer. If somebody has interest to help out here and maybe owns a modern IPP based multidevice please drop me a line. If nobody steps up or complains I plan to add sane-airscan and ipp-usb and maybe more if needed. -Andy [1] https://wiki.debian.org/CUPSDriverlessPrinting [2] https://github.com/alexpevzner/sane-airscan [3] https://aur.archlinux.org/packages/sane-airscan/ [4] https://github.com/OpenPrinting/ipp-usb [5] https://lists.debian.org/debian-printing/2020/07/msg00000.html [6] https://github.com/apple/cups/issues/5693

2 1