devel November 2024

devel@lists.fedoraproject.org

153 participants
189 discussions

Orphaning eza (rust-eza - maintained fork of exa)
by Fabio Valentini 03 Jul '25

03 Jul '25

Hi all, TL;DR: I am planning to orphan rust-eza later today. Be warned - it's a lot of work to keep up with upstream (~1 release per week), keeping it up-to-date in epel8 is a bit painful (because RHEL 8, duh), and there are license shenanigans afoot since the v0.20.0 release (package is currently at v0.19.3). Given that I don't even use eza myself and just packaged it because it was on some people's wishlist as the maintained fork of exa, I really cannot justify the ongoing cost of maintaining this package to myself. Fabio --- Longer version: The upstream project releases new versions at a very fast pace (almost exactly one release per week on average this year). They also have set up GitHub's dependabot to automatically and eagerly bump all their Rust dependencies to the latest versions - most of which are not technically necessary. Additionally, they often add new dependencies, which is an additional maintenance burden on top of needing to keep up with their eager dependency bumping. The package should be in relatively good shape, except that it is slightly outdated. I have just yesterday updated it to the latest version that does not introduce new dependencies that aren't packaged yet for Fedora (0.19.3, released on Sep 12). At the time of writing, the latest release is 0.20.6 (released today, Oct 31) - but more info on that below. The package is available in all branches of Fedora, in EPEL 9, and in EPEL 8. All branches are equivalent, with the exception of EPEL 8, which needs special handling because the Rust packaging toolchain there is ancient (from RHEL 8), while the EPEL 9 toolchain matches the one in Fedora. The package was branched for EPEL 8 per a user's request, so dropping it (or letting it become outdated) just a few months after it was added to EPEL 8 would not be nice IMO. It might be of note that the project was relicenced from MIT to EUPL-1.2 without much fanfare as of the 0.20.0 release, in this mess-of-a-PR: https://github.com/eza-community/eza/pull/1155 - I'm not a lawyer, but the maintainer unilaterally slapping a different license onto a project that's been around since 2017 in some form without asking other contributors (or the original author of exa) doesn't pass the smell test for me.

4 7

ld: error: triggering the generation of an executable stack
by Orion Poplawski 16 Jun '25

16 Jun '25

With a recent update, plplot is failing to build with: cd /builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/examples/fortran && /usr/bin/cmake -E cmake_link_script CMakeFiles/x16af.dir/link.txt --verbose=1 /usr/bin/gfortran -Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -frecursive CMakeFiles/x16af.dir/x16af.f90.o -o x16af -Wl,-rpath,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/bindings/fortran:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime ../libplfortrandemolib.a ../../bindings/fortran/libplplotfortran.so.0.2.0 -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime /usr/bin/ld: error: /tmp/cchkMGCX.ltrans0.ltrans.o: is triggering the generation of an executable stack (because it has an executable .note.GNU-stack section) /usr/bin/ld: failed to set dynamic section sizes: No such file or directory I have no idea what is up here. Seems to have started with: gcc 14.0.1-0.7.fc41 glibc 2.39.9000-3.fc41 util-linux 2.40-0.9.rc1.fc41 binutils 2.42.50-4.fc41 and lots of others, but that seems the most likely. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

6 6

dnf "no match for group package" on upgrade...
by Matthew Miller 02 Jun '25

02 Jun '25

I'm seeing a number of people confused by this message, usually followed by some actual transaction error. I _think_ this is happening because these packages are in comps but do not exist in the distro. Is this correct? I tried to search for it, but the error message is _very_ common in ... well, people who are asking about it because of what I said. (For example: https://unix.stackexchange.com/q/542877/2511) I found https://bugzilla.redhat.com/show_bug.cgi?id=1538346 but not much of a general resolution. It does note that one issue is arch-specific packages (which maybe just need "arch=..." in comps?). I think we should: 1. Have a schedule standarded task to remove any packages listed but non-existent after branch from rawhide. (I assume a Rel-Eng task?) 2. Have DNF make this message less scary. Maybe even move down to a debug message and not show it by default — I am not seeing a situation where they're useful to _most_ end-users. Anything I'm missing? -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

5 5

updates for "Change: Replace Redis with Valkey"
by Zbigniew Jędrzejewski-Szmek 03 May '25

03 May '25

Hi, For https://fedoraproject.org/wiki/Changes/Replace_Redis_With_Valkey in FESCo ticket https://pagure.io/fesco/issue/3203 we didn't make a decision and decided to wait for the situation to clarify. Has the status changed? Can we now say that Valkey is going to be the default replacement that most people will want to switch to? (If there's a clear answer, we'll want to finalize the rubberstamping of the Change Proposal. If not, we can let it sit some more.) Zbyszek

4 4

Automatic detection of unused BuildRequires
by Marián Konček 01 Apr '25

01 Apr '25

As many of you know, as packages change, so do their BuildRequires. In the current state, maintaining them requires some manual work from the maintainer. 1. So I got around the idea of a simple tool that checks file accesses during the build and using RPM queries, detects whether some package's files are not accessed at all therefore the package is not needed for the build. To my knowledge there is no such project. The project is here: https://github.com/mkoncek/unbreq It may not be completely reliable, but it also may be good enough to catch simple mistakes. 2. At least in the case of maven build system, this tool does not help with `mvn(foo:bar)` dependencies, as maven unconditionally reads all the files present in /usr/share/maven-metadata, from which it deduces the associations between jars and artifact coordinates. I imagine other build systems employ a similar strategy. 3. In the case of maven, we have a manual tool: xmvn-builddep, which reads the build.log and constructs the actual BuildRequires from it, using knowledge about the build procedure. This could be used as an additional step of this tool, having similar tools for other languages. Ultimately, I am interested in the possibility of having automated unused BuildRequires detection as part of rpmbuild / mockbuild. -- Marián Konček

6 8

F41 Change Proposal: Anaconda as native Wayland application (System Wide)
by Aoife Moloney 12 Mar '25

12 Mar '25

Wiki - https://fedoraproject.org/wiki/Changes/Anaconda_As_Native_Wayland_Applicati… Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-anaconda-as-nati… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Currently, Anaconda is still an X11 application, which we would like to fix and make Anaconda Wayland native application to allow us drop of the X11 dependencies from installation ISO images. However, this change is not just a simple switch and we need to do some adjustments during the path which will impact user experience. == Owner == * Name: Anaconda team ([[User:jkonecny| Jiří Konečný]]) * Email: jkonecny(a)redhat.com == Detailed Description == Anaconda is required to migrate to Wayland native application to drop dependencies from the installation ISO images which are deprecated. Package owners want to drop libXklavier from Fedora (see https://bugzilla.redhat.com/show_bug.cgi?id=1955025 ) but also Xorg server from CentOS Stream and RHEL. However, this change won’t be just simple switching from X11 to Wayland, we also need to change a few things in Anaconda to be able to remove the X11 dependencies. This will have two main visible impacts listed below. === VNC switch to RDP for remote GUI installations === Anaconda has to remove ‘TigerVNC' which is used for VNC connection to be able to install your machine remotely with graphical UI. Reason is that TigerVNC is built from the Xorg server sources, so we would still depend on the Xorg server with this project. As replacement, we follow the recommendation of the Fedora Workstation to switch to Gnome Remote Desktop (grd) with a better protocol Remote Desktop Protocol (RDP) which gives users better performance and security. This will have an impact on current vnc kickstart commands and kernel boot options of Anaconda. This will impact only the Anaconda installation environment (boot.iso). === Consistent keyboard control === Currently, Anaconda experiences difficulties in handling keyboard layouts in the installation environment, particularly on Wayland. Formerly, libXklavier was utilized by Anaconda to manage keyboard layout configuration, however, it proved unstable on Wayland. As a result, Anaconda has disabled keyboard handling during Wayland Live media installations due to unexpected behavior (refer to https://bugzilla.redhat.com/show_bug.cgi?id=2016613 ). This approach may lead to situations when users encountering issues while unlocking LUKS devices or using user passwords in the installed system because installation was done with a different keyboard layout. To exacerbate the situation, there is no universally applicable solution for keyboard handling on Wayland systems, as Wayland lacks a unified API for keyboard management. It means that each Fedora Desktop Environment developed their own API. Unfortunately, the Anaconda team is not able to maintain a custom solution for each Fedora spin. Some Desktop environments started to use '''systemd-localed''' DBus API to address this issue and similar issues. The systemd-localed API seems to be the best approach currently, so we want to promote it as a shared solution for all Fedora spins. The plan is: * All Fedora spins and Anaconda listen on '''org.freedesktop.locale1''' and reflect configuration on the currently running system (might be only for Live media if desired) * All Fedora spins and Anaconda reflect their configuration to org.freedesktop.locale1 * In case Fedora spin will not support '''org.freedesktop.locale1''', the keyboard configuration of Anaconda won’t be reflected in the current system and the situation will be similar to the current Live Wayland experience All the spin owners were notified about this request: * https://pagure.io/fedora-workstation/issue/430 * https://pagure.io/fedora-kde/SIG/issue/504 * https://gitlab.com/fedora/sigs/sway/SIG/-/issues/36 * https://bugzilla.redhat.com/show_bug.cgi?id=2278655 * https://bugzilla.redhat.com/show_bug.cgi?id=2278658 * https://bugzilla.redhat.com/show_bug.cgi?id=2278656 * https://bugzilla.redhat.com/show_bug.cgi?id=2278864 * https://bugzilla.redhat.com/show_bug.cgi?id=2278866 * https://bugzilla.redhat.com/show_bug.cgi?id=2278869 * https://bugzilla.redhat.com/show_bug.cgi?id=2278874 * https://pagure.io/fedora-cosmic/SIG/issue/1 * https://pagure.io/fedora-budgie/project/issue/4 * https://pagure.io/fedora-lxqt/SIG/issue/4 * https://pagure.io/i3-sig/Fedora-i3-Spin/issue/70 == Feedback == We have some feedback from the SIG owners for the keyboard handling (see the links above). We don’t have feedback for the VNC to RDP switch yet. == Benefit to Fedora == * This change will enable removal of X11 dependencies from the Anaconda which may result in reduction of installed software to the system when installing from Live ISO where ISO content is copied to the installed system (depends on the spin dependencies). * Switching from VNC to RDP allow users to use remote graphical installations which are more secure and have better performance . == Scope == * Proposal owners: The Anaconda team will implement changes required in the Anaconda project. More specifically: ** Switch Anaconda code to start Wayland environment on boot.iso instead of X11 ** Change keyboard switching logic to use systemd-localed DBus instead of libXklavier ** Switch remote graphical installations from VNC (TigerVNC) to RDP (GRD) * Other developers: Fedora SIG owners needs to add support for their environment to listen and use systemd-localed DBus API to reflect current state of the DE/WM or they won’t have support of keyboard layout switching in Anaconda. * Release engineering: [https://pagure.io/releng/issue/12138 #12138] * Policies and guidelines: Yes should be done after the implementation (https://docs.fedoraproject.org/en-US/fedora-server/installation/interactive… should switch to RDP) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == This will impact only Fedora installations so no compatibility or upgrade issues. == Early Testing (Optional) == We will reach Fedora QE to coordinate testing approach. == How To Test == # Download any installation media # Run the installation # Look for breakages during the installation Testing should be especially focused on: * Changing resolution with ''inst.resolution'' kernel boot option * Test new RDP solution (API will be clarified) ** Password can be set to the RDP ** Username can be set to the RDP * Test keyboard layout switching works correctly ** On Live media, Anaconda should react on keyboard layout change in the DE and set that to the installed system ** On Live media, Anaconda should be able to set the keyboard layout changes to the live environment ** In the network installation (boot.iso) Anaconda should correctly reflect keyboard layouts changes so text in the Anaconda is written by the correct layout ** Check if specific keyboard layouts are configured and installed as expected == User Experience == The only visible change to a user should be: * Remote graphical installations will use RDP instead of VNC. * Anaconda will be able to control keyboard layouts in the Wayland environment on Live ISOs. This will improve user experience when installing Fedora Workstation, Fedora KDE, Fedora Sway and other Wayland based environments. == Dependencies == No dependencies of this package related to this change. == Contingency Plan == * Contingency mechanism: Postpone this change to the next Fedora release. Revert landed changes in Anaconda if required. * Contingency deadline: 100% code completion deadline * Blocks release? No == Documentation == No documentation yet. However, there are a few PRs ready for merge for CentOS Stream 10: * https://github.com/rhinstaller/anaconda/pull/5463 * https://github.com/rhinstaller/anaconda/pull/5470 * https://github.com/rhinstaller/anaconda/pull/5485 * https://github.com/rhinstaller/anaconda/pull/5498 == Release Notes == TBD -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr… Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

21 57

Orphaning java-diff-utils
by Christiano Anderson 20 Feb '25

20 Feb '25

Hi, I have orphaned the java-diff-utils package, which fails to build due to broken and unmaintained dependency jgit. Thanks Christiano

2 2

Heads-up: rapidyaml 0.7.2 and c4core 0.2.2 coming to F42/Rawhide and F41/Branched
by Ben Beasley 15 Feb '25

15 Feb '25

In one week (2024-09-05), or slightly later, I plan to update the rapidyaml package to 0.7.2[1] in F42/Rawhide and F41/Branched; I will also update its support library c4core to 0.2.2[2]. Both are ABI-breaking updates with SONAME version bumps. I will also update the unversioned support library c4fs to its latest snapshot[3] and rebuild c4log. An impact check in COPR did not reveal any problems[4]. I will use side tags for these updates, using provenpackager privilege to rebuild the sole dependent package, jsonnet. I’m also planning to use these versions for the initial EPEL10 releases[5] of these packages. [1] https://src.fedoraproject.org/rpms/rapidyaml/pull-request/3 [2] https://src.fedoraproject.org/rpms/c4core/pull-request/10 [3] https://src.fedoraproject.org/rpms/c4fs/pull-request/4 [4] https://copr.fedorainfracloud.org/coprs/music/rapidyaml/packages/ [5] https://bugzilla.redhat.com/show_bug.cgi?id=2307084

1 1

Merging /usr/sbin to /usr/bin
by Zbigniew Jędrzejewski-Szmek 10 Feb '25

10 Feb '25

Hi! I'm trying to get https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin implemented. It was approved for F40, but only a few days before the mass rebuild, so there wasn't time to do much, so it was retargeted to F41. We now have some time before the F41 mass rebuild, so I want to push all the changes required in various packages so that we have time to work out any kinks before the mass rebuild commences. When I started looking at individual packages, I discovered that we have an old rule that packages are SUPPOSED to use "historical paths" to list their files. This rule was introduced to make the transition easier when UsrMove was implemented for F17. For example, mount.nfs was historically installed as /sbin/mount.nfs, so nfs-utils must use %files:/sbin/mount.nfs, even though /sbin is a symlink to /usr/sbin, meaning that the real path after installation is /usr/sbin/mount.nfs. And packages using a file path dependency on mount.nfs must use /sbin/mount.nfs too. To implement this rule, packages must use %buildroot/sbin during installation and use literal "/sbin/" in the files section. This idea made sense at the time, but now it seems overcomplicated and unecessary. It requires additional work from packagers who create the packages that provide the files, but also additional work from packagers that want to refer to those files. In fact, I only found three packages that implement the rule correctly: nfs-utils, glibc, and ocfs2-tools. So step 0. is to drop the packaging rule: https://pagure.io/packaging-committee/pull-request/1355 As to the actual sbin merge: Currently, we have %_bindir==/usr/bin, %_sbindir==/usr/sbin, and /sbin->/usr/sbin, /bin->/usr/sbin. In the end state, we will have %_bindir==%_sbindir==/usr/bin, and /bin,/sbin,/usr/sbin -> /usr/bin. This end state is simple: _any_ path will works for any binary. It's the transition, as we rebuild packages with the new definition, that requires some careful handling. After experimenting with a few different ways to handle this, the following approach seems to work best: 1. rpm is patched to provide %_sbindir==/usr/bin. (This affects what paths packages will list after being rebuilt.) 2. filesystem is patched to not contain /usr/sbin in %files, but instead symlink /usr/sbin -> bin in %pretrans. On fresh installations, this will succeed, so the merge is in place. On upgrades, this will fail, meaning that /usr/sbin remains a dir. There is also a %posttrans scriptlet to attempt a merge on upgrades, more about this below. In particular, since buildroots are created afresh for each build, package builds will get merged-sbin. 3. We need to handle the case where package foo had /usr/sbin/foo, but this file will be in /usr/bin/foo after rebuild. After the merge is done, /usr/sbin/foo and /usr/bin/foo will point to the same location, no problem, but during the transition, users or scripts might call /usr/sbin/foo. To make this work, filesystem rpm gets a scriptlet that will create symlinks from /usr/sbin to /usr/bin, for any files which were installed by packages in /usr/sbin. (A list was obtained using repoquery.) Initially, I wanted to put those scriptlets in individual packages, but that turns out to be a lot of duplicate work. Some packages have multiple subpackages with files (currently) in /usr/sbin, so we'd end up with a lot of churn. Doing it once in filesystem turns out to be fairly easy. 4. We also need to handle the case where other package bar has Requires:/usr/sbin/foo. Once foo has been rebuilt, it has only an automatic provides for /usr/bin/foo. We could adjust bar for the new path, but then bar would not be installable on old systems. Instead, a compat virtual Provides:/usr/sbin/foo is added to foo. We know that either /usr/sbin will be a symlink, or that filesystem will create the /usr/sbin/foo symlink. We need to ensure that the filesystem package that is installed is actually new enough so that the Provides is not a lie. filesystem.rpm gets a virtual Provides:filesystem(unmerged-sbin-symlinks)=1 which is used as Requires:filesystem(unmerged-sbin-symlinks) by foo. (An explicit Provides/Requires allows us to adjust or rescind the mechanism in the future.) 5. After this preparatory work is done, we can rebuild various packages with updated rpm and filesystem. Packages which don't use %_sbindir generally don't care. Some packages which use %_sbindir need small adjustments. There are some common failure modes: a. 'mv %buildroot/%_bindir/foo %buildroot/%_sbindir/' b. 'ln -s ../bin/foo %buildroot/%_sbindir/foo' c. Listing both %_bindir/foo and %_sbindir/foo in %files d. 'ln -sf ../bin/foo %buildroot/%_sbindir/foo.alt' e. 'ln -sf ../sbin/foo %buildroot/%_bindir/foo.alt' To make builds work both before and after the merge, a-c should be conditionalized on '%if "%{_sbindir}" != "%{_bindir}"'. d-e are fixed by using 'ln -sf --relative %{buildroot}/%_bindir/foo %buildroot/%_sbindir/foo.alt' or 'ln -sf --relative %{buildroot}/%_sbindir/foo %buildroot/%_bindir/foo.alt' I submitted / will submit a bunch of pull requests for various packages, but not all, so I'm describing this here so that packagers can use this as a hint. 6. As we rebuild packages in merged buildroots, and those packages are deployed on user systems, in completely new installations, /usr/sbin will be created as a symlink. On upgraded installations, /usr/sbin is a directory and will contain a mix of files and symlinks. filesystem.rpm also has a scriptlet to check if /usr/sbin contains symlinks only, and once that's true, it will nuke /usr/sbin and replace it by a symlink to /usr/bin. This will finalize the merge on upgraded systems. The plan: I. Merge https://pagure.io/packaging-committee/pull-request/1355. This isn't stricly necessary, but makes things simpler. II. I've been doing test rebuilds of packages and filing pull requests as described in 1–4. above. Those should be merged before the other things, changes are conditionalized on '"%{_sbindir}"=="%{_bindir}"'. Some pull requests have already been merged. If you get a pull request, please review and/or merge. https://src.fedoraproject.org/rpms/rpm/pull-request/56 https://src.fedoraproject.org/rpms/filesystem/pull-request/11 https://src.fedoraproject.org/rpms/chkconfig/pull-request/13 https://src.fedoraproject.org/rpms/coreutils/pull-request/15 https://src.fedoraproject.org/rpms/cyrus-sasl/pull-request/11 MERGED https://src.fedoraproject.org/rpms/dmidecode/pull-request/8 https://src.fedoraproject.org/rpms/exim/pull-request/16 MERGED https://src.fedoraproject.org/rpms/exim/pull-request/17 https://src.fedoraproject.org/rpms/glibc/pull-request/91 https://src.fedoraproject.org/rpms/kmod/pull-request/12 https://src.fedoraproject.org/rpms/libcap/pull-request/29 MERGED https://src.fedoraproject.org/rpms/nfs-utils/pull-request/15 https://src.fedoraproject.org/rpms/ocfs2-tools/pull-request/2 https://src.fedoraproject.org/rpms/opensmtpd/pull-request/1 https://src.fedoraproject.org/rpms/policycoreutils/pull-request/42 https://src.fedoraproject.org/rpms/procps-ng/pull-request/7 https://src.fedoraproject.org/rpms/rpcbind/pull-request/4 https://src.fedoraproject.org/rpms/shadow-utils/pull-request/22 https://src.fedoraproject.org/rpms/systemd/pull-request/131 https://src.fedoraproject.org/rpms/util-linux/pull-request/17 III. I have two coprs: https://copr.fedorainfracloud.org/coprs/zbyszek/merged-sbin/builds/ https://copr.fedorainfracloud.org/coprs/zbyszek/unmerged-sbin/builds/ The first one has rpm and filesystem with the changes, so the builds done there get %{_sbindir}==%{_bindir}. Other packages are rebuilt with the patches from pull requests. The second has old rpm and filesystem, and it serves as a check that the same srpms as from the first copr still build fine without the merge. It should be possible to install the packages from the first copr onto a system and either end up with a system with some links and files in /usr/sbin, or /usr/sbin being a symlink. I still need to do more builds in the coprs. If it all turns out to work as expected, I think we're ready to execute the merge. IV. After the pull requests for rpm and filesystem are accepted, I'll build those in a side tag so that they appear in the buildroots at the same time. (Things would be even more confusing with just one of those.) [rpm, filesystem] There is a bunch of packages which do 5c in the list above. Those will FTI until they have been rebuilt. I'll build those in the same side tag so that the buildroot is not broken and we don't get cascading build failures. [rpcbind, systemd-udev, policycoreutils] Once that's done, the side tag can be merged and packages will see the new buildroot layout as they are rebuilt. V. Other packages will need to rebuild to change the layout. I think it'll make sense to rebuild any packages which have had patches applied. There is no "flag day", but it'd be great if we rebuild most packages with files in /usr/sbin, so that we can actually test if the full transition works as expected. VI. A special case of V. is packages using usermode helper with files in /usr/bin and /usr/sbin. Here, each package is different and input from maitainers will be needed. As long as those packages are not rebuilt, they will continue to function in the old state, but as point they'll need to be fixed or retired. I looked into setuptool, and AFAICT, the package is absolete and doesn't actually work. A candidate for retirement. I'm sure that I missed some corner cases. In case something breaks, let me know, I'll try to fix or help to fix. I want to finish working on rpm, filesystem, and other packages soon (hopefully this week), and merge everything about a week later. Zbyszek

4 6

Applying code layout optimization to postgresql16 RPMs in Fedora 41 gave a 3%-6% improvement in IPC
by William Cohen 04 Feb '25

04 Feb '25

Hi All, There is always a desire to make code run faster and use less memory. Code layout optimization is one technique used accomplish those goals by locating strongly connected functions together to reduce the number of memory pages containing actively executing code and to reduce the amount of time that processors use to adjust mapping of logical to physical memory addresses. With the addition of binutils-2.43 in Fedora 41 it is possible to do profile guided optimization (PGO) code layout with the sediment (*) tool. As a testcase I collected profiling data on an Intel machine, created a callgraph from the profiling data, built postgresql16 RPMs with and without optimizations, and benchmarked the RPMs. I got between a 3% and 6% improvment in IPC (instructions per cycle) for pgbench running in various environments (bare metal x86_64, x86_64 guest VM, and aarch64), enough of an improvement that people might be interested. There is a newer version of sediment for Fedora 41 (**) currently in Bodhi testing that include more details on this postgresql pgbench experiment in the documentation and the upstream sediment (*) also has that same information in https://github.com/wcohen/sediment/blob/master/docs/pop.rst. Sediment has been designed to work with the RPM build process. Currently, one needs to use modified RPM macros. These can be created quickly by writing the output of the sediment make_sediment_rpmmacros command into ~/.rpmmacros. One will also need to define set the pgo macro to 1 for the rpmbuild process. The rpm spec file has minimal modifications. It has the callgraph files stored as a source file and a defines the global call_graph to the source file that holds the call graph. The approach that sediment uses differs significantly from other code layout optimization tools such as Intel Thin Layout optimizer (+), Google propeller (++), and Meta Bolt (+++). These tools make it difficult to apply the data collected from one architecture to other architectures. Also the data collected is mapped back to line numbers which will make the data become stale quite quickly as patches or rebases are done on the software. Sediment uses the function names which change less frequently in source code and allow the data from one run to be still be used for later versions of the software across multiple architectures. I would like to see people give sediment a try in Fedora and see what additional performance improvements on application code can be obtained. I would also like to get feedback on how to further improve sediment. -Will Cohen (*) https://github.com/wcohen/sediment (**) https://bodhi.fedoraproject.org/updates/FEDORA-2024-7f5ea0f053 (+) https://github.com/intel/thin-layout-optimizer/commits/main/ (++) https://github.com/google/llvm-propeller (+++) https://github.com/llvm/llvm-project/blob/main/bolt/docs/OptimizingLinux.md

4 15

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel November 2024