CentOS Errata and Bugfix Advisory 2024:1540
Upstream details at : https://access.redhat.com/errata/RHBA-2024:1540
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
096e36a0f28a54f5ad7c593b2efd58ee933bf7f9c314927179a6d0244e0a596a redhat-support-tool-0.14.0-1.el7_9.noarch.rpm
Source:
a470b95be4f9036778b3805dd90ad0bc8b196f7a847826345e04fb9da5e963dd redhat-support-tool-0.14.0-1.el7_9.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos@libera.chat
Twitter: @JohnnyCentOS
_______________________________________________
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
Wednesday, April 3, 2024
[CentOS-announce] CEBA-2024:1540 CentOS 7 redhat-support-lib-python BugFix Update
CentOS Errata and Bugfix Advisory 2024:1540
Upstream details at : https://access.redhat.com/errata/RHBA-2024:1540
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
623f1a82453fc1bd44617826a88974cd43fbbb30a2d72e47bd706b0deb895254 redhat-support-lib-python-0.14.0-1.el7_9.noarch.rpm
Source:
4492c7df1e69f89395e1347815fd9bafe952d299b2b29541c850ad72a553939e redhat-support-lib-python-0.14.0-1.el7_9.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos@libera.chat
Twitter: @JohnnyCentOS
_______________________________________________
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
Upstream details at : https://access.redhat.com/errata/RHBA-2024:1540
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
623f1a82453fc1bd44617826a88974cd43fbbb30a2d72e47bd706b0deb895254 redhat-support-lib-python-0.14.0-1.el7_9.noarch.rpm
Source:
4492c7df1e69f89395e1347815fd9bafe952d299b2b29541c850ad72a553939e redhat-support-lib-python-0.14.0-1.el7_9.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos@libera.chat
Twitter: @JohnnyCentOS
_______________________________________________
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
[CentOS-announce] CESA-2024:1498 Moderate CentOS 7 thunderbird Security Update
CentOS Errata and Security Advisory 2024:1498 Moderate
Upstream details at : https://access.redhat.com/errata/RHSA-2024:1498
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
de56cf10dbbabd9a55f388bacf02eb1f5bb04b430bbad9a217d6dc57141aaeb5 thunderbird-115.9.0-1.el7.centos.x86_64.rpm
Source:
2a36182ee2aeb5bbdb7c973d6d48bc6a4a929f8d3a3b0c8ffd8e35debc2ce22f thunderbird-115.9.0-1.el7.centos.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos@libera.chat
Twitter: @JohnnyCentOS
_______________________________________________
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
Upstream details at : https://access.redhat.com/errata/RHSA-2024:1498
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
de56cf10dbbabd9a55f388bacf02eb1f5bb04b430bbad9a217d6dc57141aaeb5 thunderbird-115.9.0-1.el7.centos.x86_64.rpm
Source:
2a36182ee2aeb5bbdb7c973d6d48bc6a4a929f8d3a3b0c8ffd8e35debc2ce22f thunderbird-115.9.0-1.el7.centos.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos@libera.chat
Twitter: @JohnnyCentOS
_______________________________________________
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
[CentOS-announce] CESA-2024:1486 Critical CentOS 7 firefox Security Update
CentOS Errata and Security Advisory 2024:1486 Critical
Upstream details at : https://access.redhat.com/errata/RHSA-2024:1486
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
33dd225ef7b01c077e7d0977782fa69f3d8fd4cea6363f4cde213cc37694b3a2 firefox-115.9.1-1.el7.centos.i686.rpm
2f160bf3a57455fd82821ea858e6ab2789596f1ae502a2b3968383670f17296f firefox-115.9.1-1.el7.centos.x86_64.rpm
Source:
3267298df86f1f220840ce663243282de3bd1cdbe0eabd1485f3f01ad1ae07ec firefox-115.9.1-1.el7.centos.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos@libera.chat
Twitter: @JohnnyCentOS
_______________________________________________
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
Upstream details at : https://access.redhat.com/errata/RHSA-2024:1486
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
33dd225ef7b01c077e7d0977782fa69f3d8fd4cea6363f4cde213cc37694b3a2 firefox-115.9.1-1.el7.centos.i686.rpm
2f160bf3a57455fd82821ea858e6ab2789596f1ae502a2b3968383670f17296f firefox-115.9.1-1.el7.centos.x86_64.rpm
Source:
3267298df86f1f220840ce663243282de3bd1cdbe0eabd1485f3f01ad1ae07ec firefox-115.9.1-1.el7.centos.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos@libera.chat
Twitter: @JohnnyCentOS
_______________________________________________
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
F41 Change Proposal: Switch to DNF5 (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/SwitchToDnf5
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 ==
Change the default package manager from dnf to dnf5.
== Owner ==
* Name: [[User:jkolarik| Jan Kolarik]]
* Email: jkolarik@redhat.com
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmracek@redhat.com
== Detailed Description ==
This proposal will implement several topics, which are outlined below.
=== Provider of the dnf command ===
This change proposes to switch the current provider of the
/usr/bin/dnf symlink from dnf to dnf5. Currently, the symlink target
is /usr/bin/dnf-3, provided by the dnf sub-package, python3-dnf. Upon
implementation of this change, the symlink will point to
/usr/bin/dnf5, provided by the dnf5 package.
=== Prepare the upgrade path ===
The dnf5 package, serving as the new provider of the /usr/bin/dnf
symlink, will obsolete the dnf package starting with Fedora 41. Upon
the release of this dnf5 package, upgrading the system or installing
dnf5 will replace the existing dnf package on the system.
Additionally, the dnf5 package will provide a /usr/bin/yum symlink for
backwards compatibility and the dnf-automatic command will be
obsoleted.
=== Feature parity with dnf ===
We aim to cover the majority of use cases available in the existing
dnf package. However, there are some features that may not be
implemented in time. Nevertheless, we plan to deliver them at a later
stage.
==== Plugins ====
The progress of implementing plugins to match the current set from the
dnf-plugins-core package is tracked
[https://github.com/rpm-software-management/dnf5/issues/389 upstream].
Among the missing plugins, we still plan to implement:
* debuginfo-install plugin
* reposync plugin
==== Modularity ====
As support for modularity was retired in Fedora 39, dnf5 currently
only implements a basic feature set for listing and enabling/disabling
modules.
=== Background service support ===
A new daemonized service, dnf5daemon, utilizing the D-Bus interface,
is prepared for clients as a sub-package. This will serve as an
alternative or replacement for the PackageKit layer. Integration of
dnf5daemon support into the default Fedora user interface, GNOME
Software, is currently in progress
=== Documentation of API changes ===
The public interface has undergone significant changes to enhance the
user experience and remove unused and obsolete code components. To
facilitate user migration to the new CLI and API interfaces, a
[https://dnf5.readthedocs.io/en/latest/changes.html guide] was
prepared covering all differences compared to the interface provided
by the existing dnf package, along with examples of typical use cases.
=== Deployment tasks ===
During the deployment of the dnf5 package manager as the new default,
several adjustments need to be made both to the infrastructure and the
dnf5 package itself. Some of these adjustments are detailed [[#Release
engineering|below]]. To ensure synchronization and address all
necessary changes, we've established an upstream tracking
[https://github.com/rpm-software-management/dnf5/issues/1057 issue].
== Feedback ==
As this is the second iteration of such a proposal, we've gathered a
lot of feedback from various sources during the first attempt to
accept this change.
=== FESCo inputs ===
A [https://pagure.io/fesco/issue/3039 ticket] discussing the reasons
why the contingency mechanism was invoked for the first attempt of the
proposal was opened by FESCo. It includes a list of items that are
either incomplete or in progress.
Below is a list of issues from the ticket that are still unresolved or
require clarification on their current status. Other items not
mentioned below are considered completed.
==== Switch in ELN ====
This should not block the proposal, as the current plan is to target
RHEL 11. Integration can occur there after the proposal is implemented
for Fedora 41.
==== Aligning configuration with the current state in dnf ====
All overrides to match the current state of dnf configuration will be
provided to the Fedora release project, see [[#Apply downstream
configuration overrides|below]].
==== System upgrade and offline transactions ====
The implementation work has been completed and is already present
upstream. We anticipate extensive testing during the summer, and we
also plan to organize testing days for this purpose.
==== Dropping the Snapper plugin ====
In dnf5, we've adopted a new approach for implementing functionality
that was previously handled by the Snapper plugin in dnf.
We're introducing the Actions plugin, which offers more capabilities
than the Snapper plugin, including support for running external
applications before or after transactions and interacting with the
dnf5 configuration.
[https://dnf5.readthedocs.io/en/latest/libdnf5_plugins/actions.8.html
Here] is the documentation for the Actions plugin, which includes
examples of how to emulate the behavior of the Snapper plugin.
==== Messages from RPM scriptlets ====
An issue with output from RPM scriptlets is the potential length,
coupled with the absence of a standardized policy for distinguishing
between important and unimportant messages.
Currently, all messages are logged in the dnf5 log files, with
differentiation based on their originating scriptlets, representing an
improvement over dnf. Additionally, in case of transaction errors, the
scriptlet output is included in the standard output. Furthermore,
there is already a resolved [https://pagure.io/koji/issue/4009 ticket]
in the infrastructure to incorporate logs on the builders.
=== Testing days ===
We've already held several dnf5 test days for Fedora
[https://fedoraproject.org/wiki/Test_Day:2023-03-14_Fedora_38_DNF_5
38], [https://fedoraproject.org/wiki/Test_Day:2023-08-11_Fedora_39_DNF_5
39], and recently also
[https://fedoraproject.org/wiki/Test_Day:2024-03-15_Fedora_40_DNF_5
40]. We've made efforts to document all reported issues in our
upstream tracking system, and major issues should now be resolved.
Some of these issues were related to user documentation, improving
command-line outputs, and enhancing overall user experience. These
topics are next on our priority list after completing the
functionality for mandatory commands and plugins.
=== Fedora QA scenarios ===
We've started a discussion
[https://discussion.fedoraproject.org/t/requirements-for-dnf5-in-fedora-41
thread] on the requirements for accepting this proposal from a QA
perspective. A list of relevant test cases and criteria has been
mentioned, which we'll review to ensure we've covered everything on
our end.
=== Fedora CI readiness ===
The dnf project is also deployed in the CI pipeline. We've initiated
communications with this team to ensure that all dnf functionality
used there is either already implemented in dnf5 or can be addressed
through an alternative dnf5 method. We've already received some
feedback from the first iteration of the proposal.
=== Tracking issue upstream ===
When implementing the first iteration of this proposal, we created an
upstream [https://github.com/rpm-software-management/dnf5/issues/635
ticket] to track all bugs or lack of needed functionality. All items
have been addressed, and only several known deployment issues remain,
which need to be managed at the time of the next switch.
== Benefit to Fedora ==
The new dnf5 will significantly improve the user experience and
performance. Detailed descriptions of individual areas are provided
below.
=== Reduced footprint ===
The dnf5 package is a fully-featured package manager that doesn't
require Python dependencies.
It also reduces the number of software management tools in Fedora by
replacing both the dnf and microdnf packages.
The installation size of the dnf5 stack in an empty container is
approximately 60% smaller than the dnf installation.
Currently, dnf, microdnf, and PackageKit use their own cache, leading
to significant metadata redundancy. With dnf5 and dnf5daemon, which
share metadata, this redundancy will be eliminated.
=== Enhanced performance ===
Loading and downloading repository metadata now occur concurrently.
Package query operations, including processing numerous command-line
arguments, have been significantly accelerated.
=== Lowered maintenance costs ===
Many functional duplicates in dnf were eliminated during the
development of the new dnf5 package manager. This was partly because
the integration of the original PackageKit and dnf libraries into the
original libdnf library was never completed.
Plugins are now included in the same package as the core functionality.
=== Unified user experience ===
Consistent user experience is offered to users across servers,
workstations, and containers, as dnf5 is the sole package manager
deployed there. Existing dnf, yum, and microdnf commands will be
linked to dnf5, while compatibility aliases for essential use cases
will be provided to facilitate migration.
Configuration files will be shared among dnf5 components.
API users will encounter unified code style and naming conventions.
Various scripting language interfaces are now provided from a single
source using SWIG bindings (formerly CPython and SWIG).
== Scope ==
=== Proposal owners ===
The remaining work on the proposal can be divided into several sections.
==== Feature implementation ====
===== [https://github.com/rpm-software-management/dnf5/issues/1052
System upgrade] =====
This command is essential for upgrading the system to the next
release. While the implementation is already completed, we plan to
conduct extensive testing, including community participation, to
minimize the risk of issues occurring in production.
===== [https://github.com/rpm-software-management/dnf5/issues/140
History command] =====
The functionality related to manipulating transaction history has not
yet been implemented. However, following the completion of the system
upgrade functionality, it is currently our top priority. Due to the
significant overlap between the functionality in the history command
and the system upgrade functionality, we anticipate its readiness
shortly thereafter.
===== [https://github.com/rpm-software-management/dnf5/issues/169
GNOME Software support] =====
The integration of dnf5 support, particularly dnf5daemon, into GNOME
Software is currently underway. Developers from both DNF5 and GNOME
Software are closely connected and regularly synchronize the progress
of their work.
==== Documentation ====
While our current priority is achieving full coverage of
[https://dnf5.readthedocs.io/en/latest/ user and API documentation],
there may still be some undocumented parts of the code. Please don't
hesitate to [https://github.com/rpm-software-management/dnf5/issues/new
report] any such issues upstream, and we'll endeavor to address them
promptly.
==== Early access for developmental branch users ====
The intention is to implement the proposed changes in the Rawhide
developmental branch prior to the date specified in the Contingency
Deadline section, targeting the transition period between March and
April. It is anticipated that certain mandatory items for the regular
release, as outlined in previous sections, may not be completed by
this time.
===== System upgrade =====
This functionality is unnecessary as Rawhide operates on a rolling
release model.
===== GNOME Software =====
Rawhide users will continue to utilize the current PackageKit backend
connected to the existing libdnf interface until the integration of
dnf5 is finalized. These libraries can coexist with the new dnf5
package on the same system. For more details, see [[#Different system
state|below]].
=== Other developers ===
The following components are already prepared for transition to dnf5:
* [https://github.com/ansible/ansible/issues/78898 Ansible]
* [https://github.com/rpm-software-management/dnf5/issues/66 Lorax]
* [https://github.com/rpm-software-management/mock/issues/894 Mock]
Below is a list of dependencies that have not yet integrated with dnf5.
==== Anaconda ====
Migration to the dnf5 API will not be implemented at this time. After
discussion with the Anaconda team, it was determined that there isn't
sufficient capacity and time to complete the work on schedule.
Therefore, the existing dnf4 Python bindings from the python3-dnf
package will continue to be used for now.
==== GNOME Software ====
This integration is already addressed in the section above, as it
involves collaborative efforts.
=== Release engineering ===
==== Building with dnf5 ====
The Fedora infrastructure has been utilizing dnf5 for building Fedora
40+ chroots since before the Fedora 40 mass rebuilds began. This
implementation was based on the system-wide change outlined
[https://fedoraproject.org/wiki/Changes/BuildWithDNF5 here].
==== Apply downstream configuration overrides ====
Starting with dnf5, distro-specific overrides of the default
configuration values are implemented using
[https://dnf5.readthedocs.io/en/latest/dnf5.conf.5.html#drop-in-configuration-directories
drop-in directories]. Options with different values upstream compared
to the current state of dnf in Fedora will be filed in a pull request
against the [https://src.fedoraproject.org/rpms/fedora-release Fedora
release project].
==== Update of kickstarts for image composes ====
The dnf team will prepare a pull request to include the packages for
the new default dnf5 package manager in the
[https://pagure.io/fedora-kickstarts Fedora Kickstarts project].
==== Update of package groups definitions ====
The dnf team will prepare a pull request to include the packages for
the new default dnf5 package manager in the
[https://pagure.io/fedora-comps Fedora Comps project].
==== Update of KIWI image descriptions ====
The dnf team will prepare a pull request to include the packages for
the new default dnf5 package manager in the
[https://pagure.io/fedora-kiwi-descriptions Fedora KIWI descriptions
project].
== Upgrade/compatibility impact ==
=== Running the upgrade ===
The dnf5 package will be installed on the system to provide
/usr/bin/dnf, replacing the existing dnf package as it becomes
obsolete. Additionally, the dnf automatic tool will be replaced by the
new dnf5 automatic plugin.
Below is an example of performing this upgrade transaction.
<pre>
$ sudo dnf upgrade
Last metadata expiration check: 0:01:09 ago on Wed 13 Mar 2024 05:48:25 AM EDT.
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
dnf5-plugin-automatic x86_64 5.1.14-1.fc41 rawhide 120 k
replacing dnf-automatic.noarch 4.19.0-1.fc40
Upgrading:
dnf-data noarch 4.19.0-1.fc41 rawhide 40 k
python3-dnf noarch 4.19.0-1.fc41 rawhide 551 k
Installing group/module packages:
dnf5 x86_64 5.1.14-1.fc41 rawhide 599 k
replacing dnf.noarch 4.19.0-1.fc40
replacing yum.noarch 4.19.0-1.fc40
Installing dependencies:
fmt x86_64 10.2.1-3.fc40 rawhide 125 k
libdnf5 x86_64 5.1.14-1.fc41 rawhide 991 k
libdnf5-cli x86_64 5.1.14-1.fc41 rawhide 229 k
Installing weak dependencies:
bash-completion noarch 1:2.11-15.fc41 rawhide 360 k
Transaction Summary
================================================================================
Install 6 Packages
Upgrade 2 Packages
</pre>
=== Binaries and symlinks ===
The existing dnf binaries will remain on the system and will be
available at /usr/bin/dnf-3, which refers to the Python 3 version to
which dnf was migrated in the past. Additionally, they will be
accessible at /usr/bin/dnf4, which is a symlink to the dnf-3 script
and denotes the major version of the dnf binary. This binary naming
convention is also used for /usr/bin/dnf5, which will become the
target of the /usr/bin/dnf symlink.
Below is the output of the tree command showing the expected file
structure after the upgrade.
==== Before upgrade ====
<pre>
$ tree /usr/bin/ -P dnf*
/usr/bin/
├── dnf -> dnf-3
├── dnf-3
└── dnf4 -> dnf-3
</pre>
==== After upgrade ====
<pre>
$ tree /usr/bin/ -P dnf*
/usr/bin/
├── dnf -> dnf5
├── dnf-3
├── dnf4 -> dnf-3
└── dnf5
</pre>
=== Different system state ===
Though the RPM DB, which contains the database of installed packages,
remains the singular source in the system, the transactional history
and installed packages reasons in dnf and dnf5 is not shared, and they
now use different formats.
Transactions performed in dnf will not be visible in dnf5, and vice
versa. Therefore, when concurrently using dnf and dnf5 on the system,
packages installed by one of them as dependencies will appear as
user-installed to the other one, potentially leading to them not being
auto-removed later.
While the history database is not migrated to dnf5, when running a
transaction in dnf5 for the first time, an attempt is made to convert
and load the existing system state from dnf. This should preserve
information about the reasons for installed packages and prevent them
from being treated as user-installed, requiring manual removal from
the system instead of being seen as dependencies of explicitly removed
packages.
=== Compatibility ===
While the majority of CLI use cases for managing packages should
remain the same, the dnf5 API has undergone significant changes. To
ease adoption, dnf5 will provide compatibility aliases for commands
and options. Additionally, user output will differ, and we plan to
offer machine-readable support for most commands. For more details,
please refer to the section above.
Applications encountering difficulties with dnf5 adoption can continue
using the existing dnf CLI and API provided by the python3-dnf and
libdnf packages. These libraries can be used in parallel on the
system, but modifying installed software is not recommended due to
differences in system state, as mentioned in the [[#Documentation of
API changes|previous]] section.
== How To Test ==
=== Copr repository ===
[https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-testing/
A testing Copr repository] has been set up with dnf5 already deployed
as the default package manager. Instructions on how to proceed are
provided alongside.
=== Quay containers ===
We have also prepared Fedora container images with the dnf5 stack
preinstalled on
[https://quay.io/repository/rpmsoftwaremanagement/fedora-dnf5
quay.io], making it easy to test in isolation with Podman.
=== Side-tag for testing ===
Before pushing the new dnf5 into the Rawhide compose, we plan to
announce the prepared side-tag containing this new package publicly.
This will allow interested parties to test it against their software.
=== Testing days ===
We are planning at least two iterations of testing days before dnf5 is
delivered into Fedora 41. One will focus on testing the overall
functionality of dnf5, with an emphasis on parts that were not tested
during previous testing days. The other iteration will center around
testing the system upgrade functionality.
=== Communication channels ===
Community feedback, including bug reports, issues, or feature
requests, is highly encouraged.
Our primary communication channel is
[https://github.com/rpm-software-management/dnf5 upstream], where you
can report [https://github.com/rpm-software-management/dnf5/issues
issues], participate in
[https://github.com/rpm-software-management/dnf5/discussions
discussions], or even propose
[https://github.com/rpm-software-management/dnf5/pulls pull requests].
We are happy to review them.
Issues specific to a particular version of the dnf5 package can also
be reported through the
[https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dnf5
Bugzilla] tracking system, which we also monitor.
== User Experience ==
=== Faster query processing ===
The processing of package metadata is now significantly faster.
Executing commands such as repoquery to list packages available in
repositories is now twice as fast compared to dnf. Similarly,
operations like listing dependencies or parsing numerous command-line
arguments are notably expedited, potentially saving users seconds to
tens of seconds in waiting time for the results.
=== Consolidated and streamlined API ===
The API for managing packages, working with repositories, and solving
package dependencies is now consolidated into a single component,
providing a unified solution. The original dnf API underwent a review
process, during which unused workflows and obsolete methods were
removed, while improving usability for users.
=== Enhanced command-line outputs ===
Transaction tables now offer more detailed information, verbose
scriptlet outputs are redirected and organized by package name into
log files, individual commands come with their own man pages, bash
completion has been enhanced, and numerous other improvements have
been made.
== Dependencies ==
=== Owned by our team ===
==== dnf-plugins-core ====
Installed plugins will persist on the system and remain functional
using the dnf4 binary from the python3-dnf package.
With the exception of the system upgrade plugin, all essential plugins
are now implemented in dnf5 and are provided by the dnf5-plugins
package or dnf5 directly.
==== dnf-plugins-extras ====
Installed plugins will persist on the system and remain functional
using the dnf4 binary from the python3-dnf package.
Porting the functionality to dnf5 is currently of low priority, and
its implementation depends more on community involvement. The
functionality of the Snapper plugin is already covered by the dnf5
actions plugin.
=== Requirements on dnf ===
This is the most critical category of packages as issues connected
with them can potentially disrupt the system upgrade path.
Here, we can split components into two groups.
The first group utilizes dnf from the command line interface (CLI),
and thus, they either need to adjust to the new syntax and behavior of
dnf5 or switch to utilizing the existing dnf4 binary directly.
The second group consists of components providing plugins for the dnf
command. These plugins will remain functional using the binary from
python3-dnf, requiring packaging changes to depend on this package
instead.
<pre>
auter
calamares
copr-builder
cpanspec
dnfdragora
etckeeper-dnf
fedora-review
fedora-upgrade
kiwi-systemdeps-core
libdnf-plugin-subscription-manager
lpf
mock
osbuild
perl-CPAN-Plugin-Sysdeps
rbm
rpmdistro-repoquery
supermin
system-config-language
</pre>
A tracking [https://github.com/rpm-software-management/dnf5/issues/418
issue] was created in advance to inform maintainers about the planned
switch to dnf5.
=== Requirements on python3-dnf ===
Here, we can also categorize components into two groups.
The first group consists of components providing plugins for the dnf
command. These plugins will remain functional using the binary from
python3-dnf, requiring packaging changes to depend on this package
instead.
The second group utilizes the dnf's Python API, and they should not be
directly affected by the change. However, testing is still necessary,
and it is strongly recommended to consider porting to the dnf5 API.
<pre>
anaconda-core
copr-builder
dnf-plugin-diff
dnf-plugin-ovl
dnfdaemon
fedora-easy-karma
fedora-review
fedrq
lorax
mock-core-configs
module-build-service
modulemd-tools
needrestart
policycoreutils-devel
pungi
python3-dnf-plugin-cow
python3-dnf-plugin-flunk_dependent_remove
python3-dnf-plugin-perfmetrics
python3-imgcreate
python3-libreport
retrace-server
subscription-manager
system-config-language
</pre>
=== Requirements on libdnf ===
These packages utilize the libdnf API and should not be directly
impacted by the change. However, testing is still necessary.
Tools that modify system software, such as PackageKit, may exhibit
different behavior when used alongside dnf5 to manage the same system,
as previously described.
Additionally, it is strongly recommended to consider porting to the
dnf5 API in this context.
<pre>
PackageKit
copr-builder
libdnf-plugin-subscription-manager
libdnf-plugin-swidtags
libdnf-plugin-txnupd
</pre>
=== Requirements on python3-hawkey ===
These components utilize unsupported Hawkey Python bindings and should
not be directly impacted by the change. However, thorough testing is
necessary. Again, it is strongly recommended to consider porting to
the dnf5 API in this context.
<pre>
mock-core-configs
modulemd-tools
python3-rpmdeplint
retrace-server
</pre>
== Contingency Plan ==
=== Contingency mechanism ===
To revert to the previous state with dnf as the default package
manager on the system, the following steps would be necessary:
* Packaging changes in dnf5 to remove the obsoletion of dnf and
provider of the /usr/bin/dnf symlink.
* Untagging the candidate dnf5 package from the compose.
* Components that adapted to the dnf5 CLI must synchronize in this
process and revert the changes to use dnf4 again. Proactive
communication will be conducted similarly to how components were
informed about the dnf5 migration.
=== Contingency deadline ===
Branch Fedora Linux 41 from Rawhide
=== Blocks release? ===
No
== Documentation ==
=== [https://dnf5.readthedocs.io/en/latest/index.html Official
documentation] ===
=== [https://github.com/rpm-software-management/dnf5 Upstream project] ===
=== [https://dnf5.readthedocs.io/en/latest/changes.html Changes
between dnf and dnf5] ===
=== [https://dnf5.readthedocs.io/en/latest/dnf_daemon/dnf5daemon_dbus_api.8.html
D-Bus API documentation] ===
=== [https://github.com/rpm-software-management/dnf5/blob/main/CONTRIBUTING.md
Contributing guide for developers] ===
== 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-leave@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
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 ==
Change the default package manager from dnf to dnf5.
== Owner ==
* Name: [[User:jkolarik| Jan Kolarik]]
* Email: jkolarik@redhat.com
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmracek@redhat.com
== Detailed Description ==
This proposal will implement several topics, which are outlined below.
=== Provider of the dnf command ===
This change proposes to switch the current provider of the
/usr/bin/dnf symlink from dnf to dnf5. Currently, the symlink target
is /usr/bin/dnf-3, provided by the dnf sub-package, python3-dnf. Upon
implementation of this change, the symlink will point to
/usr/bin/dnf5, provided by the dnf5 package.
=== Prepare the upgrade path ===
The dnf5 package, serving as the new provider of the /usr/bin/dnf
symlink, will obsolete the dnf package starting with Fedora 41. Upon
the release of this dnf5 package, upgrading the system or installing
dnf5 will replace the existing dnf package on the system.
Additionally, the dnf5 package will provide a /usr/bin/yum symlink for
backwards compatibility and the dnf-automatic command will be
obsoleted.
=== Feature parity with dnf ===
We aim to cover the majority of use cases available in the existing
dnf package. However, there are some features that may not be
implemented in time. Nevertheless, we plan to deliver them at a later
stage.
==== Plugins ====
The progress of implementing plugins to match the current set from the
dnf-plugins-core package is tracked
[https://github.com/rpm-software-management/dnf5/issues/389 upstream].
Among the missing plugins, we still plan to implement:
* debuginfo-install plugin
* reposync plugin
==== Modularity ====
As support for modularity was retired in Fedora 39, dnf5 currently
only implements a basic feature set for listing and enabling/disabling
modules.
=== Background service support ===
A new daemonized service, dnf5daemon, utilizing the D-Bus interface,
is prepared for clients as a sub-package. This will serve as an
alternative or replacement for the PackageKit layer. Integration of
dnf5daemon support into the default Fedora user interface, GNOME
Software, is currently in progress
=== Documentation of API changes ===
The public interface has undergone significant changes to enhance the
user experience and remove unused and obsolete code components. To
facilitate user migration to the new CLI and API interfaces, a
[https://dnf5.readthedocs.io/en/latest/changes.html guide] was
prepared covering all differences compared to the interface provided
by the existing dnf package, along with examples of typical use cases.
=== Deployment tasks ===
During the deployment of the dnf5 package manager as the new default,
several adjustments need to be made both to the infrastructure and the
dnf5 package itself. Some of these adjustments are detailed [[#Release
engineering|below]]. To ensure synchronization and address all
necessary changes, we've established an upstream tracking
[https://github.com/rpm-software-management/dnf5/issues/1057 issue].
== Feedback ==
As this is the second iteration of such a proposal, we've gathered a
lot of feedback from various sources during the first attempt to
accept this change.
=== FESCo inputs ===
A [https://pagure.io/fesco/issue/3039 ticket] discussing the reasons
why the contingency mechanism was invoked for the first attempt of the
proposal was opened by FESCo. It includes a list of items that are
either incomplete or in progress.
Below is a list of issues from the ticket that are still unresolved or
require clarification on their current status. Other items not
mentioned below are considered completed.
==== Switch in ELN ====
This should not block the proposal, as the current plan is to target
RHEL 11. Integration can occur there after the proposal is implemented
for Fedora 41.
==== Aligning configuration with the current state in dnf ====
All overrides to match the current state of dnf configuration will be
provided to the Fedora release project, see [[#Apply downstream
configuration overrides|below]].
==== System upgrade and offline transactions ====
The implementation work has been completed and is already present
upstream. We anticipate extensive testing during the summer, and we
also plan to organize testing days for this purpose.
==== Dropping the Snapper plugin ====
In dnf5, we've adopted a new approach for implementing functionality
that was previously handled by the Snapper plugin in dnf.
We're introducing the Actions plugin, which offers more capabilities
than the Snapper plugin, including support for running external
applications before or after transactions and interacting with the
dnf5 configuration.
[https://dnf5.readthedocs.io/en/latest/libdnf5_plugins/actions.8.html
Here] is the documentation for the Actions plugin, which includes
examples of how to emulate the behavior of the Snapper plugin.
==== Messages from RPM scriptlets ====
An issue with output from RPM scriptlets is the potential length,
coupled with the absence of a standardized policy for distinguishing
between important and unimportant messages.
Currently, all messages are logged in the dnf5 log files, with
differentiation based on their originating scriptlets, representing an
improvement over dnf. Additionally, in case of transaction errors, the
scriptlet output is included in the standard output. Furthermore,
there is already a resolved [https://pagure.io/koji/issue/4009 ticket]
in the infrastructure to incorporate logs on the builders.
=== Testing days ===
We've already held several dnf5 test days for Fedora
[https://fedoraproject.org/wiki/Test_Day:2023-03-14_Fedora_38_DNF_5
38], [https://fedoraproject.org/wiki/Test_Day:2023-08-11_Fedora_39_DNF_5
39], and recently also
[https://fedoraproject.org/wiki/Test_Day:2024-03-15_Fedora_40_DNF_5
40]. We've made efforts to document all reported issues in our
upstream tracking system, and major issues should now be resolved.
Some of these issues were related to user documentation, improving
command-line outputs, and enhancing overall user experience. These
topics are next on our priority list after completing the
functionality for mandatory commands and plugins.
=== Fedora QA scenarios ===
We've started a discussion
[https://discussion.fedoraproject.org/t/requirements-for-dnf5-in-fedora-41
thread] on the requirements for accepting this proposal from a QA
perspective. A list of relevant test cases and criteria has been
mentioned, which we'll review to ensure we've covered everything on
our end.
=== Fedora CI readiness ===
The dnf project is also deployed in the CI pipeline. We've initiated
communications with this team to ensure that all dnf functionality
used there is either already implemented in dnf5 or can be addressed
through an alternative dnf5 method. We've already received some
feedback from the first iteration of the proposal.
=== Tracking issue upstream ===
When implementing the first iteration of this proposal, we created an
upstream [https://github.com/rpm-software-management/dnf5/issues/635
ticket] to track all bugs or lack of needed functionality. All items
have been addressed, and only several known deployment issues remain,
which need to be managed at the time of the next switch.
== Benefit to Fedora ==
The new dnf5 will significantly improve the user experience and
performance. Detailed descriptions of individual areas are provided
below.
=== Reduced footprint ===
The dnf5 package is a fully-featured package manager that doesn't
require Python dependencies.
It also reduces the number of software management tools in Fedora by
replacing both the dnf and microdnf packages.
The installation size of the dnf5 stack in an empty container is
approximately 60% smaller than the dnf installation.
Currently, dnf, microdnf, and PackageKit use their own cache, leading
to significant metadata redundancy. With dnf5 and dnf5daemon, which
share metadata, this redundancy will be eliminated.
=== Enhanced performance ===
Loading and downloading repository metadata now occur concurrently.
Package query operations, including processing numerous command-line
arguments, have been significantly accelerated.
=== Lowered maintenance costs ===
Many functional duplicates in dnf were eliminated during the
development of the new dnf5 package manager. This was partly because
the integration of the original PackageKit and dnf libraries into the
original libdnf library was never completed.
Plugins are now included in the same package as the core functionality.
=== Unified user experience ===
Consistent user experience is offered to users across servers,
workstations, and containers, as dnf5 is the sole package manager
deployed there. Existing dnf, yum, and microdnf commands will be
linked to dnf5, while compatibility aliases for essential use cases
will be provided to facilitate migration.
Configuration files will be shared among dnf5 components.
API users will encounter unified code style and naming conventions.
Various scripting language interfaces are now provided from a single
source using SWIG bindings (formerly CPython and SWIG).
== Scope ==
=== Proposal owners ===
The remaining work on the proposal can be divided into several sections.
==== Feature implementation ====
===== [https://github.com/rpm-software-management/dnf5/issues/1052
System upgrade] =====
This command is essential for upgrading the system to the next
release. While the implementation is already completed, we plan to
conduct extensive testing, including community participation, to
minimize the risk of issues occurring in production.
===== [https://github.com/rpm-software-management/dnf5/issues/140
History command] =====
The functionality related to manipulating transaction history has not
yet been implemented. However, following the completion of the system
upgrade functionality, it is currently our top priority. Due to the
significant overlap between the functionality in the history command
and the system upgrade functionality, we anticipate its readiness
shortly thereafter.
===== [https://github.com/rpm-software-management/dnf5/issues/169
GNOME Software support] =====
The integration of dnf5 support, particularly dnf5daemon, into GNOME
Software is currently underway. Developers from both DNF5 and GNOME
Software are closely connected and regularly synchronize the progress
of their work.
==== Documentation ====
While our current priority is achieving full coverage of
[https://dnf5.readthedocs.io/en/latest/ user and API documentation],
there may still be some undocumented parts of the code. Please don't
hesitate to [https://github.com/rpm-software-management/dnf5/issues/new
report] any such issues upstream, and we'll endeavor to address them
promptly.
==== Early access for developmental branch users ====
The intention is to implement the proposed changes in the Rawhide
developmental branch prior to the date specified in the Contingency
Deadline section, targeting the transition period between March and
April. It is anticipated that certain mandatory items for the regular
release, as outlined in previous sections, may not be completed by
this time.
===== System upgrade =====
This functionality is unnecessary as Rawhide operates on a rolling
release model.
===== GNOME Software =====
Rawhide users will continue to utilize the current PackageKit backend
connected to the existing libdnf interface until the integration of
dnf5 is finalized. These libraries can coexist with the new dnf5
package on the same system. For more details, see [[#Different system
state|below]].
=== Other developers ===
The following components are already prepared for transition to dnf5:
* [https://github.com/ansible/ansible/issues/78898 Ansible]
* [https://github.com/rpm-software-management/dnf5/issues/66 Lorax]
* [https://github.com/rpm-software-management/mock/issues/894 Mock]
Below is a list of dependencies that have not yet integrated with dnf5.
==== Anaconda ====
Migration to the dnf5 API will not be implemented at this time. After
discussion with the Anaconda team, it was determined that there isn't
sufficient capacity and time to complete the work on schedule.
Therefore, the existing dnf4 Python bindings from the python3-dnf
package will continue to be used for now.
==== GNOME Software ====
This integration is already addressed in the section above, as it
involves collaborative efforts.
=== Release engineering ===
==== Building with dnf5 ====
The Fedora infrastructure has been utilizing dnf5 for building Fedora
40+ chroots since before the Fedora 40 mass rebuilds began. This
implementation was based on the system-wide change outlined
[https://fedoraproject.org/wiki/Changes/BuildWithDNF5 here].
==== Apply downstream configuration overrides ====
Starting with dnf5, distro-specific overrides of the default
configuration values are implemented using
[https://dnf5.readthedocs.io/en/latest/dnf5.conf.5.html#drop-in-configuration-directories
drop-in directories]. Options with different values upstream compared
to the current state of dnf in Fedora will be filed in a pull request
against the [https://src.fedoraproject.org/rpms/fedora-release Fedora
release project].
==== Update of kickstarts for image composes ====
The dnf team will prepare a pull request to include the packages for
the new default dnf5 package manager in the
[https://pagure.io/fedora-kickstarts Fedora Kickstarts project].
==== Update of package groups definitions ====
The dnf team will prepare a pull request to include the packages for
the new default dnf5 package manager in the
[https://pagure.io/fedora-comps Fedora Comps project].
==== Update of KIWI image descriptions ====
The dnf team will prepare a pull request to include the packages for
the new default dnf5 package manager in the
[https://pagure.io/fedora-kiwi-descriptions Fedora KIWI descriptions
project].
== Upgrade/compatibility impact ==
=== Running the upgrade ===
The dnf5 package will be installed on the system to provide
/usr/bin/dnf, replacing the existing dnf package as it becomes
obsolete. Additionally, the dnf automatic tool will be replaced by the
new dnf5 automatic plugin.
Below is an example of performing this upgrade transaction.
<pre>
$ sudo dnf upgrade
Last metadata expiration check: 0:01:09 ago on Wed 13 Mar 2024 05:48:25 AM EDT.
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
dnf5-plugin-automatic x86_64 5.1.14-1.fc41 rawhide 120 k
replacing dnf-automatic.noarch 4.19.0-1.fc40
Upgrading:
dnf-data noarch 4.19.0-1.fc41 rawhide 40 k
python3-dnf noarch 4.19.0-1.fc41 rawhide 551 k
Installing group/module packages:
dnf5 x86_64 5.1.14-1.fc41 rawhide 599 k
replacing dnf.noarch 4.19.0-1.fc40
replacing yum.noarch 4.19.0-1.fc40
Installing dependencies:
fmt x86_64 10.2.1-3.fc40 rawhide 125 k
libdnf5 x86_64 5.1.14-1.fc41 rawhide 991 k
libdnf5-cli x86_64 5.1.14-1.fc41 rawhide 229 k
Installing weak dependencies:
bash-completion noarch 1:2.11-15.fc41 rawhide 360 k
Transaction Summary
================================================================================
Install 6 Packages
Upgrade 2 Packages
</pre>
=== Binaries and symlinks ===
The existing dnf binaries will remain on the system and will be
available at /usr/bin/dnf-3, which refers to the Python 3 version to
which dnf was migrated in the past. Additionally, they will be
accessible at /usr/bin/dnf4, which is a symlink to the dnf-3 script
and denotes the major version of the dnf binary. This binary naming
convention is also used for /usr/bin/dnf5, which will become the
target of the /usr/bin/dnf symlink.
Below is the output of the tree command showing the expected file
structure after the upgrade.
==== Before upgrade ====
<pre>
$ tree /usr/bin/ -P dnf*
/usr/bin/
├── dnf -> dnf-3
├── dnf-3
└── dnf4 -> dnf-3
</pre>
==== After upgrade ====
<pre>
$ tree /usr/bin/ -P dnf*
/usr/bin/
├── dnf -> dnf5
├── dnf-3
├── dnf4 -> dnf-3
└── dnf5
</pre>
=== Different system state ===
Though the RPM DB, which contains the database of installed packages,
remains the singular source in the system, the transactional history
and installed packages reasons in dnf and dnf5 is not shared, and they
now use different formats.
Transactions performed in dnf will not be visible in dnf5, and vice
versa. Therefore, when concurrently using dnf and dnf5 on the system,
packages installed by one of them as dependencies will appear as
user-installed to the other one, potentially leading to them not being
auto-removed later.
While the history database is not migrated to dnf5, when running a
transaction in dnf5 for the first time, an attempt is made to convert
and load the existing system state from dnf. This should preserve
information about the reasons for installed packages and prevent them
from being treated as user-installed, requiring manual removal from
the system instead of being seen as dependencies of explicitly removed
packages.
=== Compatibility ===
While the majority of CLI use cases for managing packages should
remain the same, the dnf5 API has undergone significant changes. To
ease adoption, dnf5 will provide compatibility aliases for commands
and options. Additionally, user output will differ, and we plan to
offer machine-readable support for most commands. For more details,
please refer to the section above.
Applications encountering difficulties with dnf5 adoption can continue
using the existing dnf CLI and API provided by the python3-dnf and
libdnf packages. These libraries can be used in parallel on the
system, but modifying installed software is not recommended due to
differences in system state, as mentioned in the [[#Documentation of
API changes|previous]] section.
== How To Test ==
=== Copr repository ===
[https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-testing/
A testing Copr repository] has been set up with dnf5 already deployed
as the default package manager. Instructions on how to proceed are
provided alongside.
=== Quay containers ===
We have also prepared Fedora container images with the dnf5 stack
preinstalled on
[https://quay.io/repository/rpmsoftwaremanagement/fedora-dnf5
quay.io], making it easy to test in isolation with Podman.
=== Side-tag for testing ===
Before pushing the new dnf5 into the Rawhide compose, we plan to
announce the prepared side-tag containing this new package publicly.
This will allow interested parties to test it against their software.
=== Testing days ===
We are planning at least two iterations of testing days before dnf5 is
delivered into Fedora 41. One will focus on testing the overall
functionality of dnf5, with an emphasis on parts that were not tested
during previous testing days. The other iteration will center around
testing the system upgrade functionality.
=== Communication channels ===
Community feedback, including bug reports, issues, or feature
requests, is highly encouraged.
Our primary communication channel is
[https://github.com/rpm-software-management/dnf5 upstream], where you
can report [https://github.com/rpm-software-management/dnf5/issues
issues], participate in
[https://github.com/rpm-software-management/dnf5/discussions
discussions], or even propose
[https://github.com/rpm-software-management/dnf5/pulls pull requests].
We are happy to review them.
Issues specific to a particular version of the dnf5 package can also
be reported through the
[https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dnf5
Bugzilla] tracking system, which we also monitor.
== User Experience ==
=== Faster query processing ===
The processing of package metadata is now significantly faster.
Executing commands such as repoquery to list packages available in
repositories is now twice as fast compared to dnf. Similarly,
operations like listing dependencies or parsing numerous command-line
arguments are notably expedited, potentially saving users seconds to
tens of seconds in waiting time for the results.
=== Consolidated and streamlined API ===
The API for managing packages, working with repositories, and solving
package dependencies is now consolidated into a single component,
providing a unified solution. The original dnf API underwent a review
process, during which unused workflows and obsolete methods were
removed, while improving usability for users.
=== Enhanced command-line outputs ===
Transaction tables now offer more detailed information, verbose
scriptlet outputs are redirected and organized by package name into
log files, individual commands come with their own man pages, bash
completion has been enhanced, and numerous other improvements have
been made.
== Dependencies ==
=== Owned by our team ===
==== dnf-plugins-core ====
Installed plugins will persist on the system and remain functional
using the dnf4 binary from the python3-dnf package.
With the exception of the system upgrade plugin, all essential plugins
are now implemented in dnf5 and are provided by the dnf5-plugins
package or dnf5 directly.
==== dnf-plugins-extras ====
Installed plugins will persist on the system and remain functional
using the dnf4 binary from the python3-dnf package.
Porting the functionality to dnf5 is currently of low priority, and
its implementation depends more on community involvement. The
functionality of the Snapper plugin is already covered by the dnf5
actions plugin.
=== Requirements on dnf ===
This is the most critical category of packages as issues connected
with them can potentially disrupt the system upgrade path.
Here, we can split components into two groups.
The first group utilizes dnf from the command line interface (CLI),
and thus, they either need to adjust to the new syntax and behavior of
dnf5 or switch to utilizing the existing dnf4 binary directly.
The second group consists of components providing plugins for the dnf
command. These plugins will remain functional using the binary from
python3-dnf, requiring packaging changes to depend on this package
instead.
<pre>
auter
calamares
copr-builder
cpanspec
dnfdragora
etckeeper-dnf
fedora-review
fedora-upgrade
kiwi-systemdeps-core
libdnf-plugin-subscription-manager
lpf
mock
osbuild
perl-CPAN-Plugin-Sysdeps
rbm
rpmdistro-repoquery
supermin
system-config-language
</pre>
A tracking [https://github.com/rpm-software-management/dnf5/issues/418
issue] was created in advance to inform maintainers about the planned
switch to dnf5.
=== Requirements on python3-dnf ===
Here, we can also categorize components into two groups.
The first group consists of components providing plugins for the dnf
command. These plugins will remain functional using the binary from
python3-dnf, requiring packaging changes to depend on this package
instead.
The second group utilizes the dnf's Python API, and they should not be
directly affected by the change. However, testing is still necessary,
and it is strongly recommended to consider porting to the dnf5 API.
<pre>
anaconda-core
copr-builder
dnf-plugin-diff
dnf-plugin-ovl
dnfdaemon
fedora-easy-karma
fedora-review
fedrq
lorax
mock-core-configs
module-build-service
modulemd-tools
needrestart
policycoreutils-devel
pungi
python3-dnf-plugin-cow
python3-dnf-plugin-flunk_dependent_remove
python3-dnf-plugin-perfmetrics
python3-imgcreate
python3-libreport
retrace-server
subscription-manager
system-config-language
</pre>
=== Requirements on libdnf ===
These packages utilize the libdnf API and should not be directly
impacted by the change. However, testing is still necessary.
Tools that modify system software, such as PackageKit, may exhibit
different behavior when used alongside dnf5 to manage the same system,
as previously described.
Additionally, it is strongly recommended to consider porting to the
dnf5 API in this context.
<pre>
PackageKit
copr-builder
libdnf-plugin-subscription-manager
libdnf-plugin-swidtags
libdnf-plugin-txnupd
</pre>
=== Requirements on python3-hawkey ===
These components utilize unsupported Hawkey Python bindings and should
not be directly impacted by the change. However, thorough testing is
necessary. Again, it is strongly recommended to consider porting to
the dnf5 API in this context.
<pre>
mock-core-configs
modulemd-tools
python3-rpmdeplint
retrace-server
</pre>
== Contingency Plan ==
=== Contingency mechanism ===
To revert to the previous state with dnf as the default package
manager on the system, the following steps would be necessary:
* Packaging changes in dnf5 to remove the obsoletion of dnf and
provider of the /usr/bin/dnf symlink.
* Untagging the candidate dnf5 package from the compose.
* Components that adapted to the dnf5 CLI must synchronize in this
process and revert the changes to use dnf4 again. Proactive
communication will be conducted similarly to how components were
informed about the dnf5 migration.
=== Contingency deadline ===
Branch Fedora Linux 41 from Rawhide
=== Blocks release? ===
No
== Documentation ==
=== [https://dnf5.readthedocs.io/en/latest/index.html Official
documentation] ===
=== [https://github.com/rpm-software-management/dnf5 Upstream project] ===
=== [https://dnf5.readthedocs.io/en/latest/changes.html Changes
between dnf and dnf5] ===
=== [https://dnf5.readthedocs.io/en/latest/dnf_daemon/dnf5daemon_dbus_api.8.html
D-Bus API documentation] ===
=== [https://github.com/rpm-software-management/dnf5/blob/main/CONTRIBUTING.md
Contributing guide for developers] ===
== 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-leave@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
Tuesday, April 2, 2024
[announce] NYC*BUG Wed Apr 3: 20 Years of NYC*BUG
https://www.nycbug.org/index?action=view&id=10695
20 Years of NYC*BUG and Can We Handle 20 More?
George Rosamond
2024-04-03 @ 18:45 EDT (22:45 UTC) - NYU Tandon Engineering Building
(new), 370 Jay St, 7th Floor kitchen area, Brooklyn (directly across Jay
St from National Grid office). Closest subway exits in order are Jay St
- MetroTech Station (A, C, R, & F Trains) Borough Hall (4 & 5 Trains).
***Notice: You should RSVP for this meeting at rsvp AT lists.nycbug.org.
You should receive an autoresponse email. Your email address is
sufficient verification for entry.***
The New York City *BSD User Group officially launched at Linux World
Expo on January 2004 with a packed birds-of-a-feather session. The first
meeting was held on February 4th.
Several of us starting pulling together the group in December 2003, and
carefully planned for the events.
That makes January 2024 the official 20th anniversary of NYC*BUG, which
is a long time in user-group years.
Like every other organization, NYC*BUG's history isn't a simple linear
process. There were ebbs and flows, some due to our own decisions and
activities, others due to the larger world.
But we are still operating, with regular monthly meetings after the
pandemic, and still constantly assessing and reassessing what we're
doing and where we're going.
This isn't going to be a straight-forward presentation. Rather, the
input from everyone who experienced the trajectory at any moment is
vital for drawing a full picture. That input will provide important
ingredients for the more polished version of this presentation at BSDCan
May 31 through June 1st.
We look forward to input from those who have been part of this journey.
Hopefully the outcome will be a rich image of the history.
George Rosamond is a founder and long-time admin@ member of NYC*BUG.
He's the co-founder and CTO of ClearOPS, a privacy and security
technology startup. A sysadmin by trade with citizenship in BSD Unix
land, his area of interest and expertise lies with privacy-enhancing
technologies, most importantly with the Tor Project. He thrives on
creating and designing unorthodox solutions to ordinary problems, but so
do most other people in the *BSD community.
Offsite Participation: We plan to stream via NYC*BUG Website unless the
speaker requests otherwise. Q&A will be via IRC on Libera.chat channel
#nycbug - Please preface your questions with '[Q]'
_______________________________________________
announce mailing list
announce@lists.nycbug.org
https://lists.nycbug.org:8443/mailman/listinfo/announce
20 Years of NYC*BUG and Can We Handle 20 More?
George Rosamond
2024-04-03 @ 18:45 EDT (22:45 UTC) - NYU Tandon Engineering Building
(new), 370 Jay St, 7th Floor kitchen area, Brooklyn (directly across Jay
St from National Grid office). Closest subway exits in order are Jay St
- MetroTech Station (A, C, R, & F Trains) Borough Hall (4 & 5 Trains).
***Notice: You should RSVP for this meeting at rsvp AT lists.nycbug.org.
You should receive an autoresponse email. Your email address is
sufficient verification for entry.***
The New York City *BSD User Group officially launched at Linux World
Expo on January 2004 with a packed birds-of-a-feather session. The first
meeting was held on February 4th.
Several of us starting pulling together the group in December 2003, and
carefully planned for the events.
That makes January 2024 the official 20th anniversary of NYC*BUG, which
is a long time in user-group years.
Like every other organization, NYC*BUG's history isn't a simple linear
process. There were ebbs and flows, some due to our own decisions and
activities, others due to the larger world.
But we are still operating, with regular monthly meetings after the
pandemic, and still constantly assessing and reassessing what we're
doing and where we're going.
This isn't going to be a straight-forward presentation. Rather, the
input from everyone who experienced the trajectory at any moment is
vital for drawing a full picture. That input will provide important
ingredients for the more polished version of this presentation at BSDCan
May 31 through June 1st.
We look forward to input from those who have been part of this journey.
Hopefully the outcome will be a rich image of the history.
George Rosamond is a founder and long-time admin@ member of NYC*BUG.
He's the co-founder and CTO of ClearOPS, a privacy and security
technology startup. A sysadmin by trade with citizenship in BSD Unix
land, his area of interest and expertise lies with privacy-enhancing
technologies, most importantly with the Tor Project. He thrives on
creating and designing unorthodox solutions to ordinary problems, but so
do most other people in the *BSD community.
Offsite Participation: We plan to stream via NYC*BUG Website unless the
speaker requests otherwise. Q&A will be via IRC on Libera.chat channel
#nycbug - Please preface your questions with '[Q]'
_______________________________________________
announce mailing list
announce@lists.nycbug.org
https://lists.nycbug.org:8443/mailman/listinfo/announce
Orphaned packages looking for new maintainers
Report started at 2024-04-02 16:05:20 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/<pkgname>
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
================================================================================
botan orphan 1 weeks ago
container-workflow-tool orphan 1 weeks ago
emacs-htmlize orphan 1 weeks ago
kio-upnp-ms jgrulich, orphan 3 weeks ago
ktp-contact-runner @kde-sig, orphan, rdieter 3 weeks ago
liquidshell orphan 5 weeks ago
loudgain orphan 3 weeks ago
mrxvt orphan 3 weeks ago
nextcloud ichavero, orphan 1 weeks ago
perl-Git-PurePerl iarnell, orphan 6 weeks ago
perl-Net-GitHub jplesnik, lkundrak, orphan, 6 weeks ago
ppisar
perl-Spreadsheet-ParseExcel- jplesnik, orphan, ppisar 6 weeks ago
Simple
perl-Spreadsheet-WriteExcel- jplesnik, orphan, ppisar 6 weeks ago
Simple
perl-String-Diff iarnell, orphan 6 weeks ago
perl-WWW-Google-Contacts orphan 3 weeks ago
php-aws-sdk3 orphan 1 weeks ago
php-bantu-ini-get-wrapper adamwill, orphan 1 weeks ago
php-christophwurst-id3parser orphan 1 weeks ago
php-deepdiver-zipstreamer orphan 1 weeks ago
php-doctrine-dbal orphan, remi 1 weeks ago
php-fgrosse-phpasn1 orphan 1 weeks ago
php-giggsey-locale orphan 1 weeks ago
php-guzzlehttp-guzzle6 orphan 1 weeks ago
php-league-uri-interfaces orphan 1 weeks ago
php-opencloud-openstack orphan 1 weeks ago
php-opis-closure orphan, remi 1 weeks ago
php-phpSmug orphan 5 weeks ago
php-pimple orphan 1 weeks ago
php-punic orphan 1 weeks ago
php-ralouphie-getallheaders orphan 1 weeks ago
php-scssphp orphan 1 weeks ago
php-stecman-symfony-console- orphan 1 weeks ago
completion
python-aiomqtt orphan 4 weeks ago
python-autoprop orphan 4 weeks ago
python-colorcet orphan 4 weeks ago
python-extractcode @python-packagers-sig, orphan 3 weeks ago
python-jose orphan 0 weeks ago
python-limits orphan 3 weeks ago
python-param orphan 4 weeks ago
python-pyct orphan 4 weeks ago
python-signature-dispatch orphan 4 weeks ago
python-vecrec orphan 4 weeks ago
telepathy-logger-qt @kde-sig, jgrulich, orphan 3 weeks ago
The following packages require above mentioned packages:
Depending on: botan (13), status change: 2024-03-20 (1 weeks ago)
monotone (maintained by: thm)
monotone-1.1-48.fc40.src requires botan-devel = 1.10.17-42.fc41
monotone-1.1-48.fc40.x86_64 requires libbotan-1.10.so.1()(64bit)
guitone (maintained by: thm)
guitone-1.0-0.34.rc5.fc40.x86_64 requires monotone = 1.1-48.fc40
ikiwiki (maintained by: thm)
ikiwiki-3.20200202.4-1.fc41.noarch requires perl(Monotone) = 0.03
trac-monotone-plugin (maintained by: thm)
trac-monotone-plugin-0.0.15-0.8.20210704mtn34341a53.fc40.noarch requires monotone = 1.1-48.fc40
git-annex (maintained by: mathstuf, petersen, qulogic)
git-annex-10.20230626-4.fc40.src requires ikiwiki = 3.20200202.4-1.fc41
lua-event (maintained by: robert)
lua-event-0.4.6-14.fc40.src requires ikiwiki = 3.20200202.4-1.fc41
python-datalad (maintained by: @neuro-sig, ankursinha)
python-datalad-0.19.6-1.fc40.src requires git-annex = 10.20230626-4.fc40
python3-datalad-0.19.6-1.fc40.noarch requires git-annex = 10.20230626-4.fc40
python-neo (maintained by: @neuro-sig, ankursinha)
python-neo-0.13.0-1.fc41.src requires datalad = 0.19.6-1.fc40
python-efel (maintained by: @neuro-sig, ankursinha)
python-efel-5.4.0-2.fc40.src requires python3-neo = 0.13.0-1.fc41, python3dist(neo) = 0.13
python3-efel-5.4.0-2.fc40.x86_64 requires python3.12dist(neo) = 0.13
python-elephant (maintained by: @neuro-sig, lbazan)
python-elephant-1.0.0-13.fc40.src requires python3dist(neo) = 0.13
python3-elephant-1.0.0-13.fc40.x86_64 requires python3.12dist(neo) = 0.13
python-ephyviewer (maintained by: @neuro-sig, vanessakris)
python-ephyviewer-1.5.1-15.fc40.src requires python3dist(neo) = 0.13
python-pynn (maintained by: @neuro-sig, ankursinha)
python-pynn-0.12.2-2.fc41.src requires python3dist(neo) = 0.13
python3-pynn-0.12.2-2.fc41.x86_64 requires python3.12dist(neo) = 0.13
python-bluepyopt (maintained by: @neuro-sig, ankursinha)
python-bluepyopt-1.14.10-1.fc40.src requires python3dist(efel) = 5.4
python3-bluepyopt-1.14.10-1.fc40.x86_64 requires python3.12dist(efel) = 5.4
Depending on: perl-Spreadsheet-WriteExcel-Simple (1), status change: 2024-02-20 (6 weeks ago)
perl-Spreadsheet-ParseExcel-Simple (maintained by: jplesnik, orphan, ppisar)
perl-Spreadsheet-ParseExcel-Simple-1.04-45.fc40.src requires perl(Spreadsheet::WriteExcel::Simple) = 1.04
Depending on: php-doctrine-dbal (5), status change: 2024-03-25 (1 weeks ago)
php-doctrine-datafixtures (maintained by: remi, siwinski)
php-doctrine-datafixtures-1.6.5-2.fc39.src requires php-composer(doctrine/dbal) = 2.13.9, php-composer(doctrine/orm) = 2.14.1
php-doctrine-doctrine-bundle (maintained by: siwinski)
php-doctrine-doctrine-bundle-1.12.13-6.fc38.noarch requires php-composer(doctrine/dbal) = 2.13.9
php-doctrine-doctrine-bundle-1.12.13-6.fc38.src requires php-composer(doctrine/dbal) = 2.13.9, php-composer(doctrine/orm) = 2.14.1
php-doctrine-orm (maintained by: remi, siwinski)
php-doctrine-orm-2.14.1-3.fc39.noarch requires php-composer(doctrine/dbal) = 2.13.9
php-doctrine-orm-2.14.1-3.fc39.src requires php-composer(doctrine/dbal) = 2.13.9
php-symfony (maintained by: siwinski)
php-symfony-2.8.52-10.fc38.src requires php-composer(doctrine/data-fixtures) = 1.6.5, php-composer(doctrine/dbal) = 2.13.9, php-composer(doctrine/doctrine-bundle) = 1.12.13, php-composer(doctrine/orm) = 2.14.1
php-symfony-doctrine-bridge-2.8.52-10.fc38.noarch requires php-composer(doctrine/data-fixtures) = 1.6.5, php-composer(doctrine/dbal) = 2.13.9, php-composer(doctrine/orm) = 2.14.1
php-symfony3 (maintained by: remi, siwinski)
php-symfony3-3.4.49-5.fc38.src requires php-composer(doctrine/data-fixtures) = 1.6.5, php-composer(doctrine/dbal) = 2.13.9, php-composer(doctrine/doctrine-bundle) = 1.12.13, php-composer(doctrine/orm) = 2.14.1
php-symfony3-class-loader-3.4.49-5.fc38.noarch requires php-symfony-class-loader = 2.8.52-10.fc38
Depending on: php-guzzlehttp-guzzle6 (2), status change: 2024-03-25 (1 weeks ago)
php-aws-sdk3 (maintained by: orphan)
php-aws-sdk3-3.191.10-6.fc40.noarch requires php-composer(guzzlehttp/guzzle) = 6.5.8
php-aws-sdk3-3.191.10-6.fc40.src requires php-composer(guzzlehttp/guzzle) = 6.5.8
php-opencloud-openstack (maintained by: orphan)
php-opencloud-openstack-3.0.7-13.fc40.noarch requires php-guzzlehttp-guzzle6 = 6.5.8-6.fc40
php-opencloud-openstack-3.0.7-13.fc40.src requires php-guzzlehttp-guzzle6 = 6.5.8-6.fc40
Depending on: php-ralouphie-getallheaders (5), status change: 2024-03-25 (1 weeks ago)
php-guzzlehttp-psr7 (maintained by: remi)
php-guzzlehttp-psr7-1.9.0-6.fc40.noarch requires php-composer(ralouphie/getallheaders) = 3.0.3
php-guzzlehttp-psr7-1.9.0-6.fc40.src requires php-composer(ralouphie/getallheaders) = 3.0.3
php-aws-php-sns-message-validator (maintained by: siwinski)
php-aws-php-sns-message-validator-1.6.0-8.fc39.src requires php-composer(guzzlehttp/psr7) = 1.9.0
php-aws-sdk3 (maintained by: orphan)
php-aws-sdk3-3.191.10-6.fc40.noarch requires php-composer(guzzlehttp/guzzle) = 6.5.8, php-composer(guzzlehttp/psr7) = 1.9.0
php-aws-sdk3-3.191.10-6.fc40.src requires php-composer(guzzlehttp/guzzle) = 6.5.8, php-composer(guzzlehttp/psr7) = 1.9.0
php-guzzlehttp-guzzle6 (maintained by: orphan)
php-guzzlehttp-guzzle6-6.5.8-6.fc40.noarch requires php-composer(guzzlehttp/psr7) = 1.9.0
php-guzzlehttp-guzzle6-6.5.8-6.fc40.src requires php-composer(guzzlehttp/psr7) = 1.9.0
php-opencloud-openstack (maintained by: orphan)
php-opencloud-openstack-3.0.7-13.fc40.noarch requires php-guzzlehttp-guzzle6 = 6.5.8-6.fc40
php-opencloud-openstack-3.0.7-13.fc40.src requires php-guzzlehttp-guzzle6 = 6.5.8-6.fc40
Depending on: python-autoprop (1), status change: 2024-03-01 (4 weeks ago)
python-vecrec (maintained by: orphan)
python-vecrec-0.3.1-17.fc40.src requires python3dist(autoprop) = 4.1
python3-vecrec-0.3.1-17.fc40.noarch requires python3.12dist(autoprop) = 4.1
Depending on: python-jose (1), status change: 2024-03-30 (0 weeks ago)
python-social-auth-core (maintained by: cqi)
python-social-auth-core-4.3.0-8.fc40.src requires python3dist(python-jose) = 3.3
python3-social-auth-core+openidconnect-4.3.0-8.fc40.noarch requires python3.12dist(python-jose) = 3.3, python3dist(python-jose) = 3.3
Depending on: python-param (2), status change: 2024-03-01 (4 weeks ago)
python-pyct (maintained by: orphan)
python-pyct-0.5.0-8.fc40.src requires python3dist(param) = 2.0.2
python3-pyct-0.5.0-8.fc40.noarch requires python3.12dist(param) = 2.0.2
python3-pyct+build-0.5.0-8.fc40.noarch requires python3.12dist(param) = 2.0.2
python-colorcet (maintained by: orphan)
python-colorcet-3.0.1^20221003git809e291-12.fc40.src requires python3dist(pyct) = 0.5, python3dist(pyct[build]) = 0.5
python3-colorcet-3.0.1^20221003git809e291-12.fc40.noarch requires python3.12dist(pyct) = 0.5
Depending on: python-pyct (1), status change: 2024-03-01 (4 weeks ago)
python-colorcet (maintained by: orphan)
python-colorcet-3.0.1^20221003git809e291-12.fc40.src requires python3dist(pyct) = 0.5, python3dist(pyct[build]) = 0.5
python3-colorcet-3.0.1^20221003git809e291-12.fc40.noarch requires python3.12dist(pyct) = 0.5
Depending on: python-signature-dispatch (2), status change: 2024-03-01 (4 weeks ago)
python-autoprop (maintained by: orphan)
python-autoprop-4.1.0-10.fc40.src requires python3dist(signature-dispatch) = 1.0.1
python3-autoprop-4.1.0-10.fc40.noarch requires python3.12dist(signature-dispatch) = 1.0.1
python-vecrec (maintained by: orphan)
python-vecrec-0.3.1-17.fc40.src requires python3dist(autoprop) = 4.1
python3-vecrec-0.3.1-17.fc40.noarch requires python3.12dist(autoprop) = 4.1
Affected (co)maintainers
@kde-sig: telepathy-logger-qt, ktp-contact-runner
@neuro-sig: botan
@python-packagers-sig: python-extractcode
adamwill: php-bantu-ini-get-wrapper
ankursinha: botan
cqi: python-jose
iarnell: perl-String-Diff, perl-Git-PurePerl
ichavero: nextcloud
jgrulich: telepathy-logger-qt, kio-upnp-ms
jplesnik: perl-Spreadsheet-WriteExcel-Simple, perl-Net-GitHub, perl-Spreadsheet-ParseExcel-Simple
lbazan: botan
lkundrak: perl-Net-GitHub
mathstuf: botan
petersen: botan
ppisar: perl-Spreadsheet-WriteExcel-Simple, perl-Net-GitHub, perl-Spreadsheet-ParseExcel-Simple
qulogic: botan
rdieter: ktp-contact-runner
remi: php-opis-closure, php-ralouphie-getallheaders, php-doctrine-dbal
robert: botan
siwinski: php-ralouphie-getallheaders, php-doctrine-dbal
thm: botan
vanessakris: botan
Orphans (43): botan container-workflow-tool emacs-htmlize kio-upnp-ms
ktp-contact-runner liquidshell loudgain mrxvt nextcloud
perl-Git-PurePerl perl-Net-GitHub
perl-Spreadsheet-ParseExcel-Simple
perl-Spreadsheet-WriteExcel-Simple perl-String-Diff
perl-WWW-Google-Contacts php-aws-sdk3 php-bantu-ini-get-wrapper
php-christophwurst-id3parser php-deepdiver-zipstreamer
php-doctrine-dbal php-fgrosse-phpasn1 php-giggsey-locale
php-guzzlehttp-guzzle6 php-league-uri-interfaces
php-opencloud-openstack php-opis-closure php-phpSmug php-pimple
php-punic php-ralouphie-getallheaders php-scssphp
php-stecman-symfony-console-completion python-aiomqtt
python-autoprop python-colorcet python-extractcode python-jose
python-limits python-param python-pyct python-signature-dispatch
python-vecrec telepathy-logger-qt
Orphans (dependend on) (10): botan perl-Spreadsheet-WriteExcel-Simple
php-doctrine-dbal php-guzzlehttp-guzzle6
php-ralouphie-getallheaders python-autoprop python-jose
python-param python-pyct python-signature-dispatch
Orphans (rawhide) for at least 6 weeks (dependend on) (1):
perl-Spreadsheet-WriteExcel-Simple
Orphans (rawhide) (not depended on) (33): container-workflow-tool
emacs-htmlize kio-upnp-ms ktp-contact-runner liquidshell loudgain
mrxvt nextcloud perl-Git-PurePerl perl-Net-GitHub
perl-Spreadsheet-ParseExcel-Simple perl-String-Diff
perl-WWW-Google-Contacts php-aws-sdk3 php-bantu-ini-get-wrapper
php-christophwurst-id3parser php-deepdiver-zipstreamer
php-fgrosse-phpasn1 php-giggsey-locale php-league-uri-interfaces
php-opencloud-openstack php-opis-closure php-phpSmug php-pimple
php-punic php-scssphp php-stecman-symfony-console-completion
python-aiomqtt python-colorcet python-extractcode python-limits
python-vecrec telepathy-logger-qt
Orphans (rawhide) for at least 6 weeks (not dependend on) (4):
perl-Git-PurePerl perl-Net-GitHub
perl-Spreadsheet-ParseExcel-Simple perl-String-Diff
Depending packages (rawhide) (29): git-annex guitone ikiwiki lua-event
monotone perl-Spreadsheet-ParseExcel-Simple
php-aws-php-sns-message-validator php-aws-sdk3
php-doctrine-datafixtures php-doctrine-doctrine-bundle
php-doctrine-orm php-guzzlehttp-guzzle6 php-guzzlehttp-psr7
php-opencloud-openstack php-symfony php-symfony3 python-autoprop
python-bluepyopt python-colorcet python-datalad python-efel
python-elephant python-ephyviewer python-neo python-pyct
python-pynn python-social-auth-core python-vecrec
trac-monotone-plugin
Packages depending on packages orphaned (rawhide) for more than 6
weeks (1): perl-Spreadsheet-ParseExcel-Simple
--
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
Report finished at 2024-04-02 16:15:15 UTC
[USN-6720-1] Cacti vulnerability
-----BEGIN PGP SIGNATURE-----
wsB5BAABCAAjFiEE5rkwSLC9ntq84w397Dtram9gyMMFAmYMGtUFAwAAAAAACgkQ7Dtram9gyMPm
hAf+KRO5fEvcPbCZ0FoLAyNS5bmxOGty6YF0iYWGsOcVo9H2VS7yphR2LG/0QQXHVcrGlYILMZo5
/dfSUBrWFYYSFimoSNJlubuSRhpayly3x3KoMCUKZjT1O6zJLAhvLEPB7avXQQVLWNpBlmX3jTi2
ynNcbd2+d6j4DU7rSphzYEHPcxKZ8EGxncWWqx0QibqihAG9RTFbiIPjeHB3FFUDQ2pQjxRdWF0G
4VV88T6NOp+vKZQL/KOJTe7lx6O2AWRLzZfL08E5Ks/ljASr0tJXOQZp4m1PkRmvIKUGv+lM7SJs
d5MFOrgMr3JKFnMmEHQyqLX1Yeu4QxlH6+/4IIoSEQ==
=q9c5
-----END PGP SIGNATURE-----
==========================================================================
Ubuntu Security Notice USN-6720-1
April 02, 2024
cacti vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 22.04 LTS (Available with Ubuntu Pro)
Summary:
Cacti could be made to crash if it received specially crafted
input.
Software Description:
- cacti: web interface for graphing of monitoring systems
Details:
Kentaro Kawane discovered that Cacti incorrectly handled user provided
input sent through request parameters to the graph_view.php script.
A remote authenticated attacker could use this issue to perform
SQL injection attacks.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 22.04 LTS (Available with Ubuntu Pro):
cacti 1.2.19+ds1-2ubuntu1+esm1
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-6720-1
CVE-2023-39361
wsB5BAABCAAjFiEE5rkwSLC9ntq84w397Dtram9gyMMFAmYMGtUFAwAAAAAACgkQ7Dtram9gyMPm
hAf+KRO5fEvcPbCZ0FoLAyNS5bmxOGty6YF0iYWGsOcVo9H2VS7yphR2LG/0QQXHVcrGlYILMZo5
/dfSUBrWFYYSFimoSNJlubuSRhpayly3x3KoMCUKZjT1O6zJLAhvLEPB7avXQQVLWNpBlmX3jTi2
ynNcbd2+d6j4DU7rSphzYEHPcxKZ8EGxncWWqx0QibqihAG9RTFbiIPjeHB3FFUDQ2pQjxRdWF0G
4VV88T6NOp+vKZQL/KOJTe7lx6O2AWRLzZfL08E5Ks/ljASr0tJXOQZp4m1PkRmvIKUGv+lM7SJs
d5MFOrgMr3JKFnMmEHQyqLX1Yeu4QxlH6+/4IIoSEQ==
=q9c5
-----END PGP SIGNATURE-----
==========================================================================
Ubuntu Security Notice USN-6720-1
April 02, 2024
cacti vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 22.04 LTS (Available with Ubuntu Pro)
Summary:
Cacti could be made to crash if it received specially crafted
input.
Software Description:
- cacti: web interface for graphing of monitoring systems
Details:
Kentaro Kawane discovered that Cacti incorrectly handled user provided
input sent through request parameters to the graph_view.php script.
A remote authenticated attacker could use this issue to perform
SQL injection attacks.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 22.04 LTS (Available with Ubuntu Pro):
cacti 1.2.19+ds1-2ubuntu1+esm1
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-6720-1
CVE-2023-39361
[CentOS-announce] [Infra] - Planned outage : lists.centos.org (migration to mailman3) : please read
-----BEGIN PGP SIGNATURE-----
wsF5BAABCAAjFiEExbC4H21L30WoH1yeol26+xfzt6EFAmYMFVAFAwAAAAAACgkQol26+xfzt6HQ
pxAAvkaYQYSfVU6BOvLCQ+FB/OTrY3LSPnfYrBZAeanURkp8ssBeJCLw/OMYdz3r2RI2MEzK1oga
AgnTZLUffkpO4ViNW8RVnrkctuxAxhFfkoksrOhGH1PZhcXUXqLNCyngp5vAF9yYtz5TZF9jatZE
FfdCx4bU6jhLyvTCWp5Aqo/DPNyQ31nvpFfAqHcBHgW2oZu+bo8rq6+HhqesWioCsiZH5tlb2xiM
hcy5r+u+LYuB5wK06zFHmNiepbmTCO56G3/suhfyTWYY2A84Nkghrr01xYLUJAQJMvmbCr2PBIKb
Op7G/cEHDd9UWDWV1q/gM3QLQeyeIgAzNUcb2ww4Wo+Htk62uLM2Rj0a0i5IadAHDPv10KsxGD/7
HjHYBWUG+rvaKWQGxfVttmx8PRirdgjK2jwH3GLcxJioQxtJOGhP/xGD+fsjXSmpM1nHJzKXZOWn
DGNX1/hXOYG8vSuOFnoVV71tGIpsV1k7MkqXTDU6+oD2eeRxh3vyiTxHLVHL8FoDe4pTMn2wj7I2
uLIPFVsVcQG/oeGqJXHQ7W9BextHnPyr+tP5VlgNNYeoefwWgLJAbUMmH3J7jG1yTen3xB1tAwQh
7/aOiMI0AGrbs376/L80bBsNfADlaxT8bm2q5hAehcUVTdHN4qTAS+9hv/hURRWtz3WHSJjSdz1+
mzg=
=sWes
-----END PGP SIGNATURE-----
Due to a needed upgrade , we'll have to move the existing CentOS
mailman instance (aka https://lists.centos.org) to a new server/host.
Migration is scheduled for """"Tuesday April 8th, 7:00 am UTC time"""".
You can convert to local time with $(date -d '2024-04-08 07:00 UTC')
The expected "downtime" is estimated to ~60 minutes , time needed to :
- take last mailman2 backup
- reimport / convert mailman2 archives to mailman3 DB
- DNS propagation for A/AAAA/MX records
Here are also some important information about the mailman2 => mailman3
migration :
# Renamed lists
Worth knowing that, based on open discussion on the centos-devel list
(see whole thread at
https://lists.centos.org/pipermail/centos-devel/2024-March/165576.html),
existing lists will be *renamed* , so while we'll put aliases for
incoming mails, each list member will start receiving list mails from
new list name. So start updating your filters if you filter on email
address instead of "subject:"
Here is the overview of the new lists names :
arm-dev at centos.org => arm-dev at lists.centos.org
centos at centos.org => discuss at lists.centos.org
centos-devel at centos.org => devel at lists.centos.org
centos-announce at centos.org => announce at lists.centos.org
centos-automotive-sig at centos.org => automotive-sig at lists.centos.org
centos-{cz,de,es,fr,nl,pt-br,zh}@centos.org =>
discuss-{cz,de,es,fr,nl,pt-br,zh}@lists.centos.org
ci-users at centos.org => ci-users at lists.centos.org
centos-gsoc: => gsoc at lists.centos.org
centos-mirror at centos.org => mirror at lists.centos.org
centos-mirror-announce at centos.org => mirror-announce at lists.centos.org
centos-newsletter at centos.org => newsletter at lists.centos.org
centos-promo at centos.org => promo at lists.centos.org
centos-virt at centos.org => virt at lists.centos.org
# Authentication
Mailman2 had no real concept of authentication so you could just
subscribe to one or more lists, and have a password associated with your
email address for that/these subscription(s).
Mailman3 itself is split into "core" and "webui" components, so when
we'll import mailman2 lists/config into mailman3, your existing
subscriptions will continue to work *but* not your password.
Mailman3 will be configured to support SSO, and so if you already have a
FAS/ACO account (https://accounts.centos.org) you'll be able to login
directly into new webui and manage your settings/subscriptions *if* your
ACO email address of course matches the one you initially subscribed
with for lists.centos.org.
If that's not the case, either create an ACO/FAS account that will match
and you'll be then able to "link" your mailman3 account with FAS and so
manage your settings/subscriptions.
If you don't want to, there is always the documented process :
https://docs.mailman3.org/en/latest/userguide.html#making-a-mailman-account
Thanks for your understanding and patience.
on behalf of the Infra team,
--
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
wsF5BAABCAAjFiEExbC4H21L30WoH1yeol26+xfzt6EFAmYMFVAFAwAAAAAACgkQol26+xfzt6HQ
pxAAvkaYQYSfVU6BOvLCQ+FB/OTrY3LSPnfYrBZAeanURkp8ssBeJCLw/OMYdz3r2RI2MEzK1oga
AgnTZLUffkpO4ViNW8RVnrkctuxAxhFfkoksrOhGH1PZhcXUXqLNCyngp5vAF9yYtz5TZF9jatZE
FfdCx4bU6jhLyvTCWp5Aqo/DPNyQ31nvpFfAqHcBHgW2oZu+bo8rq6+HhqesWioCsiZH5tlb2xiM
hcy5r+u+LYuB5wK06zFHmNiepbmTCO56G3/suhfyTWYY2A84Nkghrr01xYLUJAQJMvmbCr2PBIKb
Op7G/cEHDd9UWDWV1q/gM3QLQeyeIgAzNUcb2ww4Wo+Htk62uLM2Rj0a0i5IadAHDPv10KsxGD/7
HjHYBWUG+rvaKWQGxfVttmx8PRirdgjK2jwH3GLcxJioQxtJOGhP/xGD+fsjXSmpM1nHJzKXZOWn
DGNX1/hXOYG8vSuOFnoVV71tGIpsV1k7MkqXTDU6+oD2eeRxh3vyiTxHLVHL8FoDe4pTMn2wj7I2
uLIPFVsVcQG/oeGqJXHQ7W9BextHnPyr+tP5VlgNNYeoefwWgLJAbUMmH3J7jG1yTen3xB1tAwQh
7/aOiMI0AGrbs376/L80bBsNfADlaxT8bm2q5hAehcUVTdHN4qTAS+9hv/hURRWtz3WHSJjSdz1+
mzg=
=sWes
-----END PGP SIGNATURE-----
Due to a needed upgrade , we'll have to move the existing CentOS
mailman instance (aka https://lists.centos.org) to a new server/host.
Migration is scheduled for """"Tuesday April 8th, 7:00 am UTC time"""".
You can convert to local time with $(date -d '2024-04-08 07:00 UTC')
The expected "downtime" is estimated to ~60 minutes , time needed to :
- take last mailman2 backup
- reimport / convert mailman2 archives to mailman3 DB
- DNS propagation for A/AAAA/MX records
Here are also some important information about the mailman2 => mailman3
migration :
# Renamed lists
Worth knowing that, based on open discussion on the centos-devel list
(see whole thread at
https://lists.centos.org/pipermail/centos-devel/2024-March/165576.html),
existing lists will be *renamed* , so while we'll put aliases for
incoming mails, each list member will start receiving list mails from
new list name. So start updating your filters if you filter on email
address instead of "subject:"
Here is the overview of the new lists names :
arm-dev at centos.org => arm-dev at lists.centos.org
centos at centos.org => discuss at lists.centos.org
centos-devel at centos.org => devel at lists.centos.org
centos-announce at centos.org => announce at lists.centos.org
centos-automotive-sig at centos.org => automotive-sig at lists.centos.org
centos-{cz,de,es,fr,nl,pt-br,zh}@centos.org =>
discuss-{cz,de,es,fr,nl,pt-br,zh}@lists.centos.org
ci-users at centos.org => ci-users at lists.centos.org
centos-gsoc: => gsoc at lists.centos.org
centos-mirror at centos.org => mirror at lists.centos.org
centos-mirror-announce at centos.org => mirror-announce at lists.centos.org
centos-newsletter at centos.org => newsletter at lists.centos.org
centos-promo at centos.org => promo at lists.centos.org
centos-virt at centos.org => virt at lists.centos.org
# Authentication
Mailman2 had no real concept of authentication so you could just
subscribe to one or more lists, and have a password associated with your
email address for that/these subscription(s).
Mailman3 itself is split into "core" and "webui" components, so when
we'll import mailman2 lists/config into mailman3, your existing
subscriptions will continue to work *but* not your password.
Mailman3 will be configured to support SSO, and so if you already have a
FAS/ACO account (https://accounts.centos.org) you'll be able to login
directly into new webui and manage your settings/subscriptions *if* your
ACO email address of course matches the one you initially subscribed
with for lists.centos.org.
If that's not the case, either create an ACO/FAS account that will match
and you'll be then able to "link" your mailman3 account with FAS and so
manage your settings/subscriptions.
If you don't want to, there is always the documented process :
https://docs.mailman3.org/en/latest/userguide.html#making-a-mailman-account
Thanks for your understanding and patience.
on behalf of the Infra team,
--
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/OpensslDeprecateEngine
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 disable building the packages using ENGINE API in OpenSSL without
breaking ABI.
== Owner ==
* Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
* Email: dbelyavs@redhat.com
== Detailed Description ==
We are going to deprecate OpenSSL engine support. Engines are not FIPS
compatible and corresponding API is deprecated since OpenSSL 3.0. The
engine functionality we are aware of (PKCS#11, TPM) is either covered
by providers or will be covered soon.
We don't plan to remove the API from libcrypto.so. We are going to
prevent creating the new packages dependent on OpenSSL ENGINE API and
remove ENGINE dependencies from the existing packages.
During discussion of the previous proposal - to completely remove the
ENGINE API - there were many relevant arguments why it shouldn't be
done. We agree with them but still want to deprecate the ENGINE
support to simplify removing it in the earliest release when it's
feasible.
== Feedback ==
== Benefit to Fedora ==
We get rid of deprecated functionality and enforce using up-to-date
API. Engine support is deprecated in OpenSSL upstream, and after
provider migration caused some deficiencies with engine support. No
new features will be added to engine. So we reduce maintenance burden
and potentially attack surface.
It follows approach planned for CentOS 10.
== Scope ==
* Proposal owners: maintainers of packages enumerated here:
https://clang.fedorapeople.org/c10s-engine-users/ plus probably owners
of some Fedora-only packages
For most of the packages the maintainers will just have to rebuild
their packages after the OpenSSL change lands in compose. For several
packages some patches should be implemented to prevent compilation
errors.
* Other developers: -
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
This change probably requires mass-rebuild.
* Policies and guidelines: We need reject/modify packages providing
OpenSSL engines
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
None. Users will be encouraged to switch their configurations to use
providers instead but existing engines will continue working.
== How To Test ==
OpenSSL libcrypto.so exports the same ENGINE_* symbols as for f40.
Applications relying on the ENGINE API can't be built but still work.
== User Experience ==
Users will be encouraged to reconfigure systems to providers if they
use engines. No other changes are expected.
== Dependencies ==
In theory, all OpenSSL-dependent packages. In practice, only those
that explicitly use ENGINE api.
== Contingency Plan ==
Returning the engine header file to allow old applications to be built.
* Contingency mechanism: (What to do? Who will do it?) rebuild
OpenSSL and dependent packages
* Contingency deadline: beta freeze?
* Blocks release? Yes
== Documentation ==
TBD
== Release Notes ==
TBD
--
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-leave@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
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 disable building the packages using ENGINE API in OpenSSL without
breaking ABI.
== Owner ==
* Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
* Email: dbelyavs@redhat.com
== Detailed Description ==
We are going to deprecate OpenSSL engine support. Engines are not FIPS
compatible and corresponding API is deprecated since OpenSSL 3.0. The
engine functionality we are aware of (PKCS#11, TPM) is either covered
by providers or will be covered soon.
We don't plan to remove the API from libcrypto.so. We are going to
prevent creating the new packages dependent on OpenSSL ENGINE API and
remove ENGINE dependencies from the existing packages.
During discussion of the previous proposal - to completely remove the
ENGINE API - there were many relevant arguments why it shouldn't be
done. We agree with them but still want to deprecate the ENGINE
support to simplify removing it in the earliest release when it's
feasible.
== Feedback ==
== Benefit to Fedora ==
We get rid of deprecated functionality and enforce using up-to-date
API. Engine support is deprecated in OpenSSL upstream, and after
provider migration caused some deficiencies with engine support. No
new features will be added to engine. So we reduce maintenance burden
and potentially attack surface.
It follows approach planned for CentOS 10.
== Scope ==
* Proposal owners: maintainers of packages enumerated here:
https://clang.fedorapeople.org/c10s-engine-users/ plus probably owners
of some Fedora-only packages
For most of the packages the maintainers will just have to rebuild
their packages after the OpenSSL change lands in compose. For several
packages some patches should be implemented to prevent compilation
errors.
* Other developers: -
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
This change probably requires mass-rebuild.
* Policies and guidelines: We need reject/modify packages providing
OpenSSL engines
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
None. Users will be encouraged to switch their configurations to use
providers instead but existing engines will continue working.
== How To Test ==
OpenSSL libcrypto.so exports the same ENGINE_* symbols as for f40.
Applications relying on the ENGINE API can't be built but still work.
== User Experience ==
Users will be encouraged to reconfigure systems to providers if they
use engines. No other changes are expected.
== Dependencies ==
In theory, all OpenSSL-dependent packages. In practice, only those
that explicitly use ENGINE api.
== Contingency Plan ==
Returning the engine header file to allow old applications to be built.
* Contingency mechanism: (What to do? Who will do it?) rebuild
OpenSSL and dependent packages
* Contingency deadline: beta freeze?
* Blocks release? Yes
== Documentation ==
TBD
== Release Notes ==
TBD
--
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-leave@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
F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Wiki - https://fedoraproject.org/wiki/Changes/FedoraPlasmaWorkstation
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 ==
Switch the default desktop experience for Workstation to KDE Plasma.
The GNOME desktop is moved to a separate spin / edition, retaining
release-blocking status.
== Owner ==
* Names: [[User:joshstrobl | Joshua Strobl]], [[User:marcdeop | Marc
Deop i Argemí]], [[User:tdawson | Troy Dawson]], [[User:farchord |
Steve Cossette]], [[User:aleasto| Alessandro Astone]]
* Emails: joshua@buddiesofbudgie.org, marcdeop@fedoraproject.org,
tdawson@redhat.com, farchord@gmail.com, aleasto@fedoraproject.org
== Detailed Description ==
With the release of Plasma 6, KDE Plasma has developed into a high
quality, well-regarded desktop experience.
=== Improved end user experience ===
Plasma has been at the forefront of creating a cohesive desktop
platform that empowers the user to have full ownership of their
computing experience.
Plasma provides this approachable, highly-flexible, user-extensible
experience with predictability across Plasma releases. Unlike other
desktop experiences such as GNOME Shell, the APIs leveraged by Plasma
applets / widgets have been more stable across "minor" Plasma
releases, reducing long-term user frustration and promoting a
healthier ecosystem for developers and users alike.
This extensibility additionally applies to the underlying window
manager, KWin, with effects and scripts that provide both utility and
personalization, such as:
* Automatically blocking compositing for full screen applications
* Fun effects such as window glitch and portals
Plasma provides a more traditional user experience that could be
viewed as being more approachable to everyday computing users, serving
as a smoother "on-ramp" to using Linux-based operating systems.
Alongside its wide breadth of personalization capabilities, it
provides an out-of-the-box desktop experience that is more predictable
than some of its counterparts. As an example, Plasma provides a system
tray for applications supporting StatusNotifierItem (e.g. Flameshot,
OBS Studio, VPN clients), which is not functionality supported by
default in GNOME Shell and requires an extension which may break
between releases.
=== Standardization support ===
The KDE community has a long heritage of collaborative standards
development and supporting capabilities that application developers
and users need for a productive experience.
KDE is heavily involved in the development of cross-desktop standards
and tools that benefit the larger open source desktop community. From
the XDG icon theme specification to D-Bus to StatusNotifierItems and
Wayland protocols, KDE has been front and center for evolving the
Linux desktop platform in a manner that benefits the wider community.
Many of the specifications and protocols in use today originate or are
heavily influenced by KDE, and KDE has continued to be a bastion of
innovation in a user-centric and community-centric manner.
Notably, the following recent Wayland protocols have been driven or
influenced by KDE:
* xdg-toplevel-drag (dragging tabs in and out of windows)
* content-type
* drm-lease (enable applications to selectively gain privileged
display device access)
* tearing-control (enable faster than display framerate refreshing, ie
no "vsync lock")
* ext-idle-notify
* xdg-activation (enable notifications to bring a window to the
foreground on user activation)
* xdg-decoration (server side decorations, derived from KDE's protocol)
There are several upcoming protocols being driven by KDE as well, such as:
* alpha-modifier (set alpha values for a surface)
* ext-blur (enable blur effect underneath a surface)
* xdg-toplevel-icon (enable applications to set window icons)
* ext-placement (allow application window positioning)
* window-id (consistent, uniform method window IDs)
* xdg-pip (picture in picture overlays)
* dbus-annotation (link D-Bus objects to surfaces)
This demonstrates that KDE works not to just enable new technologies
and features for Plasma Wayland, but they also do it in a way that
drives larger community adoption, success, and growth.
=== Wayland support ===
KDE Plasma offers the most advanced Wayland desktop experience today,
providing support for highly-demanded features, such as:
* Fractional scaling
* Color management
* Variable Refresh Rate for capable displays
* Support for optionally allowing legacy X11 applications to access
desktop resources
* Screensharing for legacy applications
* Global shortcut support for legacy applications
* Support for accessibility, including integration with the Orca screen reader
* Support for AR/VR displays
=== Industry support ===
KDE Plasma has been garnering wider industry support in consumer
products over the last couple years. This includes various PINE64
products (PinePhones, PineBooks, etc.), the Steam Deck from Valve, and
Tuxedo OS from Tuxedo Computers.
The Steam Deck in particular has brought the Linux desktop in the form
of KDE Plasma to more people than ever before, through the desktop
mode in SteamOS 3.x releases. As a result, Valve has heavily invested
into KDE and its technology stack for mainstream usage. Game
developers are also testing on KDE Plasma more often nowadays as part
of SteamOS compatibility testing.
=== Community Support ===
A number of Fedora downstreams have launched with KDE Plasma as the
flagship experience or migrated to it over time. Notably Fedora Asahi
Remix uses KDE Plasma as the flagship due to significantly better
support and features for ARM based platforms and the hardware that
Apple Silicon systems have. Nobara uses KDE Plasma as the flagship due
to a high quality Wayland experience that supports gaming and game
development well.
Developers of Linux XR applications and services already recommend
using KDE Plasma to be able to leverage AR/VR experiences in a modern
desktop.
Starting in 2025, KDE Plasma's release cycle switches to a semi-annual
cadence that lines up with Fedora Linux releases, enabling a tight
interlock of development and integration between Fedora and KDE.
== Feedback ==
== Benefit to Fedora ==
* Fedora Linux advertises and advocates for the most advanced Wayland
desktop experience with broad community support and engagement.
* We ship a desktop experience that supports the wide range of user
needs and enables the experiences people expect from a modern desktop
(HDR, VRR, VR gaming, HiDPI) and strives to support as many users as
possible in a manner that results in positive engagement with the
community.
* We align the default Fedora workstation experience with what the
larger PC ecosystem expects for a high quality desktop.
== Scope ==
* Proposal owners: fedora-release: -kde subpackages get renamed to
-workstation-kde. -workstation subpackages get renamed to
-workstation-gnome.
* Other developers: Fedora Plasma Workstation is added to the main
landing page and promoted as the default desktop experience
* Release engineering: [https://pagure.io/releng/issue/12043 12043]
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: No, it would not required changes as it is
already release-blocking.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
Existing Fedora Workstation systems will not be switched to KDE
Plasma. This will only affect new installs of Fedora Workstation.
Existing Fedora KDE installs will be upgraded to the Plasma
Workstation branding.
== How To Test ==
As the fundamental experience is not changing in the existing KDE
Plasma variant, users can try out the Fedora KDE spin to see what
Fedora Plasma Workstation looks like.
== User Experience ==
The user experience does not change from the existing KDE Plasma
variant. Existing Fedora Workstation users won't see their experience
change. New users of Fedora will get KDE Plasma instead of GNOME.
== Dependencies ==
N/A
== Contingency Plan ==
Retain the existing default GNOME experience for Fedora Workstation.
Move Fedora Plasma Workstation back to spin branding.
== Documentation ==
Documentation would need to be updated to reference Plasma and point
links to KDE rather than GNOME.
== Release Notes ==
Fedora Linux now offers a new default workstation experience as
"Fedora Plasma Workstation" using KDE Plasma Desktop. This replaces
the previous Fedora KDE Plasma spin. The previous "GNOME Shell"-based
desktop experience can now be accessed through its dedicated Edition
page.
--
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-leave@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
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 ==
Switch the default desktop experience for Workstation to KDE Plasma.
The GNOME desktop is moved to a separate spin / edition, retaining
release-blocking status.
== Owner ==
* Names: [[User:joshstrobl | Joshua Strobl]], [[User:marcdeop | Marc
Deop i Argemí]], [[User:tdawson | Troy Dawson]], [[User:farchord |
Steve Cossette]], [[User:aleasto| Alessandro Astone]]
* Emails: joshua@buddiesofbudgie.org, marcdeop@fedoraproject.org,
tdawson@redhat.com, farchord@gmail.com, aleasto@fedoraproject.org
== Detailed Description ==
With the release of Plasma 6, KDE Plasma has developed into a high
quality, well-regarded desktop experience.
=== Improved end user experience ===
Plasma has been at the forefront of creating a cohesive desktop
platform that empowers the user to have full ownership of their
computing experience.
Plasma provides this approachable, highly-flexible, user-extensible
experience with predictability across Plasma releases. Unlike other
desktop experiences such as GNOME Shell, the APIs leveraged by Plasma
applets / widgets have been more stable across "minor" Plasma
releases, reducing long-term user frustration and promoting a
healthier ecosystem for developers and users alike.
This extensibility additionally applies to the underlying window
manager, KWin, with effects and scripts that provide both utility and
personalization, such as:
* Automatically blocking compositing for full screen applications
* Fun effects such as window glitch and portals
Plasma provides a more traditional user experience that could be
viewed as being more approachable to everyday computing users, serving
as a smoother "on-ramp" to using Linux-based operating systems.
Alongside its wide breadth of personalization capabilities, it
provides an out-of-the-box desktop experience that is more predictable
than some of its counterparts. As an example, Plasma provides a system
tray for applications supporting StatusNotifierItem (e.g. Flameshot,
OBS Studio, VPN clients), which is not functionality supported by
default in GNOME Shell and requires an extension which may break
between releases.
=== Standardization support ===
The KDE community has a long heritage of collaborative standards
development and supporting capabilities that application developers
and users need for a productive experience.
KDE is heavily involved in the development of cross-desktop standards
and tools that benefit the larger open source desktop community. From
the XDG icon theme specification to D-Bus to StatusNotifierItems and
Wayland protocols, KDE has been front and center for evolving the
Linux desktop platform in a manner that benefits the wider community.
Many of the specifications and protocols in use today originate or are
heavily influenced by KDE, and KDE has continued to be a bastion of
innovation in a user-centric and community-centric manner.
Notably, the following recent Wayland protocols have been driven or
influenced by KDE:
* xdg-toplevel-drag (dragging tabs in and out of windows)
* content-type
* drm-lease (enable applications to selectively gain privileged
display device access)
* tearing-control (enable faster than display framerate refreshing, ie
no "vsync lock")
* ext-idle-notify
* xdg-activation (enable notifications to bring a window to the
foreground on user activation)
* xdg-decoration (server side decorations, derived from KDE's protocol)
There are several upcoming protocols being driven by KDE as well, such as:
* alpha-modifier (set alpha values for a surface)
* ext-blur (enable blur effect underneath a surface)
* xdg-toplevel-icon (enable applications to set window icons)
* ext-placement (allow application window positioning)
* window-id (consistent, uniform method window IDs)
* xdg-pip (picture in picture overlays)
* dbus-annotation (link D-Bus objects to surfaces)
This demonstrates that KDE works not to just enable new technologies
and features for Plasma Wayland, but they also do it in a way that
drives larger community adoption, success, and growth.
=== Wayland support ===
KDE Plasma offers the most advanced Wayland desktop experience today,
providing support for highly-demanded features, such as:
* Fractional scaling
* Color management
* Variable Refresh Rate for capable displays
* Support for optionally allowing legacy X11 applications to access
desktop resources
* Screensharing for legacy applications
* Global shortcut support for legacy applications
* Support for accessibility, including integration with the Orca screen reader
* Support for AR/VR displays
=== Industry support ===
KDE Plasma has been garnering wider industry support in consumer
products over the last couple years. This includes various PINE64
products (PinePhones, PineBooks, etc.), the Steam Deck from Valve, and
Tuxedo OS from Tuxedo Computers.
The Steam Deck in particular has brought the Linux desktop in the form
of KDE Plasma to more people than ever before, through the desktop
mode in SteamOS 3.x releases. As a result, Valve has heavily invested
into KDE and its technology stack for mainstream usage. Game
developers are also testing on KDE Plasma more often nowadays as part
of SteamOS compatibility testing.
=== Community Support ===
A number of Fedora downstreams have launched with KDE Plasma as the
flagship experience or migrated to it over time. Notably Fedora Asahi
Remix uses KDE Plasma as the flagship due to significantly better
support and features for ARM based platforms and the hardware that
Apple Silicon systems have. Nobara uses KDE Plasma as the flagship due
to a high quality Wayland experience that supports gaming and game
development well.
Developers of Linux XR applications and services already recommend
using KDE Plasma to be able to leverage AR/VR experiences in a modern
desktop.
Starting in 2025, KDE Plasma's release cycle switches to a semi-annual
cadence that lines up with Fedora Linux releases, enabling a tight
interlock of development and integration between Fedora and KDE.
== Feedback ==
== Benefit to Fedora ==
* Fedora Linux advertises and advocates for the most advanced Wayland
desktop experience with broad community support and engagement.
* We ship a desktop experience that supports the wide range of user
needs and enables the experiences people expect from a modern desktop
(HDR, VRR, VR gaming, HiDPI) and strives to support as many users as
possible in a manner that results in positive engagement with the
community.
* We align the default Fedora workstation experience with what the
larger PC ecosystem expects for a high quality desktop.
== Scope ==
* Proposal owners: fedora-release: -kde subpackages get renamed to
-workstation-kde. -workstation subpackages get renamed to
-workstation-gnome.
* Other developers: Fedora Plasma Workstation is added to the main
landing page and promoted as the default desktop experience
* Release engineering: [https://pagure.io/releng/issue/12043 12043]
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: No, it would not required changes as it is
already release-blocking.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
Existing Fedora Workstation systems will not be switched to KDE
Plasma. This will only affect new installs of Fedora Workstation.
Existing Fedora KDE installs will be upgraded to the Plasma
Workstation branding.
== How To Test ==
As the fundamental experience is not changing in the existing KDE
Plasma variant, users can try out the Fedora KDE spin to see what
Fedora Plasma Workstation looks like.
== User Experience ==
The user experience does not change from the existing KDE Plasma
variant. Existing Fedora Workstation users won't see their experience
change. New users of Fedora will get KDE Plasma instead of GNOME.
== Dependencies ==
N/A
== Contingency Plan ==
Retain the existing default GNOME experience for Fedora Workstation.
Move Fedora Plasma Workstation back to spin branding.
== Documentation ==
Documentation would need to be updated to reference Plasma and point
links to KDE rather than GNOME.
== Release Notes ==
Fedora Linux now offers a new default workstation experience as
"Fedora Plasma Workstation" using KDE Plasma Desktop. This replaces
the previous Fedora KDE Plasma spin. The previous "GNOME Shell"-based
desktop experience can now be accessed through its dedicated Edition
page.
--
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-leave@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
Fedora Linux 40 Final Freeze
Hi all,
Today, 2024-04-02, is an important day on the Fedora Linux 40 schedule
[1], with significant cut-offs.
Today we have the Final Freeze [2] which starts at 14:00 UTC. This means
that only packages that fix accepted blocker or freeze exception bugs
[3][4][5] will be marked as 'stable' and included in the Final composes.
Other builds will remain in updates-testing until the Final release is
approved, at which point the Final freeze is lifted and packages can
move to the 'updates' repository. Pending updates will be pushed before
the final release as zero-day updates.
Regards,
Samyak Jain
(fas/matrix: jnsamyak)
Fedora Release Engineering
[1] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
[2] https://fedoraproject.org/wiki/Milestone_freezes
[3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[5] https://qa.fedoraproject.org/blockerbugs/milestone/40/final/buglist
--
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
Today, 2024-04-02, is an important day on the Fedora Linux 40 schedule
[1], with significant cut-offs.
Today we have the Final Freeze [2] which starts at 14:00 UTC. This means
that only packages that fix accepted blocker or freeze exception bugs
[3][4][5] will be marked as 'stable' and included in the Final composes.
Other builds will remain in updates-testing until the Final release is
approved, at which point the Final freeze is lifted and packages can
move to the 'updates' repository. Pending updates will be pushed before
the final release as zero-day updates.
Regards,
Samyak Jain
(fas/matrix: jnsamyak)
Fedora Release Engineering
[1] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
[2] https://fedoraproject.org/wiki/Milestone_freezes
[3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[5] https://qa.fedoraproject.org/blockerbugs/milestone/40/final/buglist
--
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
Subscribe to:
Posts (Atom)