Wiki:
https://fedoraproject.org/wiki/Changes/UseSystemdForManagingPerUserEnvironm…
Discussion Thread: https://discussion.fedoraproject.org/t/182885
**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 ==
Rely on `systemd`'s `systemd.environment-generator` functionality for
managing per-user environment variables (such as appending `~/local/.bin`
and `~/bin` to an user's `$PATH`) instead of individual shellrc scripts
(`~/.bashrc`, `~/.zshrc` etc).
== Owner ==
* Name: [[User:Faeizmahrus| Faeiz Mahrus]]
* Email: faeizmahrus(a)proton.me, me(a)faeizmahrus.bd
== Detailed Description ==
Currently, Fedora relies on shellrc scripts (`~/.bashrc`, `~/.zshrc` files)
for modifying an user's environment variables. <br/>
An example of such a case is appending `~/.local/bin` and `~/bin`
directories to $PATH <br/>
Such shellrc scripts have only been packaged for the `bash` and `zsh`
shells. (`rpm -ql /etc/skel/{.bashrc,.zshrc}` returns packages `bash` and
`zsh`) <br/>
However, Fedora Linux also offers several alternative shells such as
`fish`, nushell (`nu`), `xonsh`, `dash` etc, for which shellrc scripts have
not been packaged. <br/>
This leads to a situation where an user might change their login shell and
be unable to directly launch scripts and programs stored in `~/.local/bin`
and `~/bin`
`systemd` provides a mechanism for applying environment variables to all
user processes via `systemd.environment-generator`. <br/>
Creating simple drop-in file(s) in the `/etc/skel/.config/environment.d/`
directory is a simpler and much cleaner way for both managing environment
variables for an user and for mitigating the `$PATH` environment variable
propagation issue for alternative shells. <br/>
Although out of scope for this specific proposal, the broader goal will be
to ultimately move as much cruft possible out of shellrc scripts scattered
across the filesystem at different places and `/etc/profile` into
`environment-generators`
== Feedback ==
Will be updated later.
== Benefit to Fedora ==
This change simplifies per-user environment variable propagation and makes
environment variable changes independant of an user's default shell.
== Scope ==
* Proposal owners:
Modify the `/etc/skel/.*rc` files located in the `bash` and `zsh` packages,
modifying them to either remove any environment variable modification parts
or splitting those parts into separate subpackages.
Search for any other packages that also modify environemt variables by
shellrc scripts.
* Other developers:
Coordinate with the respective package maintainers.
* Release engineering: [
https://forge.fedoraproject.org/releng/tickets/issues #Releng issue number]
Most likely no.
* 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 ==
None.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
Will be added later.
== User Experience ==
Cleaner shellrc files will ease management for users.
== Dependencies ==
Will be updated later.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
Revert the change. (not a System Wide Change)
* Contingency deadline: Beta freeze (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), Yes/No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
\nMoved per-user environment variable handling to
`systemd.environment-generator`\n
Wiki: https://fedoraproject.org/wiki/Changes/Update_xmlsec_to_1_3
Discussion Thread: https://discussion.fedoraproject.org/t/182444
**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 change brings xmlsec 1.3.x into Fedora. Version 1.3 is not backward
compatible with 1.2.
== Owner ==
* Name: [[User:thalman| Tomas Halman]]
* Email: thalman(a)redhat.com
== Detailed Description ==
Update of xmlsec to 1.3.9 brings new and actively developed version into
the Fedora. This version changes some interfaces and it is not backward
compatible.
This change requires rebuild and/or update of depending packages:
* aqbanking
* lasso
* libdigidocpp
* libpskc
* libreoffice
* mod_auth_mellon
* nordugrid-arc
* open-vm-tools
* openscap
== Feedback ==
== Benefit to Fedora ==
Version 1.3 is actively developed and receives new features like new
cyphers. Old version is just maintained.
== Scope ==
* Proposal owners:
* Other developers:
* Release engineering: [
https://forge.fedoraproject.org/releng/tickets/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 ==
No manual configuration changes are needed or expected.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? No
== How To Test ==
* No special hardware needed
* Packages will be tested by their owners
* We will use a copr repository for building and testing depended packages
* All applications work the same as before change.
== User Experience ==
Users should obtain new cypher suites, but this is not typically noticed by
users. But application may move defaults to more modern and safe ciphers.
== Dependencies ==
Here is list of packages depending on xmlsec1
* aqbanking
* lasso
* libdigidocpp
* libpskc
* libreoffice-core
* mod_auth_mellon
* nordugrid-arc
* open-vm-tools
* openscap
== Contingency Plan ==
* Contingency mechanism: If we found a blocker in depended component, we
will create new package (xmlsec12) with the 1.2 version and component not
possible to update will compile against old version for now. That might be
a bit more work and we might postpone the change for next version of Fedora.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), Yes/No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
\n
Wiki:
https://fedoraproject.org/wiki/Changes/IPv6-Mostly_Support_In_NetworkManager
Discussion Thread: https://discussion.fedoraproject.org/t/182443
**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 ==
Enable by default support for IPv6-mostly networks in NetworkManager.
== Owner ==
* Name: [[User:bengal| Beniamino Galvani]], [[User:Sfaye| Stanislas Faye]]
* Email: <bgalvani(a)redhat.com>, <sfaye(a)redhat.com>
== Detailed Description ==
Dual-stack networks, where IPv4 and IPv6 run in parallel, are currently the
most common transition mechanism to IPv6. However, they don't solve the
problem of the IPv4 address exhaustion; furthermore, the availability of
IPv4 on every host masks problems with IPv6 and provides very little
incentive to fully move to IPv6.
A new architecture is emerging as an alternative to dual stack:
IPv6-mostly. RFC 8925 describes an IPv6-mostly network as:
*A network that provides NAT64 (possibly with DNS64) service as well as
IPv4 connectivity and allows the coexistence of IPv6-only, dual-stack, and
IPv4-only hosts on the same segment. Such a deployment scenario allows
operators to incrementally turn off IPv4 on end hosts, while still
providing IPv4 to devices that require IPv4 to operate. But
IPv6-only-capable devices need not be assigned IPv4 addresses.*
The key components of a IPv6-mostly network are:
* **DHCPv4 option 108 (IPv6-only preferred - RFC 8925)**. An IPv6-mostly
network advertises this option. If the client supports and receives this
option, it will go IPv6-only, disabling IPv4 configuration. This option
serves as the signal for supporting clients to transition to IPv6-only mode.
* **464XLAT (RFC 6877)**. This architecture provides IPv4 connectivity to
hosts in a IPv6-only network. It works by implementing a double
translation: on the client a CLAT (Customer-side translator) converts IPv4
packets to IPv6; on the network side a PLAT (Provider-side translator) uses
NAT64 to convert those packets back to IPv4 before they are delivered to
the v4 Internet.
* **PREF64 option (RFC8781)**. The network includes this option in Router
Advertisement messages to communicate the prefix used by the NAT64 gateway
available in the network.
With this change, NetworkManager will enable automatically the
handling of option 108, CLAT and PREF64. As a result, when operating
in a IPv6-mostly network, it will behave as a IPv6-only host without
getting a DHCPv4 lease. Applications that need to reach the v4 Internet
will still continue to work because of DNS64 and/or NAT64.
On networks not advertising option 108 NetworkManager will continue to
configure native IPv4 addressing.
== Feedback ==
N/A
== Benefit to Fedora ==
By enabling option 108 and CLAT, Fedora's networking stack will be
compliant with modern Internet standards. This puts Fedora on par with
other major operating systems that already support and enable these
technologies such as Android, macOS and (recently) Windows.
Option 108 allows network administrators to conserve scarce IPv4
address pools, without the need of creating separate segments for IPv4
and IPv6 clients.
CLAT ensures that applications relying on AF_INET sockets or hardcoded
IPv4 literals continue to function transparently even when the host
only has IPv6 connectivity.
== Scope ==
* Proposal owners: Set the default value for option `ipv4.clat` to `auto`,
either at build time or via a configuration snippet in /usr. This enables
the automatism that starts CLAT based on PREF64, and also enables the
handling of option 108.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
There is no manual configuration or data migration needed. The change will
be transparent to users.
== Early Testing (Optional) ==
N/A
== How To Test ==
This change can only be tested on an IPv6-mostly network with DHCPv4 option
108, NAT64 and PREF64. Such a network can be set up using equipment that
supports those technologies, but also by configuring a Linux router with
radvd, dhcpd, and a NAT64 implementation such as jool or tayga.
This feature is tested as part of the [
https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/blob/main…
NetworkManager-ci] project using network namespaces with radvd, dhcpd and
tayga.
== User Experience ==
When connected to a IPv6-mostly network (with option 108, NAT64 and
PREF64), the host will get a public IPv6 and a private CLAT IPv4 address in
the 192.0.0.0-192.0.0.7 range.
Native IPv6 connectivity will be used for most of the traffic. If there are
applications connecting by name to an IPv4-only server, the DNS64 server
will return a synthetic AAAA entry that directs the communication to the
NAT64 gateway. The CLAT instance started by NetworkManager will be used to
convert the remaining IPv4 traffic to IPv6, for example traffic generated
by applications using IPv4 literals.
All of this will be transparent to the user.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Revert the configuration and disable CLAT and
option 108
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
The configuration options involved are described in the upstream
documentation:
* ipv4.clat:
https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/…
* ipv4.dhcp-ipv6-only-preferred:
https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/…
== Release Notes ==
This change should be mentioned in the Releases Notes.
Wiki: https://fedoraproject.org/wiki/Changes/DrmPanicFrontend
Discussion Thread: https://discussion.fedoraproject.org/t/182239
**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 ==
Deploy a web-based frontend application for Fedora's DRM Panic feature that
provides users with an accessible, user-friendly interface for
understanding kernel panic information and facilitating bug reports through
Bugzilla integration.
== Owner ==
* Name: [[User:Jexposit| José Expósito]]
* Email: jexposit(a)redhat.com
== Detailed Description ==
=== Background ===
With Fedora 42, the [https://fedoraproject.org/wiki/Changes/EnableDrmPanic
DRM Panic] feature was enabled by default, allowing the Linux kernel to
display panic screens with QR codes that encode error traces when kernel
panics occur. While this feature successfully captures technical
information, the raw kernel traces encoded in QR codes are largely
incomprehensible to average users and provide no guidance on next steps.
=== Solution ===
The DRM Panic Frontend is a web application that bridges the gap between
technical kernel panic data and user-friendly presentation. When users scan
a QR code from a DRM Panic screen with their mobile device, they are
directed to a Fedora-hosted web interface that:
# **Provides contextual information** - Explains what happened in
accessible language
# **Decodes and displays panic information** - Presents kernel version,
architecture, and error traces in a structured, readable format
# **Facilitates bug reporting** - Offers streamlined integration with
Fedora Bugzilla, pre-filling bug reports with relevant system information
and error traces
# **Improves user experience** - Uses PatternFly design patterns to provide
interface consistent with Fedora's design language
=== Technical Details ===
**Technology Stack:**
* Built with React 19 for dynamic user interfaces
* PatternFly 6 for consistent Fedora design language
* Webpack-based build system
* Static HTML/CSS/JavaScript output (no server-side processing required)
**Deployment Requirements:**
* Static web hosting on Fedora infrastructure
* Updating the kernel to point to the new endpoint
* No database or server-side runtime required
**Configuration:**
The application requires minimal configuration [
https://github.com/JoseExposito/drm-panic-frontend/blob/main/.env.example
via .env file]:
* <code>WEBPACK_BUGZILLA_URL</code> - URL of the Fedora Bugzilla instance
(for example, https://bugzilla.redhat.com)
<code>npm run build:production</code> generates a website pointing to the
configured Bugzilla URL.
**Information Flow:**
# DRM Panic generates QR code containing compressed panic data (URL with
query parameters)
# User scans QR code with mobile device
# Browser loads web application from Fedora infrastructure
# JavaScript decodes URL parameters and decompresses trace data
# Application presents information and provides bug reporting workflow
# No information leaves the user mobile device. The trace is encoded in the
URL hash, which is not sent to the server
**Demo:**
The following link displays an screenshot of a DRM Panic. Scan the QR code
with your phone to test the application:
https://jexposit.fedorapeople.org/drm-panic-demo.png
=== Current Implementation Status ===
The DRM Panic Frontend is fully functional and includes:
* Complete panic information display with system details (kernel version,
architecture)
* Modal dialogs for detailed error traces and bug reporting instructions
* Bugzilla integration with pre-filled bug report URLs
* Responsive design for mobile and desktop viewing
* Minimal test coverage with Jest
== Feedback ==
Initial community feedback from the devel(a)lists.fedoraproject.org
announcement has been positive, with recognition that improving the user
experience for kernel panics is valuable.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
== Benefit to Fedora ==
# **Improved User Experience** - Transforms a technical, intimidating error
screen into an approachable interface that guides users through
understanding and reporting issues
# **Increased Bug Reports** - By lowering the barrier to bug reporting,
Fedora and upstream developers will receive more actionable panic reports,
leading to better kernel stability
# **Accessibility** - Makes kernel debugging information accessible to
non-technical users who can now effectively report issues even without
understanding kernel internals
== Scope ==
* Proposal owners:
** Maintain the DRM Panic Frontend application
** Respond to bug reports and feature requests
** Keep dependencies up to date
* Other developers:
** **Fedora Infrastructure team** - Provide hosting for the static web
application, configure domains, and set up deployment pipeline
** **Fedora Design team** (optional) - Review and suggest improvements to
the user interface
** **Kernel team** - Coordinate on QR code URL format and ensure DRM Panic
QR codes point to the hosted frontend
* 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)
* Alignment with the Fedora Strategy:
This change aligns with the Fedora Strategy by improving user experience
and making Fedora more accessible to non-technical users while also
improving the quality of bug reports that help make Fedora more stable and
reliable.
== Upgrade/compatibility impact ==
This change has no impact on existing systems. The DRM Panic Frontend is an
optional, additive feature that enhances the existing DRM Panic
functionality without modifying kernel behavior.
== Early Testing (Optional) ==
N/A
== How To Test ==
=== Testing the Web Application ===
**Local Development Testing:**
<pre>
git clone https://github.com/JoseExposito/drm-panic-frontend.git
cd drm-panic-frontend
npm install
cp .env.example .env
npm start
</pre>
**Access Test URL:** Navigate to the example URL provided in HACKING.md
which simulates a DRM Panic QR code
**Verify Functionality:**
* Panic information displays correctly (kernel version, architecture)
* Error trace is readable and properly formatted
* "Report Issue" modal provides clear instructions
* Bugzilla link is correctly formatted with pre-filled fields
* Copy-to-clipboard functionality works
* Responsive design works on mobile devices
**Production Build Testing:**
<pre>
npm run build:production
</pre>
Verify the <code>dist/</code> directory contains optimized static files
ready for deployment
== User Experience ==
=== Before This Change ===
When a user experiences a kernel panic with DRM Panic enabled:
# Screen displays a kernel panic message with a QR code
# User scans QR code
# User sees technical information with no context
# No clear path to report the issue or get help
=== After This Change ===
When a user experiences a kernel panic:
# Screen displays a kernel panic message with a QR code
# User scans QR code
# Browser loads a Fedora-branded web page
# User sees:
#* Clear explanation of what happened
#* System information in readable format (kernel version, architecture)
#* Structured error trace display
#* Step-by-step bug reporting instructions
== Dependencies ==
=== Build Dependencies ===
* Node.js 18+ (for development and building)
* npm or yarn package manager
=== Runtime Dependencies ===
* Modern web browser with JavaScript enabled
* No server-side runtime dependencies (static files only)
=== Integration Dependencies ===
* DRM Panic kernel feature (enabled in Fedora 42+)
* QR code configuration pointing to the hosted frontend URL
== Contingency Plan ==
* Contingency mechanism: If the DRM Panic Frontend cannot be deployed for
Fedora 45, DRM Panic continues to function with raw QR code data URLs.
Users experience the pre-existing workflow (direct URL with encoded data).
No regression or loss of functionality. Deployment can be attempted in a
future release.
* Contingency deadline: Beta freeze. If hosting infrastructure is not ready
by Beta, the deployment can be postponed without impact.
* Blocks release? No. This is a web application deployment separate from
the Fedora release compose process.
== Documentation ==
=== Application Documentation ===
* [https://github.com/JoseExposito/drm-panic-frontend GitHub Repository]
* HACKING.md - Development and testing guide
=== Related Documentation ===
* [https://fedoraproject.org/wiki/Changes/EnableDrmPanic Fedora Change:
Enable DRM Panic]
* [https://docs.kernel.org/gpu/drm-kms-helpers.html#drm-panic-infrastructure
Kernel DRM Panic Documentation]
* [https://www.phoronix.com/news/DRM-Panic-Nicer-Fedora-Idea Phoronix
Coverage]
== Release Notes ==
Fedora 45 introduces the DRM Panic Frontend, a user-friendly web interface
for kernel panic reporting. When you scan a QR code from a kernel panic
screen, you'll be directed to a helpful Fedora web page that explains what
happened and guides you through reporting the issue to help improve Fedora.
This makes it easier for everyone to contribute to Fedora's stability.