Hi all, just as an update before the end of the year holidays. Michael Schroeder, Fabian Vogt and myself have been finishing off all missing pieces of implementation work to be able to transparently utilize the build service to provide glibc-hwcaps overlays of shared libraries optimized for higher architecture levels than baseline. While the original intention was to implement the proposal https://en.opensuse.org/openSUSE:X86-64-Architecture-Levels#Available_option... which is addressing an x86_64 specific need, all of the implemented pieces are reusable to also utilize on other architectures that have similar needs (can think of s390x here for example). What needs to be done as a package? By default, nothing. The x86_64-vX (I suggest targeting -v3 as it has a good balance of performance improvement and hardware compatibility over -v4 or -v2) builds will be limited to those packages that are opting into the glibc-hwcaps feature. if they opt in (which probably needs some analysis as we have seen also seen no increase or slight performance decrease), the only thing needed to do is to add one extra line to the spec file: %{?suse_build_hwcaps_libs} It only works if the package is building a shared library following the shared library policy as a subpackage and provides a `baselibs.conf` file that identifies that package by name. see https://en.opensuse.org/openSUSE:Packaging_Conventions_RPM_Macros#%{?suse_build_hwcaps_libs} for details Currently this macro is undefined as it relies on a number of not-yet-upstream-accepted changes: * https://github.com/rpm-software-management/rpm/pull/2315 * https://github.com/openSUSE/obs-build/pull/904 * https://github.com/openSUSE/obs-build/pull/907 * https://github.com/openSUSE/post-build-checks/pull/54 * https://build.opensuse.org/package/rdiff/Base:System/filesystem?opackage=filesystem&oproject=openSUSE%3AFactory&rev=233 * optional: yet undetermined way of providing the user an ability to "opt into the optimized libraries" (current suggestion is via a specific provides in the system to be provided by the patterns package, but could be also done via some zypper specific feature). Once all those changes are in, we can start implementing this in Tumbleweed, if consensus is given on the approach. Unlikely to happen still in 2022. In my testing, it appears beneficial to enable that for most of the dependencies of ImageMagick, the webbrowser dependencies and also the toolkit libraries (gtk, glib, qt etc) for improved desktop experience. In total that would be around 50 packages to submit with the additional macro, but I don't have a very scientific way of determining whether it is worth it yet. Happy to hear your input or feedback. Greetings, Dirk