F41 Change Proposal: Enabling composefs by default for Atomic
Desktops, CoreOS and IoT (Self-Contained)
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/ComposefsAtomicCoreOSIoT
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-enabling-compo...
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 want to enable composefs by default for Fedora Atomic Desktops,
Fedora CoreOS and Fedora IoT. This makes the root mount of the system
(`/`) a truly read only filesystem, increasing the system integrity
and robustness. This is the first step toward a full ''at runtime''
verification of filesystem integrity.
This change will be enabled only for the Bootable Container images of
Fedora Atomic Desktops and not the classic ostree ones.
== Owner ==
* [[User:jbtrystram| Jean-Baptiste Trystram]], jbtrystram(a)redhat.com
* [[User:Siosm| Timothée Ravier]], siosm(a)fedoraproject.org
* [[User: pwhalen| Paul Whalen]], pwhalen(a)fedoraproject.org
== Detailed Description ==
Ostree based systems currently have `/usr` mounted as read-only and
managed by ostree/rpm-ostree. The integrity of the content of `/usr`
is only validated by ostree/rpm-ostree during updates and deployment
operations, but not at "runtime". If a file is corrupted on disk
(maliciously or not), it will only be detected if a full check is
performed using `ostree fsck`.
On those systems, the runtime root (`/`) of the system is currently
mounted as read-write but with the `immutable` bit set (`chattr +i /`)
to prevent accidental modifications.
[https://github.com/containers/composefs composefs] is a new project
that combines several existing filesystems (overlayfs, EROFS) to
provide a very flexible mechanism to support read-only mountable
filesystem trees, stacking on top of an underlying "lower" Linux
filesystem.
Using composefs, it will no longer be possible to mutate the
underlaying file content that is part of the system (`/usr`) nor the
layout of the root directory. It will result in I/O errors at the
kernel level.
The content is `/etc` and `/var` will remain writtable as it is today.
This change is part of the
[https://fedoraproject.org/wiki/Initiatives/Fedora_bootc Fedora
Bootable Containers Initiative]. The `bootc` container images already
enable composefs thus this change is to align existing variants to the
new Bootable Containers defaults.
It is tracked in:
* Fedora Atomic Desktops: https://gitlab.com/fedora/ostree/sig/-/issues/35
* Fedora CoreOS: https://github.com/coreos/fedora-coreos-tracker/issues/1718
* Fedora IoT: https://github.com/fedora-iot/iot-distro/issues/52
This is the first step toward a full boot chain integrity, that will
requiring signing the composefs metadata during composes and using
Unified Kernel Images (UKI). See:
https://gitlab.com/fedora/bootc/tracker/-/issues/14
As podman also use composefs to store containers layers, this enable
deduplication of files between containers and host. This will result
in less disk usage but also faster container startup and less memory
use. See https://github.com/containers/composefs/issues/125
== Feedback ==
Nothing specific so far.
We have the following "known issues":
* Conflicts with `ostree-grub2`, which impacts Dual Boot support:
** https://github.com/ostreedev/ostree/issues/3198
** We will remove ostree-grub2 from Fedora Atomic Desktops bootable
container images
** Related to: https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd
** We can do this ''now'' for the container images as they are not
officially released for Fedora, and generally ''newer'', so it's more
likely that the bootloader on those systems are already BLS capable.
** We can not do this for "classic ostree" Atomic Desktops yet as we
need a transition period with bootupd enabled by default before
removing ostree-grub2.
** However with the recent Secure Boot issue
(https://github.com/fedora-silverblue/issue-tracker/issues/543)
forcing everybody to manually update their bootloader, we might be
able to shorten this transition period.
** See for Dual Boot:
https://github.com/fedora-silverblue/issue-tracker/issues/530
* No longer possible to create root level direcotries (`chattr -i` workaround):
** Requires derivation, thus the container flow
** https://github.com/coreos/rpm-ostree/issues/337
** Alternative: https://github.com/ostreedev/ostree/pull/3114
** Might impact Podman Desktop for Fedora CoreOS. They will likely
disable it until a solution is found.
* Issues with kdump:
** https://bugzilla.redhat.com/show_bug.cgi?id=2284097
** https://gitlab.com/fedora/bootc/tracker/-/issues/19
== Benefit to Fedora ==
This will increase the robustness of image based Fedora systems and
prepare them for future increased security guarantees.
This will align the existing image based variants of Fedora (Atomic
Desktops, CoreOS, IoT) to the work that is done as part of the
Bootable Containers Initiative.
== Scope ==
* Proposal owners:
** Enable composefs in Atomic Desktops (bootable containers only)
** Enable composefs in CoreOS
** Enable composefs in IoT
* Other developers:
** Applications doing disk-full checks on `/` will have to be updated
to look at other places as `/` will be small (a few MB) and full (100%
used).
* Release engineering: N/A (not needed for this 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 2028:
** Aligns with the goal: "Immutable variants are the majority of
Fedora Linux in use"
== Upgrade/compatibility impact ==
To be fleshed out
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
* Make sure that you do not rely on Dual Boot support
* Make sure that you bootloader is recent enough to support BLS configs
** If you don't know, update it using the instructions from
https://github.com/fedora-silverblue/issue-tracker/issues/543#issuecommen...
first
* Remove `ostree-grub2` from the upcoming deployment: `rpm-ostree
override remove ostree-grub2`
* Enable composefs: `sudo ostree config set ex-integrity.composefs yes`
* Update your system to a new version: `rpm-ostree update`
** Or do a manual (re)deploy of the current version: `sudo ostree
admin deploy fedora/39/x86_64/silverblue`
* Reboot into the new deployment
== User Experience ==
The main visible change will be that the root filesystem (`/`) is now
small and full (a few MB, 100% used). The real root is mounted in
`/sysroot` and most of the data is stored in `/var`.
== Dependencies ==
For the Atomic Desktops, this change depends on:
* Bootupd support:
** https://gitlab.com/fedora/ostree/sig/-/issues/1
** https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd
CoreOS and IoT already do not depends on `ostree-grub2`.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Undo the
change. It's a single line change in a configuration file.
* Contingency deadline: Beta Freeze / Release Freeze
* Blocks release? No
== Documentation ==
To be written.
== Release Notes ==
To be written once the change is accepted.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
19 hours, 18 minutes
F41 Change Proposal: acpica-tools: Deprecate Big Endian Support (System-Wide)
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/Acpica-tools_Deprecate-Big_Endian_...
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-acpica-tools-d...
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 ==
The acpica-tools package has supported big-endian architectures for
several years, but it has few uses. For Fedora 41, remove all of the
patches for big-endian support and remove s390x from the list of
supported architectures.
== Owner ==
* Name: [[User:ahs3| Al Stone]]
* Email: ahs3(a)fedoraproject.org
== Detailed Description ==
For many years, the acpica-tools package has supported the big-endian
s390x architecture, despite ACPI being a little-endian ''only''
standard. This made sense originally, as some s390x packages had to
have mechanisms for dealing with ACPI tables, and there were several
packages with build dependencies since they created ACPI tables.
Neither of these is really true any longer.
What's more, big-endian support has always had a fairly high cost. In
the first place, upstream wants nothing to do with big-endian support;
it is completely irrelevant, despite several attempts to get them to
accept it. Secondly, every release of the upstream source requires
significant backporting of the big-endian patches, creating new
patches to support new features of, or changes in, the ACPI standard,
and then testing and debugging the results. In the last ten years,
the least amount of time to do this was two full days; the longest it
has taken has been two full weeks. One has to plan for at least a
week. And finally, the need for big-endian has diminished
considerably. At one point, some virtualization functions required
these tools so that there was no virtualization on s390x without them;
again, this is no longer true.
The actual changes to the acpica-tools package will actually simplify
maintenance significantly. The change itself is fairly
straightforward: remove the big-endian patches, and add s390x to
ExcludeArch.
== Feedback ==
This proposal was actually prompted by a recent PR on acpica-tools
requesting a way to ignore the big-endian patches:
[https://src.fedoraproject.org/rpms/acpica-tools/pull-request/5].
Upstream has ''never'' accepted big-endian support. Should this
proposal be accepted, it would be one way of meeting the request
behind the PR, however. Some discussion has occurred with s390x
supporters (both recently, and in the past) that would indicate this
would be something that is not ideal (no one likes to lose packages),
but doesn't really create problems. Part of the reason for making
this proposal is to be sure I'm not missing something.
== Benefit to Fedora ==
The primary benefit to this proposal is that it simplifies maintenance
significantly. Of the 69 patches for the package, 49 can simply be
removed. The longest and most difficult builds will not be needed;
the s390x testing that always takes most of the package update time
will no longer be needed either. This will make it easier to ensure
that acpica-tools more closely matches upstream than has been possible
recently, producing a higher quality package quicker.
== Scope ==
* Proposal owners: The actual changes to the acpica-tools package will
be to remove the big-endian patches, and add s390x to ExcludeArch.
This is quite straightforward.
* Other developers: Based on an initial investigation, it appears that
most changes will be to simply exclude s390x. So far, the only
packages that seem to be affected are hw-probe, vim-syntastic-asl, and
edk2. There appears to be some use outside of Fedora
(xorg-x11-drv-nvidia, their proprietary drivers, for some reason).
* Release engineering: This change only affects the specific packages
mentioned so far.
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
Only s390x systems would notice a change in that this package would no
longer be available.
== How To Test ==
There is a test suite included in the acpica-tools package that is
always run as part of the %check step in the spec file.
No new testing should be required.
== User Experience ==
Only s390x systems would notice a change in that this package would no
longer be available.
== Dependencies ==
The packages hw-probe, vim-syntastic-asl, and edk2 depend on
acpica-tools. However, to make the changes to acpica-tools, there are
no other dependencies.
== Contingency Plan ==
* Contingency mechanism: do nothing; the existing f40 package can
continue to be used.
* Contingency deadline: beta freeze
* Blocks release? No
== Documentation ==
These changes actually put the Fedora version of the package back into
a state where it matches upstream more closely.
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
19 hours, 24 minutes
F41 Change Proposal: Nvidia Driver Installation with Secure Boot
Support (self-contained)
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/NvidiaInstallationWithSecureboot
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-nvidia-driver-...
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 ==
Nvidia Drivers have been removed from GNOME Software because it didn't
support Secure Boot which is increasingly often enabled. This change
brings the option back with Secure Boot supported.
== Owner ==
* Name: [[User:eischmann|Jiří Eischmann]]
* Name: Milan Crha
* Email: eischmann(a)redhat.com
* Email: mcrha(a)redhat.com
== Detailed Description ==
The goal is this change is to provide an easy way to install Nvidia
drivers in Fedora Workstation. It was removed from GNOME Software
because the original mechanism didn't support Secure Boot. When users
installed the drivers with Secure Boot enabled, they could not boot
the OS.
What we're doing this time is using mokutil to create a key for the
user to self-sign the drivers. When installing the drivers, the user
is asked to provide a password for the key. On the next reboot the
user is presented with the mokutil interface to enroll the key.
See the [https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/2034
upstream merge request] for more details and screenshots.
== Feedback ==
== Benefit to Fedora ==
The Nvidia drivers are necessary not only for gaming, but especially
for CUDA and AI/LLM workloads. The Nvidia drivers can't be part of
Fedora because of their license, but Fedora should offer an easy
installation of them to stay relevant in the respective fields.
== Scope ==
* Proposal Owners: The feature will be implemented in GNOME Software
47 and will be shipped in the gnome-software package in Fedora Linux
41.
* Other Developers: No work required from other Fedora developers. The
only requirement outside of the scope of the proposal owners is to
reintroduce AppStream metadata into the Nvidia driver repo on
RPMFusion.org.
* Release Engineering:
* Policies and Guidelines:
* Trademark approval:
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
No impact is expected.
== How To Test ==
1. Open GNOME Software.<br>
2. Search for "nvidia".<br>
3. Choose the Nvidia driver, click Install and follow the prompts.<br>
4. Reboot and enroll the self-signing key in the mokutil tool
following <<the documentation will be added>><br>
5. The OS should boot up with the Nvidia driver enabled.<br>
== User Experience ==
This change aims to improve user experience of installing the
proprietary Nvidia driver.
== Contingency Plan ==
If the feature is not implemented on time for Fedora Linux 41, we can
simply remove AppStream metadata from the Nvidia driver repo and the
driver will not show up in GNOME Software like in Fedora Linux 40.
== Documentation ==
The GNOME Software part is intuitive and doesn't require
documentation. The mokutil part is less intuitive and will be
documented in the Fedora Workstation section on
docs.fedoraproject.org. The docs will be published when the feature
lands in Fedora Linux 41.
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
1 week
F41 Change Proposl: Libvirt Virtual Network NFTables (self-contained)
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/LibvirtVirtualNetworkNFTables
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposl-libvirt-virtual...
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 ==
The default firewall backend for the default libvirt virtual network
(the virbr0 bridge device), will change from 'iptables' to 'nftables'.
== Owner ==
* Name: [[User:berrange| Daniel Berrange]]
* Email: berrange(a)redhat.com
== Detailed Description ==
A default installation of libvirt will create an isolated bridge
device (virbr0), to which guest virtual machines can have their NIC
connected. Firewall rules are used to provide NAT based connectivity
on this bridge device, as well as allow access to the DNS/DHCP
services provided by the dnsmasq it launches on the host.
Historically libvirt has always used the iptables tools, which first
talked to the iptables kernel modules, but in recent Fedora uses the
nftables kernel modules. When Fedora switched Firewalld to use
nftables for its own firewall rules, libvirt kept using its iptables
userspace backend, which then indirectly created kernel nftables
rules. To work correctly, libvirt added the ability to associate its
bridge devices with a 'libvirt' zone in firewall to ensure guest->host
DHCP/DNS/SSH traffic was not blocked by firewall.
With this change, libvirt will now prefer to directly use the nftables
userspace tools to create its firewall rules, where they are
installed:
* nftables only installed => libvirt uses its nftables backend
* iptables only intsalled => libvirt uses its iptables backend
* nftables and iptables installed => libvirt uses its nftables backend
This default behaviour can be overridden to force a specific backend
by editting settings in /etc/libvirt/network.conf.
Note that this change only applies to libvirt's virtual network
functionality. Libvirt's nwfilter (network filter) functionality is
still exclusively using iptables/ebtables. This will be switched to
nftables in a future Fedora release, timeframe to be determined.
== Feedback ==
TBD
== Benefit to Fedora ==
* Libvirt will be using the same recommended modern nftables userspace
as firewalld instead of the legacy iptables compatibility tools which
secretly talk to nftables behind the scenes.
* All the libvirt nftables rules will be self-contained in a dedicated
'libvirt_network' nftables table, reducing the scope for other
applications accidentally changing/removing them.
* Improved performance scalability since libvirt's nftables rules are
written to use an interface ID match which is a simple lookup, while
traditional string based interface name matches in iptables require
multiple string comparisons.
== Scope ==
* Proposal owners: Change the libvirt RPM spec to set the 'nftables'
backend as the preferred default
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
Existing hosts with libvirt deployed will be using iptables for their
firewall rules. When the Fedora upgrade brings in the new libvirt, it
will detect the switch to nftables and attempt to remove the
historically created iptables rules, and create new nftables rules
providing equivalent functionality.
A number of iptables chains will remain present after an upgrade
* Chain LIBVIRT_FWI
* Chain LIBVIRT_FWO
* Chain LIBVIRT_FWX
* Chain LIBVIRT_INP
* Chain LIBVIRT_OUT
These chains should not contain rules and thus be harmless. They will
go away permanently the next time the host is rebooted, or can be
deleted manually if desired.
=== Reverting to iptables for compatibility ===
If an incompatibility is discovered between libvirt's nftables backend
and some other use case, it is possible to tell libvirt to revert to
its iptables backend.
* Edit /etc/libvirt/network.conf and set 'firewall_backend = "iptables"'
* systemctl restart virtnetworkd
Libvirt should then automatically delete its nftables rules and create
equivalent iptables rules as present on previous Fedora releases.
Alternatively, if the 'nftables' userspace tools are not installed at
all, libvirt will attempt to use the 'iptables' userspace tools
instead, if present.
=== Known issue: docker ===
The Docker iptables integration force changes the iptables FORWARD
chain policy from ACCEPT to DENY. This makes '''Docker incompatible
with any application that is using nftables''' to try to allow
forwarding:
https://docs.docker.com/network/packet-filtering-firewalls/#docker-on-a-r...
When libvirt uses its iptables backend, its FORWARD rules will end up
in the same table as docker's, and so override the DENY policy docker
had created. When libvirt uses its nftables backend, its FORWARD rules
end up in a separate table from dockers'. Since nftables requires a
packet to be allowed by *all* top level tables, docker's DENY rules
will block the libvirt traffic.
The possible workarounds are:
* Reconfigure libvirt to use iptables when compatibility with docker is required
* Use podman instead of docker, since podman does not create
problematic iptables rules
* TBD: whether libvirt can do something automagic to workaround
docker's DENY policy
=== Known issue: non-firewalld firewall mgmt tools ===
Libvirt requires the ability to mark traffic from the guest to the
host, for DHCP and DNS as permitted.
When using iptables kernel modules, libvirt could achieve this by
inserting some rules in the INPUT chain to allow DHCP/DNS.
When using nftables kernel modules, there are an arbitrary number of
application defined top level tables with unknown names. All top level
tables must allow a packet in order for it to pass. libvirt must not
touch tables created by other applications, thus it is no longer
practical to seemlessly allow DHCP & DNS when nftables userspace is
used by any component on the system.
To address this, when Fedora 32 switched firewall to its nftables
backend, libvirt gained ability to install a firewalld zone files to
allow guest traffic. Libvirt does not have equivalent integration for
any other nftables based firewall mgmt tool, but other tools using
iptables remained compatible as long as libvirt also kept using
iptables.
With libvirt changing to prefer its nftables backend, libvirt is will
be incompatible with any other non-firewalld firewall management
tools.
The compatibility matrix is as follows
# Kernel module: iptables, firewall mgmt userspace: iptables, libvirt
backend: iptables => WORKS for all firewall mgmt tools
# Kernel module: nftables, firewall mgmt userspace: iptables, libvirt
backend: iptables => WORKS for all firewall mgmt tools
# Kernel module: nftables, firewall mgmt userspace: iptables, libvirt
backend: nftables => WORKS for firewalld, other tools require
workaround
# Kernel module: nftables, firewall mgmt userspace: nftables, libvirt
backend: iptables => WORKS for firewalld, other tools require
workaround
# Kernel module: nftables, firewall mgmt userspace: nftables, libvirt
backend: nftables => WORKS for firewalld, other tools require
workaround
The two main workaround options:
* Change /etc/libvirt/network.conf 'firewall_backend' setting to 'iptables'
* Manually add rules to the firewall mgmt tool to allow DHCP, DNS &
SSH from guests.
The long term answer is to enhance libvirt upstream to natively learn
about integration for more firewall mgmt tools than just firewalld. eg
UFW: https://gitlab.com/libvirt/libvirt/-/issues/644
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
* Perform a default libvirt KVM install 'dnf groupinstall @Virtualization'
* Create a KVM guest using virt-install, virt-manager, or cockpit, and
configure it to use the 'default' virtual network
* Boot the KVM guest
* Login to the KVM guest graphical console, and attempt to connect to
the internet. eg curl https://google.com
* Configure the KVM guest to enable SSH (if not already allowed & started)
* Attempt to SSH to the guest from the host
== User Experience ==
* Libvirt firewall rules will no longer be present when running 'iptables -L'
* A new 'libvirt_network' table will be present when running 'nft list ruleset'
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Libvirt maintainers to change the
libvirt.spec to set 'prefer_nftables' variable to '0' for Fedora 41
* Contingency deadline: Final freeze
* Blocks release? No
== Documentation ==
General libvirt network documentation at https://libvirt.org/formatnetwork.html
== Release Notes ==
The libvirt virtual network has been changed to prefer use of the
nftables firewall backend instead of iptables.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
1 week
F41 Change Proposal: Confidential Virtualization Host with AMD
SEV-SNP (self-contained)
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/ConfidentialVirtHostAMDSEVSNP
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-confidential-v...
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 enables Fedora virtualization hosts to launch confidential
virtual machines using AMD's SEV-SNP technology. Confidential
virtualization prevents admins with root shell access, or a
compromised host software stack, from accessing memory of any running
guest. SEV-SNP is an evolution of previously provided SEV and SEV-ES
technologies providing stronger protection and unlocking new features
such as a secure virtual TPM.
== Owner ==
* Name: [[User:berrange| Daniel P. Berrangé]]
* Email: berrange(a)redhat.com
== Detailed Description ==
Fedora has provided support for launching confidential virtual
machines using KVM on x86_64 hosts for several years, using the SEV
and SEV-ES technologies available from AMD CPUs. These technologies
have a number of design limitations, however, that make them less
secure than is desired, and prevent exposure of desirable features
such as secure TPMs. The SEV-SNP technology is a significant design
enhancement and architectural change to addresses the key gaps,
increasing security and unlocking more powerful use cases for
confidential virtual machines.
With SEV/SEV-ES, attestation of the launched VM has to be initiated
from the host, which means for a guest owner to attest their VM, they
need to rely on API services exposed by the virtualization management
stack which will vary across applications. With SEV-SNP, guest owners
can initiate attestation from within guest context, providing a
standard mechanism across any virtualization environment running
SEV-SNP, avoiding a reliance on any host platform tools/APIs.
The SEV-SNP technology also unlocks the ability to have a paravisor
run in guest context, which is a miniature OS that runs at a higher
privilege level (VMPL 0) than the guest firmware / OS (VMPL 3). The
paravisor, specifically the [https://github.com/coconut-svsm/svsm
Coconut SVSM] implementation, is able to expose trusted services to
the guest firmware and OS, which also remain inaccessible to the host.
This makes it possible to provide a secure virtual TPM for
confidential guests, thus allowing guest OS software to be better
secured than is the case with normal virtual TPMs running in host OS
context.
== Feedback ==
* TBD
== Benefit to Fedora ==
Confidential guests running under a Fedora SEV-SNP enabled KVM host
will be able to:
* Self initiate an VM attestation to prove integrity of their running
guest machine. This guarantees their guest is running on AMD hardware
with SEV-SNP setup in a given configuration, running a particular
build for EDK2 firmware, providing data confidentiality even if the
host is compromised or malicious.
* Measure all aspects of the guest machine boot process into PCRs in a
securely hosted virtual TPM
* Protect against various known weaknesses of the traditional SEV and
SEV-ES technologies
== Scope ==
=== Proposal owners ===
* Ensure kernel packages built in Fedora have SEV-SNP feature
integrated and enabled. Code is in kvm/next tree, targetted to merge
to linus's tree when 6.11 merge window opens. Will require backport to
Fedora's 6.10 tree.
* Ensure QEMU packages built in Fedora have SEV-SNP feature integrated
and enabled. Queued for merge into the forthcoming
[https://wiki.qemu.org/Planning/9.1 9.1.0 upstream release] - rc0 Jul
30th, GA Sep 3rd. F41 beta will ship a QEMU rc, and F41 GA will have
QEMU GA release.
* Ensure libvirt packages built in Fedora have SEV-SNP feature
integrated. Targeted to release immediately following merge into QEMU
git HEAD. Releases on 1st of each month, anticipated Sept 1st release
at latest, version 10.7.0, but ideally Aug 1st release.
* Ensure EDK2 packages built in Fedora have a EFI binary built
suitable for use with SEV-SNP guests with SVSM paravisor. EDK2
currently in rawhide has support for SNP + SVSM. Only lacking vTPM
support.
* Add new Coconut SVSM package, to provide paravisor for SEV-SNP
guests. Work in progress adding required rust deps.
* Add new IGVM library package, to enable bundling of Coconut SVSM and
EDK2 firmware into one launch binary. Work in progress adding required
rust deps.
* Ensure that an IGVM binary is built containing paired EDK2 and SVSM binaries.
* Ensure that virt-install is able to launch an SEV-SNP guest with SVSM and EDK2
=== Other developers ===
* Kernel maintainers: responsible for building new kernel that
includes SEV-SNP feature. Currently code is in kvm/next tree,
targetted for linus' tree when the 6.11 merge window opens. '''ONLY'''
if it merges to linus' tree, then proposal owners are to provide
Fedora kernel maintainers with a set of backported patches against
6.10 prior to Fedora Beta. Fedora 41 will get 6.11 kernels after GA.
=== Release engineering ===
N/A
=== Policies and guidelines ===
N/A
=== Trademark approval ===
N/A
=== Alignment with the Fedora Strategy ===
* Fedora will be demonstrating leading / state of the art integration
of SEV-SNP feature into a Linux distribution's virtualization host
stack.
* Fedora will be providing the fully OSS host-to-guest stack for
confidential virtual machines on modern AMD x86_64 EPYC hardware.
== Upgrade/compatibility impact ==
No impact anticipated. Existing users of SEV/SEV-ES technology will
keep using it without changes. The new SEV-SNP technology is strictly
an opt-in for users with suitably new AMD CPUs.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? Y (probably useful?)
== How To Test ==
Use of AMD SEV-SNP technology requires an AMD EPYC CPU with the Zen 3
generation micro-architecture, or newer (Milan, Genoa). These are
identified by the 4th digit in the processor model name having the
value '3' or greater. eg EPYC7xx3 or EPYC9xx4. See also
[https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/tuni...
SEV User Guide (pdf), Chapter 1] for CPU model support guidance.
* TBD: document process for configuring host bare metal firmware (if
applicable?)
* TBD: document process for deploying host software components. Likely
should not require any special steps, beyond the normal libvirt + KVM
install process.
* TBD: document process for creating a guest. Will update existing
[https://libvirt.org/kbase/launch_security_sev.html libvirt SEV docs]
to cover SEV-SNP
* TBD: document process for attesting a running guest. Again, will
update above libvirt SEV docs.
== User Experience ==
* Virtualization host owners will be launch confidential virtual
machines using AMD SEV-SNP technology
* Virtualization host owners will be able to provide a secure virtual
TPM to confidential guests, replacing the current non-confidential
swtpm solution in the host
* Guest owners will be able to prove that their OS is running in a
Fedora host confidential virtual machine protected by AMD SEV-SNP, by
performing a guest attestation
* Guest owners will be able to measure their guest OS software
environment using the TPM. Caveat: this is an ephemeral TPM initially,
which imposes limits on the ways in which users can take advantage of
it. A persistent TPM will be supported at a later date.
== Dependencies ==
* kernel
* edk2
* coconut-svsm (new package [https://github.com/coconut-svsm/svsm
github upstream])
** rust-intrusive-collections (new package,
[https://bugzilla.redhat.com/show_bug.cgi?id=2290692 Review Request])
** rust-packit (new package or include as vendored)
* igvm (new package [https://github.com/microsoft/igvm/ github upstream])
** rust-hmac-sha512 (new package,
[https://bugzilla.redhat.com/show_bug.cgi?id=2290698 Review Request])
** rust-bitfield-struct (new package,
[https://bugzilla.redhat.com/show_bug.cgi?id=2290696 Review Request])
** rust-open-enum (new package)
** rust-open-enum-derive (new package)
** rust-range-map-vec (new package,
[https://bugzilla.redhat.com/show_bug.cgi?id=2282977 Review Request]:
Approved)
* qemu
* libvirt
* virt-manager (for virt-install tool)
* snphost [https://github.com/virtee/snphost github upstream]
* snpguest (new package, [https://github.com/virtee/snpguest github upstream])
== Contingency Plan ==
* Contingency mechanism: None. All the work is arriving either via
rebases to new upstream versions of existing packages, patches to
existing packages, or via new package reviews. If the deadline is
missed, then whatever has already arrived in Fedora will remain in
Fedora and will not harm other existing Fedora functionality. The
remaining pieces will wait until the next Fedora dev cycle to be
integrated, completing the desired user experience. As such, no
contingency action needs to be taken should the Fedora feature
completion deadline be missed.
* Contingency deadline: N/A
* Blocks release? No
== Documentation ==
* Insert link to kernel docs, when available
* Insert link to QEMU docs, when available
* Insert link to libvirt docs, when available
* Write a Fedora wiki page illustrating end-to-end setup and usage example
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
1 week
F411 Change Proposal: KDE Plasma Mobile Spin and Fedora Kinoite
Mobile (Self-Contained)
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/Fedora_KDE_Plasma_Mobile
Discussion Thread -
https://discussion.fedoraproject.org/t/f411-change-proposal-kde-plasma-mo...
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 ==
A Fedora Spin using KDE Plasma Mobile and a Fedora Kinoite Mobile
Bootable Container image.
== Owner ==
* SIG: [[SIGs/KDE|KDE SIG]]
* Name: [[User:tdawson| Troy Dawson]]
* Email: tdawson(a)redhat.com
* Name: [[User:ngompa| Neal Gompa]]
* Email: ngompa13(a)gmail.com
* Name: [[User:Siosm| Timothée Ravier]]
* Email: travier(a)redhat.com
== Detailed Description ==
Built on the foundations of KDE Plasma Desktop, KDE Plasma Mobile
brings its flexibility to a mobile form factor. Although originally
geared towards phones, the touch friendly interface works very well on
tablets and 2-in-1 laptops.
We propose to create a Fedora KDE Plasma Mobile spin and the
corresponding Atomic variant: Kinoite Mobile (only Bootable Container
images, no classic ostree variant).
== Feedback ==
Feedback has been positive thus far. As KDE Plasma Mobile has taken
shape in Fedora, more and more people have asked for a spin so it is
easier to setup on their machines.
== Benefit to Fedora ==
KDE Plasma Mobile will give Fedora a strong showing in the mobile
market. Many other distributions that targeted the mobile market have
concentrated on cellphones. We believe that by targeting all
touchscreen devices, we can bring more users
into the Fedora community.
== Scope ==
* Proposal owners:
** '''Spin configuration:'''
** '''Work with RelEng to build:'''
** '''Test Day coordination:'''
* Other developers: N/A
* Release engineering: Will submit issue once this is approved.
[https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: Will submit issue once this is approved.
* Alignment with the Fedora Strategy: Yes.
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
Proper Fedora KDE Plasma Mobile Spin:
1. Boot the Fedora KDE Plasma Mobile Spin ISO image either on
bare-metal or in a virtual machine (V.M.).
2. Confirm successful boot into a configured KDE Plasma Mobile
environment with basic packages available.
3. Launch Anaconda installer.
4. Confirm no major issues with windows and display. The installed
system uses sddm as the login manager and comes preinstalled with KDE
Plasma Mobile as the default desktop environment and with default
applications present for most use cases.
Repeat with Kinoite Mobile.
== User Experience ==
Users are able to consume KDE Plasma Mobile from
https://spins.fedoraproject.org instead of installing another desktop
and then manually installing KDE Plasma Mobile after the initial
installation. Similarly for Kinoite Mobile.
The Spin should remain as minimal as possible and only include small
supplements on top of making the default configuration workable. We
should make the user experience as easy and simple as possible without
defining too many opinions.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Push this off to the next Fedora release
* Contingency deadline: Beta Freeze
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
This release brings the Fedora KDE Plasma Mobile Spin and its
corresponding Atomic variant: Kinoite Mobile. Built on the foundations
of KDE Plasma Desktop, KDE Plasma Mobile and Kinoite Mobile bring its
flexibility to a mobile form factor. Although originally geared
towards phones, the touch friendly interface works very well on
tablets and 2-in-1 laptops.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
1 week, 1 day
F41 Change Proposal: Replace Nose With Pynose (self-contained)
by Aoife Moloney
wiki - https://fedoraproject.org/wiki/Changes/ReplaceNoseWithPynose
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-replace-nose-w...
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 ==
Package <code>python-nose</code> was
[https://fedoraproject.org/wiki/Changes/DeprecateNose deprecated] in
Fedora 32. It’s official successor,
[https://github.com/nose-devs/nose2 <code>nose2</code>] does not
provide all the functionality of <code>nose</code>. However,
[https://github.com/mdmintz/pynose <code>pynose</code>] does and thus
can be used as a drop-in replacement for <code>nose</code> allowing us
to retire <code>python-nose</code>.
== Owner ==
* Name: [https://fedoraproject.org/wiki/User:gui1ty Sandro]
* Email: gui1ty(a)penguinpee.nl
== Feedback ==
There are still a few (~70) packages in Fedora depending on deprecated
<code>python3-nose</code> for their tests. Other packages have been
switched to <code>python3-pytest</code> when nose was deprecated or
migrated to <code>python3-pynose2</code>. As efforts are underway to
upgrade <code>python3-pytest</code> to version 8.x.y, it turns out
this version no longer supports running nose setup/teardown
functions/methods, thereby breaking packages that still rely on those
functionality.
Since pynose is using the same namespace as deprecated nose, with a
minor hack<ref>[https://src.fedoraproject.org/fork/gui1ty/rpms/python-pynose/c/594c580ae1...
nose metadata hack]</ref>, the package can be modified to provide a
proper replacement for <code>python3-nose</code> with regards to the
RPM as well as the Python metadata. Pynose also provides the same set
of executables. So packages still running <code>nosetests</code> will
be able to switch seemlessly to <code>python3-pynose</code> in
[https://copr.fedorainfracloud.org/coprs/gui1ty/pynose-nose/builds/
most cases].
Packagers can also decide to switch their packages manually by simply
changing to <code>python3-pynose</code>, which is currently available
in rawhide.
== Benefit to Fedora ==
Providing pynose as a drop-in replacement for nose will allow us to
retire long deprecated <code>python-nose</code> without forcing any
packages still depending on it to go look for an alternative or be
retired. It will also assist in the efforts of upgrading pytest to
version 8 by allowing packages that still rely on nose setup/teardown
functions/methods to switch back to <code>nosetests</code> provided by
pynose.
== Scope ==
* Proposal owners:
Provide <code>python3-pynose</code> as a drop-in replacement for
<code>python3-nose</code>; provide PRs for packages that need
adaption; provide help
* Other developers:
Manually switch to depending on <code>python3-pynose</code> if
desired; switch back to <code>nostests</code> if adapting to pytest 8
proves difficult
* 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 Community Initiatives:
== Upgrade/compatibility impact ==
Transitioning from nose to pynose will happen behind the secenes.
Packages now depending on <code>python3-nose</code> or
<code>python3dist(nose)</code> will have that dependency satisfied by
<code>python3-pynose</code> instead of <code>python3-nose</code>.
Where packages need to be adapted, PRs will be provided to make them
work with pynose.
== How To Test ==
Packagers can test their package using the
[https://copr.fedorainfracloud.org/coprs/gui1ty/pynose-nose/ Copr
repo].
# <code>copr mock-config gui1ty/pynose-nose fedora-rawhide-x86_64 >
~/.config/mock/pynose-nose-rawhide.cfg</code>
# <code>fedpkg --release rawhide mockbuild --root pynose-nose-rawhide</code>
Let us know if you need help.
== Dependencies ==
Packages currently build requiring <code>python3-nose</code>:
* binwalk
* bmap-tools
* hgsvn
* mod_nss
* nova-agent
* odcs
* openms
* ProDy
* pydot
* pytest
* python-agate
* python-agate-dbf
* python-agate-excel
* python-agate-sql
* python-anyjson
* python-axolotl
* python-behave
* python-binstruct
* python-blessings
* python-boto
* python-case
* python-colorspacious
* python-curtsies
* python-deap
* python-epc
* python-etcd
* python-eyed3
* python-fedmsg-meta-fedora-infrastructure
* python-flask-xml-rpc
* python-fluidity-sm
* python-gensim
* python-hglib
* python-http-ece
* python-httpretty
* python-ifcfg
* python-inflect
* python-ipmi
* python-iptools
* python-ipython_genutils
* python-jenkins
* python-leather
* python-mapnik
* python-migrate
* python-moksha-common
* python-moksha-hub
* python-musicbrainzngs
* python-neurosynth
* python-nitime
* python-ofxparse
* python-ordered-set
* python-pycdio
* python-pygatt
* python-pygeoip
* python-pypillowfight
* python-pyramid-tm
* python-pytest-mpl
* python-pytimeparse
* python-queuelib
* python-rows
* python-sievelib
* python-simplebayes
* python-spec
* python-spur
* python-statsd
* python-stomper
* python-supersmoother
* python-tilestache
* python-www-authenticate
* python-xvfbwrapper
* vigra
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
[https://github.com/mdmintz/pynose/blob/master/README.md pynose
README] and above
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
1 week, 1 day
F41 Change Proposal: GIMP Version 3 (self-contained)
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/Gimp_3
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-gimp-version-3...
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 introduces the upcoming major version 3 of the GNU Image
Manipulation Program in Fedora Linux.
== Owner ==
* Name: [[User:Nphilipp| Nils Philippsen]]
* Email: nphilipp -at- redhat.com (or nils -at- tiptoe.de)
== Detailed Description ==
The [https://gimp.org GIMP project] intends to release the
[https://developer.gimp.org/core/roadmap/#gimp-30-development-branch-roadmap
major version 3] of the GNU Image Manipulation Program
[https://gitlab.gnome.org/GNOME/gimp/-/issues/10373#timeline later
this year].
This new version involves substantial changes to the technologies
used, which in turn means that third party plugins have to be ported
to be compatible. Therefore, this change will add the new version as a
new package <code>gimp3</code> which can be installed side-by-side
with the existing version 2.x package, so people can continue working
on existing projects with the old gimp version and its plugins.
In order to make upgrades seamless for users (and avoid having to go
through an exception process for a “new” <code>gimp2</code> package
needing Python 2.x), the existing package will remain named
<code>gimp</code> and it plus <code>gimp3</code> will obsolete the
version 2.x packages from Fedora Linux <= 40 in version 41.
== Feedback ==
Alternative proposals were made, e.g. in
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
the respective thread on the devel mailing list]:
* ''Replacing version 2 with version 3 wholesale, without possibility
for parallel installation, starting in Fedora Linux 41.''<br/>This
would force users to choose between using either using version 2.x or
3.x of GIMP, and it might make users with existing GIMP projects stay
longer on an older version of Fedora Linux than they would do
otherwise.
* ''Add <code>gimp2</code> for the old version, let <code>gimp</code>
become version 3 in Fedora Linux 41 …''<br/>This would need an
exception for the <code>gimp2</code> package, as it needs Python 2.x.
** ''… and introduce version 3 as <code>gimp3</code> in Fedora Linux
<= 40.'' This would come along with even more packaging churn, it
would introduce <code>gimp3</code> only for two existing Fedora
versions and then obsolete the package, also makes the upgrade
obsolete dance from 40 to 41 more complicated than it needs to be.
** ''… and only introduce GIMP version 3 in Fedora Linux >= 41.'' This
would withhold the benefits of the new GIMP version to users of older
Fedora Linux versions without a technical need to do so.
== Benefit to Fedora ==
This change upgrades GIMP to a version which doesn’t use ancient 2.x
versions of both GTK and Python anymore. Other than many new features
including better color management and the support of CMYK
import/export, it greatly improves user experience with certain input
devices such as tablets and on displays with very high resolutions.
Developers of plugins using Python can now use packages and language
features which simply don’t exist in Python 2.x.
== Scope ==
* Proposal owners:
** Make (pre-releases) available as <code>gimp3</code> in Rawhide and
existing Fedora Linux versions.
** Ensure users of <code>gimp</code> get both versions when upgrading
their OS to Fedora Linux 41.
** Ensure comps is updated to refer to the new GIMP version from
Fedora Linux 41 on.
* Other developers: Maintainers of third party plugins work with their
respective upstreams to either find out if they have been ported to
GIMP 3.x, or assist in porting and make such ports available in
Fedora.
* Release engineering: This is a self-contained change and doesn’t
require that release engineering is involved.
* 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 doesn’t particularly
relate to the [https://discussion.fedoraproject.org/t/fedora-strategy-2028-february-marc...
the current Fedora Strategy], but it aligns well with “Freedom”,
“Features” and maybe ”First” of the
[https://docs.fedoraproject.org/en-US/project/#_what_is_fedora_all_about
Fedora Foundations].
== Upgrade/compatibility impact ==
The plan is that existing users of <code>gimp</code> end up with both
this package and the new version as <code>gimp3</code>. It should be
possible to install either version without pulling in the other on
Fedora Linux >= 41 (if technically feasible).
== User Experience ==
With Fedora Linux 41, users who install GIMP as an RPM package will
get the new version by default. It contains many new features and
improvements in the handling of input devices such as tablets and when
used on high resolution displays.
== Dependencies ==
A number of third party GIMP plugins are available to be installed as
packages on Fedora Linux. With the continued availability of version
2.x of GIMP, these packages can still be installed and used with the
old version. Whether or not these plugins will support the new GIMP
version very much depends on the particular plugin, or rather the
upstream projects for these plugins. Therefore it’s a bit early to
make plans for packaging plugins available for both GIMP versions at
this point.
== Contingency Plan ==
* Contingency mechanism: Not ship the package, bump “seamless update”
measures to be effective in Fedora Linux 42.
* Contingency deadline: Beta Freeze
* Blocks release? No
== Documentation ==
* https://gimp.org/
* https://developer.gimp.org/core/roadmap/#gimp-30-development-branch-roadmap
* https://gitlab.gnome.org/GNOME/gimp/-/issues/10373#timeline
== Release Notes ==
This release of Fedora Linux ships version 3 of the GNU Image
Manipulation Program, with many new features and improved user
experience. The package is called <code>gimp3</code>, the old version
will still be available under the old name, <code>gimp</code> for
users who need it for existing projects.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
1 week, 1 day
F41 Change Proposal: Mark Fedora KDE AArch64 as Release-Blocking (System-Wide)
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/Fedora_KDE_AArch64_ReleaseBlocker
Discussion Topic -
https://discussion.fedoraproject.org/t/f41-change-proposal-mark-fedora-kd...
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 ==
Mark Fedora KDE AArch64 deliverables as release-blocking, leveraging
the same criteria for Fedora on AArch64 and Fedora KDE on x86_64.
== Owner ==
* Name: [[User:Ngompa| Neal Gompa]]
* Email: ngompa13(a)gmail.com
== Detailed Description ==
The Fedora KDE SIG already considers Fedora KDE on AArch64 at the same
level of importance as Fedora KDE on x86_64, and the SIG wants the
Fedora KDE AArch64 deliverables (such as the disk images and ISOs) to
be release-blocking alongside existing Fedora KDE x86_64 deliverables.
== Feedback ==
== Benefit to Fedora ==
This allows the Fedora KDE SIG to reinforce its commitment to the
highest quality KDE Plasma experience on Fedora possible on AArch64
like on x86_64, and it lets Fedora better support the larger ecosystem
around Fedora leveraging KDE Plasma (of one notable member being the
Fedora Asahi Remix).
== Scope ==
* Proposal owners: Update pungi-fedora to mark AArch64 artifacts as
release blocking ([https://pagure.io/pungi-fedora/pull-request/1290
pagureio#pungi-fedora#1290])
* Other developers: N/A (not needed for this Change)
* Release engineering: [https://pagure.io/releng/issue/12165 #12165]
* 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 aligns with expanding and
improving Fedora's connections to the larger ecosystem by supporting
upstream KDE with our expertise on AArch64 and downstream
distributions like the Fedora Asahi Remix using Fedora KDE on AArch64.
== Upgrade/compatibility impact ==
This has no impact on users.
== How To Test ==
Fedora KDE can be tested on AArch64 the same way Fedora Workstation is:
* Fedora KDE AArch64 ISO on either QEMU/KVM or a device with UEFI CD
boot such as [https://github.com/pftf the Raspberry Pi using UEFI
firmware]
* Fedora KDE AArch64 raw disk image on existing supported AArch64 devices
== User Experience ==
This does not change anything for the user experience.
== Dependencies ==
There are no extra dependencies.
== Contingency Plan ==
* Contingency mechanism: Revert release-blocking status for Fedora KDE
on AArch64
* Contingency deadline: Final Freeze
* Blocks release? Yes
== Documentation ==
There is no user-facing documentation to update. Fedora QA
documentation on release-blocking artifacts will note Fedora KDE
AArch64 artifacts as release-blocking.
== Release Notes ==
Not applicable as this is not a user-facing Change.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
1 week, 1 day
