Wiki - https://fedoraproject.org/wiki/Changes/Acpica-tools_Deprecate-Big_Endian_Su…
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-acpica-tools-dep…
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
--
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi,
Instruction [1] about building upstream kernel should be updated,
because since commit 5e6abd7f4dce [2] the Fedora kernel config contain
CONFIG_SYSTEM_TRUSTED_KEYS="certs/rhel.pem" and this is lead to build
error:
HOSTCC /home/mikhail/packaging-work/git/linux/tools/bpf/resolve_btfids/ctype.o
HOSTCC /home/mikhail/packaging-work/git/linux/tools/bpf/resolve_btfids/str_error_r.o
HOSTLD /home/mikhail/packaging-work/git/linux/tools/bpf/resolve_btfids/resolve_btfids-in.o
LINK resolve_btfids
make[3]: *** No rule to make target 'certs/rhel.pem', needed by
'certs/x509_certificate_list'. Stop.
make[3]: *** Waiting for unfinished jobs....
I always use Fedora current kernel config for bisecting upstream kernel.
Not sure if my solution is right. But for a quick workaround I decided
to remove CONFIG_SYSTEM_TRUSTED_KEYS value.
[1] https://fedoraproject.org/wiki/BuildingUpstreamKernel
[2] https://src.fedoraproject.org/rpms/kernel/c/5e6abd7f4dce6f47a9f6df3919ee081…
> diff /boot/config-6.10.0-0.rc1.20240531git4a4be1ad3a6e.22.fc41.x86_64+debug /boot/config-6.10.0-0.rc1.20240529gite0cce98fe279.20.fc41.x86_64+debug
3c3
< # Linux/x86_64
6.10.0-0.rc1.20240531git4a4be1ad3a6e.22.fc41.x86_64+debug Kernel
Configuration
---
> # Linux/x86_64 6.10.0-0.rc1.20240529gite0cce98fe279.20.fc41.x86_64+debug Kernel Configuration
36c36
< CONFIG_BUILD_SALT="6.10.0-0.rc1.20240531git4a4be1ad3a6e.22.fc41.x86_64"
---
> CONFIG_BUILD_SALT="6.10.0-0.rc1.20240529gite0cce98fe279.20.fc41.x86_64"
10745c10745
< CONFIG_SYSTEM_TRUSTED_KEYS="certs/rhel.pem"
---
> CONFIG_SYSTEM_TRUSTED_KEYS=""
--
Best Regards,
Mike Gavrilov.
I've bumped simple-mail to version 3.0.0 which includes a soname bump, or
rather a soname rename in rawhide.
It doesn't look like anything currently uses this lib.
--
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>
Wiki - https://fedoraproject.org/wiki/Changes/NvidiaInstallationWithSecureboot
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-nvidia-driver-in…
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
--
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi!
I noticed that GIMP 3.0 is scheduled[1] for release in June. It'd be
nice to have it in F41. Are there any plans to do so? Do the maintainers
(Cc'd) need any help?
[1] https://gitlab.gnome.org/GNOME/gimp/-/issues/10373#timeline
Regards,
Dominik
--
Fedora https://fedoraproject.org
Deep in the human unconscious is a pervasive need for a logical universe that
makes sense. But the real universe is always one step beyond logic.
-- from "The Sayings of Muad'Dib" by the Princess Irulan