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

Re: [arch-dev-public] Spring cleanup '21
by Antonio Rojas 29 Apr '21

29 Apr '21

> Unless there be dragons, I could happily pick up munin and > procinfo-ng... Moved munin. procinfo-ng is in [core], I'll give people a few days to raise objections against moving it out (hopefully joined by an offer to maintain it).

1 0

[arch-dev-public] archlinux-tools group
by Jelle van der Waa 25 Apr '21

25 Apr '21

Hi All, I've introduced a new group "archlinux-tools" for arch-rebuild-order and orhun will add it to arch-repro-status. I'm planning to add arch-signoff, and ask Fox to add archlinux-contrib as well. The idea is that Arch Linux related tools which benefit packaging get added to the archlinux-tools group. P.S. check out arch-repro-status, it's an awesome tool to inspect your non-reproducible packages! Greetings, Jelle van der Waa

3 3

[arch-dev-public] Dropping arptables/ebtables
by Sébastien Luttringer 13 Apr '21

13 Apr '21

Hello, I would like stop maintaining arptables and ebtables and drop them in [unsupported]. The future in the linux kernel is clearly nftables and keeping them in the repository present is of little interest these days. ebtables is still an hard dependency on others packages, but the iptables-nft package ship a remplacement based on nftables. I have not tested the compatibility, so if someone think it's not possible, please let me know. If you have spare time, I suggest you take a look at the nftable package and become a master in nft-fu. It is much more convenient and efficient than the iptables / ipset / ebtables / arptables solution. For the less enthusiastic about the command line, firewalld has an nftables backend. Regards, Sébastien "Seblu" Luttringer

2 2

[arch-dev-public] Dropping packages to AUR
by alad 09 Apr '21

09 Apr '21

Hi, As I no longer use them, I will drop the following packages to AUR unless someone picks them up: * deadbeef * mit-scheme * mksh * python-kitchen * qjournalctl * diffstat * rtv * xkcdpass The following packages are dependencies of existing packages, and could equally use a new maintainer: * diffstat (dependency for quilt) Cheers, Alad

1 1

[arch-dev-public] RFC Final Comment Period: Provide a x86_64_v3 microarchitecture level port
by Allan McRae 25 Mar '21

25 Mar '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/2 Please visit the above link for discussion. (Note much discussion in that link is relevant for the prior proposal of using x86-64-v2 as a baseline.) Summary: Provide a x86_64_v3 microarchitecture level port Build packages for both --march=x86-64 and --march=x86-64-v3. Assuming SSE4 and AVX2 (and others) while compiling will provide greater out-of-the-box performance in Arch Linux. Note, the exact implementation of this change is not discussed in the RFC. I'm of the opinion that RFCs are about ideas, so do not always need to go into full implementation details. However, to provide packages for two architectures we could (1) have packagers build both, (2) bring in packagers to keep the architectures in sync, (3) have a bot do it automatically. I'd guess a combination of 1+2 initially, and add 3 once we get the signing enclave running. Or 3 could be done with a variant of the rebuild system where jobs spawn out to available build machines. Also, we need both gcc-11 and clang-12 to be released to provide support for the x86-64-v3 variant. And support for enabling multiple architectures in pacman needs to be implemented (though we do have a 9 year old patch that did that!). So this will not happen overnight.

1 0

[arch-dev-public] On holiday for the next 2 weeks
by Eli Schwartz 24 Mar '21

24 Mar '21

It's that time of year again, the Passover holiday, so I'll be irregularly available or simply offline for days at a time until April 6 or thereabouts. I'll try to catch up with messages when I get a chance (expect delays!), but I'll be getting very little actual work done. Please feel free to bump my packages for me. -- Eli Schwartz Bug Wrangler and Trusted User

1 0

[arch-dev-public] Looking for co-maintainers
by Balló György 21 Mar '21

21 Mar '21

Hi all, Recently I have less interest in keeping my packages up to date. So I'm looking for co-maintainers for my packages [1], especially for the following ones, which are most frequenly updated: - blueberry - converseen - coolreader - deja-dup - drawing - eolie - featherpad - flowblade - gnome-boxes - gnome-initial-setup - gnome-passwordsafe - gpodder - gpxsee - gst-editing-services - mailnag - openbve - osinfo-db - photoflare - python-owslib - python-pykeepass - qgis - rssguard - synfig - tupitube - xarchiver Please let me know if you are interested in adopting any of them. [1] https://archlinux.org/packages/?maintainer=bgyorgy Thanks, György Balló Trusted User

1 0

[arch-dev-public] Arch Linux partners with Nitrokey to equip its staff with USB keys
by Levente Polyak 16 Mar '21

16 Mar '21

We are happy to announce that Arch Linux has partnered with Nitrokey [0] to equip its staff with free Nitrokey devices. We will use the Nitrokey devices to store cryptographic keys for signing of git commits, emails and software packages, GnuPG keys, and SSH accounts. Thanks to the Nitrokey’s discount and the Arch Linux funds, each Arch Linux staff is eligible to receive one free Nitrokey Pro 2 or hopefully soon the new Nitrokey 3. To receive their Nitrokey, eligible staff will need to register with their @archlinux.org email address at the dedicated order form. Further instructions about this process will be sent to our staff. A Nitrokey Guide will be made available on the Arch Linux Wiki with FAQ & instructions for integrating Nitrokeys into our workflow. Nitrokey Pro 2 provides strong reliable hardware encryption. It has open source firmware, is open hardware and can help you to: sign Git commits; decrypt emails and files; secure server access; and protect accounts against identity theft via two-factor authentication (one-time passwords). Furthermore, the new Nitrokey 3 will support additional features like FIDO. Nitrokey is a German IT security company committed to open source hardware and software. Nitrokey develops and produces USB keys for data encryption, email encryption (PGP/GPG, S/MIME), and secure account logins (SSH, two-factor authentication via OTP and FIDO). Besides their hardware products they offer services, consulting and help you with concept, development and certification of your specific security solutions. Nitrokey is proud to support Arch Linux in further securing its infrastructure and contributing to a secure open source Linux ecosystem. [0] https://www.nitrokey.com/

1 0

[arch-dev-public] Tracking different CPU architectures with pkgstats
by Pierre Schmitz 16 Mar '21

16 Mar '21

Hi all, while reading Allan's RFC about increasing Arch's CPU requirements(*) I had the idea to start tracking the different x86_64 architecture level using pkgstats. I am sure whether to drop support for old CPUs is not a matter of "if" but "when"; similar as it was with i686. Therefore it should help to have a rough estimate about which CPUs our users have and how the numbers develop over time. While I am at it, I'd like to also support different ARM architectures provided by archlinuxarm.org (or maybe even i486/i686 by archlinux32.org) There is a small catch though and the reason I am asking for your opinion: While we will know how many users use which architecture, all package usage data will be aggregated regardless of architecture. This means for a given package we cannot tell how often it is used on a specific architecture compared to others. I do not think that this would matter for most packages though. Greetings, Pierre *) https://gitlab.archlinux.org/archlinux/rfcs/-/blob/c5ee0eb715a01c6cd10aa5a9…

4 7

[arch-dev-public] Killing python2 v3...v4...v5
by Morten Linderud 15 Mar '21

15 Mar '21

Yo! As people know python2 has been unsupported for a year and we current have ~170 python2 packages in our repositories. Currently the removal has been fairly slow and done a bit ad-hoc. There has been a todo list but the follow up to that has not really been great and I think it's reasonable for us to try and fix the remaining packages to the best of our abilities. Thus I'm proposing a game plan! 1) Todo list for removal of all python2 checkdepends in packages 2) Remove free python2 packages 3) Remove packages with python3 equivalents 4) Remove unported and unsupported packages depending on python2 Clearly this is ambitious and there are going to be exceptions, but it would be great to have most of this work done within the next couple of months. The exceptions are largely going to be anything still using python2 for their build system dependencies. This is a fine compromise as this should leave us with a minimal set of packages to take care of. Rest of the problematic packages can be found on a handy list with what fedora is working on: https://fedora.portingdb.xyz/ If there are no objections I'll start preparing the needed todo lists and figure out the uneeded python2 packages. Should probably update the long-standing python2 removal todo as well. https://archlinux.org/todo/conversion-of-programs-that-use-python-2-to-pyth… Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

4 5