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

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

[arch-dev-public] RFC: Provide an x86_64_v3 microarchitecture level port
by Allan McRae 14 Mar '21

14 Mar '21

Hi all, A "new" RFC has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2 Summary: This RFC is proposing adding an x86_64_v3 port in Arch Linux. Assuming SSE4 and AVX2 (and others) while compiling will provide greater out-of-the-box performance in Arch Linux. This is a rework of the previous RFC regarding bumping the baseline to x86-64-v2. The comments on that RFC indicated that providing multiple architectures would be the preferred approach. While implementation details are do not necessarily needed to accept the RFC, devtools is set up for handling both architectures as a relic of the i686 days. There are a couple of pacman considerations needed around the "Architecture" configure option. Your friendly pacman dev will likely add the ability to have people install packages from multiple architectures, so people using x86_64_v3 can still use x86_64 packages when needed (e.g. user supplied repos that only build for one architecture). There will need to be further discussions about autobuilding vs packages uploading two variants, vs a team keeping x86_64_v3 in sync with the main port (or a combination of all of the above!). Again, just flagging the full implementation details are in progress. The RFC is just about whether this is the approach we should take. Please visit the above link for discussion. Allan

1 0

[arch-dev-public] RFC: Use x86_64-v2 architecture
by Allan McRae 12 Mar '21

12 Mar '21

Hi all, A new RFC has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2 Summary: Make -march=x86_64-v2 the default for our packages. This assumes the following instruction sets which are essentially available on all but the oldest AMD CPUs: CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3 Please visit the above link for discussion. Allan

8 29

[arch-dev-public] RFC Final Comment Period: Enable LTO by default
by Allan McRae 12 Mar '21

12 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/4 Please visit the above link for discussion. Summary: Enable LTO by default in our packages. In the interests of a fair discussion, I will highlight the disadvantage that was brought up during the initial discussion period: The use of LTO can cause the memory usage of GBD to markedly increase. It can also make debugging more difficult due to inlining across build units. Interestingly, the increased memory usage was bought up due to packages that already use LTO in their build system! But should be a consideration for larger pieces of software. Note that this RFC can not be implemented until pacman-6.0 is release (which may or may not be a while away), unless a couple of small patches are backported by the package maintainer. It may be worth timing this RFC and the buildflags one to occur at the same time.

1 0