Enabling RPM based sysuser handling
by Florian Festi
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
12 hours, 52 minutes
[Node.js] Stepping down as Node.js Maintainer in Fedora
by Stephen Gallagher
tl;dr: I'll be stepping down from maintaining the nodejs22, nodejs20
and nodejs16 packages in Fedora, effective June 30, 2024. I will
continue to maintain libuv.
It's been a hard decision to come to, but I think this is the correct
decision for me. I've been effectively the sole maintainer of Node.js
in Fedora for nearly a dozen years now (apparently, I landed the first
official package in Fedora on Dec. 18, 2012). It has been a long, long
road.
I first picked up Node.js because it was being added as a new
dependency on a package I maintained at the time: Review Board (a
Django-base code-review application). When I looked into it, I
discovered that others had tried - and failed - to package Node.js
previously, but Fedora's rules at the time were *very* strict with
regards to carrying bundled software and Node.js upstream at the time
had a build-system that pretty much only allowed bundling. It took
quite a bit of effort to work through that, but we got there in the
end and I was able to deliver Node.js 0.8 as the very first version to
ship as part of Fedora. It's been a wild ride ever since.
For a long time, Fedora carried a single version of Node.js - whatever
was the latest version destined for LTS status at the time that Fedora
version would be released. Then, along came... Modularity. As you may
know, I was heavily involved with the design of Modularity. Node.js in
particular was something I viewed as a perfect consumer of this new
packaging mechanism: it gave us the ability to ship all versions of
Node.js in Fedora (not just the LTS ones) in a way that could be
packaged in VMs and (new at the time) container images without needing
to modify the way the applications were launched.
Sadly, as you probably know, the implementation of Modularity fell
short of its lofty goals and has largely been relegated to the
dust-bin of history. When it became clear that Modules were going to
be dropped from Fedora, I took on another big packaging exercise:
DE-modularizing Node.js. Rather than go back to the "single Node.js
version in Fedora" approach, I moved to a hybrid approach where we
would have a single "system" version of Node.js LTS like in the older
style, but we would also package the older (and newer!) LTS releases
in a non-default arrangement, similar to how Python packages are
delivered in Fedora. I've been doing it this way for a few years now,
and while there have been some bumps in the road around major-release
upgrades, it's been overall quite workable.
Recently, the Node.js downstream maintainers made some additional
improvements in Node.js 20 to unbundle some previously-precompiled
WASM code into their own packages which build it properly. This is
great! Unfortunately, it has introduced some new issues with the
non-default version in the release (as many of you probably saw last
week). We sorted this out by temporarily re-bundling the WASM in the
non-default versions, but this is really a stop-gap solution.
It's not a huge issue, but it took a big chunk out of my week to get
that resolved and in doing it, I came to an important realization: I'm
burnt out. I took a moment to think through it and realized that I
don't actually *use* Node.js anywhere anymore. I've been maintaining
it for so long that it's become a habit, but I'm not a real consumer
of it. I've sent requests in the past to fedora-devel asking for
comaintainers, but I've never actually had anyone step up, so I've
just kept going.
So that brings us to today and my decision to step down. It's been a
wild ride, but I need to step away and focus on other things. I hope
someone out there will pop up and take over for me. I'm perfectly
happy to train someone on how I maintain the various versions, but my
time as a maintainer is coming to an end. I'll keep things going for
another month, but after that it becomes Someone Else's Problem.
If you read this far, thanks for suffering through that rambling journey.
2 days, 11 hours
GIMP 3.0 in F41?
by Dominik 'Rathann' Mierzejewski
Hi!
I noticed that GIMP 3.0 is scheduled[1] for release in June. It'd be
nice to have it in F41. Are there any plans to do so? Do the maintainers
(Cc'd) need any help?
[1] https://gitlab.gnome.org/GNOME/gimp/-/issues/10373#timeline
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
5 days, 6 hours
Does ccache ever help with kernel mock build?
by Julian Sikorski
Hello,
has anyone successfully managed to get ccache to speed up kernel
mockbuilds, be it SRPMS from kernel-ark or from dist-git? I gave it a
brief shot but saw no difference, if anything the build was slower.
The machine I am building on has 32 GB RAM which is not quite enough to
fit everything on a ramdisk, and the drive I am building to is an NVME
SSD, "only" PCI Express 3.0. CPU is a Ryzen 5 5600x. A baseonly builds
takes about 25 minutes, which is somewhat annoying when one has to
bisect something.
If ccache can speed this up, how big does it need to be? I understand
the default 4 GB is nowhere near enough but what would be needed to
actually help? Thanks!
Best regards,
Julian
1 week
GRUB2 rebase (from 2.06 to 2.12) landing soon on rawhide
by Leo Sandoval
Hi team,
We (the Red Hat bootloader team) are completing the work of
rebasing/reviewing/testing current rawhide patches, from GRUB2 2.06 to
2.12, so at
some point in the near future these would land finally into rawhide. Once
everything is in place, we would like your help to start testing the
package and report any boot issue found.
If there is any concern on this work, please let me know.
Regards,
Leo
1 week
[SPDX] Mass license change GPL+ to GPL-1.0-or-later
by Miroslav Suchý
Hi.
I am going to do the mass change of the license from GPL+ to GPL-1.0-or-later
The proposed diff is in attachment.
Affected packages:
afpfs-ng
alex4
arc
atomorun
bib2html
buffer
catdoc
colorgcc
curlftpfs
cvsps
dia-gnomeDIAicons
docbook-utils
e2tools
echolinux
flpsed
fortune-firefly
freeze
gambas3
gemdropx
gnome-mime-data
gphotofs
graphlcd-base
gt5
hwinfo
jed
launchy
logserial
machineball
meterbridge
mirrormagic
moon-buggy
mussh
netgen
nethogs
R-servr
nss_updatedb
nullmodem
p0rn-comfort
perl-HTTP-Recorder
perl-Image-Xpm
perl-Nagios-NSCA
perl-Test-AutoLoader
perl-WWW-OrangeHRM-Client
php-lukasreschke-id3parser
procinfo
pwgen
qucs
R-biglm
redhat-menus
rocksndiamonds
rpld
rubber
safecopy
setserial
sgml-common
shippy
SolarModel
six
stripesnoop
system-config-rootpassword
tcpflow
trophy
tse3
tunctl
tuxanci
vdr-epg2vdr
vdr-remote
vdr-scraper2vdr
vdr-screenshot
vdr-skinenigmang
wipe
xdialog
xl2tpd
xosview
xteddy
zisofs-tools
Unless somebody stop me, I will do this change directly in dist-git after a week.
--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
1 week, 2 days
F41 Change Proposal: Anaconda as native Wayland application (System Wide)
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/Anaconda_As_Native_Wayland_Applica...
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-anaconda-as-na...
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/interacti...
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.fedora...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
1 week, 5 days
libtiff-4.6.0-2.fc40 continues to ship old .so.5* libraries
by David Abdurachmanov
Andrea (in CC) recently pointed me to libtiff installation warnings on
Fedora/RISCV side:
[..]
Installing : libtiff-4.6.0-2.fc40.riscv64 5/5
Running scriptlet: libtiff-4.6.0-2.fc40.riscv64 5/5
/usr/sbin/ldconfig: /lib64/lp64d/libtiffxx.so.5 is not a symbolic link
/usr/sbin/ldconfig: /lib64/lp64d/libtiff.so.5 is not a symbolic link
[..]
7 months ago libtiff was updated to 4.5.0 [0] with a bunch of CVEs
listed in commit.
This added:
[..]
# Copy old soname %{_libdir}/libtiff.so.5
# Copy old soname %{_libdir}/libtiffxx.so.5
cp %{_libdir}/libtiff.so.5* $RPM_BUILD_ROOT%{_libdir}
cp %{_libdir}/libtiffxx.so.5* $RPM_BUILD_ROOT%{_libdir}
[..]
I assume this was added instead of doing a proper compat package
before SOVERSION bump, or maybe one-time-thing for a side tag while
everything gets rebuilt for a new libtiff.
This is from Fedora Rawhide (today) after installing
libtiff-0:4.6.0-2.fc40.x86_64 (via DNF).
# readelf -p .note.package /usr/lib64/libtiff.so.5
String dump of section '.note.package':
[ 4] |
[ 8] ~^Z�DO
[ 10] {"type":"rpm","name":"libtiff","version":"4.4.0-8.fc40","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:39"}
This seems to come from 4.4.0-8.fc40. Random check suggests there are
a bunch of CVEs with "LibTIFF 4.4.0" string.
The old "*.so.5*" should be removed from this package, as we keep
carrying them over to the next build.
david
- - -
[0] https://src.fedoraproject.org/rpms/libtiff/c/cfa398260d7055fd80951b4c73d9...
2 weeks
