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/56https://src.fedoraproject.org/rpms/filesystem/pull-request/11https://src.fedoraproject.org/rpms/chkconfig/pull-request/13https://src.fedoraproject.org/rpms/coreutils/pull-request/15https://src.fedoraproject.org/rpms/cyrus-sasl/pull-request/11 MERGED
https://src.fedoraproject.org/rpms/dmidecode/pull-request/8https://src.fedoraproject.org/rpms/exim/pull-request/16 MERGED
https://src.fedoraproject.org/rpms/exim/pull-request/17https://src.fedoraproject.org/rpms/glibc/pull-request/91https://src.fedoraproject.org/rpms/kmod/pull-request/12https://src.fedoraproject.org/rpms/libcap/pull-request/29 MERGED
https://src.fedoraproject.org/rpms/nfs-utils/pull-request/15https://src.fedoraproject.org/rpms/ocfs2-tools/pull-request/2https://src.fedoraproject.org/rpms/opensmtpd/pull-request/1https://src.fedoraproject.org/rpms/policycoreutils/pull-request/42https://src.fedoraproject.org/rpms/procps-ng/pull-request/7https://src.fedoraproject.org/rpms/rpcbind/pull-request/4https://src.fedoraproject.org/rpms/shadow-utils/pull-request/22https://src.fedoraproject.org/rpms/systemd/pull-request/131https://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
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
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
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
Hello!
Latest live555-2024.03.08 comes with an SONAME bump from 107 to 112.
The only consumer seems to be vlc, which I'll rebuild in a side-tag
(f41-build-side-87311) and submit together as an update.
This is rawhide only.
Regards,
Dominik
--
Fedora https://fedoraproject.org
Deep in the human unconscious is a pervasive need for a logical universe that
makes sense. But the real universe is always one step beyond logic.
-- from "The Sayings of Muad'Dib" by the Princess Irulan
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
I'm trying to figure out the best way to handle the situation where a
project decides to use submodules in Git. The archive generated doesn't
incorporate the submodule files.
I've done some searching on this, and haven't really come up with much.
I've reviewed: Packaging:Github
<https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#G…>
; but that really doesn't address the submodule issue.
I looked through some packages that are currently in the Fedora repository
and found where a few folks have rebuilt the tarball and referenced that
version as the Source in the spec file; then they put in a comment stating:
The source of this package was pulled from upstreams' vcs. Use the
following
commands to generate the tarball:
...
- git clone
...
- git submodule init
- git submodule update
...
This approach is the best that I've found. Any other suggestions?
Thanks much!
Hi Folks,
We would like to replace power-profiles-daemon with tuned. There are
many power-related software that offer similar functions. Advanced
users may install several power management tools, for example, tuned
and power-profiles-daemon (ppd), and get confused about which tools
manage the system and cause unexpected behaviors for the system. By
integrating power-profiles-daemon with tuned, the user can get extra
features to finetune the system, and the basic feature provided by ppd
can be used according to the user's demand. It also can reduce the
efforts of the maintainer.
The impact of this plan would be gnome-control-center (power panel),
KDE, sysprof, and tuned (or some projects depending on ppd). We should
move the ppd API and features to tuned to provide the same features of
it. From the API aspect, we also can design a new API for the basic
feature, ppd provided but the software dependent on ppd should be
modified to use the new API. Although, for the long-term plan, a set
of new API is a good option. For the short-term plan, moving the
original one to tuned is good for those applications depending on ppd.
Moreover, the detailed change proposal can be found here.
https://fedoraproject.org/wiki/Changes/TunedReplacesPower-profiles-daemon
If you have any suggestions, please let us know.
Thank you. :)
--
BR,
Kate
We've been looking at the AppStream extractor issues in Fedora, and
we've come across a few broken applications. Broken apps are not
visible in the application installer. The apps include:
* albumart
* apitrace-gui
* appstream
* asylum
* audience
* bomber
* bovo
* calligra-braindump
* cervisia
* choqok
* classified-ads
* crrcsim
* cube
* curblaster
* dsi
* escape
* ettercap
* font-manager
* freedink-engine
* gap-core
* gnofract4d
* gvrng
* hgview
* hyperrogue
* kaddressbook
* key-mon
* kgraphviewer
* knotes
* konqueror
* LabPlot
* nextcloud-client (maybe fixed in distgit)
* openms
* openvibe
* owncloud-client
* pingus
* pioneer
* portecle
* qdigidoc
* qjackctl
* qsynth
* qtikz
* recoll
* renku
* rodent
* screengrab
* screenruler
* simple-ccsm
* slashem
* spectacle
* speed-dreams
* tennix
* tilp2
* tortoisehg
* trophy
* tzclock
* uzbl-defaults
* vdrift
* vegastrike
* wireshark-gtk
* xfce4-power-manager
* xfpanel-switch
* xskat
* yakuake
* zanshin
* zathura
The full list, along with what failed is available here:
https://dl.fedoraproject.org/pub/alt/screenshots/f26/failed.html
If you want any suggestions or advice, I'm happy to help. Most of the
failures are pretty self explanatory, e.g. "No <summary> in AppData"
or "icon was too small 24x24" -- our guidelines are here:
https://github.com/hughsie/appstream-glib/blob/master/README.md#guidelines-…
As a reminder, you can validate AppData files using: appstream-util
validate-relax file.appdata.xml
Thanks, and comments welcome. I can set up a script that sends email
to the package maintainer if this would be helpful, but I thought we
might be able to get the majority of these sorted with this email.
Richard.