Orphaned packages looking for new maintainers
Report started at 2024-05-21 23:14:51 UTC The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in the left column on https://src.fedoraproject.org/rpms/ Full report available at: https://a.gtmx.me/orphans/orphans.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change 3Depict orphan 0 weeks ago BitchXorphan, rdieter 0 weeks ago ansible-collection-community- @infra-sig, gotmax23, orphan 0 weeks ago rabbitmq balsa orphan 0 weeks ago bti orphan 4 weeks ago buildstream atim, orphan 0 weeks ago container-exception-logger@abrt-sig, mmarusak, orphan 0 weeks ago cutecworphan 0 weeks ago dnssec-nodes orphan 0 weeks ago dnssec-system-trayorphan 0 weeks ago dnssec-tools orphan 0 weeks ago erlang-p1_acme@erlang-maint-sig, orphan1 weeks ago fleet-commander-admin orphan 0 weeks ago fleet-commander-clientorphan 0 weeks ago gofer orphan 0 weeks ago golang-github-client9-gospell @go-sig, orphan 0 weeks ago golang-github-elves-elvish@go-sig, orphan 4 weeks ago golang-github-xiaq-persistent @go-sig, orphan 4 weeks ago golang-k8s-cli-runtime@go-sig, orphan 1 weeks ago golang-k8s-kubectl@go-sig, orphan 1 weeks ago gtypist orphan 0 weeks ago jgit orphan 0 weeks ago jolokia-jvm-agent orphan 6 weeks ago kanotf-fonts orphan 0 weeks ago laf-pluginorphan 0 weeks ago levien-museum-fonts orphan 0 weeks ago libitlmoceap, orphan 0 weeks ago logserial orphan 0 weeks ago lookuporphan 0 weeks ago mingw-cppunit orphan 3 weeks ago mingw-freeimage orphan 6 weeks ago mingw-sword orphan 1 weeks ago neofetch orphan 2 weeks ago nuntius kalev, orphan0 weeks ago oc-inject orphan 0 weeks ago perl-Crypt-OpenSSL-PKCS10 orphan 0 weeks ago perl-Flickr-API orphan 0 weeks ago perl-Flickr-Uploadorphan 0 weeks ago perl-Getopt-GUI-Long orphan 0 weeks ago perl-QWizard orphan 0 weeks ago pidgin-guifications nosnilmot, orphan0 weeks ago prometheus-jmx-exporter orphan 6 weeks ago prometheus-simpleclient-java orphan 6 weeks ago python-git-changelog @neuro-sig, orphan, 0 weeks ago vanessakris python-glue orphan 0 weeks
F41 Change Proposal: Anaconda as native Wayland application (System Wide)
Wiki - https://fedoraproject.org/wiki/Changes/Anaconda_As_Native_Wayland_Application Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-anaconda-as-native-wayland-application-system-wide/118550 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 == Currently, Anaconda is still an X11 application, which we would like to fix and make Anaconda Wayland native application to allow us drop of the X11 dependencies from installation ISO images. However, this change is not just a simple switch and we need to do some adjustments during the path which will impact user experience. == Owner == * Name: Anaconda team ([[User:jkonecny| Jiří Konečný]]) * Email: jkone...@redhat.com == Detailed Description == Anaconda is required to migrate to Wayland native application to drop dependencies from the installation ISO images which are deprecated. Package owners want to drop libXklavier from Fedora (see https://bugzilla.redhat.com/show_bug.cgi?id=1955025 ) but also Xorg server from CentOS Stream and RHEL. However, this change won’t be just simple switching from X11 to Wayland, we also need to change a few things in Anaconda to be able to remove the X11 dependencies. This will have two main visible impacts listed below. === VNC switch to RDP for remote GUI installations === Anaconda has to remove ‘TigerVNC' which is used for VNC connection to be able to install your machine remotely with graphical UI. Reason is that TigerVNC is built from the Xorg server sources, so we would still depend on the Xorg server with this project. As replacement, we follow the recommendation of the Fedora Workstation to switch to Gnome Remote Desktop (grd) with a better protocol Remote Desktop Protocol (RDP) which gives users better performance and security. This will have an impact on current vnc kickstart commands and kernel boot options of Anaconda. This will impact only the Anaconda installation environment (boot.iso). === Consistent keyboard control === Currently, Anaconda experiences difficulties in handling keyboard layouts in the installation environment, particularly on Wayland. Formerly, libXklavier was utilized by Anaconda to manage keyboard layout configuration, however, it proved unstable on Wayland. As a result, Anaconda has disabled keyboard handling during Wayland Live media installations due to unexpected behavior (refer to https://bugzilla.redhat.com/show_bug.cgi?id=2016613 ). This approach may lead to situations when users encountering issues while unlocking LUKS devices or using user passwords in the installed system because installation was done with a different keyboard layout. To exacerbate the situation, there is no universally applicable solution for keyboard handling on Wayland systems, as Wayland lacks a unified API for keyboard management. It means that each Fedora Desktop Environment developed their own API. Unfortunately, the Anaconda team is not able to maintain a custom solution for each Fedora spin. Some Desktop environments started to use '''systemd-localed''' DBus API to address this issue and similar issues. The systemd-localed API seems to be the best approach currently, so we want to promote it as a shared solution for all Fedora spins. The plan is: * All Fedora spins and Anaconda listen on '''org.freedesktop.locale1''' and reflect configuration on the currently running system (might be only for Live media if desired) * All Fedora spins and Anaconda reflect their configuration to org.freedesktop.locale1 * In case Fedora spin will not support '''org.freedesktop.locale1''', the keyboard configuration of Anaconda won’t be reflected in the current system and the situation will be similar to the current Live Wayland experience All the spin owners were notified about this request: * https://pagure.io/fedora-workstation/issue/430 * https://pagure.io/fedora-kde/SIG/issue/504 * https://gitlab.com/fedora/sigs/sway/SIG/-/issues/36 * https://bugzilla.redhat.com/show_bug.cgi?id=2278655 * https://bugzilla.redhat.com/show_bug.cgi?id=2278658 * https://bugzilla.redhat.com/show_bug.cgi?id=2278656 * https://bugzilla.redhat.com/show_bug.cgi?id=2278864 * https://bugzilla.redhat.com/show_bug.cgi?id=2278866 * https://bugzilla.redhat.com/show_bug.cgi?id=2278869 * https://bugzilla.redhat.com/show_bug.cgi?id=2278874 * https://pagure.io/fedora-cosmic/SIG/issue/1 * https://pagure.io/fedora-budgie/project/issue/4 * https://pagure.io/fedora-lxqt/SIG/issue/4 * https://pagure.io/i3-sig/Fedora-i3-Spin/issue/70 == Feedback == We have some feedback from the SIG owners for the keyboard handling (see the links above). We don’t have feedback for the VNC to RDP switch yet. == Benefit to Fedora == * This change will enable removal of X11 dependencies from the Ana
F41 Change Proposal: LLVM 19 (System-Wide)
Wiki - https://fedoraproject.org/wiki/Changes/LLVM-19 Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-llvm-19-system-wide/118552 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: == 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 Change Proposal: Removing network-scripts package (System-Wide)
Wiki - https://fedoraproject.org/wiki/Changes/NetworkScriptsRemoval Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-removing-network-scripts-package-system-wide/118553 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 == network-scripts package will be removed in Fedora 41. By removing the package, we also remove support for legacy ifup/ifdown network scripts that have been deprecated since 2018. == Owner == * Name: [[User:jamacku| Jan Macku]] * Name: [[User:lnykryn| Lukáš Nykrýn]] * Email: [mailto:jama...@redhat.com jama...@redhat.com] * Email: [mailto:lnyk...@redhat.com lnyk...@redhat.com] == Detailed Description == network-scripts will be removed in Fedora 41. It provides legacy ifup/ifdown scripts as well as network.service. The network-scripts were '''deprecated in 2018''', and since then, upstream has provided only limited support. The main reason for removing network-scripts 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 network-scripts rpm package. * Other developers: Make sure that dependency on network-scripts 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 == ifup/ifdown command are no longer available. Use nmcli connection up/down or networkctl up/down instead. Old ifcfg network configuration should still work thanks to NetworkManager-initscripts-ifcfg-rh package. No migration is needed, but it is recommended to migrate from ifcfg to keyfiles 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-configuration == How To Test == Networking should work as before the removal of network-scripts package. == User Experience == == Dependencies == RPM packages that depends in some form on network-scripts: * libteam - https://bugzilla.redhat.com/show_bug.cgi?id=2262986 * NetworkManager - https://bugzilla.redhat.com/show_bug.cgi?id=2275295 * openvswitch - https://bugzilla.redhat.com/show_bug.cgi?id=2262982 * ppp - 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 network-scripts 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/b748244cf9905696baf1bc16e0432f85093414c2 == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[HEADS UP] Fedora 41 Python 3.13 rebuilds to start in a side tag (hopefully) next week
Hello, To deliver Python 3.13 with Fedora Linux 41, we will run a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.13 Python 3.13.0b2 is scheduled for Tuesday, Jun 4th 2024. We hope to start the mass rebuild shortly after it's available. TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.13. Details: If you see a "Rebuilt for Python 3.13" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f41-python $ koji wait-repo f41-python --build It takes time to build all the essential packages, so don't expect all your dependencies to be available right away. Any attempts to build your packages in the side tag before we do will likely fail due to missing dependencies. When in trouble, ask here or on Fedora's Matrix - Fedora Python room (https://matrix.to/#/#python:fedoraproject.org) Ping me (ksurma) or Miro (mhroncok) if you need to talk to us. Builds will appear here: https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f41-python&order=-build_id&inherited=0 Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over. Thanks! Karolina -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
41 Change Proposal: Make Tuned the Default Power Profile Management Daemon (System-Wide)
Wiki - https://fedoraproject.org/wiki/Changes/TunedAsTheDefaultPowerProfileManagementDaemon Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-make-tuned-the-default-power-profile-management-daemon-system-wide/118554 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: , == Detailed Description == 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. 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. Tuned released a new translation API service called tuned-ppd https://github.com/redhat-performance/tuned/tree/master/tuned/ppd. 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 https://github.com/redhat-performance/tuned/blob/master/tuned/ppd/ppd.conf. 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. 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. == Feedback == '''From fedora-devel''' https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/B3UJKFOCRAY3BEEPTHVPW4RY5GFBZWHU/#B3UJKFOCRAY3BEEPTHVPW4RY5GFBZWHU 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. '''From the hardware vendor''' 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
F41 Change Proposal: Unprivileged updates for Fedora Atomic Desktops (Self-Contained)
Wiki - https://fedoraproject.org/wiki/Changes/UnprivilegedUpdatesAtomicDesktops
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-unprivileged-updates-for-fedora-atomic-desktops-self-contained/118556
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]], boredsquir...@secure.mailbox.org
* [[User:Siosm| Timothée Ravier]], si...@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`
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.rollbac
F41 Change Proposal: Golang 1.23 (System-Wide)
Wiki - https://fedoraproject.org/wiki/Changes/golang1.23
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-golang-1-23-system-wide/118631
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: 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/de...@lists.fedoraproject.org/thread/ZQROWTMARIUS45KIQZIUNAA45K3NWLRW/
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 ==
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'
Omitted due to the number of packages listed: ~2000.
== 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@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@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.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
