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

[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

[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] News draft: Moving to Zstandard images by default on mkinitcpio
by Giancarlo Razzolini 17 Feb '21

17 Feb '21

Hi Guys, So, mkinitcpio-30 (on [testing]), uses zstd by default for initramfs images, since all our kernels now support it. I plan to move mkinitcpio in the next 24-48 hours but, since I anticipate some people holding back 5.4 kernels, I want to send the following news announcement (here [0] is the md I'm using, so feel free to help there): ---- All official kernels of Arch Linux now support zstd compressed initramfs images, so mkinitcpio is switching to zstd compressed images by default on the version that is currently on [testing]. If, for any reason, you are using a kernel version prior to 5.9, make sure to change mkinitcpio.conf COMPRESSION to use one of the compressors supported, like gzip, otherwise you *will not* be able to boot images generated by mkinitcpio. Regards, Giancarlo Razzolini [0] https://md.archlinux.org/zh8Ac75qQPSieS8ftGBkIg

3 4