Planned Outage - updates / reboots - 2025-03-26 21:00UTC
There will be an outage starting at 2025-03-26 21:00UTC
which will last approximately 5 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2025-03-26 21:00UTC'
Reason for outage:
We will be applying updates to all our servers and rebooting into newer kernels. Services will be up or down during the outage window.
Affected Services:
Many services will be affected, but most should only be down for a short time as their particular resources are rebooted.
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/12455
Please join #fedora-admin or #fedora-noc on irc.libera.chat
or #admin:fedoraproject.org / #noc:fedoraproject.org on matrix.
Please add comments to the ticket for this outage above.
Updated status for this outage may be available at
https://www.fedorastatus.org/
Wiki - https://fedoraproject.org/wiki/Changes/Package_builds_are_expected_to_be_re…
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-package-builds-a…
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 ==
Over the last few releases, we changed our build infrastructure to
make package builds reproducible. This is enough to reach 90%. The
remaining issues need to be fixed in individual packages. After this
Change, '''package builds are expected to be reproducible'''. Bugs
will be filed against packages when an irreproducibility is detected.
The goal is to have no fewer than 99% of package builds reproducible.
A public service with package rebuild statistics and reports for
individual packages is made available. (An instance of
[https://github.com/kpcyrd/rebuilderd/ rebuilderd].) A script to make
local rebuilds of historic koji builds is made available
([https://github.com/keszybz/fedora-repro-build fedora-repro-build]).
== Owner ==
*
** Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
** Email: zbyszek(a)in.waw.pl
*
** Name: Davide Cavalca
** Email: dcavalca(a)fedoraproject.org
*
** Name: [[User:Jelly| Jelle van der Waa]]
** Email: jvanderw(a)redhat.com
== Detailed Description ==
We define "reproducible" as when a completely independent rebuild of a
koji package produces rpms that are identical except for the build
timestamps, signatures, and some associated metadata. The ''payload''
(i.e. packaged files) and important metadata are bit-for-bit
identical.
In 2023, [[Changes/ReproducibleBuildsClampMtimes]] added clamping of
mtimes to `$SOURCE_DATE_EPOCH` and changed the process to produce
`.pyc` files to take `$SOURCE_DATE_EPOCH` into account. In 2024,
[[Changes/ReproduciblePackageBuilds]] introduced `add-determinism`
into package builds. Along the way, various details in rpm itself and
other tools were adjusted to increase reproducibility. With those
changes, about 90% of package builds are reproducible. The initial
"big" issues that affect all packages are now solved, and what remains
are problems that require changes in individual packages.
The next step is to '''ask maintainers to resolve reproducibility
issues in their packages'''. The goal is to have 99% of packages
reproducible in Fedora. To achieve this, bugzillas will be opened
against packages when a rebuild reports differences.
We are aware of some issues that cannot be fixed easily:
* Haskell packages are not reproducible when compiled with more than
one thread. Upstream is
[https://gitlab.haskell.org/ghc/ghc/-/issues/12935 working on the
issue], the next release of ghc may resolve the issue completely.
* mingw packages have irreproducible debug data.
* golang packages have irreproducible debug data
([https://pagure.io/fedora-reproducible-builds/project/issue/15
irreproducibility#15]).
* the kernel uses an ephemeral key for module signatures. See
[https://lore.kernel.org/lkml/20241225-module-hashes-v1-0-d710ce7a3fd1@weiss…]
for a possible solution.
* packages that are signed for SecureBoot use a private key (shim, grub2).
* Some BuildRequires on srpms are architecture-dependent. This is
mostly an artifact of how we prepare the environment for builds. It
does not directly affect binary rpms.
We will create tracker bugs for the issues that affect multiple
packages (haskell, mingw, golang). We hope that those issues will be
resolved either upstream or downstream.
== Feedback ==
== Benefit to Fedora ==
(''The first three paragraphs are copied unchanged from
[[Changes/ReproduciblePackageBuilds]].)
Adding determinism (i.e., removing non-determinsim) enables the Fedora
community to have confidence that, if given the same source code,
build environment, build instructions, and metadata from the build
artifacts, any party can recreate copies of the artifacts that are
identical except for the signatures and some parts of metadata.
Reproducibility of builds leads to packages of higher quality. It
turns out that quite often those irreproducible bits are caused by an
error or sloppiness in the code. In particular, any dependence on
architecture in noarch packages is almost always unwanted and/or a
bug. Test builds that check reproducibility will expose such
instances.
Reproducibility of builds makes it easier to develop packages: when a
small change is made and a package is rebuilt (in the same
environment), then with a reproducible package, the only difference is
directly caused by the change. If the package is different every time
it is rebuilt, making a comparison is much harder.
Build reproducibility is a topic that is gaining in popularity. Major
distributions like Debian, Arch, OpenSUSE, and NixOS are trying to
achieve full reproducibility. By making b-r an expectation in Fedora,
we avoid driving away people who consider b-r a requirement. We may
even attract additional contributors who are interested in this topic,
if we achieve better results than other distros. With 90%
reproducibility we're on par, with 99% we can be the leader 😀.
== Scope ==
* Proposal owners:
** Package [https://github.com/keszybz/fedora-repro-build
fedora-repro-build] to allow local rebuilds of historical koji builds
** Make [https://github.com/kpcyrd/rebuilderd/ rebuilderd] work with
Fedora packages and repos
** Stand up a public rebuilderd instance for Fedora rawhide
** Adjust `add-determinism` to handle new cases, if widespread issues
are found and it's possible to handle them in the cleanup phase
** Open bugs against packages when irreproducibilities are detected,
initially as a manual process
** Open a pull request for Packaging Guidelines
* Other developers:
** Fix irreproducibility issues in individual packages
** Fix tooling issues that affect multiple packages, if possible
** Review the pull request for Packaging Guidelines
** Adjust various packager workflow descriptions in the wiki
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines:
** Packaging Guidelines will be changed to say that packages
**should** build reproducibly, and link to our docs
([https://docs.fedoraproject.org/en-US/reproducible-builds/
reproducible builds]) and upstream docs at
[https://reproducible-builds.org/documentationreproducible-builds.org]
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
N/A
== Early Testing (Optional) ==
We have the tooling in place to do a local rebuild of a koji build and
compare the results. Packagers can do such rebuilds and verify the
result or fix the issues if any are found.
== How To Test ==
When the public rebuilderd instance is up, maintainers will be able to
see reports and diffoscope output for their packages. They can then
use this to learn about any issues in their packages.
== User Experience ==
No user-visible changes. Users ''may'' do local rebuilds and expect
that the results are reproducible.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: All the items in the Scope are additions to
the current tooling and infrastructure, so there is no need for a
contingency plan for them. If we back out of the whole idea, rather
than just postponing it for example, Packaging Guidelines changes
would probably need to be reverted and any bugzillas closed.
* Contingency deadline: any time
* Blocks release? no
== Documentation ==
* [https://reproducible-builds.org/docsreproducible-builds.org/docs]
* https://docs.fedoraproject.org/en-US/reproducible-builds/
== Release Notes ==
Reproducibility of package builds has improved. TBD% of package builds
are now reproducible.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Java25AndNoMoreSystemJdk
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-java25-and-no-mo…
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 ==
Add java-25-openjdk with non blocking mass bump and rebuild.
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: jvanek(a)redhat.com
== Detailed Description ==
JDK 25 will be released in September 2025, and will most likely become
a LTS JDK.
It will be added to all live Fedoras, however in f43 and higher, it
will provide "java".
Note, that in f43 and f44, there still will be JDK21, and it will
continue to provide "java".
java-latest-openjdk won't be providing "java" as usual, and it will be
bumped to JDK26 as soon as possible.
JDK21 will remain in Fedoras, until it is newest JDK providing java in
any live Fedora (f44) - as described in
https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks)
Highlight - the JDK21 will no longer be present in f45.
<b>Highlight:</b> In practice, this means that in f43 and f44, there
will be two JDKs (JDK21 and JDK25) providing java. That is
intentional, and it is unexpected consequence of
https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks - because
every third-party JDK is providing java. Maven and Ant tools has
adapted to this schema already during the life-time of f41 and f42.
This is conceptually removing the need of mass rebuild, because any
package in f43 will be built by JDK21 as they are now, and maintainers
will have more then year and half to migrate to JDK25.
We will do a mass-rebuild, where we will try to build every java
package by jdk25, but if they fallback, they will immediately roll
back to jdk21, with maintainer notified.
This transparency is handled in javapackages-tools/maven/ant... whose
versionless requires still require JDK21, but have also version-full
requires. Those version-full requires are recommended to be used, so
packager is clear what JDK he wants to pull. My approach for mass
rebuild will be bump to current version-less requires version-full -
JDK25 - requires. If build fails, the "revert" will go to version-full
- JDK21 requires, not to version-less. The
https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/ will
need adjusting.
The version-less being transparent as JDK21 requirement, should remain
as it is, and will die on its own with removal of jdk21.
Enumerations:
* `javapackages-local-openjdk21` - requires `java-21-openjdk-devel`
and in addition provides `javapackages-local`
* `javapackages-local` requires `javapackages-local-openjdk21` and
will die with it.
* `javapackages-local-openjdk25` - requires `java-25-openjdk-devel`
and provides only `javapackages-local-openjdk25`
Same for `ant` and `maven-local`:
* `maven-local` is alias for `maven-local-openjdk21`, and it will remain
** further packages should require '''maven-local-openjdkXY'''
** `maven-local-openjdk21` for "legacy" and `maven-local-openjdk25` for future
* `ant` '''suggests''' `ant-local-openjdk21`
** once jdk25 is out, it should change (in rawhide/sine f43) to
`ant-local-openjdk25`
** `ant` should always be used together with '''javapackages-local-openjdkXYZ'''
** without exact javapackages-local-openjdkXYZ ant is rolling reelase
The JDKs are now stable and have smooth update path from one LTS to
another over STSs, and similar behavior should be the desired one.
Any packager can decide to keep any (available) JDK version, as long
as it is in system, so if there is major breakage for them, they have
more than a year to fix it.
In scope of https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks,
the JDK will disappear from Fedora and will be recommended to be
replaced by Temurin by losing its status of "system jdk" in any live
Fedora (so JDK21 should no longer be available in f45).
== Schedule ==
* 18.7.2025 Oracle CPU unembargo date
* approx. 24.7 Oracle CPU reaches Fedora (hopefully stable)
** JDK25 has to reach Fedora as EA (because of the early branching)
** JDK may not need to be branched
** mass rebuild must happen in July
* no later then 31.7 java-latest-openjdk will become jdk25
** ideally immediately after CPU.
* no later then 8.8. java-25-openjdk will be forked and used in rawhide
** ideally immediately after CPU.
** mass rebuild right after it
* fedora branching 12.8.2025 - https://pagure.io/fesco/issue/3362
** no exception it seems
* if mass rebuild will not happen, then the contingency plan is to go
on without mass rebuild, just with devel announcement, and maybe do a
mass rebuild in f44
== Feedback ==
<!-- Summarize the feedback from the community and address why you
chose not to accept proposed alternatives. This section is optional
for all change proposals but is strongly suggested. Incorporating
feedback here as it is raised gives FESCo a clearer view of your
proposal and leaves a good record for the future. If you get no
feedback, that is useful to note in this section as well. For
innovative or possibly controversial ideas, consider collecting
feedback before you file the change proposal. -->
todo
== Benefit to Fedora ==
<!-- What is the benefit to the distribution? Will the software we
generate be improved? How will the process of creating Fedora releases
be improved?
Be sure to include the following areas if relevant:
If this is a major capability update, what has changed?
For example: This change introduces Python 5 that runs
without the Global Interpreter Lock and is fully multithreaded.
If this is a new functionality, what capabilities does it bring?
For example: This change allows package upgrades to be
performed automatically and rolled-back at will.
Does this improve some specific package or set of packages?
For example: This change modifies a package to use a
different language stack that reduces install size by removing
dependencies.
Does this improve specific Spins or Editions?
For example: This change modifies the default install of
Fedora Workstation to be more in line with the base install of Fedora
Server.
Does this make the distribution more efficient?
For example: This change replaces thousands of individual
%post scriptlets in packages with one script that runs at the end.
Is this an improvement to maintainer processes?
For example: Gating Fedora packages on automatic QA tests
will make rawhide more stable and allow changes to be implemented more
smoothly.
Is this an improvement targeted as specific contributors?
For example: Ensuring that a minimal set of tools required
for contribution to Fedora are installed by default eases the
onboarding of new contributors.
When a Change has multiple benefits, it's better to list them all.
Consider these Change pages from previous editions as inspiration:
https://fedoraproject.org/wiki/Changes/Annobin (low-level and
technical, invisible to users)
https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo
(low-level, but visible to advanced users)
https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration
(primarily a UX change)
https://fedoraproject.org/wiki/Changes/NoMoreAlpha (an
improvement to distro processes)
https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to
a popular software stack, visible to users of that stack)
-->
Fedora will stay on top with fresh technologies by having newest JDK
available immediately and having new system JDK as soon as possible.
Fedora will become multi-java friendly distribution, where each JDK
vendor built will be correctly reusable.
https://openjdk.org/projects/jdk/25/https://openjdk.org/projects/jdk/24/https://openjdk.org/projects/jdk/23/https://openjdk.org/projects/jdk/22/
== Scope ==
* Proposal owners:
<!-- What work do the feature owners have to accomplish to complete
the feature in time for release? Is it a large change affecting many
parts of the distribution or is it a very isolated change? What are
those changes?-->
We will add JDK25 to Fedora, and will ensure, that it "java" provides
are correct. That also means no java provides in f41 and f42
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- What work do other developers have to accomplish to complete the
feature in time for release? Is it a large change affecting many
parts of the distribution or is it a very isolated change? What are
those changes?-->
Maven and Ant stacks are already adapted thanx to
https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks#adoptium-temuri…
Other packagers may need to update packages to work fine with jdk25 or
freeze their package to exact (21) version of JDK, and will have a
year and half to fix theirs issues.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering
(e.g. changes to installer image generation or update package
delivery)? Is a mass rebuild required? include a link to the releng
issue.
The issue is required to be filed prior to feature submission, to
ensure that someone is on board to do any process development work and
testing and that all changes make it into the pipeline; a bullet point
in a change is not sufficient communication -->
* Policies and guidelines: N/A (not needed for this Change) <!--
REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Do the packaging guidelines or other documents need to be updated
for this feature? If so, does it need to happen before or after the
implementation is done? If a FPC ticket exists, add a link here.
Please submit a pull request with the proposed changes before
submitting your Change proposal. -->
* Trademark approval: N/A (not needed for this Change)
<!-- If your Change may require trademark approval (for example, if it
is a new Spin), file a ticket (
https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark
approval from the Fedora Council. This approval will be done via the
Council's consensus-based process. -->
* Alignment with the Fedora Strategy: ok, I think
<!-- Does your proposal align with the current Fedora Strategy:
https://discussion.fedoraproject.org/t/fedora-strategy-2028-february-march-…
? It's okay if it doesn't, but it's something to consider -->
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of
Fedora installed and are updated to the version containing this
change? Will anything require manual configuration or data migration?
Will any existing functionality be no longer supported? -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
User which was used to have exactly one - system - JDK, may end in having two.
== Early Testing (Optional) ==
<!-- This is an optional step for system-wide changes to avail of. If
you would like to build an initial proof of concept of your change and
have a member of Fedora QA help you write and/or run some initial
basic tests on your code, please email tests(a)fedoraproject.org and
include the link to your change proposal. This step is *optional*. -->
Do you require 'QA Blueprint' support? Y/N <!-- Optional Step for
System-Wide Changes only -->
== How To Test ==
<!-- This does not need to be a full-fledged document. Describe the
dimensions of tests that this change implementation is expected to
pass when it is done. This can be based off of the above section if
early testing has been completed. If it needs to be tested with
different hardware or software configurations, indicate them. The
more specific you can be, the better the community testing can be.
Remember that you are writing this how to for interested testers to
use to check out your change implementation - documenting what you do
for testing is OK, but it's much better to document what *I* can do to
test your change.
A good "how to test" should answer these four questions:
0. What special hardware / data / etc. is needed (if any)?
1. How do I prepare my system to test this change? What packages
need to be installed, config files edited, etc.?
2. What specific actions do I perform to check that the change is
working like it's supposed to?
3. What are the expected results of those actions?
-->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
todo
== User Experience ==
<!-- If this change proposal is noticeable by users, how will their
experiences change as a result?
This section partially overlaps with the Benefit to Fedora section
above. This section should be primarily about the User Experience,
written in a way that does not assume deep technical knowledge. More
detailed technical description should be left for the Benefit to
Fedora section.
Describe what Users will see or notice, for example:
- Packages are compressed more efficiently, making downloads and
upgrades faster by 10%.
- Kerberos tickets can be renewed automatically. Users will now have
to authenticate less and become more productive. Credential management
improvements mean a user can start their work day with a single sign
on and not have to pause for reauthentication during their entire day.
- Libreoffice is one of the most commonly installed applications on
Fedora and it is now available by default to help users "hit the
ground running".
- Green has been scientifically proven to be the most relaxing color.
The move to a default background color of green with green text will
result in Fedora users being the most relaxed users of any operating
system.
-->
Change should be transparent to all users and power users.
Users will have latest JDK as soon as possible, as usual, and all Java
packages should remain fully operational.
== Dependencies ==
<!-- What other packages (RPMs) depend on this package? Are there
changes outside the developers' control on which completion of this
change depends? In other words, completion of another change owned by
someone else and might cause you to not be able to finish on time or
that you would need to coordinate? Other upstream projects like the
kernel (if this is not a kernel change)? -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Whole javastack will be affected and verified as much as possible.
* this proposal depends on existence of `java-25-openjdk`
** review NEW https://bugzilla.redhat.com/show_bug.cgi?id=2352963
* which depends on existence of `java-25-openjdk-portable`
** review CLOSED_RAWHIDE: https://bugzilla.redhat.com/show_bug.cgi?id=2351138
== Contingency Plan ==
<!-- If you cannot complete your feature by the final development
freeze, what is the backup plan? This might be as simple as "Revert
the shipped configuration". Or it might not (e.g. rebuilding a number
of dependent packages). If you feature is not completed in time we
want to assure others that other parts of Fedora will not be in
jeopardy. -->
* Contingency mechanism: (What to do? Who will do it?) :
** If it goes wrong, all packages will remain on JDK21. The JDK25 will
stay there, and will also most likely still provide java
** If the multiple java providing schema will case to work, the jdk21
java provides will be stripped off, and normal mass rebuild will
happen.
<!-- When is the last time the contingency mechanism can be put in
place? This will typically be the beta freeze. -->
* Contingency deadline: beta freeze <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship
with the feature in incomplete state? -->
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
== Documentation ==
=== common issues packagers can face and gathered solutions ===
==== Removed SecurityManager ====
Any applications with security manager will need to explicitly stay on
jdk21 or heavily update. SecurityManager is deprecated since JDK17.
* jdk24 jep: https://openjdk.org/jeps/486
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Drop_PLATFORM_ID
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-drop-platform-id…
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 ==
A few years ago PLATFORM_ID was added to `os-release` for Modularity,
but Modularity has been retired and we don't need this key. It'll be
dropped from our `os-release` files.
== Owner ==
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek(a)in.waw.pl
== Detailed Description ==
As discussed in [https://bugzilla.redhat.com/show_bug.cgi?id=2350301
bug 2350301], PLATFORM_ID= setting in
`/usr/lib/os-release`/`/etc/os-release` is undocumented and most
likely completely unused. It is a one-line change to get rid of it.
It is very hard to prove that this field is not used by somebody
somewhere, so the main purpose of this Change Proposal is to have a
page we can point people to.
== Feedback ==
== Benefit to Fedora ==
We get rid of an unexpected line in our `os-release` files.
== Scope ==
* Proposal owners: pull request for `fedora-release` package
* Other developers: merge the pull request
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
No impact.
== Early Testing (Optional) ==
== How To Test ==
== User Experience ==
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Revert the patch.
* Contingency deadline: Any time.
* Blocks release? No.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
An unused `PLATFORM_ID=` field in
[https://www.freedesktop.org/software/systemd/man/latest/os-release.html
os-release] has been dropped.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/DeprecatePythonAsyncTimeout
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-deprecate-python…
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 ==
The {{package|python-async-timeout}}
({{package|python3-async-timeout}}) package will be
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packa…
deprecated] in [[Releases/43|Fedora 43]]. The package provides timeout
utilities for asyncio, but as of Python 3.11, its functionality has
been integrated into the standard library. Fedora packages should use
`asyncio.Timeout` instead. Many still depend on `async-timeout`, so we
cannot remove it yet. Packagers are encouraged to work with upstream
to switch to `asyncio.Timeout` if possible. A simple try-import
mechanism can be applied as a temporary (or even permanent) downstream
solution.
== Owner ==
* Name: [[User:lbalhar| Lumír Balhar]]
* Email: lbalhar(a)redhat.com
== Detailed Description ==
The {{package|python-async-timeout}} package provides timeout
utilities for applications using asyncio module. However, starting
from Python 3.11, the core functionality of this package has been
integrated into the standard library, and:
* Version 5.0+ of `async-timeout` provides dual-mode execution on
Python 3.11+, where `asyncio_timeout.Timeout` is fully compatible with
`asyncio.Timeout`.
[https://src.fedoraproject.org/rpms/python-async-timeout/pull-request/5
Update to 5.0.1] in rawhide is in progress.
* The library is no longer actively supported upstream and exists
primarily for backward compatibility and easing migration.
Given that Fedora ships with modern Python versions, using this
library as a separate package is redundant. We'd like to encourage
both downstream packages and upstream projects to switch to
`asyncio.Timeout` instead. Eventually, we aim to remove
{{package|python-async-timeout}} from Fedora entirely. Before
attempting removal, we need to prevent new packages from depending on
it, hence the deprecation.
=== Affected packages ===
As of now (March 2025), there are 29 packages in rawhide depending on
python3-async-timeout:
$ dnf repoquery --repo=rawhide,rawhide-source --whatrequires
python3-async-timeout
gns3-server-0:2.2.53-3.fc43.noarch
python-aioesphomeapi-0:15.0.0-4.fc42.src
python-aiokafka-0:0.12.0-2.fc42.src
python-async-upnp-client-0:0.14.15-16.fc42.src
python-enturclient-0:0.2.1-16.fc42.src
python-httpx-socks-0:0.10.0-1.fc43.src
python-pycomfoair-0:0.0.4-15.fc42.src
python-pygmtools-0:0.5.3-4.fc42.src
python-pysqueezebox-0:0.5.5-17.fc42.src
python-socks-0:2.7.1-1.fc43.src
python3-aioesphomeapi-0:15.0.0-4.fc42.noarch
python3-aiokafka-0:0.12.0-2.fc42.x86_64
python3-aiopg-0:1.3.4-10.fc42.noarch
python3-async-upnp-client-0:0.14.15-16.fc42.noarch
python3-dingz-0:0.5.0-10.fc42.noarch
python3-enturclient-0:0.2.1-16.fc42.noarch
python3-epson-projector-0:0.2.3-15.fc42.noarch
python3-glances-api-0:0.2.0-23.fc42.noarch
python3-hole-0:0.7.0-9.fc42.noarch
python3-httpx-socks+asyncio-0:0.10.0-1.fc43.noarch
python3-metno-0:0.8.1-15.fc42.noarch
python3-netdata-0:0.2.0-17.fc42.noarch
python3-opensensemap-api-0:0.1.5-23.fc42.noarch
python3-pycomfoair-0:0.0.4-15.fc42.noarch
python3-pygmtools-0:0.5.3-4.fc42.noarch
python3-pysqueezebox-0:0.5.5-17.fc42.noarch
python3-volkszaehler-0:0.2.1-15.fc42.noarch
python3-waqiasync-0:1.0.0-15.fc42.noarch
python3-webthing-ws-0:0.1.0-19.fc42.noarch
=== How to migrate to `asyncio.Timeout` ===
For projects that need to maintain compatibility with both old and new
Python versions, performing the following conditional import should be
enough:
import sys
if sys.version_info >= (3, 11):
from asyncio import timeout, timeout_at
else:
from async_timeout import timeout, timeout_at
Upstream projects should also depend on `async-timeout` only for
Python releases older than 3.11:
"async-timeout; python_version < '3.11'"
== Benefit to Fedora ==
Eventually, we might be able to eliminate the need to maintain a
separate timeout library for asyncio, reducing redundancy and
improving compatibility with upstream Python.
== Scope ==
* Proposal owners: Deprecate {{package|python3-async-timeout}} and
update its package description. Provide migration assistance to other
packagers if needed.
* Other developers: No immediate action required, but developers are
encouraged to transition their packages to `asyncio.Timeout` where
possible.
* Release engineering: No impact on Release Engineering is anticipated.
* Policies and guidelines: N/A (not a System Wide Change).
* Trademark approval: N/A (not needed for this Change).
* Alignment with Objectives: N/A (not needed for this Change).
== Upgrade/compatibility impact ==
The package will remain available in Fedora for now, but new packages
should not depend on it. Eventually, when it is retired, we do not
plan to obsolete/provide python3-async-timeout from
{{package|python3-libs}}, since its import name differs. The package
will eventually be obsoleted by {{package|fedora-obsolete-packages}}.
== How To Test ==
$ repoquery --repo=rawhide --provides python3-async-timeout
...
deprecated()
...
== User Experience ==
No immediate changes for end users. Developers should transition to
`asyncio.Timeout` as their codebases update to Python 3.11+.
== Dependencies ==
N/A (not a System Wide Change).
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change).
* Contingency deadline: N/A (not a System Wide Change).
* Blocks release? No.
== Documentation ==
[https://docs.python.org/3/library/asyncio-task.html#asyncio.timeout
Python asyncio.timeout documentation]
== Release Notes ==
The `python-async-timeout` package has been deprecated in Fedora.
Developers are encouraged to migrate to `asyncio.Timeout` in Python
3.11+ for improved compatibility with the standard library.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Debuginfod_IMA_Verification
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-debuginfod-ima-v…
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 ==
Enable client-side cryptographic verification of [[Debuginfod]]
auto-downloaded debugging information and source code by default.
== Owner ==
* Name: [[User:FChE| Frank Ch. Eigler]]
* Email: <fche(a)redhat.com>
== Detailed Description ==
Fedora's [[Debuginfod]] clients and servers can take advantage of
[[Changes/Signed_RPM_Contents|signed RPMs]] to provide and verify
cryptographic
integrity of debuginfo & source code files made available to clients.
Upstream [https://sourceware.org/elfutils elfutils] code has contained
all the logic since version 0.192. The Fedora debuginfod servers have
made this IMA signature information available for apprx. all RPMS in
Fedora 39+. It only needs client side configuration to activate
verification.
Activating this requires changing the `$DEBUGINFOD_URLS` environment
variable's value. This variable is constructed from files in
`/etc/debuginfod/*.url` files. The concrete proposal is to replace
the `/etc/debuginfod/elfutils.urls` file, provided by the
`elfutils-debuginfod-client` subrpm, to the following value:
<pre>ima:enforcing https://debuginfod.fedoraproject.org ima:ignore</pre>
This will force crypto verification of files downloaded from that
server, and let the client reject any unverifiable files. The
trailing "ima:ignore" part is for the situation where an end-user
might naively append additional debuginfod server URLs to the
environment variable, but we don't want to assert enforcing mode for
them.
== Feedback ==
This feature fills a gap identified back when
[[Changes/DebuginfodByDefault]] arrived during F35.
== Benefit to Fedora ==
The warm fuzzy feeling of more end-user-verifiable security over files
they download from Fedora.
== Scope ==
* Proposal owners: Adjustment to `elfutils.spec`
* Other developers: None
* Release engineering: None, except continuing to publish IMA key
certificates in a timely & complete manner in `fedora-gpg-keys` into
`/etc/keys/ima/`.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: ?
== Upgrade/compatibility impact ==
None. With `fedora-gpg-keys` containing public key signatures for
''all'' recent Fedoras, debugging older or newer binaries should also
work fine.
== How To Test ==
Set the `$DEBUGINFOD_URLS` environment variable by hand, or edit the
`/etc/debuginfod/*.url` file(s), to add `ima:enforcing` in the proper
place.
For more diagnostics, set `$DEBUGINFOD_VERBOSE` to `1`.
Use `debuginfod-find -v debuginfo $BINARY`. Observe successful download.
== User Experience ==
Normally, no observable change at all, assuming that all RPMs
distributed from koji continue to be built with IMA per-file
signatures.
Should there be unsigned RPMs, or ones whose signatures become invalid
due to storage or transmission errors, this will result in user tools
treating the debuginfo as unavailable. There may be diagnostics
printed. At that point, a user can in principle disable checking
manually, download debuginfo by hand (e.g. via `debuginfo-install`),
or grin and bear it.
== Dependencies ==
The `fedora-gpg-keys` rpm contains the public key certificates against
which the client verifies download signatures. The location of these
certificates is a compiled-in default into the debuginfod client code
(`/etc/keys/ima`), but may be changed with an environment variable.
Releng/koji need to keep building RPMs for present / future versions
of Fedora with IMA signatures attached. Transitions between
major-version signing keys should be okay, as long as the
`fedora-gpg-keys` RPM (containing the certificates) gets updated in a
timely manner.
== Contingency Plan ==
* Contingency mechanism: Unroll the `elfutils.spec` change or
hand-edit env. vars.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
"The debuginfod client tools used to auto-download debuginfo & source
code into tools like `gdb` now cryptographically verify the integrity
of the downloaded files from the Fedora debuginfod server."
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Hello packagers.
As a followup to this email sent a month ago to the python-devel list, I now
plan to make the incorrect (and unsafe) usage of %pyproject_buildrequires -t/-e
and %tox without a suitable tox configuration fail the build.
This is a breaking change, but I believe it's the only way to prevent packages
with always passing %checks.
If your package has no tox configuration, do not use the -t/-e option for
%pyproject_buildrequires, do not use %tox.
This change will land to rawhide first and later to all stable releases as well.
For reference:
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/512
On 05. 02. 25 10:47, Miro Hrončok wrote:
> Hello Pythonistas.
>
> When we updated tox from version 3 to 4, it no longer fails when here is no
> suitable tox configuration found. This was a deliberate upstream choice.
>
> Unfortunately, it means that packages that use %pyproject_buildrequires with -t
> or -e now silently succeed if there is no tox configuration found.
>
> I identified 95 packages that are affected by this, see below.
>
> Unfortunately, it is tricky to detect a missing tox configuration directly from
> %pyproject_buildrequires. For now, I did this by looking for a specific
> information in tox output, but that might not be stable.
>
> I built all Rawhide packages matching %\{?pyproject_buildrequires\s+(.+\s)?-
> \S*[te] in a copr with a modified version of %pyproject_buildrequires which
> fails when this happens.
>
> https://copr.fedorainfracloud.org/coprs/churchyard/pyproject-buildrequires-…
> tox-error/builds/
>
> For all the failures, I looked into the logs and identified the 95 failures are
> caused by that (see below).
>
>
> If this affects your package, please consider if your usage of -t/-e for
> %pyproject_buildrequires is a mistake (and remove it), or see if some explicit
> build dependencies are missing (and the package only builds by chance).
>
> Sometimes, upstreams which use tox don't put their tox configuration into sdist
> (%pypi_source) and only keep it in git.
>
> Sometimes, upstreams don't use tox at all and the usage of -t/-e is wrong.
>
> If you have questions, I am happy to help.
>
> Maintainers by package:
> hddfancontrol filiperosset
> lazygal rathann
> mat2 atim
> mkdocs dcavalca smani
> mogui xdelaruelle
> onnx aalvarez dherrera
> past-time fab
> patool eclipseo
> pmbootstrap defolos
> pykka girst
> python-ailment fab mikep
> python-aioftp fab
> python-aiomultiprocess fab
> python-archinfo fab mikep
> python-archspec orion
> python-asn1tools peter
> python-asysocks fab
> python-base58 peter
> python-blowfish limb
> python-ckzg peter
> python-claripy fab mikep
> python-cmd2 fab jcapitao ktdreyer
> python-dataclassy peter
> python-diff-match-patch amigadave
> python-dropbox limb
> python-einops trix
> python-envisage orion
> python-eth-abi peter
> python-eth-account peter
> python-eth-event peter
> python-eth-hash peter
> python-eth-keyfile peter
> python-eth-keys peter
> python-eth-rlp peter
> python-eth-stdlib peter
> python-eth-typing peter
> python-eth-utils peter
> python-flask-httpauth jpena
> python-flask-session frantisekz
> python-haversion fab
> python-hexbytes peter
> python-hvac ignatenkobrain ngompa rcallicotte
> python-influxdb-client fedepell stevetraylen
> python-jaconv kevin
> python-jsonpath-ng fab
> python-lazy_load peter
> python-libusb1 jonny peter
> python-logutils limb
> python-lru-dict peter
> python-mailman-web salimma
> python-migen somlo
> python-morphys peter
> python-multiaddr peter
> python-multibase peter
> python-multicodec peter
> python-multihash peter
> python-music21 zbyszek
> python-nine ondrejj
> python-optking jussilehtola
> python-optuna limb
> python-paginate dcavalca
> python-pandas-datareader sergiopr
> python-pyaes thebeanogamer
> python-pybeam peter
> python-pyiqvia fab
> python-pymongo apevec cstratak hhorak jonathanspw orion
> python-pyrad antorres cicku peter
> python-pytest-dependency mikelo2
> python-pytest-fixture-config kevin
> python-qcelemental jussilehtola
> python-requests-unixsocket jcaratzas radez
> python-rlp peter
> python-rpyc fab
> python-simple-pid ttorcz
> python-smi fab
> python-ssdp fab
> python-telnetlib3 dcavalca
> python-textile thm
> python-textparser fab
> python-timeout-decorator jcapitao
> python-tinydb petersen suanand
> python-towncrier eclipseo
> python-trie peter
> python-uhashring amoralej
> python-unix-ar ppfeister
> python-warlock apevec jcapitao mrunge
> python-xlrd ondrejj pingou
> python-zstandard ignatenkobrain rathann
> python3-exiv2 asn
> quearcode limb
> reuse jstanek
> rpm-spec-language-server frostyx
> scancode-toolkit eclipseo
> syncstar t0xic0der
> vapoursynth slaanesh
>
> Packages by maintainer:
> aalvarez onnx
> amigadave python-diff-match-patch
> amoralej python-uhashring
> antorres python-pyrad
> apevec python-pymongo python-warlock
> asn python3-exiv2
> atim mat2
> cicku python-pyrad
> cstratak python-pymongo
> dcavalca mkdocs python-paginate python-telnetlib3
> defolos pmbootstrap
> dherrera onnx
> eclipseo patool python-towncrier scancode-toolkit
> fab past-time python-ailment python-aioftp python-aiomultiprocess
> python-archinfo python-asysocks python-claripy python-cmd2 python-haversion
> python-jsonpath-ng python-pyiqvia python-rpyc python-smi python-ssdp python-
> textparser
> fedepell python-influxdb-client
> filiperosset hddfancontrol
> frantisekz python-flask-session
> frostyx rpm-spec-language-server
> girst pykka
> hhorak python-pymongo
> ignatenkobrain python-hvac python-zstandard
> jcapitao python-cmd2 python-timeout-decorator python-warlock
> jcaratzas python-requests-unixsocket
> jonathanspw python-pymongo
> jonny python-libusb1
> jpena python-flask-httpauth
> jstanek reuse
> jussilehtola python-optking python-qcelemental
> kevin python-jaconv python-pytest-fixture-config
> ktdreyer python-cmd2
> limb python-blowfish python-dropbox python-logutils python-optuna quearcode
> mikelo2 python-pytest-dependency
> mikep python-ailment python-archinfo python-claripy
> mrunge python-warlock
> ngompa python-hvac
> ondrejj python-nine python-xlrd
> orion python-archspec python-envisage python-pymongo
> peter python-asn1tools python-base58 python-ckzg python-dataclassy python-
> eth-abi python-eth-account python-eth-event python-eth-hash python-eth-keyfile
> python-eth-keys python-eth-rlp python-eth-stdlib python-eth-typing python-eth-
> utils python-hexbytes python-lazy_load python-libusb1 python-lru-dict python-
> morphys python-multiaddr python-multibase python-multicodec python-multihash
> python-pybeam python-pyrad python-rlp python-trie
> petersen python-tinydb
> pingou python-xlrd
> ppfeister python-unix-ar
> radez python-requests-unixsocket
> rathann lazygal python-zstandard
> rcallicotte python-hvac
> salimma python-mailman-web
> sergiopr python-pandas-datareader
> slaanesh vapoursynth
> smani mkdocs
> somlo python-migen
> stevetraylen python-influxdb-client
> suanand python-tinydb
> t0xic0der syncstar
> thebeanogamer python-pyaes
> thm python-textile
> trix python-einops
> ttorcz python-simple-pid
> xdelaruelle mogui
> zbyszek python-music21
>
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok