Wiki - https://fedoraproject.org/wiki/Changes/golang1.23
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-golang-1-23-syst…
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 of Go (golang package) to the upcoming version 1.23 in Fedora 41.
== Owner ==
* Name: [[User:alexsaezm| Alejandro Sáez Morollón]]
* Email: asm(a)redhat.com
== Detailed Description ==
Update of Go (golang package) to the upcoming version 1.23 in Fedora
41. Go 1.23 is expected to be released in
[https://tip.golang.org/doc/go1.23 August 2024]. A mass rebuild of all
of the dependent packages is required.
== Feedback ==
No feedback yet.
There is an [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
ongoing conversation] about removing a patch and revert to the
defaults a couple of variables.
== Benefit to Fedora ==
Up-to-date and latest Go release will be delivered to Fedora users.
Being close to upstream allows us to avoid security issues and provide
more up-to-date features. Therefore, Fedora will be providing a
reliable development platform for the Go language and projects written
in it.
For a complete list of changes, see upstream change notes at
https://tip.golang.org/doc/go1.23
== Scope ==
* Proposal owners:
Rebase Golang package in Fedora 41, and help resolve possible issues
found during package rebuilds.
* Other developers:
Fix possible issues, with help from Golang maintainers.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
Rebuild of dependent packages as part of planned mass-rebuild.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
It doesn't align directly with the current objectives, but it helps
maintain the quality of the project.
== Upgrade/compatibility impact ==
No upgrade or compatibility impact.
== How To Test ==
# Install golang 1.23 from rawhide and use it to build your
application(s)/package(s).
# Perform a scratch build against rawhide.
# Your application/package built using golang 1.23 should work as expected.
== User Experience ==
Users will have a newer version of Go, with new features described in
the release notes and security fixes.
== Dependencies ==
<pre>
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
</pre>
<pre>
Omitted due to the number of packages listed: ~2000.
</pre>
== Contingency Plan ==
* Contingency mechanism: Revert to Go 1.22.X if significant issues are
discovered
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
https://tip.golang.org/doc/go1.23
== 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
Wiki - https://fedoraproject.org/wiki/Changes/TunedAsTheDefaultPowerProfileManagem…
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-make-tuned-the-d…
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 makes ‘tuned’ the default power profile management daemon
in Fedora Workstation, KDE Plasma, and Budgie instead of
power-profiles-daemon.
* tuned-ppd provides a drop-in replacement for power-profiles-daemon,
which allows it to be used with current desktops
* power users can customize the desktop-exposed power profiles by
editing /etc/tuned/ppd.conf
== Owner ==
* Name: [[User:smallorange| Kate Hsuan]], [[User:jskarvad | Jaroslav Škarvada]]
* Email: <hpa(a)redhat.com>, <jskarvad(a)redhat.com>
== Detailed Description ==
<p>
Tuned and power-profiles-daemon provide a similar function to set and
tune the power status of a system. Both of them have similar features,
if they can be integrated into one, it allows the Fedora user to have
more options for power settings of their system and benefits the
users. In this proposal, we set up tuned to the default power profile
management daemon for the GNOME in Fedora Workstation and the KDE
Plasma Spin. Tuned already provides power profiles for different use
cases. Recently, tuned released the translation API layer called
tuned-ppd which can translate the power-profiles-daemon API to tuned.
The applications that use power-profiles-daemon API can access tuned
without modifying the code. For now, the Fedora user can immediately
switch to tuned by installing the tuned-ppd package without impacting
the user experience. Therefore, tuned can be the default power profile
management daemon for Fedora.
</p>
<p>
This work would replace power-profiles-daemon with tuned. Since tuned
already provides a wide range of power profiles for different
purposes, this allows the user to have more options for configuring
the system power profile.
Tuned provides many kinds of advanced and basic profiles for different
purposes. Power-profiles-daemon provides the basic power profiles and
the profiles can be set to the system through platform_profiles, Intel
p-state and AMD p-state. That is simple and clever. However, if the
users want to ask for an advanced profile, they need to install
another power utility, such as tuned to fine-tune their system. With
tuned as the default power profile management daemon, users have a
wider range of profiles to fine-tune the system.
</p>
<p>
Tuned released a new translation API service called tuned-ppd
<ref>https://github.com/redhat-performance/tuned/tree/master/tuned/ppd</ref>.
tuned-ppd can translate the power-profiles-daemon API to the tuned API
so applications can talk with tuned without modification. Moreover,
the GUI settings, such as gnome-control-center can configure tuned
profiles through tuned-ppd. tuned-ppd also allows the user to override
the basic three power profiles, including power-saver, balanced, and
performance through the config file /etc/tuned/ppd.conf
<ref>https://github.com/redhat-performance/tuned/blob/master/tuned/ppd/ppd.conf</ref>.
If the user wants to use a customized profile, they can edit the
config file and map the custom profile to the basic three
power-profiles-daemon profile names. In this way, gnome-control-center
can keep the original design to configure the customized profile.
</p>
<p>
The work expects tuned to replace the power-profiles-daemons to offer
a wider range of power profiles to Fedora users. tuned-ppd resolved
the API translation issue so the application can access tuned service
through power-profiles-daemon API without converting to the tuned API.
Moreover, the three basic profiles can be overridden when the user
needs it for their use case. It also benefits GNOME applications that
can keep the original design and designing a new GUI tool for custom
profiles is unnecessary. Therefore, tuned can be the default power
setting service for Fedora.
</p>
== Feedback ==
'''From fedora-devel'''
<p>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
1. The dependency concern. Since tuned is written by Python, that
causes a dependency impact on Fedora installation.
2. The power-profiles-daemon API should be ported to tuned to provide
the function to the application that uses power-profiles-daemon API,
such as gnome-shell and gnome-control-center.
</p>
'''From the hardware vendor'''
<p>
Moreover, we discuss it with vendors through the mail.
1. Since tuned covers several kinds of system tuning schemes that
allow the vendor to implement their power profile for different
devices or workloads. For power-profile-daemon, it only has three
profiles to set and every detail setting should be done through the
firmware level. If tuned can replace power-profiles-daemon, they can
imagine they can develop the profile in a much more flexible manner.
</p>
'''The previous discussions'''
<p>
https://discussion.fedoraproject.org/t/f40-change-proposal-tuned-replaces-p…
</p>
== Benefit to Fedora ==
<p>
<ol>
<li>Benefits the user. The user would have more options to tune their
system.</li>
<li>Benefits the maintainer. Integrate similar software into one
software to reduce the maintenance effort.</li>
</ol>
</p>
== Scope ==
* Proposal owners:
** for GNOME: update gnome-control-center weak dependency on
power-profile-daemon to tuned-ppd
** for KDE: update powerdevil weak dependency on power-profile-daemon
to tuned-ppd
** for Budgie: update budgie-control-center weak dependency on
power-profile-daemon to tuned-ppd
* Other developers:
* 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 ==
<p>
Since tuned-ppd provides the ppd APIs and features, there is no impact
on other applications.
</p>
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? Y/N
== How To Test ==
<ol>
<li>
Remove power-profiles-daemon.<br>
$ sudo dnf remove power-profiles-daemon
</li>
<li>Install tuned and tuned-ppd through the following command<br>
$ sudo dnf install tuned<br>
$ sudo dnf install tuned-ppd
</li>
<li>
Run gnome-control-center and switch to the power panel and then select
one of the three power profiles.
Click the top-right corner of the screen and you can see the “Power
Mode” shows the profile name that you selected previously.
</li>
<li>
Run the following command to show the active profile. Since tuned-adm
shows the tuned profile name, the profile name mapping can be found in
/etc/tuned/ppd.conf.<br>
$ tuned-adm active
</li>
</ol>
== User Experience ==
<ol>
<li>
The workstation user can set the power profile through the gnome-control-center.
</li>
<li>
The server users switch the profile through the tuned command line.
</li>
</ol>
== Dependencies ==
<p>
tuned is written by Python so it depends on python packages and its 40 packages.
</p>
== Contingency Plan ==
* Contingency mechanism:
<p>
Use the original power-profiles-daemon
</p>
* Contingency deadline:
<p>
Before F41 beta freeze.
</p>
* Blocks release?
<p>
No, tuned-ppd provides all the power-profiles-daemon APIs otherwise
the original power-profile-daemon can be used when the plan blocks the
release.
</p>
== Documentation ==
I have talked with tuned about this information.<br>
https://github.com/redhat-performance/tuned/issues/559
== Release Notes ==
* https://github.com/redhat-performance/tuned/tree/master/tuned/ppd
* https://github.com/redhat-performance/tuned/blob/master/tuned/ppd/ppd.conf
--
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
Wiki - https://fedoraproject.org/wiki/Changes/UnprivilegedUpdatesAtomicDesktops
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-unprivileged-upd…
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 update the Polkit rule currently controlling access to the
rpm-ostree daemon on Fedora Atomic Desktops to do the following:
* Enable users to update the system without being an administrator or
typing a password.
* Restrict the current rule for administrators to make more operations
explicitly require a password.
== Owner ==
* [[User:boredsquirrel| Henning]], boredsquirrel(a)secure.mailbox.org
* [[User:Siosm| Timothée Ravier]], siosm(a)fedoraproject.org
== Detailed Description ==
This change tries to address two issues:
* Give more users the permission to update their systems as this
should be an entirely safe operation on Fedora Atomic Desktops.
** Silverblue already automatically update the system and Flatpaks by
default and Kinoite is looking at doing it as well:
https://fedoraproject.org/wiki/Changes/KDEKinoiteAutoUpdateByDefault
** We will thus enable all active and interactive users to update the
system without being an administrator or typing a password.
** Note that this is only about system updates (and repo metadata
updates) and no other operations.
* Reduce access to the most privileged operations of rpm-ostree for
administrators to avoid mistakes.
** The current setup is not directly a security issue as it only
allows those operations for users that are part of the wheel group and
thus assumed to be administrators.
** However, some of those operations can be more dangerous than others
so we should ask the administrator to confirm them or let them do it
via `sudo`.
** Operations such as changing kernel arguments, installing a local
package, rebasing to another image, etc. will thus be removed from the
current Polkit rule and will now require the administrator password,
similarly to calling it via `sudo`.
** Only the install/uninstall packages from the repos, upgrade,
rollback, cancel and cleanup operations will remain password-less, to
match the behavior on package mode Fedora with dnf.
See:
* https://gitlab.com/fedora/ostree/sig/-/issues/7
* https://github.com/rohanssrao/silverblue-privesc/issues/4
* https://bugzilla.redhat.com/show_bug.cgi?id=2203555
Initial work in:
* https://src.fedoraproject.org/rpms/fedora-release/pull-request/324
* https://src.fedoraproject.org/rpms/fedora-release/pull-request/325
== Feedback ==
Nothing here so far beyond comments in the PRs, which have mostly been
addressed.
== Benefit to Fedora ==
This change will make it easier to setup a Fedora system with
non-administrator (unprivileged) users that can still update the
system without administrator intervention. Note that major version
upgrades (rebase operation) will still require privileges (or an
administrator password) for now. This is due to a limit of the current
rpm-ostree interface.
This is also a step towards the goals of the
[https://fedoraproject.org/wiki/SIGs/ConfinedUsers Confined Users
Special Interest Group (SIG)].
== Scope ==
* Proposal owners:
** Implement the change in the polkit rules
** Validate that this changes works on all Fedora Atomic Desktops
(notably with GNOME Software and Plasma Discover)
* Other developers:
** Developers depending on the current polkit rules might have to
adapt their software. We don't know of any software impacted right
now.
* 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: Not specificaly
== Upgrade/compatibility impact ==
This change does not remove any interface so it should not have any
impact for users on upgrade. If some of the now "password-full"
operations were used previously, they will now ask for a password.
If administrators previously disabled or overwrote the current polkit
rules, then they might have to update their override for the new
behavior.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? No
== How To Test ==
* Write the following file:
`/etc/polkit-1/rules.d/org.projectatomic.rpmostree1.rules`
<pre>
polkit.addRule(function(action, subject) {
if ((action.id == "org.projectatomic.rpmostree1.repo-refresh" ||
action.id == "org.projectatomic.rpmostree1.upgrade") &&
subject.active == true &&
subject.local == true) {
return polkit.Result.YES;
}
if ((action.id ==
"org.projectatomic.rpmostree1.install-uninstall-packages" ||
action.id == "org.projectatomic.rpmostree1.rollback" ||
action.id == "org.projectatomic.rpmostree1.reload-daemon" ||
action.id == "org.projectatomic.rpmostree1.cancel" ||
action.id == "org.projectatomic.rpmostree1.cleanup" ||
action.id == "org.projectatomic.rpmostree1.client-management") &&
subject.active == true &&
subject.local == true &&
subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
if ((
action.id == "org.projectatomic.rpmostree1.install-local-packages" ||
action.id == "org.projectatomic.rpmostree1.override" ||
action.id == "org.projectatomic.rpmostree1.deploy" ||
action.id == "org.projectatomic.rpmostree1.rebase" ||
action.id == "org.projectatomic.rpmostree1.rollback" ||
action.id == "org.projectatomic.rpmostree1.bootconfig" ) &&
subject.active == true &&
subject.local == true &&
subject.isInGroup("wheel")) {
return polkit.Result.AUTH_ADMIN;
}
});
</pre>
* Test that normal / unprivileged users can '''only do''' the
following operations '''without a password''':
** Update the system: `rpm-ostree update`
** Refresh the metadata: `rpm-ostree refresh-md`
* Test that admin / privileged users can do the following operations
'''without a password''':
** Install a package from the official Fedora repos: `rpm-ostree install strace`
** Cancel an in-progress transaction: `rpm-ostree cancel`
** Rollback to a previous version: `rpm-ostree rollback`
** Reload the daemon: `rpm-ostree reload`
** Cleanup pending or rollback deployments: `rpm-ostree cleanup`
* Test that admin / privileged users are '''asked a password''' for
the following operations:
** Install a local RPM package: `rpm-ostree install ./foo.rpm`
** Override replace a package: `rpm-ostree override replace vim-x.y.z.rpm`
** Deploy a specific version: `rpm-ostree deploy 40.20240518.1`
** Rebase to any version: `rpm-ostree rebase ...` (try with Kinoite on
Silverblue, etc.)
** Change kernel argments: `rpm-ostree kargs --append=foo=bar`
== User Experience ==
This change should be mostly transparent for users.
If some of the now "password-full" operations were used previously,
they will now ask for a password.
Unprivileged users will be able to update the system.
== Dependencies ==
The rules are shipped as part of the `fedora-release` RPM. There are
no other dependencies.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
** We can revert the change to the `fedora-release` package at any time.
** Will be done by the change owners.
* Contingency deadline: Beta freeze or final freeze
* Blocks release? No
== Documentation ==
No additional documentation.
== Release Notes ==
To be written once the change is accepted.
--
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
Wiki - https://fedoraproject.org/wiki/Changes/NetworkScriptsRemoval
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-removing-network…
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 ==
<code>network-scripts</code> package will be removed in Fedora 41. By
removing the package, we also remove support for legacy
<code>ifup/ifdown</code> network scripts that have been deprecated
since 2018.
== Owner ==
* Name: [[User:jamacku| Jan Macku]]
* Name: [[User:lnykryn| Lukáš Nykrýn]]
* Email: [mailto:jamacku@redhat.com jamacku(a)redhat.com]
* Email: [mailto:lnykryn@redhat.com lnykryn(a)redhat.com]
== Detailed Description ==
<code>network-scripts</code> will be removed in Fedora 41. It provides
legacy <code>ifup</code>/<code>ifdown</code> scripts as well as
<code>network.service</code>.
The <code>network-scripts</code> were '''deprecated in 2018''', and
since then, upstream has provided only limited support.
The main reason for removing <code>network-scripts</code> is that ISC
dhcp has not been maintained upstream since the end of 2022. There is
[https://fedoraproject.org/wiki/Changes/dhclient_deprecation plan to
remove it upcoming Fedora release]. Network scripts heavily depend on
the DHCP client, and since Network Scripts are no longer developed,
there is no chance of updating them to use an alternative client.
== Feedback ==
== Benefit to Fedora ==
We don't deliver software that has been deprecated for many years,
unmaintained upstream, and for which we don't have resources to
maintain downstream. Additionally, it simplifies networking tasks for
users and administrators because NetworkManager will be used more
uniformly across Fedora environments.
== Scope ==
* Proposal owners: Removing of <code>network-scripts</code> rpm package.
* Other developers: Make sure that dependency on
<code>network-scripts</code> package is removed (see
[[Changes/NetworkScriptsRemoval#Dependencies| #Dependencies]]).
* 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 Community Initiatives: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
<code>ifup/ifdown</code> command are no longer available. Use
<code>nmcli connection up/down</code> or <code>networkctl
up/down</code> instead.
Old <code>ifcfg</code> network configuration should still work thanks
to <code>NetworkManager-initscripts-ifcfg-rh</code> package. No
migration is needed, but it is recommended to migrate from
<code>ifcfg</code> to <code>keyfiles</code> configuration.
You can use one of the following articles on how to migrate:
* https://fedoramagazine.org/converting-networkmanager-from-ifcfg-to-keyfiles/
* https://opensource.com/article/22/8/migrate-networkmanager-keyfiles-configu…
== How To Test ==
Networking should work as before the removal of
<code>network-scripts</code> package.
== User Experience ==
== Dependencies ==
RPM packages that depends in some form on <code>network-scripts</code>:
* <code>libteam</code> - https://bugzilla.redhat.com/show_bug.cgi?id=2262986
* <code>NetworkManager</code> -
https://bugzilla.redhat.com/show_bug.cgi?id=2275295
* <code>openvswitch</code> - https://bugzilla.redhat.com/show_bug.cgi?id=2262982
* <code>ppp</code> - https://bugzilla.redhat.com/show_bug.cgi?id=2262981
Note that this will also affect all users with local custom
network-scripts that require functionality from
<code>network-scripts</code> package.
== Contingency Plan ==
* Contingency mechanism: Since
[https://fedoraproject.org/wiki/Changes/dhclient_deprecation dhcp
client is no longer maintained] and is going to be deprecated in
Fedora, there is currently no contingency mechanism.
* Contingency deadline: beta freeze
* Blocks release: No
== Documentation ==
* Upstream Deprecation notice -
https://github.com/fedora-sysv/initscripts/commit/b748244cf9905696baf1bc16e…
== 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
Wiki - https://fedoraproject.org/wiki/Changes/LLVM-19
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-llvm-19-system-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 ==
Update all llvm sub-projects in Fedora Linux to version 19.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 19, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang18, llvm18, lld18, compiler-rt18, and
libomp18 will be added to ensure that packages that currently depend
on clang and llvm version 18 libraries will continue to work. We may
add other compatibility packages too if they're determined to be
necessary to maintain functionality in other RPMS that use llvm/clang.
Any compatibility packages we add for Fedora 41 will be retired or
orphaned before the Fedora 42 branch date. As stated in the
[[Changes/LLVM-18 | LLVM-18 change proposal]], we plan to retire or
orphan these older compatibility packages prior to the Fedora 41
branch date:
* llvm17
* clang17
* lld17
* compiler-rt17
* libomp17
Other notable changes:
* '''Build compat packages (e.g. llvm18) as early as possible.'''
When we package a new major release of llvm, we create a compat
package so that packages that aren't compatible with the new version
can still use the old version. In the past, we've waited to introduce
the compat packages until the new version of LLVM was ready (typically
during the Beta Freeze). However, this proved to be an issue this
release for packages the were ready to switch to the compat packages
early in the release cycle, but then had to wait for Beta freeze.
* '''Spec file merge.''' We plan to retire the clang, compiler-rt,
lld and libomp packages and merge them in with llvm and have them be
sub-packages of the llvm package. All these packages have their
sources in the same upstream git repository and use the same
versioning. This change will allow us to use the build configuration
recommended by upstream and also make it possible to optimize the
packages using Profile-Guided Optimizations (PGO). It's possible that
in future releases (f42+), we may decided to merge more packages in
with llvm too.
* '''Fat LTO'''. All RPMS built with clang will default to using the
-ffat-lto option. Fat LTO is a feature that allows the compiler to
produce libraries that contain LTO bitcode along side the traditional
ELF binary code so that the libraries can be linked in both LTO mode
and non-LTO mode. gcc also supports this feature and has it enabled in
Fedora. In Fedora 40 and older, with LTO enabled, clang produces
binaries with only LTO bitcode, so we need to run a post-processing
script (brp-llvm-compile-to-elf) on the libraries to convert them to
ELF code so they can be used by other packages. Enabling Fat LTO will
allow us to remove this script and simplify the build process. We
originally proposed this feature for Fedora 40, but it was not ready
in time.
===Planned Schedule===
Our plan is to push 19.1.0-rc3 into Fedora 41 as a Beta Freeze
exception. Updates after 19.1.0-rc3 will generally be very small and
can be done after the Beta Freeze is over. If we are late packaging
releases after 19.1.0-rc3, we will not ask for a Final Freeze
exception, unless they contain a fix for a critical release blocking
bug.
We are not planning to push 19.1.0-rc1 into rawhide because the
library ABI is not stabilized at that point. Typically, the ABI
stabilizes after -rc3, but there are no guarantees from upstream about
this. Given the history of minimal ABI changes after -rc3, we feel
like it's safe to push -rc3 into rawhide and Fedora 41. The worst
case scenario would be an ABI change in -rc4 or the final release that
would force us to patch LLVM to maintain compatibility with the -rc3
ABI. This scenario would not require rebuilding LLVM library users in
Fedora, so it would merely be a self-contained change to LLVM.
====Important Dates====
Dates may change depending on circumstances.
* Jun 4: Build llvm18, clang18, lld18, compiler-rt18, and lld18
compat packages in rawhide.
* July 26: Begin building LLVM 19.1.0-rc1 in COPR.
* Aug 6: Begin building LLVM 19.1.0-rc2 in COPR.
* '''''Aug 6: Fedora f41 branches created.'''''
* Aug 20: Begin building LLVM 19.1.0-rc3 in Rawhide and f41 side-tags.
* '''''Aug 20: Fedora f41 Beta Freeze'''''
* Aug 20-> Sep 10: Request Beta Freeze Exception and push 19.1.0-rc3
into f41 stable.
* Sep 3: Begin building LLVM 19.1.0-rc4 in Rawhide side-tag.
* Sep 17: Begin building LLVM 19.1.0 in Rawhide and f41 side-tags.
* Sep 17 -> Oct 1: Push 19.1.0 into f41 stable.
* '''''Oct 1: Fedora f41 Final Freeze.'''''
== Feedback ==
== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.
== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan
any packages that are no longer used.
** Build and test early release candidates of LLVM 19 in COPR.
* Other developers:
** Fix build issues found with LLVM-19 or switch their package to use
the llvm18 compat libs. The LLVM team will not block Bodhi updates on
dependent packages that fail to build or run with LLVM-19. There
should be around 6-8 weeks between when -rc1 lands in the koji
side-tag and the Final Freeze for package maintainers to fix issues
uncovered with the LLVM-19 update.
* Release engineering: [https://pagure.io/releng/issue/12118]
* 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 ==
This change should not impact upgrades.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
The CI tests for the llvm sub-packages in Fedora will be used to catch
regressions that might be potentially introduced by the update to LLVM
19.
== User Experience ==
== Dependencies ==
Packages that depend on one of the llvm packages will need to be
updated to work with LLVM19 or will need to switch to using one of the
llvm18 compat packages.
== Contingency Plan ==
If there are major problems with LLVM 19, the compatibility package
provide a way for other packages to continue using LLVM 18.
* Contingency deadline:Final Freeze
* Blocks release? No (not a System Wide Change)
== Documentation ==
LLVM sub-projects in Fedora have been updated to version 19:
* llvm (now includes clang, lld, compiler-rt, libomp)
* lldb
* llvm-test-suite
* libcxx
* python-lit
* flang
* mlir
* polly
* libclc
* llvm-bolt
== 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
On behalf of KDE SIG, and pursuant to the Fedora non-responsive
maintainer policy, I'm trying to reach Roland Wolters (FAS: liquidat),
the sole maintainer of audex[1].
audex has been promoted to KDE Gear, and therefore KDE SIG wishes to
co-maintain it in order to update it in tandem with the rest of Gear
releases. As such, a PR[2] has been posted with the initial changes,
and at least commit permissions for @kde-sig are being requested to
facilitate ongoing updates.
If someone knows how to contact him, please let me know.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2283874
[2] https://src.fedoraproject.org/rpms/audex/pull-request/5
--
Yaakov Selkowitz
Principal Software Engineer - Emerging RHEL
Red Hat, Inc.
Hello everyone,
I would like to announce that the Anaconda team has decided to postpone
Web UI System Wide change[0] from Fedora 41 to 42.
Reason is that we don't have time required to get the project into shape
which we would like to deliver to users based on the feedback we were
able to collect[1]. We also have other Fedora 41 and CentOS Stream 10
work[2] we would like to deliver which is again reducing our capacity
for the Web UI project.
We, FESCO and Fedora QE need to decide how to handle this in Rawhide. If
we keep Web UI in Rawhide or revert it.
Sorry for keeping you waiting even longer. I really hope you will love
the Web UI when it's ready!
[0]:
https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
[1]:
https://discussion.fedoraproject.org/t/feedback-anaconda-web-ui-partitionin…
[2]:
https://fedoraproject.org/wiki/Changes/Anaconda_As_Native_Wayland_Applicati…
Best Regards,
Jirka and the Anaconda team
Hi all,
We are moving swiftly in the F41 release cycle already, so I wanted to get
a survey out to you to reflect on and share feedback for the F40 release
cycle. I'm very interested to hear your thoughts on anything that can be
tweaked/changed/added to improve the release cycle, and what aspects are
working really well too.
The survey can be found here
https://fedoraproject.limequery.com/857364?lang=en , its live now and will
remain open until Friday June 7th.
Please take some time to share your feedback and thank you in advance for
your insights!
Kindest regards,
Aoife
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney