devel November 2024

devel@lists.fedoraproject.org

153 participants
186 discussions

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

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

Plans for OCaml 5.2/5.3
by Richard W.M. Jones 09 Jan '25

09 Jan '25

Just a heads up for OCaml. We currently have OCaml 5.2.0 in Fedora 41 & Rawhide. OCaml 5.3.0 is expected to be released at the "end of November or beginning of December"[1], so it would make sense to move straight to this version in Rawhide after that happens. [1] https://ocaml.org/changelog/2024-10-31-ocaml-5.3.0.beta1 Release notes for 5.3.0: https://github.com/ocaml/ocaml/blob/5.3/Changes OCaml 5.2.1 is "a collection of safe but import[ant] runtime time bug fixes backported from the 5.3 branch of OCaml"[2]. It was released a couple of days ago. If I have the energy I'll update Fedora 41 to this version, but only after 5.3.0 is released first (as otherwise I'll need to do Rawhide twice to avoid the version in Rawhide being lower). [2] https://ocaml.org/changelog/2024-11-18-ocaml-5.2.1 Note that updating an OCaml version involves recompiling all the related packages, about 200 of them. Also there's a new version of LWT, so it makes sense to update that at the same time: https://bugzilla.redhat.com/show_bug.cgi?id=2326159 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW

2 3

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:

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