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

[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

[arch-dev-public] FC Final Comment Period: Buildflag updates
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/3 Please visit the above link for discussion. Summary: Update the buildflags in makepkg.conf to: #CPPFLAGS="" CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \ -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS -Werror=format-security \ -fstack-clash-protection -fcf-protection" CXXFLAGS="$CFLAGS" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" DEBUG_CFLAGS="-g -fvar-tracking-assignments"

1 0

[arch-dev-public] glew-wayland
by Alexander F Rødseth 09 Mar '21

09 Mar '21

Hi, I'm planning to move glew-wayland to AUR, ref: https://bugs.archlinux.org/task/56025 -- Sincerely, Alexander F Rødseth / xyproto

1 0

[arch-dev-public] RFC: Build using LTO by default
by Allan McRae 04 Mar '21

04 Mar '21

Hi, When pacman-6.0 is release, makepkg will provide the option to build packages using Link Time Optimisation (LTO) by default. This provides smaller, faster executables/DSOs, and improves GCC diagnostics. SUSE saw an average 5% decrease in binary size. In short, makepkg.conf will have: OPTIONS=(.... lto) When enabled, makepkg with add -flto to CFLAGS/CXXFLAGS The use of LTO can be disabled as needed in a PKGBUILD: options=('!lto') For full details and to comment, see: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/4 Allan

1 0

[arch-dev-public] RFC: Buildflag updates
by Allan McRae 04 Mar '21

04 Mar '21

Hi, Now we have had some controversy... lets look at some easier RFCs! The first is about additions to build flags. Specifically, our makepkg.conf would look like: #CPPFLAGS="" CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \ -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS -Werror=format-security \ -fstack-clash-protection -fcf-protection" CXXFLAGS="$CFLAGS" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" DEBUG_CFLAGS="-g -grecord-gcc-switches -fvar-tracking-assignments" For full details and to discuss the changes, please look at: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/3 Allan

1 0

[arch-dev-public] RFC: Using RFCs
by David Runge 02 Mar '21

02 Mar '21

Dear staff, I have begun work on a Request for Comment (RFC) process for Arch Linux and I am excited to now be able to open the first RFC... to introduce "Using RFCs" :) A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/1 Please visit the above link for discussion. Summary: A Request for Comment (RFC) is a way for Arch Linux contributors to propose, design, and discuss new features and changes in project direction in a focused environment. Best, David P.S.: To all staff members, that do not have an SSO account yet, please get in touch with Sven-Hendrik Haase <svenstaro(a)archlinux.org> to be signed up and be able to participate in the discussion. -- https://sleepmap.de

5 10