Hi all,
Today, 2025-12-20, we have removed inactive packagers
from the packager group.
This is in accordance with the FESCo policy on inactive packagers:
https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/
If the removed user is 'main admin' for a package, this package
will be orphaned. If there are co-maintainers for the package,
one of them should take the role of 'main admin',
by clicking "✋ Take" on
`https://src.fedoraproject.org/rpms/<package>`".
Otherwise any packager may take the package while it's orphaned.
After 6 weeks, the package will be retired.
After another 8 weeks, a new review is needed to unretire it.
see https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_pa…
for more details.
More details available in
https://pagure.io/fedora-infrastructure/issue/12891
Packages that have been orphaned are:
flatpaks/libreoffice
rpms/bashmount
rpms/btrfs-progs
rpms/ccache
rpms/ceres-solver
rpms/cl-asdf
rpms/cockpit-composer
rpms/common-lisp-controller
rpms/cvsps
rpms/deco
rpms/deco-archive
rpms/et
rpms/fctxpd
rpms/geany
rpms/gecode
rpms/golang-github-alibabacloud-debug
rpms/golang-github-alibabacloud-tea
rpms/golang-github-aliyun-cli
rpms/golang-github-aliyun-credentials
rpms/golang-github-aliyun-ossutil
rpms/golang-github-alyu-configparser
rpms/golang-github-droundy-goopt
rpms/golang-github-dustinkirkland-petname
rpms/golang-github-gehirninc-crypt
rpms/golang-github-haproxytech-client-native
rpms/golang-github-haproxytech-config-parser
rpms/golang-github-haproxytech-logger
rpms/golang-github-lestrrat-apache-logformat
rpms/golang-github-lestrrat-envload
rpms/golang-github-lestrrat-strftime
rpms/golang-github-nathanaelle-syslog5424-2
rpms/golang-github-rodaine-hclencoder
rpms/golang-github-shulhan-bindata
rpms/ikona
rpms/java-jd-decompiler
rpms/libfaketime
rpms/libstatgrab
rpms/lxsplit
rpms/mingw-jansson
rpms/mingw-speexdsp
rpms/mingw-yaml-cpp
rpms/multimedia-menus
rpms/muse
rpms/nodejs-rhea
rpms/nodejs-underscore
rpms/openjdk-asmtools
rpms/perl-Alien-Packages
rpms/perl-Log-Any
rpms/perl-MooX-Log-Any
rpms/perl-MooX-Roles-Pluggable
rpms/perl-Net-Twitter
rpms/perl-Unix-Statgrab
rpms/perl-WWW-Shorten
rpms/phototonic
rpms/python3-gql
rpms/python-novaclient-os-networks
rpms/python-octaviaclient
rpms/python-pyvat
rpms/qclib
rpms/qt5-qtwebchannel
rpms/qt5-qtwebsockets
rpms/rcs
rpms/rubygem-bacon-colored_output
rpms/rubygem-codeclimate-test-reporter
rpms/rubygem-diffy
rpms/rubygem-generator_spec
rpms/rubygem-ipaddress
rpms/rubygem-minitest-around
rpms/rubygem-mixlib-cli
rpms/rubygem-mixlib-config
rpms/rubygem-mixlib-shellout
rpms/rubygem-nifti
rpms/rubygem-powerpack
rpms/rubygem-systemu
rpms/serafettin-cartoon-fonts
rpms/smaclient
rpms/systemd-bootchart
rpms/twirssi
rpms/uchardet
rpms/vera++
rpms/ws-commons-util
tests/scap-security-guide
tests/scap-workbench
Wiki:
https://fedoraproject.org/wiki/Changes/StopCreatingDefaultNetworkProfilesBy…
Discussion Thread: https://discussion.fedoraproject.org/t/177637
**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 ==
Traditionally Anaconda installer used to create default network profiles
(NetworkManager ifcfg files or keyfiles) on the installed sytem for each
wired device. With the change only ... [truncated]
== Owner ==
* Name: [[User:rvykydal| Radek Vykydal]]
* Email: rvykydal(a)redhat.com
== Detailed Description ==
The reasons for the current behavior - creating of the default profiles for
each wired network device - were from large part technical, imposed by the
architecture of the installer network configuration module. The Anaconda
default profiles were created at the initial stage of installation from
NetworkManager connections where possible - either by dumping a connection
(for example 'Wired Connection' created in initramfs) - or cloning a
default connection ('Wired Connection 1' created after switchroot) with
connection id updated to the interface name. In cases where reusing the
connection created by NM was not possible Anaconda created new connection
on its own via NetworkManager API. In some cases Anaconda was also updating
some values of the connections like addr-gen-mode.
Over the years there were requests from the users to stop creating the
profiles for unconfigured devices - only the devices configured in
installer should have persistent profile created on the installed system.
The updates in the NewtworkManager backend and its integration in the
installer, together with improved CI coverage, now allows to drop the
default connections and by this also to address several long term issues:
* There were bugs reported related to the default connections present on
the installed system unexpectedly by the users (
https://bugzilla.redhat.com/show_bug.cgi?id=2031385#c8,
https://bugzilla.redhat.com/show_bug.cgi?id=2115783,
https://issues.redhat.com/browse/RHEL-100200) In some cases the profiles
prevented proper activation of virtual connections configured by the user.
The issues were usually addressed by installer by updating already complex
logic for management of the profiles by the installer. For port devices
installer already stopped to create the profiles recently (
https://github.com/rhinstaller/anaconda/pull/5703)
* On the Live ISO installations (as Fedora Workstation) the installer
network configuration UI and the connection management had to be disabled
because it was conflicting with the Gnome configuration tools present in
the environment. In scope of the ongoing move towards the WebUI graphical
user interface the installer team aims to provide UI that can seamlessly
integrate with other tools, usable both in Live ISO environment and
installer image environment (for example Server variant using Netinst ISO
or DVD ISO), preferably reusing Cockpit network configuration module. This
requires dropping some parts of installer network connections management -
with this change being an important step (see
https://issues.redhat.com/browse/INSTALLER-3088)
* Significant part of installer users work around the current behavior by
removing the default connections created by installer in their custom
kickstart '%post' scripts or other installation post-processing ([
https://pagure.io/fedora-kickstarts/blob/f43/f/fedora-cloud-base.ks#_146
fedora-cloud-base.ks] for example).
* There was already a request from NetworkManager side for installer team
to drop creating of default profiles:
https://github.com/rhinstaller/anaconda/pull/1588. Installer team was not
able to prioritize it to be addressed yet.
== Feedback ==
The feedback we were getting from the community over the past years was
asking for removing of the default Anaconda profiles, as pointed out in the
**Detailed Description**.
On the other hand we may expect negative feedback triggered by potential
need for adaptation to the new behavior.
== Benefit to Fedora ==
* Improved consistency - persistent profiles exist only for configured
devices.
* Single point of truth for defaults - installer steps out of the business
of creating default network profiles (name, id, binding) and even setting
its default values.
* User perspective: no unexpected network configuration produced by
installation. Workarounds for removing undesired profiles in post
installation steps are no more needed.
* More flexibility for network configuration tooling choices in the
installer environment (like LiveISO).
* Makes shared use of Cockpit network configuration module in installer
WebUI for non-live ISO variants feasible.
== Scope ==
* Proposal owners: replace the DumpMissingConfigFiles API with API for just
persisting initramfs configuration. The work is in advanced progress in
https://github.com/rhinstaller/anaconda/pull/6787.
* Other developers: potentially adapt scripts and tools assuming existence
of the persistent profiles for non-configured devices
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
Upgrades impact: none, the change is applied only to newly installed
systems.
Compatibility impact: automation tools used to post process network
configuration of systems after installation might need adjustments if they
are working with network profiles without verifying its existence
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? Y/N
== How To Test ==
The change can be tested by installing Fedora variants which are using
installer environment iso (boot.iso, netinst or DVD, for example Fedora
Server) on various installation scenarios with or without network
configuration in installer:
* via boot options (for example 'ip=dhcp', 'ip=enp1s0:dhcp')
* via kickstart ('network' command)
* via text UI
* via Gtk UI
The devices not configured by any of these means should not have persistent
configuration profile on installed system (in
'/etc/NetworkManager/system-connecitons'). See also the examples in the
**User Experience** section.
== User Experience ==
**Example 1**: Fedora Server Network Installation, no network configuration
during installation.
*Without the change* - state after installed system reboot:
root@ibm-p8-kvm-03-guest-02:~# nmcli con
NAME UUID TYPE DEVICE..
enp0s22 2c4fb9f7-feab-3c4e-a4d5-549b34feab67 ethernet enp0s22.
lo eff6e9ee-ffe6-4cd8-8d91-a131d75ccdaf loopback lo......
root@ibm-p8-kvm-03-guest-02:~# ls
/etc/NetworkManager/system-connections/
enp0s22.nmconnection
root@ibm-p8-kvm-03-guest-02:~# cat
/etc/NetworkManager/system-connections/enp0s22.nmconnection.
[connection]
id=enp0s22
uuid=2c4fb9f7-feab-3c4e-a4d5-549b34feab67
type=ethernet
autoconnect-priority=-999
interface-name=enp0s22
timestamp=1765956677
[ethernet]
[ipv4]
method=auto
[ipv6]
addr-gen-mode=eui64
method=auto
[proxy]
*With the change* - state after installed system reboot:
root@ibm-p8-kvm-03-guest-02:~# nmcli con
NAME UUID TYPE
DEVICE..
Wired connection 1 3500649e-c341-3a36-bb89-02e29d6f6f4f ethernet
enp0s22.
lo 4147084d-dedd-4513-aed2-bb8ecbe0b26e loopback
lo......
root@ibm-p8-kvm-03-guest-02:~# ls
/etc/NetworkManager/system-connections/
root@ibm-p8-kvm-03-guest-02:~# ls
/run/NetworkManager/system-connections/
lo.nmconnection 'Wired connection 1.nmconnection'
root@ibm-p8-kvm-03-guest-02:~# cat
/run/NetworkManager/system-connections/Wired\ connection\ 1.nmconnection.
[connection]
id=Wired connection 1
uuid=3500649e-c341-3a36-bb89-02e29d6f6f4f
type=ethernet
autoconnect-priority=-999
interface-name=enp0s22
timestamp=1765959194
[ethernet]
[ipv4]
method=auto
[ipv6]
addr-gen-mode=default
method=auto
[proxy]
[.nmmeta]
nm-generated=true
**Example 2**: Fedora Server DVD installation with network device unplugged
during installation and plugged in before booting installed system. No
network configuration during installation.
*Without the change* - state after installed system reboot:
root@dhcp193:~# nmcli con
NAME UUID TYPE DEVICE.
lo 60c2b452-c923-44b7-b119-484f1fc119dc loopback lo.....
enp1s0 f986e267-90bc-4e3a-bc89-d16ffa581246 ethernet --.....
root@dhcp193:~# ls /etc/NetworkManager/system-connections/
enp1s0.nmconnection
root@dhcp193:~# ls /run/NetworkManager/system-connections/
lo.nmconnection
root@dhcp193:~# cat
/run/NetworkManager/system-connections/enp1s0.nmconnection
[connection]
id=enp1s0
uuid=f986e267-90bc-4e3a-bc89-d16ffa581246
type=ethernet
autoconnect=false
interface-name=enp1s0
[ethernet]
[ipv4]
method=auto
[ipv6]
addr-gen-mode=eui64
method=auto
[proxy]
*With the change* - state after installed system reboot (is the same as in
Example 1):
root@dhcp193:~# nmcli con
NAME UUID TYPE
DEVICE
Wired connection 1 9196327c-a909-3cda-8733-06d6c77546f9 ethernet
enp1s0
lo 64f89f2c-85c8-40eb-92bf-b6712e3162d5 loopback lo
root@dhcp193:~# ls /etc/NetworkManager/system-connections/
root@dhcp193:~# ls /run/NetworkManager/system-connections/
lo.nmconnection 'Wired connection 1.nmconnection'
root@dhcp193:~# cat /run/NetworkManager/system-connections/Wired\
connection\ 1.nmconnection
[connection]
id=Wired connection 1
uuid=9196327c-a909-3cda-8733-06d6c77546f9
type=ethernet
autoconnect-priority=-999
interface-name=enp1s0
timestamp=1765961287
[ethernet]
[ipv4]
method=auto
[ipv6]
addr-gen-mode=default
method=auto
[proxy]
[.nmmeta]
nm-generated=true
== Dependencies ==
It is possible that some Anaconda installer clients performing installed
system post processing will need to adapt to the change, expecting the
Anaconda default profiles existing (for their modification, removal, etc).
Regarding system management / configuration tools, I think the risk they
may assume the profiles existing on the installed system is reasonably
small, and the tools should be able to handle their removing without issues.
== Contingency Plan ==
* Contingency mechanism: Reverting the change.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
I am not aware of the current behavior being documented anywhere else then
in the [
https://anaconda-installer.readthedocs.io/en/latest/autoapi/pyanaconda/modu…
DumpMissingConfigFiles API].
The new behavior should be the one users would expected by default, so no
explicit documentation is required.
The change of behavior will be documented in release notes.
== Release Notes ==
Wiki:
https://fedoraproject.org/wiki/Changes/Java21RemovedEarlierThenScheduled
Discussion Thread: https://discussion.fedoraproject.org/t/177636
**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 ==
Remove java-21-openjdk already from F44, rather then F45 as was originally
announced
[[Changes/ThirdPartyLegacyJdks| here]] and
[[Changes/Java25AndNoMoreSystemJdk#Detailed_Description| here]]
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: jvanek(a)redhat.com
== Detailed Description ==
Short preliminary [
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
discussion] happened in early December without any strong opposition but
with several good ideas. but From total java-stack(546 packages), only 26
requires jdk21 for build:
* apache-commons-modeler-0:2.0.1-43.fc42.src
* apache-commons-text-0:1.10.0-8.fc42.src
* apache-sshd-1:2.11.0-2.fc41.src
* decentxml-0:1.4-36.fc41.src
* fop-0:2.9-9.fc41.src
* Java-WebSocket-0:1.6.0-4.fc43.src
* l10n-maven-plugin-0:1.1.0-2.fc43.src
* maven-archetype-0:3.2.1.0.8b3bdb6-14.fc41.src
* resteasy-0:3.0.26-32.fc42.src
* xmlgraphics-commons-0:2.11-1.fc43.src
* javapoet-0:1.7.0-27.fc43.src
* java-runtime-decompiler-0:10.0-6.fc43.src
* jol-0:0.17-10.fc43.src
* juniversalchardet-0:2.4.0-16.fc43.src
* plexus-velocity-0:2.2.1-2.fc43.src
* stringtemplate4-0:4.3.4-9.fc43.src
* xbean-0:4.24-8.fc43.src
* xbean-0:4.24-9.fc43.src
* icedtea-web-0:1.8.8-10.fc43.src
* ldapjdk-0:5.6.0-0.1.alpha1.fc43.3.src
* ldapjdk-0:5.6.0-1.fc43.src
* mecab-java-0:0.996-14.fc43.src
* openjdk-asmtools-0:9.0.0.b12.ea.eb1979669-0.fc43.src
* mecab-java-0:0.996-14.fc43.src
* fop-0:2.9-9.fc41.src
* nekohtml-0:1.9.22-29.fc42.src
* jedit-0:5.6.0-8.fc43.src
From those aprox 10 is FTBFs even with java-21-openjdk, and the rest seems
to be ok to switch to java-25-openjdk. This part will be elaborated on.
Once those packages are resolved, jdk21 will be removed from rawhide and
the [
https://src.fedoraproject.org/rpms/adoptium-temurin-java-repository/blob/ra…
adoptium-temurin-java-repository package] will obsolete jdk21 in f44, and
will warn about jdk21 being deprecated in f43 and down.
== Feedback ==
For now the headless subpakcage was rebuked as priority to fix on temurin
side. Others may pop up.
== Benefit to Fedora ==
Benefit to distribution itself is controversial. A lot of development is
focussed to Eclispe Temurins, but we failed to prepare proper 1:1
replacement in past.
Main benefit will be the spared cycles of developers who will maintain one
less jdk for one less cycle. Main focus of saved cycles should be the 1:1
compatibility of Temurins with our RPMs.
Note, that side benefit of this is, that Temurin JDK rpms will become more
like Fedora rpms, rather then "more like Debian" or similarly.
== Scope ==
* Proposal owners:
** We will help to migrate remaining packages to jdk25
** we will deprecate and remove jdk21
** we should improve temurin rpms to fit more
* Other developers:
** No work is expected
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: ok, I think
== Upgrade/compatibility impact ==
User which was used to have several system JDKs will have one system JDK
(25) and one rolling future jdk java-latest-openjdk (26 in that time) if
applicable.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? Y/N
== How To Test ==
todo
== User Experience ==
Change should be transparent to all users and power users.
Users will have latest JDK as soon as possible, as usual, and all Java
packages should remain fully operational.
== Dependencies ==
* adoptium-temurin-java-repository as per schedule and description
* java-21-openjdk as per schedule and description
* remaining packages in javastack as per schedule and description
== Contingency Plan ==
* Return java-21-openjdk as it is
* Contingency deadline: beta freeze
* Blocks release? No
== Documentation ==
N/A for now
== Release Notes ==
\n
Wiki: https://fedoraproject.org/wiki/Changes/ModernizeBootISO
Discussion Thread: https://discussion.fedoraproject.org/t/177634
**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 ==
We will switch over production of the boot.iso from using `lorax` to
`image-builder` modernizing the build of the deliverable while keeping
functional parity.
== Owner ==
* Name: [[User:supakeen| Simon de Vlieger]], [[User:ngompa| Neal Gompa]]
* Email: cmdr(a)supakeen.com, ngompa13(a)gmail.com
== Detailed Description ==
Over the past few Fedora releases we have slowly been moving deliverable
production over to new image build tooling. Package based live media has
moved onto `kiwi`. ostree-, and bootc-based artifacts have moved onto
`image-builder` though some deliverables remain to be migrated in this area.
One of the important artifacts in Fedora is the boot.iso. This is the
network installer that is shipped as the "Everything" network installer, or
the "Server" network installer for Fedora Server edition.
This artifact is used in pungi and processed further into the dvd.iso (by
embedding a compose's repositories into the boot.iso) and the Fedora Atomic
installers (by embedding a compose's ostree commit into the boot.iso).
We would like to start producing the boot.iso with modern image build
tooling.
`image-builder` is currently deployed in Fedora's Koji build system and can
produce both the Everything and Fedora Server Edition boot.iso's. Thus for
this effort we would like to switch over the pungi configuration to start
using `image-builder` for these deliverables.
While `image-builder` definitions currently provide a boot.iso that is at
parity we would like to also use this switch to address several concerns
with the boot.iso media while keeping functional parity. This includes
(less|no) usage of Lorax in the build process which might necessitate
changes to packages and/or configuration (mostly in Anaconda).
Since the boot.iso media is used in many workflows both internal to Fedora
and by users we have explicitly targeted Fedora 45 to give us enough time
to discover any dragons that might appear.
We plan to switch over as early as possible after rawhide becomes Fedora 45
to give users and ourselves the maximum amount of time to find any
regressions and address them.
Separately, any work on the Pungi side of things and the investigative work
that will go into this will benefit other image build tooling such as
`kiwi` to also be able to produce these deliverables in the future as these
parts are shared. Having redundancy in our tooling (both `image-builder`
and `kiwi` being able to build the same artifacts) is a great thing to have
as it allows us to switch over the build backend when one or the other is
having issues and reduces the risk of any complications affecting all
deliverables.
== Feedback ==
== Benefit to Fedora ==
Changing the production of the boot.iso over to `image-builder` brings
infrastructural benefits. It also allows users to easily build (customized)
boot.iso's locally that match official Fedora deliverables and provides an
easier way to produce derivatives and Fedora remixes that want to create
boot.iso media using `image-builder` or `kiwi`.
Aside from this the process on how these deliverables are produced becomes
more linear and simpler to understand.
## Scope [📖](https://fedoraproject.org/wiki/Changes/ModernizeBootISO#Scope)
* Proposal owners: implement definitions (`image-builder`) and descriptions
(`kiwi`) to build modernized boot.iso media. Update pungi configuration to
make use of this (might imply changes to pungi itself as well).
* Other developers: None.
* Release engineering:
https://forge.fedoraproject.org/releng/tickets/issues/13140
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
== Early Testing (Optional) ==
Users can test the current state of these artifacts by installing
`image-builder` and building the deliverables as they are now:
$ sudo dnf install image-builder
$ sudo image-builder build everything-network-installer
Note that several changes need to land upstream and thus these installers
do not properly reflect the state that we want in Fedora, yet.
== How To Test ==
Once the pungi configuration for rawhide has been changed to produce these
deliverables with `image-builder` OpenQA will start testing these
automatically.
Users can also start testing after this point. The tests would involve the
usual requirements and criteria for the boot.iso.
Once the new deliverables are testable an announcement will be made on the
mailinglist and discussion forum to get as many eyes on this as possible.
== User Experience ==
The user experience of using the boot.iso media should not change in any
functional way.
== Dependencies ==
There are no dependencies on other changes. The owners of this proposal
will likely need to perform work in pungi, the pungi configuration, and
perhaps Anaconda.
We have explicitly targeted Fedora 45 to give us enough time to make these
changes as they might have long(er) timeframes to land in Fedora.
If any critical changes are not able to land before Fedora 45 we will have
the option to either pave over them in `image-builder` (for example, if
configuration files need to be moved around, or directories need to be
removed) or to trigger the contigency and defer to Fedora 46.
== Contingency Plan ==
* Contingency mechanism: Revert pungi configuration changes
* Contingency deadline: Beta Freeze
* Blocks release: Yes
== Documentation ==
Notes will be written and kept as the implementation progresses.
== Release Notes ==
\n
Hi everyone,
As per Changes/GolangPackagesVendoredByDefault [1], all golang libraries
that are currently leaves (as defined in [2]) will be mass retired. This
will happen in the coming days. The full list of packages is available
at [3].
Note that golang libraries that current packages depend on will not be
retired as part of this process. However, non-leaf golang libraries may
still be retired as part of Orphaned Packages Process and FTI/FTBFS
processes, so this may affect your package(s) if you did not/do not take
action before these processes' respective deadlines.
Existing packages are recommended to migrate to the new vendored
dependency approach, and the updated Guidelines that mandate vendoring
apply to all new Golang applications packages added to the distribution [4].
Thank you for your cooperation and let me know if you have any questions!
Happy holidays and happy new year,
Maxwell
[1]
https://fedoraproject.org/wiki/Changes/GolangPackagesVendoredByDefault#Plan
[2] https://gitlab.com/fedora/sigs/go/package-data/-/blob/main/README.md
[3]
https://gitlab.com/fedora/sigs/go/package-data/-/blob/f6aad6bb0b54760f2e7a4…
[4] https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang
Wiki: https://fedoraproject.org/wiki/Changes/Rework_Games_Lab
Discussion Thread: https://discussion.fedoraproject.org/t/177296
**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 ==
Modernize the Games Lab deliverable by leveraging the latest technologies
to offer a high quality gaming and game development experience. This
includes a change from Xfce to KDE Plasma to take advantage of the latest
and greatest Wayland stack for gaming.
== Owner ==
* Name: [[User:Dogphilosopher|Noel Miller]], [[User:Owensz|Owen
Zimmerman]], [[User:Jaidenriordan|Jaiden Riordan]], [[User:Lleyton|Lleyton
Gray]]
* Email: nomiller(a)redhat.com , owen(a)fyralabs.com, jade(a)fyralabs.com,
lleyton(a)fyralabs.com
== Detailed Description ==
The Games Lab has been on minimal maintenance for some time, with nearly
all members having left.
There have been many developments in the ecosystem that benefit gamers that
could be pulled into this lab to make it a more compelling offering and
potential platform of growth for Fedora.
In the past ten years, there's been signficant effort around Linux gaming,
and the past five years have seen a meteoric rise in adoption of Linux for
gaming.
In that timeframe, technologies like Wayland and PipeWire have matured and
now exclusively offer compelling features (such as HDR and VRR) that are
increasingly considered critical to gaming.
As part of this rework, we are:
* Refreshing Fedora gaming documentation to showcase the new capabilities
of Linux gaming, and give references to game playing, emulation,
development, installation, ways to improve, etc.
* Providing an environment to upstream common gaming patches that provide
functionality for handhelds and other gaming hardware, that have otherwise
stayed within downstreams.
* Showcasing a strong set of open source games and creation tools to
demonstrate what an open gaming platform is capable of.
* Leveraging the work of the Fedora KDE Plasma Desktop Edition as the basis
for building our experience.
* Emphasizing the role of downstreams (ex. Bazzite) in delivering to the
needs of users, by providing a commons for Fedora-based gaming focused
downstreams to acheive common goals.
== Feedback ==
== Benefit to Fedora ==
This change will modernize the Fedora Games Lab, bringing the user
experience and documentation up to speed as a modern, customized Fedora
experience built on the flagship Fedora KDE Plasma Desktop Edition, while
showcasing the best of gaming on Linux for users and developers.
== Scope ==
* Proposal owners:
** Make new Games Lab definitions in fedora-kiwi-descriptions
** Improve the state of Plasma Bigscreen
** Document contemporary aspects of Linux gaming
*** Actually playing games
*** Emulation
*** Game Development
*** Game Installation
*** Issues
* Other developers: N/A (not needed for this Change)
* Release engineering: [
https://forge.fedoraproject.org/releng/tickets/issues/13135 #13135]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: This effort aligns with the
objectives to broaden our audience and expand our connections with gaming
communities to make Fedora the preferred platform for gaming and game
development.
== Upgrade/compatibility impact ==
There will be no change to existing Fedora Games Lab installations, only
new installations will get the new experience.
For those who would like to manually switch, there will be documentation on
how to do so.
== Early Testing (Optional) ==
N/A
== How To Test ==
Install the refreshed Games Lab and play any of the preloaded games.
== User Experience ==
Users will have a modernized entry point into the Fedora gaming ecosystem,
with improved access to information regarding the game experience on
Fedora/Linux.
== Dependencies ==
N/A.
== Contingency Plan ==
* Contingency mechanism: Revert back to pre-Change configuration and defer
to the next Fedora release
* Contingency deadline: Beta Freeze
* Blocks release? No
== Documentation ==
The current [https://docs.fedoraproject.org/en-US/gaming/ Fedora gaming SIG
documentation] will be redone and brought to the same standard as the new
Lab.
== Release Notes ==
\n\n\nThe Fedora Games Lab now uses KDE Plasma as its desktop experience.
Existing users who have the previous Xfce-based experience will not be
upgraded to this.\nUsers who want to adapt existing installs to the new
experience can read the Games Lab documentation for more
information.\n\nThe Fedora Games Lab now includes a modernized games and
game development tools package set.\n\nGaming on Fedora documentation has
been modernized and greatly expanded on.
Wiki: https://fedoraproject.org/wiki/Changes/Podman6
Discussion Thread: https://discussion.fedoraproject.org/t/177294
**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 ==
This proposal introduces Podman 6.0, a new major version of the container
management tool, into Fedora 44. This update includes significant API and
CLI breaking changes, new functionality, and the final removal of
deprecated components including slirp4netns, cgroups v1, and the BoltDB
backend.
== Owner ==
* Name: [[User:Lsm5|Lokesh Mandvekar]], [[User:Bbaude|Brent Baude]],
[[User:Mohanboddu|Mohan Boddu]]
* Email: lsm5(a)redhat.com, bbaude(a)redhat.com, mboddu(a)bhujji.com
== Detailed Description ==
This change will update the podman package to version 6.0, which
incorporates several major architectural changes and finalizes previously
announced deprecations.
Key technical changes include:
**Removal of Deprecated Code:** The code for several deprecated components
will be fully removed.
* **slirp4netns**: Replaced by Pasta, which became the default rootless
networking option in Podman 5.0.
* **CgroupsV1**: Podman 6.0 will no longer support cgroups v1; all related
code and tests will be removed.
* **BoltDB**: The BoltDB database backend, replaced by SQLite as the
default in Podman 4.8, will be removed. A deprecation notice has been added
to Podman 5.7 to warn users. Users should first upgrade to Podman 5.8 first
(will be release on all active Fedora releases) and reboot before upgrading
to Podman 6 to ensure migration. Refer to [
https://blog.podman.io/2025/12/boltdb-database-migration/ this blog post]
for details on BoltDB to SQLite migration.
* **--network-cmd-path**: This option, only used by slirp4netns, will also
be removed.
**Configuration File Rework:** A significant redesign of configuration file
handling will be implemented to address long-standing confusion between
remote clients (Windows/Mac) and the server. This will likely involve a
client/server approach to containers.conf and unifying the parsing logic
for containers.conf and storage.conf.
**Netavark Enhancements:** The Netavark network backend will remove support
for iptables favoring nftables which has been the default since Fedora 41,
consolidate the network create logic into Netavark itself, and change
internal structures to preserve the network order for containers. This will
impact only the users who manually configured iptables.
**New Conmon:** A new version of conmon is being evaluated to address
several user enhancements and improvements.
== Feedback ==
== Benefit to Fedora ==
**Modernization and Maintenance:** Aligns Fedora with the latest container
technologies by removing legacy, unmaintained, or superseded components
like slirp4netns, cgroupsv1, BoltDB. This reduces maintenance overhead,
technical debt, and attack surface.
**Improved User Experience:** The configuration file rework will resolve
significant confusion for users, especially those on Windows and macOS, by
clarifying client vs. server settings and normalizing configuration file
parsing.
**Enhanced Networking:** Finalizing the move to Netavark and removing
iptables support simplifies the networking stack and aligns with Fedora's
modern defaults (nftables).
== Scope ==
* Proposal owners: The Podman maintainers will be responsible for updating
the podman package, managing associated dependency changes (like conmon),
and ensuring the new version builds and runs correctly in Fedora 44. They
will also manage the upstream changes in netavark and common.
* Other developers: Maintainers of buildah and skopeo will likely need to
adapt to the new configuration file parsing logic, which could require a
major version bump for those tools. The podman-py maintainers will need to
verify compatibility with the new configuration system. These are
maintained by the same team of maintainers as Podman and they are on board
with this change. These changes would likely need to additionally be
coordinated with CoreOS and Image Mode developers.
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This is a major version update with several breaking changes.
* Users on systems still using CgroupsV1 will no longer be supported.
* Users who have not migrated their database from BoltDB to SQLite will
find their container state unusable after the upgrade.
* Networking configurations relying on slirp4netns will no longer function.
Users must be using Netavark and Pasta (which are the defaults in Podman 5).
* Existing containers.conf files may need to be migrated or split to
accommodate the new client/server configuration logic.
== Early Testing (Optional) ==
N/A
== How To Test ==
No special hardware is required (other than an x86_64 or aarch64 machine).
# Install the new podman 6.0 package on a fresh Fedora 44 system.
# Verify that basic container lifecycle works (run, stop, rm, ps, inspect).
# Verify that networking functions correctly using the default Netavark
(root) and Pasta (rootless) backends.
# Test upgrading from Fedora 43 with Podman 5.x. Verify that existing
SQLite databases are read correctly and containers still run.
== User Experience ==
Users will benefit from a cleaner, more maintainable codebase with removed
legacy components. The configuration file improvements will reduce
confusion for users working with remote Podman clients on Windows and
macOS. Users still relying on deprecated components (slirp4netns, cgroups
v1, BoltDB) will need to migrate to the supported alternatives before
upgrading.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
N/A (Upstream documentation will be provided with the 6.0 release)
== Release Notes ==
Podman has been updated to major version 6.0. This release finalizes the
removal of support for slirp4netns, cgroups v1, and the BoltDB database
backend. Users must be on Netavark, Pasta, cgroups v2, and SQLite,
respectively. Configuration file handling for remote clients has been
significantly refactored, which may require user migration.
Wiki: https://fedoraproject.org/wiki/Changes/LLVM-22
Discussion Thread: https://discussion.fedoraproject.org/t/177293
**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 ==
Update all llvm sub-projects in Fedora Linux to version 22.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: tstellar(a)redhat.com
== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 22. There will
be a soname version change for the llvm libraries, and an llvm21 compat
package added to ensure that packages that currently depend on clang and
llvm version 21 libraries will continue to work.
Other notable changes:
***flang merged into llvm** The flang RPMs are now built from the llvm SRPM.
=== Planned Schedule ===
Our plan is to push 22.1.0 into Fedora 44 during the Beta Freeze with a
Beta Freeze exception.
We are not planning to push earlier release candidates into rawhide because
the library ABI is not stabilized until the final 22.1.0 release.
==== Important Dates ====
* Jan 16: Begin building LLVM 22.1.0-rc1 in COPR.
* Jan 27: Begin building LLVM 22.1.0-rc2 in COPR.
* ***Feb 3: Fedora f44 branches created***
* Feb 10: Begin building LLVM 22.1.0-rc3 in COPR.
* ***Feb 17: Fedora f44 Beta Freeze***
* Feb 24: Begin building LLVM 22.1.0 in Rawhide and 44 side-tags.
* Feb 24 -> Mar 17: Request a Beta Freeze exception for LLVM.
* ***Mar 31: Fedora f44 Final Freeze***
== Feedback ==
== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.
== Scope ==
* Proposal owners:
** Build and test release candidates of LLVM 22 in COPR.
** Build and test final release of LLVM 22 in koji.
* Other developers:
** Fix build issues found with LLVM-22 or switch their package to use the
llvm21 compat libs. The LLVM team will not block Bodhi updates on dependent
packages that fail to build or run with LLVM-22. There should be around ~10
weeks between when -rc1 lands in COPR and the Final Freeze for package
maintainers to fix issues uncovered with the LLVM-22 update.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
== User Experience ==
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) If there are major
problems with LLVM 22, the compatibility package provide a way for other
packages to continue using LLVM 21.
* Contingency deadline: Final Freeze
* Blocks release? No
== Documentation ==
LLVM sub-projects in Fedora have been updated to version 22:
* llvm (now includes flang)
* libclc
* llvm-test-suite
== Release Notes ==
\n