Reminder: F40 final freeze starts next week (2024-04-02)
by Kevin Fenzi
Just a reminder that, because Beta used it's 'target date #2'
(ie, today), the gap between the Beta release and Final freeze is only 1
week this time.
So, please take this time to do any last minute testing and bugfixing
and make sure any packages you expect to be in the final f40 base
repositories are pushed stable before next Tuesday (2024-04-02).
https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
kevin
2 months, 3 weeks
- 1
- 0
Fedora Linux 40 Beta Released
by Samyak Jain
Fedora Linux 40 Beta Released
------------------------------------------
The Fedora Project is pleased to announce the immediate availability of
Fedora Linux 40 Beta, the next step towards our planned Fedora Linux 40
release at the end of April.
Download the prerelease from our Get Fedora site:
* Get Fedora Linux 40 Beta Workstation:
https://fedoraproject.org/workstation/download/
* Get Fedora Linux 40 Beta Server: https://fedoraproject.org/server/download/
* Get Fedora Linux 40 Beta IoT: https://fedoraproject.org/iot/download/
* Get Fedora Linux 40 Beta CoreOS: https://fedoraproject.org/coreos/download/
* Get Fedora Linux 40 Beta Cloud: https://fedoraproject.org/cloud/download/
Or, check out one of our popular variants, including KDE Plasma, Xfce,
and other desktop environments:
* Get Fedora Linux 40 Beta Spins: https://spins.fedoraproject.org/prerelease
* Get Fedora Linux 40 Beta Labs: https://labs.fedoraproject.org/prerelease
For more details about the release, read the full announcement at
* https://fedoramagazine.org/announcing-fedora-linux-40-beta/
or look for the prerelease pages in the download sections at
* https://fedoraproject.org/
Since this is a Beta release, we expect that you may encounter bugs or
missing features. To report issues encountered during testing, contact
the Fedora QA team via the test(a)lists.fedoraproject.org mailing list or
in #fedora-qa on Libera Chat or the #qa:fedoraproject.org Matrix room.
Regards,
Samyak Jain
fas/matrix: jnsamyak
Fedora Release Engineering
2 months, 3 weeks
- 1
- 0
F41 Change Proposal: Versioned Kubernetes Packages (Self-Cont
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/VersionedKubernetesPackages
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.
= Multiple Versioned Kubernetes Packages =
== Summary ==
Provide all maintained Kubernetes releases in Fedora as multiple,
versioned packages. Current practice is a separate Kubernetes release
matched with each Fedora release.
== Owner ==
* Name: [[User:Buckaroogeek| Brad Smith]]
* Email: bradley.g.smith(a)gmail.com
== Detailed Description ==
The Kubernetes project maintains 3 concurrent versions with a new
release every 4 months. Each version has a defined life-cycle of
approximately 1 year (https://https://kubernetes.io/releases/ for
details and current versions). In this proposal a release is a
major:minor version combination such as 1.28 or 1.27 and ignores any
patch updates (e.g. 1.28.1 or 1.28.2 as these are part of the same
1.28 minor release).
We currently match one version of Kubernetes with each Fedora release.
See https://src.fedoraproject.org/rpms/kubernetes for the list of
Kubernetes releases by Fedora release. Due to the differing release
cadences between Fedora and Kubernetes this means that a new release
of Fedora may not have the most current release of Kubernetes. And,
given that the Kubernetes cluster upgrade process does not permit
skipping major:minor releases, not providing a Kubernetes release in
Fedora so that the most current Kubernetes release is available when a
Fedora release goes into production becomes a barrier to using Fedora
as a host OS for Kubernetes.
We propose to create packages for all current Kubernetes releases for
each Fedora release starting with Fedora 40. The package name would
follow the Fedora naming convention standard for multiple package
versions of "kubernetes[major].[minor]". Using the kubernetes-client
rpm as an example, instead of kubernetes-client-1.29.2-1.fc41 Fedora
would offer kubernetes1.29-client-1.29.2-1.fc41,
kubernetes1.28-client-1.28.5-1.fc41, and
kubernetes1.27-client-1.27.8-1.fc41. The exact list of Kubernetes
versions available will depend on what is supported upstream.
We also propose that there not be any default version of Kubernetes
for a given Fedora release. Fedora would not provide a
kubernetes-client-1.30.1-1.fc41 package available, assuming that
Kubernetes 1.30 is the "default" for Fedora 41. Default versions
coupled to a given Fedora release can result in unplanned version
updates to the installed Kubernetes version (i.e. v1.28 to v1.29)
which can adversely affect cluster functioning.
It is also important to note that each Kubernetes release is built
with a specific version of the Go language. The version of Go
available in a Fedora release will potentially be a constraint on
which version of Kubernetes can be provided for an older Fedora
release.
We also maintain a Kubernetes page on Fedora Quick Docs with
information about the change and how to install Kubernetes using
Fedora provided packages.
== Feedback ==
To be provided.
== Benefit to Fedora ==
Fedora becomes a first class platform for Kubernetes using packages
from Fedora repositories. That is, all current, maintained releases of
Kubernetes are available in the main Fedora repositories, subject to
the Go language constraint. This allows Fedora, as a host OS for a
Kubernetes cluster, to be maintained and upgraded independently of the
Kubernetes release used by the cluster. This also allows the cluster
to be upgraded independently of the Fedora release using Fedora
provided packages.
This also means that a Kubernetes cluster administrator using Fedora
as their workstation can install and use or retain the appropriate
Kubernetes command line client, kubectl, that matches the release of
the cluster. Updating to a new Fedora release will not inadvertently
install a command line client that is not compatible with the release
version of the cluster(s) managed by the user.
== Scope ==
* Proposal owners:
With each new minor release of Kubernetes, package owners would
request a new repository on src.fedoraproject.org from engineering
similar to what the nodejs team now does for the parallel-installable
versions of nodejs. Documentation would be refreshed to inform users
of the new version and what specific Fedora releases the new version
of Kubernetes would be available on.
* Other developers:
Releases of cri-o and cri-tools are version matched with Kubernetes
release at the major:minor level. Cri-o uses modularity in Fedora 38
and older to provide multiple versions. The cri-o and cri-tools
package maintainers will adopt a similar versioned approach to
packaging and release in Fedora.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
Release engineering would need to create the new dist-git repository
for each new Kubernetes release.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
This change will require documentation in on-line Fedora documentation
such as the dedicated Quick Docs page and posts to various forums and
mailing lists to raise awareness. Upgrading to Fedora 40 on a machine
with Fedora 39 or Fedora 38 would require a manual step by the user to
select the appropriate versioned Kubernetes package.
== How To Test ==
1. Install a versioned Kubernetes package on a fresh instance of
Fedora and create a functioning test cluster.
2. On a cluster node, replace a non-versioned Kubernetes package with
a versioned package and rejoin cluster. There should not be any
errors.
== User Experience =
The user experience should remain unchanged except for the need to
select a specific version of Kubernetes.
== Dependencies ==
No direct dependencies. If cri-o and/or cri-tools are installed and
used then these packages and kubernetes should have the same
major:minor version.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A
== Documentation ==
Fedora Quick Docs:
https://docs.fedoraproject.org/en-US/quick-docs/using-kubernetes/
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
2 months, 3 weeks
- 1
- 0
F41 Change Proposal: Switch to DNF 5 (System-Wide)
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/SwitchToDnf5
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(a)redhat.com
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmracek(a)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 two dnf5 test days for Fedora
[https://fedoraproject.org/wiki/Test_Day:2023-03-14_Fedora_38_DNF_5
38] and [https://fedoraproject.org/wiki/Test_Day:2023-08-11_Fedora_39_DNF_5
39]. 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. These libraries can
coexist with the new dnf5 package on the same system. Although the
setup is not ideal due to differences in package state metadata
formats stored at separate locations, resulting in inefficient storage
usage, this is generally imperceptible for typical GUI users.
Furthermore, the underlying RPM DB remains the sole shared source of
information about installed packages.
=== 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-configurat...
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 ===
The transactional history 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.
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
2 months, 3 weeks
- 1
- 0
F41 Change Proposal: RPM 4.20 (System-Wide)
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/RPM-4.20
== Summary ==
Update RPM to the up coming [https://rpm.org/wiki/Releases/4.20.0
4.20] release.
== Owner ==
* Name: [[User:ffesti| Florian Festi]]
* Email: ffesti(a)redhat.com
== Detailed Description ==
RPM 4.20 contains various improvements over previous versions.
* Hands-free packaging
** [https://github.com/rpm-software-management/rpm/issues/1087
Declarative build system]
** Dynamic spec generation extended
** [https://github.com/orgs/rpm-software-management/projects/16/views/1
File trigger scriptlet arguments]
** [https://github.com/rpm-software-management/rpm/issues/782 Support
for spec local dependency generators]
** [https://github.com/rpm-software-management/rpm/issues/2816 Support
for sysusers 'm' directive]
** [https://github.com/rpm-software-management/rpm/issues/2078
Guaranteed per-build directory]
* [https://github.com/rpm-software-management/rpm/issues/1536 Public plugin API]
* Increased install scriptlet isolation
([https://github.com/rpm-software-management/rpm/issues/2632 #2632],
[https://github.com/rpm-software-management/rpm/issues/2665 #2665])
The 4.20 alpha release is expected in late March/early April and the
final release is expected in time for the Fedora 41 release cycle as
usual.
== Feedback ==
== Benefit to Fedora ==
This release comes with many improvements. It opens the possibility
for Fedora to adopt the new major features mentioned above.
== Scope ==
* Proposal owners:
** Release RPM 4.20 alpha
** Rebase RPM in rawhide
** Assist with dealing with incompatibilities
* Other developers:
** Test new release, report issues and bugs
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: None
== Upgrade/compatibility impact ==
== How To Test ==
Rpm receives a thorough and constant testing via every single package
build, system installs and updates. New features can be tested
specifically as per their documentation.
== User Experience ==
There are no major differences in the normal user experience.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Revert back to RPM 4.19
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
Release notes at https://rpm.org/wiki/Releases/4.20.0 (still tbd) and
reference manual at
https://rpm-software-management.github.io/rpm/manual/
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
2 months, 3 weeks
- 1
- 0
Fedora Linux 40 Beta release is GO
by Aoife Moloney
The Fedora Linux 40 Beta RC 1.10 compose is GO and will be shipped
live on Tuesday, 26th March 2024.
For more information please check the Go/No-Go meeting minutes[1] or log[2].
[1] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-0...
[2] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-0...
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
2 months, 4 weeks
- 1
- 0
Orphaned packages looking for new maintainers
by Maxwell G
(NOTE: Some packages in this report were already retired in distgit but
still show up in the orphaned packages list due to
https://pagure.io/releng/issue/12028)
Report started at 2024-03-21 16:05:32 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
================================================================================
R-presser @r-maint-sig, orphan 7 weeks ago
atinout orphan 6 weeks ago
botan orphan 0 weeks ago
deepin-dock @deepinde-sig, cheeselee, 0 weeks ago
felixonmars, orphan, zsun
emacs-htmlize orphan 0 weeks ago
gnome-shell-extension-freon orphan 2 weeks ago
gnome-translate orphan 7 weeks ago
golang-github- @go-sig, ngompa, orphan 6 weeks ago
googlecloudplatform-guest-
logging
golang-storj-uplink @go-sig, orphan 6 weeks ago
google-compute-engine-guest- ngompa, orphan 6 weeks ago
configs
google-disk-expand orphan 6 weeks ago
google-guest-agent @go-sig, ngompa, orphan 6 weeks ago
google-osconfig-agent @go-sig, orphan 6 weeks ago
kio-upnp-ms jgrulich, orphan 2 weeks ago
ktp-contact-runner @kde-sig, orphan, rdieter 2 weeks ago
libmodulemd1 @copr-sig, orphan 7 weeks ago
libtranslate orphan 7 weeks ago
lightly orphan 8 weeks ago
liquidshell orphan 3 weeks ago
loudgain orphan 1 weeks ago
mrxvt orphan 1 weeks ago
ocaml-newt orphan 7 weeks ago
perl-Git-PurePerl iarnell, orphan 4 weeks ago
perl-Net-GitHub jplesnik, lkundrak, orphan, 4 weeks ago
ppisar
perl-PDF-Haru orphan 6 weeks ago
perl-Spreadsheet-ParseExcel- jplesnik, orphan, ppisar 4 weeks ago
Simple
perl-Spreadsheet-WriteExcel- jplesnik, orphan, ppisar 4 weeks ago
Simple
perl-String-Diff iarnell, orphan 4 weeks ago
perl-WWW-Google-Contacts orphan 2 weeks ago
phosh-mobile-settings orphan 6 weeks ago
php-doctrine-persistence2 orphan 7 weeks ago
php-doctrine-persistence3 orphan 7 weeks ago
php-echonest-api orphan 7 weeks ago
php-endroid-qrcode orphan 7 weeks ago
php-interfasys-lognormalizer orphan 7 weeks ago
php-ircmaxell-random-lib orphan 7 weeks ago
php-ircmaxell-security-lib orphan 7 weeks ago
php-kukulich-fshl orphan 7 weeks ago
php-mikealmond-musicbrainz orphan 7 weeks ago
php-nyholm-psr7 orphan 7 weeks ago
php-pear-MDB2-Schema orphan 6 weeks ago
php-phpSmug orphan 4 weeks ago
php-phpdocumentor-reflection- orphan 7 weeks ago
docblock
php-symfony-monolog-bundle orphan 7 weeks ago
php-true-punycode orphan 7 weeks ago
python-aiomqtt orphan 2 weeks ago
python-autoprop orphan 2 weeks ago
python-colorcet orphan 2 weeks ago
python-extractcode @python-packagers-sig, orphan 1 weeks ago
python-limits orphan 1 weeks ago
python-param orphan 2 weeks ago
python-pyct orphan 2 weeks ago
python-signature-dispatch orphan 2 weeks ago
python-vecrec orphan 2 weeks ago
python-wtforms-sqlalchemy orphan 5 weeks ago
qterm orphan 6 weeks ago
raptor orphan, rdieter 4 weeks ago
rubygem-rest-client jaruga, orphan, tdawson 6 weeks ago
rubygem-rubygems-mirror orphan 7 weeks ago
rust-loopdev @rust-sig, bgurney, orphan 7 weeks ago
sphinxbase @epel-packagers-sig, orphan 7 weeks ago
svnkit orphan 6 weeks ago
telepathy-logger-qt @kde-sig, jgrulich, orphan 2 weeks ago
The following packages require above mentioned packages:
Depending on: botan (13), status change: 2024-03-20 (0 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.3-17.fc40.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.3-17.fc40
lua-event (maintained by: robert)
lua-event-0.4.6-14.fc40.src requires ikiwiki = 3.20200202.3-17.fc40
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: deepin-dock (13), status change: 2024-03-20 (0 weeks ago)
deepin-control-center (maintained by: @deepinde-sig, cheeselee, zsun)
deepin-control-center-5.5.158-3.fc40.src requires deepin-dock-devel = 5.5.81-3.fc40
deepin-control-center-5.5.158-3.fc40.x86_64 requires deepin-daemon = 5.14.44-8.fc40, deepin-network-core = 1.1.9-3.fc40, startdde = 5.10.1-3.fc40
deepin-file-manager (maintained by: @deepinde-sig, cheeselee, zsun)
deepin-desktop-5.8.3-1.fc40.x86_64 requires deepin-control-center = 5.5.158-3.fc40, deepin-dock = 5.5.81-3.fc40, deepin-launcher = 5.6.1-3.fc40, deepin-session-ui = 5.6.2-3.fc40
deepin-file-manager-5.8.3-1.fc40.src requires deepin-dock-devel = 5.5.81-3.fc40
deepin-network-core (maintained by: @deepinde-sig, cheeselee, zsun)
deepin-network-core-1.1.9-3.fc40.src requires deepin-control-center-devel = 5.5.158-3.fc40, deepin-dock-devel = 5.5.81-3.fc40, deepin-session-shell-devel = 5.5.93-3.fc40
deepin-network-core-1.1.9-3.fc40.x86_64 requires libdccwidgets.so()(64bit)
deepin-session-ui (maintained by: @deepinde-sig, cheeselee, felixonmars, zsun)
deepin-session-ui-5.6.2-3.fc40.src requires pkgconfig(dde-dock) = 4.0
deepin-session-ui-5.6.2-3.fc40.x86_64 requires deepin-daemon = 5.14.44-8.fc40, deepin-session-shell = 5.5.93-3.fc40, startdde = 5.10.1-3.fc40
deepin-system-monitor (maintained by: @deepinde-sig, cheeselee, zsun)
deepin-system-monitor-6.0.3-1.fc40.src requires deepin-dock-devel = 5.5.81-3.fc40
deepin-dock (maintained by: @deepinde-sig, cheeselee, felixonmars, orphan, zsun)
deepin-dock-5.5.81-3.fc40.src requires deepin-control-center-devel = 5.5.158-3.fc40
deepin-dock-5.5.81-3.fc40.x86_64 requires deepin-network-core = 1.1.9-3.fc40, libdccwidgets.so()(64bit)
deepin-session-shell (maintained by: @deepinde-sig, cheeselee, zsun)
deepin-session-shell-5.5.93-3.fc40.x86_64 requires deepin-network-core = 1.1.9-3.fc40
deepin-daemon (maintained by: @deepinde-sig, @go-sig, cheeselee, zsun)
deepin-daemon-5.14.44-8.fc40.x86_64 requires deepin-session-ui = 5.6.2-3.fc40
deepin-draw (maintained by: @deepinde-sig, cheeselee, zsun)
deepin-draw-6.0.6-3.fc40.x86_64 requires deepin-notifications = 5.6.2-3.fc40
deepin-editor (maintained by: @deepinde-sig, cheeselee, zsun)
deepin-editor-6.0.10-4.fc40.x86_64 requires deepin-notifications = 5.6.2-3.fc40
deepin-calendar (maintained by: @deepinde-sig, cheeselee, felixonmars, zsun)
deepin-calendar-5.10.0-3.fc40.x86_64 requires deepin-daemon(x86-64) = 5.14.44-8.fc40
deepin-launcher (maintained by: @deepinde-sig, cheeselee, zsun)
deepin-launcher-5.6.1-3.fc40.x86_64 requires deepin-daemon = 5.14.44-8.fc40, startdde = 5.10.1-3.fc40
startdde (maintained by: @deepinde-sig, @go-sig, cheeselee, zsun)
startdde-5.10.1-3.fc40.x86_64 requires deepin-daemon = 5.14.44-8.fc40
Depending on: golang-github-googlecloudplatform-guest-logging (2), status change: 2024-02-06 (6 weeks ago)
google-osconfig-agent (maintained by: @go-sig, orphan)
golang-github-googlecloudplatform-osconfig-devel-20231107.00-1.fc40.noarch requires golang(github.com/GoogleCloudPlatform/guest-logging-go/logger) = 0-9.20220819gitfacc9c0.fc39
google-osconfig-agent-20231107.00-1.fc40.src requires golang(github.com/GoogleCloudPlatform/guest-logging-go/logger) = 0-9.20220819gitfacc9c0.fc39
google-guest-agent (maintained by: @go-sig, ngompa, orphan)
google-guest-agent-20230726.00-3.fc39.src requires golang(github.com/GoogleCloudPlatform/guest-logging-go/logger) = 0-9.20220819gitfacc9c0.fc39
Depending on: libmodulemd1 (1), status change: 2024-01-30 (7 weeks ago)
fedmod (maintained by: kalev, nphilipp)
fedmod-0.6.6-5.fc40.noarch requires python3-libmodulemd1 = 1.8.16-10.fc39
fedmod-0.6.6-5.fc40.src requires python3-libmodulemd1 = 1.8.16-10.fc39
Depending on: libtranslate (1), status change: 2024-01-29 (7 weeks ago)
gnome-translate (maintained by: orphan)
gnome-translate-0.99-43.fc39.src requires libtranslate-devel = 0.99-117.fc40
gnome-translate-0.99-43.fc39.x86_64 requires libtranslate.so.0()(64bit)
Depending on: perl-Spreadsheet-WriteExcel-Simple (1), status change: 2024-02-20 (4 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-ircmaxell-security-lib (1), status change: 2024-01-31 (7 weeks ago)
php-ircmaxell-random-lib (maintained by: orphan)
php-ircmaxell-random-lib-1.2.0-15.fc39.noarch requires php-composer(ircmaxell/security-lib) = 1.1.0, php-ircmaxell-security-lib = 1.1.0-19.fc39
php-ircmaxell-random-lib-1.2.0-15.fc39.src requires php-composer(ircmaxell/security-lib) = 1.1.0, php-ircmaxell-security-lib = 1.1.0-19.fc39
Depending on: php-nyholm-psr7 (1), status change: 2024-01-31 (7 weeks ago)
php-symfony-psr-http-message-bridge (maintained by: siwinski)
php-symfony-psr-http-message-bridge-1.3.0-7.fc38.src requires php-composer(nyholm/psr7) = 1.8.0
Depending on: python-autoprop (1), status change: 2024-03-01 (2 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-param (2), status change: 2024-03-01 (2 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 (2 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 (2 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
Depending on: raptor (2), status change: 2024-02-19 (4 weeks ago)
COPASI (maintained by: @neuro-sig, sagitter)
COPASI-4.42.284-6.fc40.src requires raptor-devel = 1.4.21-44.fc40
COPASI-4.42.284-6.fc40.x86_64 requires libraptor.so.1()(64bit)
COPASI-gui-4.42.284-6.fc40.x86_64 requires libraptor.so.1()(64bit)
python3-COPASI-4.42.284-6.fc40.x86_64 requires libraptor.so.1()(64bit)
traverso (maintained by: vascom)
traverso-0.49.6-12.fc40.src requires raptor-devel = 1.4.21-44.fc40
Affected (co)maintainers
@copr-sig: libmodulemd1
@deepinde-sig: deepin-dock
@epel-packagers-sig: sphinxbase
@go-sig: google-osconfig-agent, golang-storj-uplink, google-guest-agent, golang-github-googlecloudplatform-guest-logging, deepin-dock
@kde-sig: telepathy-logger-qt, ktp-contact-runner
@neuro-sig: botan, raptor
@python-packagers-sig: python-extractcode
@r-maint-sig: R-presser
@rust-sig: rust-loopdev
ankursinha: botan
bgurney: rust-loopdev
cheeselee: deepin-dock
felixonmars: deepin-dock
iarnell: perl-String-Diff, perl-Git-PurePerl
jaruga: rubygem-rest-client
jgrulich: telepathy-logger-qt, kio-upnp-ms
jplesnik: perl-Net-GitHub, perl-Spreadsheet-WriteExcel-Simple, perl-Spreadsheet-ParseExcel-Simple
kalev: libmodulemd1
lbazan: botan
lkundrak: perl-Net-GitHub
mathstuf: botan
ngompa: google-guest-agent, google-compute-engine-guest-configs, golang-github-googlecloudplatform-guest-logging
nphilipp: libmodulemd1
petersen: botan
ppisar: perl-Net-GitHub, perl-Spreadsheet-WriteExcel-Simple, perl-Spreadsheet-ParseExcel-Simple
qulogic: botan
rdieter: raptor, ktp-contact-runner
robert: botan
sagitter: raptor
siwinski: php-nyholm-psr7
tdawson: rubygem-rest-client
thm: botan
vanessakris: botan
vascom: raptor
zsun: deepin-dock
Orphans (63): R-presser atinout botan deepin-dock emacs-htmlize
gnome-shell-extension-freon gnome-translate
golang-github-googlecloudplatform-guest-logging
golang-storj-uplink google-compute-engine-guest-configs
google-disk-expand google-guest-agent google-osconfig-agent
kio-upnp-ms ktp-contact-runner libmodulemd1 libtranslate lightly
liquidshell loudgain mrxvt ocaml-newt perl-Git-PurePerl
perl-Net-GitHub perl-PDF-Haru perl-Spreadsheet-ParseExcel-Simple
perl-Spreadsheet-WriteExcel-Simple perl-String-Diff
perl-WWW-Google-Contacts phosh-mobile-settings
php-doctrine-persistence2 php-doctrine-persistence3
php-echonest-api php-endroid-qrcode php-interfasys-lognormalizer
php-ircmaxell-random-lib php-ircmaxell-security-lib
php-kukulich-fshl php-mikealmond-musicbrainz php-nyholm-psr7
php-pear-MDB2-Schema php-phpSmug
php-phpdocumentor-reflection-docblock php-symfony-monolog-bundle
php-true-punycode python-aiomqtt python-autoprop python-colorcet
python-extractcode python-limits python-param python-pyct
python-signature-dispatch python-vecrec python-wtforms-sqlalchemy
qterm raptor rubygem-rest-client rubygem-rubygems-mirror
rust-loopdev sphinxbase svnkit telepathy-logger-qt
Orphans (dependend on) (13): botan deepin-dock
golang-github-googlecloudplatform-guest-logging libmodulemd1
libtranslate perl-Spreadsheet-WriteExcel-Simple
php-ircmaxell-security-lib php-nyholm-psr7 python-autoprop
python-param python-pyct python-signature-dispatch raptor
Orphans (rawhide) for at least 6 weeks (dependend on) (5):
golang-github-googlecloudplatform-guest-logging libmodulemd1
libtranslate php-ircmaxell-security-lib php-nyholm-psr7
Orphans (rawhide) (not depended on) (50): R-presser atinout
emacs-htmlize gnome-shell-extension-freon gnome-translate
golang-storj-uplink google-compute-engine-guest-configs
google-disk-expand google-guest-agent google-osconfig-agent
kio-upnp-ms ktp-contact-runner lightly liquidshell loudgain mrxvt
ocaml-newt perl-Git-PurePerl perl-Net-GitHub perl-PDF-Haru
perl-Spreadsheet-ParseExcel-Simple perl-String-Diff
perl-WWW-Google-Contacts phosh-mobile-settings
php-doctrine-persistence2 php-doctrine-persistence3
php-echonest-api php-endroid-qrcode php-interfasys-lognormalizer
php-ircmaxell-random-lib php-kukulich-fshl
php-mikealmond-musicbrainz php-pear-MDB2-Schema php-phpSmug
php-phpdocumentor-reflection-docblock php-symfony-monolog-bundle
php-true-punycode python-aiomqtt python-colorcet
python-extractcode python-limits python-vecrec
python-wtforms-sqlalchemy qterm rubygem-rest-client
rubygem-rubygems-mirror rust-loopdev sphinxbase svnkit
telepathy-logger-qt
Orphans (rawhide) for at least 6 weeks (not dependend on) (30):
R-presser atinout gnome-translate golang-storj-uplink
google-compute-engine-guest-configs google-disk-expand
google-guest-agent google-osconfig-agent lightly ocaml-newt
perl-PDF-Haru phosh-mobile-settings php-doctrine-persistence2
php-doctrine-persistence3 php-echonest-api php-endroid-qrcode
php-interfasys-lognormalizer php-ircmaxell-random-lib
php-kukulich-fshl php-mikealmond-musicbrainz php-pear-MDB2-Schema
php-phpdocumentor-reflection-docblock php-symfony-monolog-bundle
php-true-punycode qterm rubygem-rest-client
rubygem-rubygems-mirror rust-loopdev sphinxbase svnkit
Depending packages (rawhide) (39): COPASI deepin-calendar
deepin-control-center deepin-daemon deepin-dock deepin-draw
deepin-editor deepin-file-manager deepin-launcher
deepin-network-core deepin-session-shell deepin-session-ui
deepin-system-monitor fedmod git-annex gnome-translate
google-guest-agent google-osconfig-agent guitone ikiwiki lua-event
monotone perl-Spreadsheet-ParseExcel-Simple
php-ircmaxell-random-lib php-symfony-psr-http-message-bridge
python-autoprop python-bluepyopt python-colorcet python-datalad
python-efel python-elephant python-ephyviewer python-neo
python-pyct python-pynn python-vecrec startdde
trac-monotone-plugin traverso
Packages depending on packages orphaned (rawhide) for more than 6
weeks (6): fedmod gnome-translate google-guest-agent
google-osconfig-agent php-ircmaxell-random-lib
php-symfony-psr-http-message-bridge
--
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-03-21 16:09:32 UTC
--
Maxwell G (@gotmax23)
Pronouns: He/They
2 months, 4 weeks
- 1
- 0
REMINDER: Fedora Linux 40 Beta Go/No-Go Meeting Tomorrow, March 21st
by Aoife Moloney
Hi folks,
A quick reminder that the Fedora Linux 40 Beta Go/No-Go meeting[1]
will be held at 1700 UTC on Thursday 21st March in
#meeting:fedoraproject.org on Matrix.
More information about the Go/No-Go meeting can be found on the wiki[2].
[1] https://calendar.fedoraproject.org/meeting/10764/
[2] https://fedoraproject.org/wiki/Go_No_Go_Meeting
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
2 months, 4 weeks
- 1
- 0
F41 Change Proposal: Enable Consistent Device Naming in Cloud Images (self-contained)
by Aoife Moloney
Wiki -> https://fedoraproject.org/wiki/Changes/EnableConsistentDeviceNamingCloud
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.
= Enable Consistent Device Naming in Cloud Images =
== Summary ==
This proposal aims to remove the `net.ifnames=0` kernel command line
entry from the Fedora cloud kickstarts so that consistent device
naming is enabled for cloud instances. This change brings Fedora Cloud
in line with Fedora Server, Workstation, and CoreOS.
== Owner ==
* Name: [[User:mhayden|Major Hayden]]
* Email: major(a)redhat.com
== Detailed Description ==
Fedora cloud images currently set `net.ifnames=0` on the kernel
command line during the
[https://pagure.io/fedora-kickstarts/blob/main/f/fedora-cloud-base.ks#_35
kickstart] process. This disables consistent device naming and ensures
that ethernet devices retain the old-style names of `eth0`, `eth1`,
`eth2`, and so on.
Removing the `net.ifnames=0` configuration allows Fedora cloud
instances to use consistent device names for network devices. This
brings Cloud images in line with Fedora Server, Workstation, and
CoreOS.
== Feedback ==
One of the proposed alternatives is to leave `net.ifnames=0` in the
kernel command line to remain consistent between releases. Although
RHEL allows for `net.ifnames=0` for KVM instances, it is
[https://access.redhat.com/solutions/2435891|strongly recommended not
to use it] with OpenStack or RHV environments. Fedora Cloud images are
used for multiple types of clouds, including public clouds and private
clouds.
This approach is less disruptive, but it pushes off the consistent
device naming change until a later date and causes cloud images to
operate differently than other Fedora deployments.
Other distributions have taken different turns with this
configuration. [https://lists.ubuntu.com/archives/ubuntu-devel/2016-April/039325.html|
Ubuntu] removed it in 2016, Debian
[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863385| added it
back in 2017], and
[https://documentation.suse.com/sles/15-SP4/pdf/article-minimal-vm_en.pdf|
SUSE has had it] for some time. There were issues with cloud-init
during the early days of network device naming in 2016/2017, but
[https://github.com/canonical/cloud-init/blob/d8e3a4b4d4ca443227bf06bdaa5d...
cloud-init supports consistent network names] since 2017. RHEL
currently uses `net.ifnames=0`, but there is a debate about whether it
should be removed in a future major release.
== Benefit to Fedora ==
The main benefit comes from bringing cloud instances inline with other
deployment types in how they name network devices. It also helps with
cloud providers that offer up different types of network interfaces to
an instance. For example, an emulated network device would present
itself differently than one offered via SRIOV and it would allow an
instance administrator to easily tell which network interface
corresponds to each network device. This is especially important for
certain clouds, such as OpenStack clouds.
== Scope ==
* Proposal owners:
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
'''Upgrades:''' Users who are upgrading to the next Fedora release
will not notice a change in their instances since the `net.ifnames=0`
change is only applied during the kickstart process. Their instances
will continue using the old network names.
'''New deployments:''' If a user has older Fedora deployments and they
deploy a new Fedora release with this change applied, their network
devices will use consistent network names instead of the old `eth0`
and `eth1` style names. Although this won't impact software like
cloud-init, it will impact users who have deployment scripts
(Terraform or Ansible, for example) that need to set network
configuration based on the network adapter's name. They will need to
adjust the name of the network device in their deployment scripts.
== How To Test ==
Use an image built without `net.ifnames=0` or take an existing cloud
instance and remove `net.ifnames=0` from the kernel command line:
grubby --update-kernel=current_kernel --remove-args="kernel_args"
After a reboot, the device names should change from `eth0` to reflect
the consistent device names based on the hardware:
$ ip link | grep ^[0-9]
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state
UNKNOWN mode DEFAULT group default qlen 1000
2: enp2s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq
state DOWN mode DEFAULT group default qlen 1000
3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP mode DEFAULT group default qlen 1000
4: enp2s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq
state DOWN mode DEFAULT group default qlen 1000
== User Experience ==
Users who don't need to apply any specialized network configuration
will likely not notice a change. All of the cloud-init functionality
will work the same as it did previously.
For users who need to apply specific network configuration on specific
instances will need to change the name they use to refer to those
network interfaces. For example, the main network device may shift
from `eth0` to `ens3` on some KVM platforms. Other cloud instances
might show a network device that specifies a PCI bus entry, such as
`enp2s0f0`. Although this might be confusing at first glance, it will
be familiar to users of Fedora Workstation, Server, and CoreOS.
Users could opt out by adding `net.ifnames=0` back to their kernel command line:
grubby --update-kernel=ALL --args="net.ifnames=0"
== Dependencies ==
This change does not depend on any other changes and it has no impact
on cloud-specific dependencies, such as cloud-init.
If users have custom setup scripts that apply network configuration,
or if they use Terraform/Ansible to perform these steps, they may need
to adjust their scripts to account for the new network names.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), Yes/No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
3 months
- 1
- 0
F41 Change Proposal: Change Compose Settings (system-wide)
by Aoife Moloney
= Upgrade systems to createrepo_c 1.0 and change repositories metadata
settings <!-- The name of your change proposal --> =
{{Change_Proposal_Banner}}
Wiki -> https://fedoraproject.org/wiki/Changes/ChangeComposeSettings
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
This is a proposal for upgrading systems which produce composes to
createrepo_c > 1.0 and changing some options used to create Fedora
repositories metadata. Note that some of these changes are inevitable
due to createrepo_c >= 1.0 behavioral change. We aim to change both
Rawhide/F41, then move all following releases to the new settings,
while preserving most of the current settings for releases <= 40.
== Owner ==
* Name: [[User:mattia| Mattia Verga]], [[User:kevin| Kevin Fenzi]]
* Email: mattia(a)fedorapeople.org, kevin(a)fedorapeople.org
== Detailed Description ==
With createrepo_c < 1.0 we're currently using different settings for
Rawhide repository metadata and stable releases repository metadata.
* Rawhide
** gzip compression for all metadata
** no updateinfo.xml file is generated (no updates repository exists)
** sqlite database of repodata is generated and compressed with gzip as well
** comps repodata is made available both as uncompressed xml and gzipped
** zchunk is active
** DRPMs disabled
* F40
** gzip compression for primary metadata
** updateinfo.xml (for updates repository) is compressed with XZ
** sqlite database of repodata is generated and compressed with BZ2
** comps repodata is made available both as uncompressed xml and gzipped
** zchunk is active
** DRPMs disabled (approved change for F40)
* F<40
** gzip compression for primary metadata
** updateinfo.xml (for updates repository) is compressed with XZ
** sqlite database of repodata is generated and compressed with BZ2
** comps repodata is made available both as uncompressed xml and gzipped
** zchunk is active
** DRPMs enabled
With createrepo_c > 1.0 moving to zstd as the default compression
type, we want to have consistent settings for all new releases and to
specify those settings manually, so that possible future changes of
defaults don't cause unexpected breakages. So we propose the following
settings:
* Rawhide/F>=41
** use `--general-compress-type` set to zstd to compress all metadata to zstd
** updateinfo.xml (for updates repository) compressed with zstd as well
** disable generating the additional sqlite database, as it was only
useful for yum
** comps repodata will be available only zstd compressed
** zchunk is active
** DRPMs disabled
* F<=40
** nothing should change by using the `--compatibility` flag of
createrepo_c >= 1.0
Note that updating bodhi-composer to use createrepo_c >= 1.0 will also
introduce an unavoidable change into EPEL8 updates repositories: comps
repodata will be made available only in compressed format (which is
set to XZ in EPEL8). Other EPEL releases (EPEL7 and EPEL9) can use the
`--compatibility` flag to maintain actual settings.
== Feedback ==
The zstd compression type was chosen to match createrepo_c settings.
As an alternative, we might want to choose xz, especially after
zlib-ng has been made the default in Fedora and brought performance
improvements.
The sqlite database distributed alongside the repodata is not useful
for dnf, but it might be used by some external consumer we're not
aware. Please do let us know.
== Benefit to Fedora ==
We're aiming at having consistent defaults for Rawhide and stable
releases and avoid future changes to createrepo_c defaults to cause
unexpected changes to repodata. Also, by using better compression
methods and avoid generating the sqlite database we're reducing
repodata disk usage.
== Scope ==
* Proposal owners:
** change createrepo_c settings for Rawhide in compose-rawhide01
(which is already upgraded to f39)
** upgrade bodhi-composer to f39 and have it using createrepo_c >= 1.0.0
** upgrade (if a new release is released in time) or backport patch
into bodhi to support all createrepo_c settings
** change bodhi's `createrepo_c.ini` in ansible to use the new
settings for F>=41
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
No change should be noticed while upgrading from previous releases.
== How To Test ==
DNF normal day usage should not be affected: upgrading/installing
packages should work as before, maybe a little faster in downloading
repodata.
== User Experience ==
User experience should not be affected.
Possible external custom repodata consumers might stop working and
will need to adjust to the new compression method.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: revert back to old createrepo_c < 1.0 and
previous settings and wait for the next day compose.
* Contingency deadline: F41-beta freeze
* Blocks release? Yes
== Documentation ==
https://docs.pagure.org/pungi/configuration.html#createrepo-settings
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
3 months
- 1
- 0