devel June 2024

devel@lists.fedoraproject.org

152 participants
198 discussions

Intel's Clear Linux optimizations
by František Zatloukal 06 Aug '25

06 Aug '25

Hi, Phoronix recently release article[1] about Intel's Clear Linux with some cool graphs showing nice performance gain compared to Xubuntu. I didn't have time to dig in and look how it's performing against Fedora, but I'd assume Fedora can be compared to Xubuntu in terms of compiler settings. I think i'll be interesting to look into it and find out if Fedora can't tweak compiler settings (eg use LTO for critical things like Mesa, Kernel, ...). I think it could be interesting fo Fedora users to have this enabled if there are not any disadvantages other than compile time, compile memory usage and so on. What do you think? [1] http://www.phoronix.com/scan.php?page=article&item=intel-clr-opengl&num=1 -- Best regards / S pozdravem, František Zatloukal Project Coordinator Red Hat

15 50

%patchN deprecated?
by Michael J Gruber 12 Jul '25

12 Jul '25

Has `%patchN` been deprecated in favour of `%patch N`? I got a push by a proven packager to one of the packages which I maintain, commit subject and changelog entry "Fix deprecated patch rpm macro". It contains no explanation and no reference whatsoever. I didn't find any heads up notice, nor info in the packaging guidelines, but I didn't try too hard - because it's not my job. I mean: One person is doing that push. Is it too much to ask to get at least the slightest bit of reference or communication before or into a push which probably affects hundreds of people? If not out of courtesy then out of mere common sense of efficiency? On the technical side, I'd be interested why this is better (fewer macros?) and which releases can take it, and what are the recommendations for `PatchN:`-lines (with or without N), and why (or whether) the recommendation isn't to go for `%autosetup` or `%autopatch` - maybe all answered in the missing reference. P.S.: There is nothing to "fix" here either, only to "adapt" to the deprecation notice, but I'll take that one easy between non-native speakers, presumably.

7 9

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

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

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

11 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

Orphaned magic-wormhole + its python deps
by Fabio Valentini 21 Jan '25

21 Jan '25

Hi everyone, I have just orphaned magic-wormhole (the original one written in Python) and its dependencies. I no longer use it, I have no time to fix the packages for new Python versions, and upstream is pretty much dead since they started porting the project to Rust. - python-magic-wormhole - python-magic-wormhole-mailbox-server - python-magic-wormhole-transit-relay - python-txtorcon - python-spake2 - python-hkdf There is an alternative Go implementation of the "Wormhole Protocol" (wormhole-william), for which eclipseo already submitted a review request. It seems to be better maintained than the Python original, if we want to have a Wormhole client in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1922806 The official port of magic-wormhole to Rust also seems to be progressing, we might want to package that one instead once it's released: https://github.com/magic-wormhole/magic-wormhole.rs Fabio

4 6

Time to retire GlusterFS in Fedora?
by Kaleb Keithley 09 Jan '25

09 Jan '25

HI, Development has effectively ended. For years Red Hat drove development for its RHGS product, but with the EOL of RHGS at the end of 2024 [1], and the disbanding of RHGS engineering at Red Hat, no development is being done. The last update (11.1) was on 6 Nov., 2023. Little or no, development is taking place in the greater Gluster community (such as it is), and no new updates appear to be forthcoming from any direction. Over in the CentOS world, the CentOS Storage SIG members have decided not to build GlusterFS RPMs for Stream 10. Therefore I intend to retire the GlusterFS package in Fedora 42, unless someone else would like to step in and take over as package owner. [1] https://access.redhat.com/support/policy/updates/rhs/ -- Kaleb

9 16

Enabling RPM based sysuser handling
by Florian Festi 21 Dec '24

21 Dec '24

Hi everyone! RPM 4.19 added automatic sysuser handling [1]. In Fedora 39 this feature was not enabled right away [2] as it requires some care to properly transition to it. Also going back to 4.18 was technically still the fallback option during this change. I just noticed in an issue in the RPM upstream repository [3] that the sysuser feature is still not enabled. May be right now might be a good time to get this going for Fedora 41. I am happy to help with the technical details but would prefer if this effort was driven from within Fedora. Currently users are either done manually by calling useradd in scriptlets or using the macros in systemd-rpm-macros which is a sub package of the systemd package. RPM's mechanism is switched off by rpm-4.18.92-disable-sysusers.patch in the rpm package. This whole thing probably needs to be a Global Change involving a change to the Packaging Guidelines [4] and may be an Mass Package Change (although that might be avoided by changing the macros in systemd-rpm-macros to NOPs). Anyone interested in picking this up? I remember quite a few people being exited about this when it was announced with the rpm-4.19 Change. Florian [1] https://rpm-software-management.github.io/rpm/manual/users_and_groups.html [2] https://fedoraproject.org/wiki/Changes/RPM-4.19 [3] https://github.com/rpm-software-management/rpm/issues/3073 [4] https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups

7 18

Jump to page:

2026

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 June 2024