wiki - https://fedoraproject.org/wiki/Changes/ReplaceNoseWithPynose
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-replace-nose-wit…
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 ==
Package <code>python-nose</code> was
[https://fedoraproject.org/wiki/Changes/DeprecateNose deprecated] in
Fedora 32. It’s official successor,
[https://github.com/nose-devs/nose2 <code>nose2</code>] does not
provide all the functionality of <code>nose</code>. However,
[https://github.com/mdmintz/pynose <code>pynose</code>] does and thus
can be used as a drop-in replacement for <code>nose</code> allowing us
to retire <code>python-nose</code>.
== Owner ==
* Name: [https://fedoraproject.org/wiki/User:gui1ty Sandro]
* Email: gui1ty(a)penguinpee.nl
== Feedback ==
There are still a few (~70) packages in Fedora depending on deprecated
<code>python3-nose</code> for their tests. Other packages have been
switched to <code>python3-pytest</code> when nose was deprecated or
migrated to <code>python3-pynose2</code>. As efforts are underway to
upgrade <code>python3-pytest</code> to version 8.x.y, it turns out
this version no longer supports running nose setup/teardown
functions/methods, thereby breaking packages that still rely on those
functionality.
Since pynose is using the same namespace as deprecated nose, with a
minor hack<ref>[https://src.fedoraproject.org/fork/gui1ty/rpms/python-pynose/c/594c580ae126…
nose metadata hack]</ref>, the package can be modified to provide a
proper replacement for <code>python3-nose</code> with regards to the
RPM as well as the Python metadata. Pynose also provides the same set
of executables. So packages still running <code>nosetests</code> will
be able to switch seemlessly to <code>python3-pynose</code> in
[https://copr.fedorainfracloud.org/coprs/gui1ty/pynose-nose/builds/
most cases].
Packagers can also decide to switch their packages manually by simply
changing to <code>python3-pynose</code>, which is currently available
in rawhide.
== Benefit to Fedora ==
Providing pynose as a drop-in replacement for nose will allow us to
retire long deprecated <code>python-nose</code> without forcing any
packages still depending on it to go look for an alternative or be
retired. It will also assist in the efforts of upgrading pytest to
version 8 by allowing packages that still rely on nose setup/teardown
functions/methods to switch back to <code>nosetests</code> provided by
pynose.
== Scope ==
* Proposal owners:
Provide <code>python3-pynose</code> as a drop-in replacement for
<code>python3-nose</code>; provide PRs for packages that need
adaption; provide help
* Other developers:
Manually switch to depending on <code>python3-pynose</code> if
desired; switch back to <code>nostests</code> if adapting to pytest 8
proves difficult
* Release engineering: N/A
* 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 ==
Transitioning from nose to pynose will happen behind the secenes.
Packages now depending on <code>python3-nose</code> or
<code>python3dist(nose)</code> will have that dependency satisfied by
<code>python3-pynose</code> instead of <code>python3-nose</code>.
Where packages need to be adapted, PRs will be provided to make them
work with pynose.
== How To Test ==
Packagers can test their package using the
[https://copr.fedorainfracloud.org/coprs/gui1ty/pynose-nose/ Copr
repo].
# <code>copr mock-config gui1ty/pynose-nose fedora-rawhide-x86_64 >
~/.config/mock/pynose-nose-rawhide.cfg</code>
# <code>fedpkg --release rawhide mockbuild --root pynose-nose-rawhide</code>
Let us know if you need help.
== Dependencies ==
Packages currently build requiring <code>python3-nose</code>:
* binwalk
* bmap-tools
* hgsvn
* mod_nss
* nova-agent
* odcs
* openms
* ProDy
* pydot
* pytest
* python-agate
* python-agate-dbf
* python-agate-excel
* python-agate-sql
* python-anyjson
* python-axolotl
* python-behave
* python-binstruct
* python-blessings
* python-boto
* python-case
* python-colorspacious
* python-curtsies
* python-deap
* python-epc
* python-etcd
* python-eyed3
* python-fedmsg-meta-fedora-infrastructure
* python-flask-xml-rpc
* python-fluidity-sm
* python-gensim
* python-hglib
* python-http-ece
* python-httpretty
* python-ifcfg
* python-inflect
* python-ipmi
* python-iptools
* python-ipython_genutils
* python-jenkins
* python-leather
* python-mapnik
* python-migrate
* python-moksha-common
* python-moksha-hub
* python-musicbrainzngs
* python-neurosynth
* python-nitime
* python-ofxparse
* python-ordered-set
* python-pycdio
* python-pygatt
* python-pygeoip
* python-pypillowfight
* python-pyramid-tm
* python-pytest-mpl
* python-pytimeparse
* python-queuelib
* python-rows
* python-sievelib
* python-simplebayes
* python-spec
* python-spur
* python-statsd
* python-stomper
* python-supersmoother
* python-tilestache
* python-www-authenticate
* python-xvfbwrapper
* vigra
== Contingency Plan ==
* Contingency mechanism: 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)
== Documentation ==
[https://github.com/mdmintz/pynose/blob/master/README.md pynose
README] and above
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Gimp_3
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-gimp-version-3-s…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
This change introduces the upcoming major version 3 of the GNU Image
Manipulation Program in Fedora Linux.
== Owner ==
* Name: [[User:Nphilipp| Nils Philippsen]]
* Email: nphilipp -at- redhat.com (or nils -at- tiptoe.de)
== Detailed Description ==
The [https://gimp.org GIMP project] intends to release the
[https://developer.gimp.org/core/roadmap/#gimp-30-development-branch-roadmap
major version 3] of the GNU Image Manipulation Program
[https://gitlab.gnome.org/GNOME/gimp/-/issues/10373#timeline later
this year].
This new version involves substantial changes to the technologies
used, which in turn means that third party plugins have to be ported
to be compatible. Therefore, this change will add the new version as a
new package <code>gimp3</code> which can be installed side-by-side
with the existing version 2.x package, so people can continue working
on existing projects with the old gimp version and its plugins.
In order to make upgrades seamless for users (and avoid having to go
through an exception process for a “new” <code>gimp2</code> package
needing Python 2.x), the existing package will remain named
<code>gimp</code> and it plus <code>gimp3</code> will obsolete the
version 2.x packages from Fedora Linux <= 40 in version 41.
== Feedback ==
Alternative proposals were made, e.g. in
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
the respective thread on the devel mailing list]:
* ''Replacing version 2 with version 3 wholesale, without possibility
for parallel installation, starting in Fedora Linux 41.''<br/>This
would force users to choose between using either using version 2.x or
3.x of GIMP, and it might make users with existing GIMP projects stay
longer on an older version of Fedora Linux than they would do
otherwise.
* ''Add <code>gimp2</code> for the old version, let <code>gimp</code>
become version 3 in Fedora Linux 41 …''<br/>This would need an
exception for the <code>gimp2</code> package, as it needs Python 2.x.
** ''… and introduce version 3 as <code>gimp3</code> in Fedora Linux
<= 40.'' This would come along with even more packaging churn, it
would introduce <code>gimp3</code> only for two existing Fedora
versions and then obsolete the package, also makes the upgrade
obsolete dance from 40 to 41 more complicated than it needs to be.
** ''… and only introduce GIMP version 3 in Fedora Linux >= 41.'' This
would withhold the benefits of the new GIMP version to users of older
Fedora Linux versions without a technical need to do so.
== Benefit to Fedora ==
This change upgrades GIMP to a version which doesn’t use ancient 2.x
versions of both GTK and Python anymore. Other than many new features
including better color management and the support of CMYK
import/export, it greatly improves user experience with certain input
devices such as tablets and on displays with very high resolutions.
Developers of plugins using Python can now use packages and language
features which simply don’t exist in Python 2.x.
== Scope ==
* Proposal owners:
** Make (pre-releases) available as <code>gimp3</code> in Rawhide and
existing Fedora Linux versions.
** Ensure users of <code>gimp</code> get both versions when upgrading
their OS to Fedora Linux 41.
** Ensure comps is updated to refer to the new GIMP version from
Fedora Linux 41 on.
* Other developers: Maintainers of third party plugins work with their
respective upstreams to either find out if they have been ported to
GIMP 3.x, or assist in porting and make such ports available in
Fedora.
* Release engineering: This is a self-contained change and doesn’t
require that release engineering is involved.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: This change doesn’t particularly
relate to the [https://discussion.fedoraproject.org/t/fedora-strategy-2028-february-march-…
the current Fedora Strategy], but it aligns well with “Freedom”,
“Features” and maybe ”First” of the
[https://docs.fedoraproject.org/en-US/project/#_what_is_fedora_all_about
Fedora Foundations].
== Upgrade/compatibility impact ==
The plan is that existing users of <code>gimp</code> end up with both
this package and the new version as <code>gimp3</code>. It should be
possible to install either version without pulling in the other on
Fedora Linux >= 41 (if technically feasible).
== User Experience ==
With Fedora Linux 41, users who install GIMP as an RPM package will
get the new version by default. It contains many new features and
improvements in the handling of input devices such as tablets and when
used on high resolution displays.
== Dependencies ==
A number of third party GIMP plugins are available to be installed as
packages on Fedora Linux. With the continued availability of version
2.x of GIMP, these packages can still be installed and used with the
old version. Whether or not these plugins will support the new GIMP
version very much depends on the particular plugin, or rather the
upstream projects for these plugins. Therefore it’s a bit early to
make plans for packaging plugins available for both GIMP versions at
this point.
== Contingency Plan ==
* Contingency mechanism: Not ship the package, bump “seamless update”
measures to be effective in Fedora Linux 42.
* Contingency deadline: Beta Freeze
* Blocks release? No
== Documentation ==
* https://gimp.org/
* https://developer.gimp.org/core/roadmap/#gimp-30-development-branch-roadmap
* https://gitlab.gnome.org/GNOME/gimp/-/issues/10373#timeline
== Release Notes ==
This release of Fedora Linux ships version 3 of the GNU Image
Manipulation Program, with many new features and improved user
experience. The package is called <code>gimp3</code>, the old version
will still be available under the old name, <code>gimp</code> for
users who need it for existing projects.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Fedora_KDE_AArch64_ReleaseBlocker
Discussion Topic -
https://discussion.fedoraproject.org/t/f41-change-proposal-mark-fedora-kde-…
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 ==
Mark Fedora KDE AArch64 deliverables as release-blocking, leveraging
the same criteria for Fedora on AArch64 and Fedora KDE on x86_64.
== Owner ==
* Name: [[User:Ngompa| Neal Gompa]]
* Email: ngompa13(a)gmail.com
== Detailed Description ==
The Fedora KDE SIG already considers Fedora KDE on AArch64 at the same
level of importance as Fedora KDE on x86_64, and the SIG wants the
Fedora KDE AArch64 deliverables (such as the disk images and ISOs) to
be release-blocking alongside existing Fedora KDE x86_64 deliverables.
== Feedback ==
== Benefit to Fedora ==
This allows the Fedora KDE SIG to reinforce its commitment to the
highest quality KDE Plasma experience on Fedora possible on AArch64
like on x86_64, and it lets Fedora better support the larger ecosystem
around Fedora leveraging KDE Plasma (of one notable member being the
Fedora Asahi Remix).
== Scope ==
* Proposal owners: Update pungi-fedora to mark AArch64 artifacts as
release blocking ([https://pagure.io/pungi-fedora/pull-request/1290
pagureio#pungi-fedora#1290])
* Other developers: N/A (not needed for this Change)
* Release engineering: [https://pagure.io/releng/issue/12165 #12165]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: This aligns with expanding and
improving Fedora's connections to the larger ecosystem by supporting
upstream KDE with our expertise on AArch64 and downstream
distributions like the Fedora Asahi Remix using Fedora KDE on AArch64.
== Upgrade/compatibility impact ==
This has no impact on users.
== How To Test ==
Fedora KDE can be tested on AArch64 the same way Fedora Workstation is:
* Fedora KDE AArch64 ISO on either QEMU/KVM or a device with UEFI CD
boot such as [https://github.com/pftf the Raspberry Pi using UEFI
firmware]
* Fedora KDE AArch64 raw disk image on existing supported AArch64 devices
== User Experience ==
This does not change anything for the user experience.
== Dependencies ==
There are no extra dependencies.
== Contingency Plan ==
* Contingency mechanism: Revert release-blocking status for Fedora KDE
on AArch64
* Contingency deadline: Final Freeze
* Blocks release? Yes
== Documentation ==
There is no user-facing documentation to update. Fedora QA
documentation on release-blocking artifacts will note Fedora KDE
AArch64 artifacts as release-blocking.
== Release Notes ==
Not applicable as this is not a user-facing Change.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/OpenSSLDistrustSHA1SigVer
Discussion Topic -
https://discussion.fedoraproject.org/t/f41-change-proposal-make-openssl-dis…
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 ==
OpenSSL will no longer trust cryptographic signatures using SHA-1 by
default, starting from Fedora 41.
== Owner ==
* Name: [[User:Asosedkin| Alexander Sosedkin]]
* Email: asosedki(a)redhat.com
== Detailed Description ==
We would like to deprecate SHA-1 in signatures, because chosen-prefix
collision attacks on SHA-1 are becoming increasingly feasible.
Specifically, https://sha-mbles.github.io claims a complexity of
2^63.4, and a cost of 45k US dollars, with an estimated cost of 10k US
dollars by 2025 to find a chosen-prefix collision for a SHA-1
signature.
With this change accepted and implemented,
OpenSSL will start blocking SHA-1 signature creation and verification
by default.
The rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]]
has previously included this change among several others.
This is a second attempt to propose it, two years later, with a narrower scope.
== Feedback ==
This change, when discussed as part of the rejected [[
Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]],
has proved itself controversial.
There seems to be a consensus that the change has to be done sooner or later,
but Fedora is a remarkably conservative distribution
when it comes to deprecating legacy cryptography, even if by-default-only.
The decision to discover code reliant on SHA-1 signatures
by blocking creation/verification has not gathered many fans,
but it's not like many viable alternative proposals have been raised
in return either.
In particular, there is no suitable facility to perform opt-out
logging of the deprecated operation.
Opt-in logging through USDT probes has been implemented the last time
and has been reinstated again to aid testing this change.
The precursor change has received limited testing during Fedora 37 Test Days,
with only a handful of bugs discovered.
The ones that were, though, wouldn't be something realistically
discoverable by other means.
The change has received significant testing in RHEL,
which distrusts SHA-1 signatures by default starting from RHEL-9.
Having this switch flipped in RHEL for ~2 years further enforces our
confidence in the change.
== Benefit to Fedora ==
Fedora's security defaults will inch closer to what is considered
secure in the modern-day cryptographic landscape.
== Scope ==
* Proposal owners: flip that switch in the DEFAULT policy, provide
transitional policies for testing the change.
* Other developers:
Test your applications under TEST-FEDORA41 policy.
If the security of your application depends on trusting SHA-1 signatures,
fix this, or it will stop working unless users explicitly opt into
lower security guarantees. See
[[SHA1SignaturesGuidance | SHA1SignaturesGuidance]].
* Release engineering: [https://pagure.io/releng/issue/12096 #12096]
A change is a runtime change, so the mass rebuild considerations
boil down to %check-time testsuite failures expecting different defaults.
Specifically, reverting the change can be safely done without a mass-rebuild.
* Policies and guidelines:
CryptoPolicies section of the packaging guidelines
will have to be updated to reflect that
SHA-1 signatures must not be trusted by default.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
The change is not expected to break upgrades themselves.
The ways people use Fedora are a multitude, and the rare scenarios
relying on trusting SHA-1 signatures will break.
Administrators willing to retain previous behavior and sacrifice security
will be able to apply a compatibility policy or subpolicy
before or after the upgrade.
== How To Test ==
Preview the new defaults with `update-crypto-policies --set TEST-FEDORA41`.
Proceed to use the system as usual,
identify the workflows which are broken by blocking SHA-1 signature
creation/verification,
ideally also verify that `update-crypto-policies --set DEFAULT` fixes them,
file bug reports against the affected components if not filed already.
Please start your ticket title with `OpenSSLDistrustSHA1SigVer: `,
mention this change page, the version of crypto-policies package
and the policies under which your workflow does and does not work.
Alternatively, a tool to identify the affected operation without
blocking them will likely be provided,
installable from
https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer.
One would need openssl-3.2.1-9.fc41 or newer for the tool to work.
== User Experience ==
Some less-than-common use-cases will break.
(One example from Fedora 37 test days was interoperability with old
Apple devices).
The affected users will need to either explicitly opt into the
previous, less secure system configuration,
or wait until the affected packages are updated to move away from SHA-1.
Users that need the previous behaviour and don't mind the security
implications will be able to revert to the old behavior system-wide
(`update-crypto-policies --set FEDORA40`) or per-process (`runcp
FEDORA40 command args`, requires a
[https://copr.fedorainfracloud.org/coprs/asosedkin/crypto-policies-extras
copr-packaged] tool).
FEDORA40 policy will be maintained for several more Fedora releases.
== Dependencies ==
All reverse dependencies of openssl are potentially affected.
== Contingency Plan ==
* Contingency mechanism: the change is reverted
* Contingency deadline: Fedora 41 Beta Freeze
* Blocks release? Yes
Note: with the change being a flip of a switch at heart, there's not
much room for creativity in not completing it. Reverting is would be a
straightforward ordeal, and would not require a mass rebuild.
== Documentation ==
[[SHA1SignaturesGuidance | SHA1SignaturesGuidance]] contains relevant notes.
Fedora packaging guidelines should be modified accordingly.
== Release Notes ==
We'll need something to the tune of:
OpenSSL no longer trusts SHA-1 signatures are no longer trusted by default.
Affected users can opt out of the change at the expense of lowering
the system's security.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/RemoveIfcfgSupportInNM
Discussion Thread -
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 ==
Remove support for connection profiles stored in ifcfg format in NetworkManager.
== Owner ==
* Name: [[User:bengal| Beniamino Galvani]], [[User:ffmancera| Fernando
Fernández Mancera]], [[User:Till| Till Maas]]
* Email: <bgalvani(a)redhat.com>, <ferferna(a)redhat.com>, <till(a)fedoraproject.org>
== Detailed Description ==
NetworkManager supports different formats to persist connection
profiles to disk. The two formats currently in use in Fedora are
''keyfile'' and ''ifcfg''.
[https://networkmanager.dev/docs/api/latest/nm-settings-keyfile.html
Keyfile] is the native and preferred format. It supports all the
connection types and all the features.
[https://networkmanager.dev/docs/api/latest/nm-settings-ifcfg-rh.html
Ifcfg] is compatible with the old network-scripts. It only supports a
limited set of connection types, and it is
[https://lists.freedesktop.org/archives/networkmanager/2023-May/000103.html
deprecated] upstream.
This change proposal aims at removing NetworkManager support for ifcfg
files in Fedora. This is the last step of a process started several
releases ago:
* in Fedora 33, the default connection format was changed from ifcfg to keyfile;
* in Fedora 36, the plugin that handles ifcfg files was shipped in a
separate package and was not included in new installations;
* since Fedora 39, the NetworkManager daemon automatically migrates
ifcfg files to the keyfile format.
== Benefit to Fedora ==
Since ifcfg support is going to be removed upstream, it must also be
removed in Fedora. Keyfile is a valid and better replacement.
== Scope ==
* Proposal owners: drop the following packages:
** `NetworkManager-initscripts-ifcfg-rh` containing the ifcfg plugin
** `NetworkManager-dispatcher-routing-rules` containing a dispatcher
script to apply routing rules in ifcfg format
** `NetworkManager-initscripts-updown` containing alternative
ifup/ifdown scripts compatible with initscripts commands, using
NetworkManager.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
At this point no users should have connection profiles stored in ifcfg
format, as NetworkManager is automatically migrating them to keyfile
since Fedora 39.
According to [https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline
documentation] , system upgrades are supported only over 2 releases at
most (e.g. from 38 to 40); therefore, users upgrading to Fedora 41
must come from Fedora 39 or 40, which have the migration enabled.
If some users disabled the migration, they might still have ifcfg
files in `/etc/sysconfig/network-scripts`. A “readme-ifcfg-rh.txt”
file there warns users that the format is deprecated and is going to
be removed.
== How To Test ==
* Try to install the NetworkManager-initscripts-ifcfg-rh package
* The package is not available.
== User Experience ==
See the “Upgrade/compatibility impact” section.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Revert the change, try again the next Fedora release.
* Contingency deadline: Beta freeze
* Blocks release? no
== Documentation ==
No documentation change required.
== Release Notes ==
The change needs to be mentioned in the Release Notes.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Separate_dtrace_package
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-separate-package…
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 ==
Split <code>/usr/bin/dtrace</code> from
<code>systemtap-sdt-devel</code> ({{package|systemtap}}) into a
separate package to optimize many buildroots by removing unnecessary
Python dependencies.
== Owner ==
* Name: [[User:lbalhar| Lumír Balhar]]
* Email: lbalhar(a)redhat.com
== Detailed Description ==
The package <code>systemtap-sdt-devel</code> currently contains header
files and the script <code>/usr/bin/dtrace</code>, which is written in
Python and uses pycparser. This results in unnecessary Python and
pycparser installations for many packages that do not need the script
(and many times Python at all), as they only require the header files.
Moreover, some important packages (like perl-devel) require
systemtap-sdt-devel which means hundreds of Perl packages have Python
installed in their buildroots because of the single script they don't
need.
The idea was tested on all packages build-requiring perl-devel but
don't build-requiring python-devel directly - 520 in total. And from
that number:
* 7 failed to build for unrelated reasons
* 3 packages have python3-devel in buildroot (different reasons than
systempat-sdt-devel)
* 81 packages have python3-libs but not python3-devel (different
reasons than systemtap-sdt-devel)
and finally, the rest - 436 packages - builds fine without the Python
script in systemtap-sdt-devel and therefore without Python at all.
Further testing on packages directly requiring systemtap-sdt-devel
identified the following needing the dtrace script:
* glib2
* sssd
* qemu
* python2.7
* postgresql15
* postgresql16
* perl
* php
* mariadb10.11
* libvirt
Those will depend on a new package to which we move the script.
== Feedback ==
The proposal has been positively received on the
[https://lists.fedorahosted.org/archives/list/devel@lists.fedoraproject.org/…
Fedora devel list].
== Benefit to Fedora ==
By splitting the <code>/usr/bin/dtrace</code> script into a separate
package, we reduce the buildroot size and improve build times for
hundreds of packages that do not require Python.
== Scope ==
* Proposal owners:
# Move the script to a new package <code>systemtap-sdt-dtrace</code>
and update <code>systemtap-sdt-devel</code> to require this new
package for backward compatibility.
# Update affected packages to depend on <code>systemtap-sdt-dtrace</code>.
# Remove the backward-compatible requirement from
<code>systemtap-sdt-devel</code>.
* Other developers: Review and merge proposed changes, and report any bugs.
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
== How To Test ==
Package maintainers can proactively prepare their packages after the
first step from the plan above is implemented. Failed builds
identifying packages requiring changes are available in
[https://copr.fedorainfracloud.org/coprs/lbalhar/sdt-devel-no-dtrace/
COPR].
Maintainers can also build and test their packages with the version of
systemtap-sdt-devel from which the script has been removed.
== User Experience ==
Regular distro users shouldn't notice any change.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Change owner will revert the change in
{{package|systemtap}}.
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED
FOR SYSTEM WIDE CHANGES -->
* Blocks release? N/A (not a System Wide Change) <!-- REQUIRED FOR
SYSTEM WIDE CHANGES -->
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/WaylandOnlyGNOMEWorkstationMedia
Discussion Topic -
https://discussion.fedoraproject.org/t/f41-change-proposal-wayland-only-gno…
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 ==
Remove the GNOME X11 packages from the Fedora Workstation media. The
packages will remain available in the repositories maintained by the
GNOME SIG, but not preinstalled on the media anymore.
== Owner ==
* Name: [[User:Ngompa| Neal Gompa]]
* Email: ngompa13(a)gmail.com
== Detailed Description ==
As part of the upstream deprecation and effort to remove X11 support
from GNOME, Fedora Workstation media will no longer include the GNOME
X11 packages. The packages will remain in the repository (maintained
by the GNOME SIG/Workstation WG) for users to manually install at this
time.
== Feedback ==
== Benefit to Fedora ==
This aligns us with the effort going on upstream to deprecate and
retire the GNOME X11 session. It also partly aligns us with Fedora
KDE. Like the Fedora KDE SIG, the Fedora Workstation WG recommends and
supports the Wayland platform for graphics.
Fedora Workstation has a long history of developing and promoting the
Wayland experience for GNOME, and
[https://fedoraproject.org/wiki/Changes/WaylandByDefaultOnNVIDIA it
has been the primary experience for all users (including those with
NVIDIA cards) since Fedora Linux 36]. This reaffirms our commitment to
the Wayland GNOME experience in furtherance of the goal to provide the
highest quality GNOME experience through Fedora Workstation.
== Scope ==
* Proposal owners: Drop the GNOME X11 packages from the GNOME groups
in comps and replace them with their Wayland counterparts. Pull
request: [https://pagure.io/fedora-comps/pull-request/972
pagureio#fedora-comps#972]
* Other developers: N/A (not needed for this Change)
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Systems upgrading from older releases of Fedora Workstation will not
be impacted, as this only affects new installs.
== Early Testing (Optional) ==
Not applicable to this change.
== How To Test ==
Not applicable to this change, as we're only dropping a non-default
experience from the media.
== User Experience ==
Going forward until the X11 session packages are fully dropped, users
will need to manually install them from the repository if they need
it.
== Dependencies ==
Not applicable for this change.
== Contingency Plan ==
* Contingency mechanism: Revert the comps change
* Contingency deadline: Final freeze
* Blocks release? Yes.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Fedora Workstation no longer pre-installs the deprecated GNOME X11
session for new installations. Users who wish to add it back can do so
by installing the <code>gnome-session-xsession</code> and
<code>gnome-classic-session-xsession</code> packages.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Hello,
To deliver Python 3.13 with Fedora Linux 41, we will run a coordinated
rebuild in a side tag.
https://fedoraproject.org/wiki/Changes/Python3.13
Python 3.13.0b2 is scheduled for Tuesday, Jun 4th 2024.
We hope to start the mass rebuild shortly after it's available.
TL;DR: If you can, for the period of the mass rebuild just don't build
your packages in rawhide.
We will let you know when the side tag rebuild actually starts and when
it is merged and it's safe to build in rawhide with Python 3.13.
Details:
If you see a "Rebuilt for Python 3.13" (or similar) commit in your package,
please don't rebuild it in regular rawhide or another rawhide side tag.
If you need to, please let us know, so we can coordinate.
If you'd like to build a package after we already rebuilt it, you should
be able to build it in the side tag via:
on branch rawhide:
$ fedpkg build --target=f41-python
$ koji wait-repo f41-python --build <nvr>
It takes time to build all the essential packages,
so don't expect all your dependencies to be available right away.
Any attempts to build your packages in the side tag before we do will
likely fail due to missing dependencies.
When in trouble, ask here or on Fedora's Matrix - Fedora Python room
(https://matrix.to/#/#python:fedoraproject.org)
Ping me (ksurma) or Miro (mhroncok) if you need to talk to us.
Builds will appear here:
https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f41-python&order=…
Please avoid any potentially disturbing or major changes in Python
packages until the rebuild is over.
Thanks!
Karolina