Re: Fedora 34 Change: Disable Python 2 Dist RPM Generators and Freeze
Python 2 Macros (was: Remove Python2 RPM Macros) (Self-Contained Change proposal)
by Ben Cotton
This proposal has been heavily modified:
https://fedoraproject.org/w/index.php?title=Changes%2FDisable_Python_2_Di...
It has therefore been resubmitted.
https://fedoraproject.org/wiki/Changes/Disable_Python_2_Dist_RPM_Generato...
= Disable Python 2 Dist RPM Generators and Freeze Python 2 Macros =
== Summary ==
The `python2.7dist()` and `python2dist()` automatic provides/requires
from {{package|python-rpm-generators}} will no longer be automatically
generated, no functional packages in Fedora use them. The `python(abi)
= 2.7` automatic provides/requires will be kept.
The {{package|python2-rpm-macros}} package will be removed from Fedora
34 and newer. The python2 RPM macros
(`/usr/lib/rpm/macros.d/macros.python2`) will be moved to
{{package|python2.7}} and frozen (no new development, except critical
bugfixes that affect packages outside the remaining Python 2
ecosystem).
Note that Python 2 packages are already not allowed in Fedora, except
explicitly granted exceptions.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhroncok(a)redhat.com
== Detailed Description ==
Python 2 is upstream dead, usage in Fedora packages is forbidden,
except for several package with an explicit FESCo approved exception.
The Python Maintenance team no longer wishes to support the python2
dist RPM generators from the {{package|python-rpm-generators}} package
nor the python2 RPM macros from the {{package|python2-rpm-macros}}
package (located at `/usr/lib/rpm/macros.d/macros.python2`) and hence
decided to disable the generators for Python 2 and freeze the macros.
Provides/requires like this will no longer be automatically generated in Fedora:
python2dist(...)
python2.7dist(...)
Currently, no functional Fedora 34 packages need such provides. The
`python(abi) = 2.7` automatic provides/requires will be kept.
The following macro definitions will be moved from
{{package|python2-rpm-macros}} to {{package|python2.7}}:
%{python2_sitelib}
%{python2_sitearch}
%{python2_version}
%{python2_version_nodots}
%{python2_platform}
%{py2_shbang_opts}
%{py2_shbang_opts_nodash}
%{py2_shebang_flags}
%py2_shebang_fix
%py2_build
%py2_build_egg
%py2_build_wheel
%py2_install
%py2_install_egg
%py2_install_wheel
And their definition will remain frozen unless a bug is found that
affects Fedora packages outside the remaining Python 2 ecosystem.
Packagers of Python 2 packages affected by bugs in the macros are
encouraged to apply workarounds and/or submit fixes themselves.
Only the following packages use some of the macros:
* several Python 2 trac plugins, but {{package|trac}} uses Python 3 now
** only those require `python2dist(...)` / `python2.7dist(...)`
* several Python 2 sugar packages, but they already don't build and/or
install as {{package|sugar}} uses Python 3 now
* 13 other affected packages in Fedora (some of them co-owned by Python Maint):
** avahi
** gimp-layer-via-copy-cut
** gimp-resynthesizer
** chromium
** NFStest
** offlineimap
** pygobject2
** pygtk2
** python-psutil
** python-six
** python2-cairo
** python2-dns
** python2-setuptools
Note: Many other packages use the macros in a disabled `%if` section.
Some of the listed ones might as well (and hence are not really
impacted), the list is an intersection of packages that (Build)Require
Python 2 and are greppable for the macros.
{{package|python2.7}} will provide and obsolete
{{package|python2-rpm-macros}} at least for 2 more releases (or until
it is removed entirely from Fedora).
The following macros will remain defined in
{{package|python-srpm-macros}} for the time being to not break
packages that are using Python 2 as build-time only dependency (which
is also not allowed, but happens more often):
%{__python2}
%{python2}
The [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix...
Python 2 section of Python packaging guidelines] will be amended to
say that the Python 2 macros may not completely mirror the Python 3
macros.
The changes will happen after the Fedora 34 mass rebuild and before branching.
== Feedback ==
At first, we have
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
proposed to remove the macros entirely]. That proposal has received
negative feedback and we have reworked it to only freeze the macros
and disable the dist generators.
== Benefit to Fedora ==
With each change of the RPM Python dist generators we had to create
artificial packages to test the impact on Python 2, because the real
set of Python 2 package in Fedora is basically non-existent. By
disabling them, we no longer have to worry about breaking things for
our downstreams or projects building atop Fedora.
In the past, we tried to keep the macros as similar to their Python 3
counterparts as possible, but we have decided that it is not worth it
for 13 packages. This way, historical packages can still be built atop
Fedora with the macros, but we don't need to worry about keeping them
up-to-date. Once {{package|python2.7}} is retired, the macros will go
away as well. This is also true for RHEL 9.
== Scope ==
* Proposal owners:
** Disable the `python2dist()`/`python2.7dist()` dependency generators.
** Move the python2 macros from {{package|python2-rpm-macros}} to
{{package|python2.7}}.
** Remove {{package|python2-rpm-macros}} and obsolete/provide it from
{{package|python2.7}}.
* Other developers: No action required.
* Release engineering: no impact on Release Engineering is anticipated
* Policies and guidelines: a note will be added to the Python 2 guidelines
* Trademark approval: Not necessary.
* Alignment with Objectives: Not really.
== Upgrade/compatibility impact ==
The {{package|python2-rpm-macros}} package will be obsoleted by
{{package|python2.7}}. Users that happened to have the macros
installed but not the interpreter will suddenly pull the interpreter
on upgrades, but we think that's a reasonable compromise.
== How To Test ==
Build a Python 2 package that used to provide and/or require
`python2.7dist()` or `python2dist()` automatically. Verify it does not
do that. Verify it still requires `python(abi) = 2.7`. Verify the
macros are still defined. Verify {{package|python2-rpm-macros}} is no
more. Verify {{package|python2.7}} does not depend on RPM.
== Packager Experience ==
Mildly worse for packagers building Python 2 RPMs atop Fedora. If such
packagers need the dist generators to do so, they are encouraged to
build their own version. Feel free to talk to the change owner about
how to do that.
Fedora packages are not affected.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: Revert the changes.
* Contingency deadline: Beta freeze.
* Blocks release? No.
* Blocks product? No.
== Documentation ==
This page is the documentation for the affected 3rd party packagers.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 3 months
List of long term FTBFS packages to be retired in February
by Miro Hrončok
Dear maintainers.
Based on the current fail to build from source policy, the following packages
will be retired from Fedora 34 approximately one week before branching (February
2021).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fai...
Note that some listed packages are orphaned and hence may be retired even sooner.
The packages in rawhide were not successfully built at least since Fedora 32.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ft...
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
============================================================================
VirtualGL gsgatlin, raphgro Fedora 31
sugar-flipsticks callkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31
sugar-getiabooks callkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31
sugar-infoslicer callkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31
sugar-labyrinth callkalpa, chimosky, pbrobinson Fedora 31
sugar-ruler callkalpa, chimosky Fedora 31
sugar-starchart callkalpa, chimosky, orphan Fedora 31
sugar-view-slides callkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31
No packages require above mentioned packages.
Affected (co)maintainers
callkalpa: sugar-flipsticks, sugar-view-slides, sugar-ruler, sugar-getiabooks,
sugar-labyrinth, sugar-starchart, sugar-infoslicer
chimosky: sugar-flipsticks, sugar-view-slides, sugar-ruler, sugar-getiabooks,
sugar-labyrinth, sugar-starchart, sugar-infoslicer
gsgatlin: VirtualGL
pbrobinson: sugar-flipsticks, sugar-view-slides, sugar-getiabooks,
sugar-labyrinth, sugar-infoslicer
raphgro: VirtualGL
tuxbrewr: sugar-flipsticks, sugar-infoslicer, sugar-getiabooks, sugar-view-slides
3 years, 3 months
Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DeprecatePythonMock
== Summary ==
The {{package|python-mock}} ({{package|python3-mock}}) package will be
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-pac...
deprecated] in [[Releases/34|Fedora 34]]. The package is a standard
library backport for older Pythons, Fedora packages should use
`unittest.mock` instead. Many still depend on `mock`, so we cannot
remove it yet. Packagers are encouraged to work with upstream to
switch to `unittest.mock` when available. A simple `sed` can be
applied in `%prep` as a temporary (or even permanent) downstream
solution.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhroncok(a)redhat.com
== Detailed Description ==
The {{package|python-mock}} package is the
[https://pypi.org/project/mock/ 3rd party backport of the standard
library `unittest.mock` module].
> mock is now part of the Python standard library, available as [https://docs.python.org/dev/library/unittest.mock.html unittest.mock] in Python 3.3 onwards.
> This package contains a rolling backport of the standard library mock code compatible with Python 3.6 and up.
Fedora has recent enough versions of Python, hence using a library
backport is redundant. Many packages only use it out of habit. We'd
like to encourage both downstream packages and upstreams to switch to
[https://docs.python.org/dev/library/unittest.mock.html unittest.mock]
instead. Eventually, we'd like to drop {{package|python-mock}} from
Fedora entirely, if possible. Before we attempt to remove the package,
we need to stop new packages to (Build)Require
{{package|python3-mock}}, hence we want to have it
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-pac...
deprecated].
Note that the change owner does not currently officially maintain
{{package|python-mock}} but the Python Maintenance team maintains the
package in RHEL and contributes to the Fedora package when needed. The
Fedora package maintainers have been contacted without response.
=== How to migrate to unittest.mock ===
In most cases, performing the following replacement should be enough:
s/^(\s*)import mock/\1from unittest import mock/
s/^(\s*)from mock import /\1from unittest.mock import /
If upstream really needs to support Python versions without
`unittest.mock`, we recommend using a `try-import` mechanism, such as:
try:
from unittest import mock
except ImportError:
import mock
If dual support for `unittest.mock` and `mock` is required, and the
`mock` package is required in the metadata (such as in the testing
''extras''), conditionalize it, with:
mock;python_version<"3.3"
== Feedback ==
In the past, we've managed to migrate some packages away from
python-mock, without a push back:
* https://src.fedoraproject.org/rpms/python-urllib3/pull-request/13
* https://src.fedoraproject.org/rpms/python-freezegun/pull-request/10
* https://src.fedoraproject.org/rpms/python-hypothesis/c/65a4191709
== Benefit to Fedora ==
Eventually, we might be able to no longer maintain a standard library
backport in a separate package.
== Scope ==
* Proposal owners: Deprecate {{package|python3-mock}} and update the
package description. Provide help migrating to `unittest.mock` to
other packagers who ask for it.
* Other developers: No action needed. Don't add new dependencies on
{{package|python3-mock}}. If interested, migrate existing packages to
`unittest.mock` (feel free to ask for help)
* 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. Only new packages cannot depend on it.
Once retired (in distant future), we don't plan to obsolete/provide
<code>python3-mock</code> from {{package|python3-libs}}, because it
cannot work as drop-in replacement (the import name is different). The
package will eventually be obsoleted by
{{package|fedora-obsolete-packages}} once Python is updated to 3.N+1
after the removal to avoid broken upgrades.
== How To Test ==
$ repoquery --repo=rawhide --provides python3-mock
...
deprecated()
...
== User Experience ==
No changes.
== Dependencies ==
N/A (not a System Wide Change)
== 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)
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 3 months
Fedora 34 Change: fbrnch (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/fbrnch
== Summary ==
Add the [https://github.com/juhp/fbrnch fbrnch] packager tool to Fedora.
== Owner ==
* Name: [[User:Petersen|Jens Petersen]]
* Email: <petersen(a)redhat.com>
== Detailed Description ==
fbrnch (F(ed) Branch) is a tool designed to help simplify or
semi-automate workflow processes for Fedora Packagers.
It was first presented at "Nest with Fedora" last year, and has
received some favorable feedback from users.
It is currently only available in a
[https://copr.fedorainfracloud.org/coprs/petersen/fbrnch/ Copr repo].
This Change is simply to bring the package into Fedora itself and
broaden awareness about the tool.
See the Benefit section below for more details about the functionality
that fbrnch provides.
== Benefit to Fedora ==
fbrnch is a CLI tool for Fedora Packagers, which supports some common
tasks like:
* merging and building packages across release branches
* automatic parallel builds of sets of packages in dependency order in
Koji sidetags
* srpm, scratch, local install, and mock builds from arbitrary package branches
* cloning and listing Fedora packages from Pagure
* progressive Copr builds across chroots
* creating, updating and listing one's package reviews
* requesting new repos and branches, and importing new packages
directly from package reviews
and more. See https://github.com/juhp/fbrnch#readme for example usage.
== Scope ==
* Proposal owners:
** Release fbrnch with new dependencies on the Haskell Hackage
repository and add to Stackage. (Latest current version tagged in
github and built in copr is 0.6.8.)
** Submit and complete package review(s).
** Build packages.
** Test fbrnch package working correctly.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (check by Release Engineering not needed:
this just adds a few new package(s))
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
fbrnch has already been tested quite bit over the last 6 months.
* dnf install fbrnch
The [https://github.com/juhp/fbrnch#readme Readme file] contains
examples of usage, and <code>fbrnch --help</code> provides help
output.
== User Experience ==
Fedora Packagers who wish to use fbrnch will be able to install it
without having to add another Copr repo,
and benefit easily from the advanced packaging workflow features
provided by fbnrch.
The package will get updated through Bodhi and with more testing, will
gain broader confidence from Packagers.
== Dependencies ==
A few package reviews will need to be completed in time.
== 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)
In the case the Change is not completed, the remainder can safely be
deferred until Fedora 35.
== Documentation ==
* https://github.com/juhp/fbrnch#readme
* https://github.com/juhp/presentations/blob/master/fedora-nest-2020-fbrnch...
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 3 months
Fedora 34 Change: uEFI for ARMv7 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/ARMv7UEFI
== Summary ==
Move ARMv7 to use UEFI as default for all armhfp generated images
== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: pbrobinson at fedoraproject dot org
== Detailed Description ==
In Fedora 30 we tried to move ARMv7 to UEFI and as part of that change
we got all the infrastructure changes in place as described in that
change. It turned out there were issues with upstream kernel,
bootloaders and a number of other pieces out of our control. Those
pieces of the puzzle are now fixed and we've been building the core
pieces since before Fedora 33 so we know it's now fixed and working
having engaged with upstream since.
== Benefit to Fedora ==
This allows ARMv7 to move to grub2 providing the same experience to
ARMv7 users as all other architectures across the distribution. It
simplifies a number of software stacks across the distribution due to
being able to use a single install/support/upgrade path as well as
providing a single set of docs.
== Scope ==
* Proposal owners: Changes to kickstarts.
* Other developers: None, all the required changes landed as part of
the prior feature, this is just flipping the switch.
* Release engineering: [https://pagure.io/releng/issue/9946 #9946] (a
check of an impact with Release Engineering is needed)
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Upgrades from prior versions of Fedora will continue to work as they
do currently. Devices booting with extlinux will continue to upgrade
and work as planned. For recent (F-25 and later) clean installs there
will be a documented migration process for those that wish to migrate
to grub2 boot process. For older installs (those without a VFAT
partition for firmware) will need to do a clean install. Devices with
non Fedora built u-boot will need to ensure they have a recent enough
u-boot to support the required uEFI functionality.
== How To Test ==
The process for testing will be the same as aarch64. This standardises
the arm architectures ultimately making things more straight forward
and eventually allowing code clean up.
== User Experience ==
The user experience will be the same as uEFI on aarch64 and x86_64
with the grub2 menu and features. This will provide a consistent
experience across all Fedora architectures and resolves a number of
issues seen with the basic extlinux menu system on ARMv7.
== Dependencies ==
There are no dependencies. The changes required are artefact output. I
will work with release engineering on this.
== Contingency Plan ==
* Contingency mechanism: Revert back to current extlinux boot process.
The IoT Edition has been supporting this method since Fedora 33 and
it's reported to work fine. We produced prototype
Workstation/Server/Minimal images in Fedora 33 with few issues.
* Contingency deadline: Beta Freeze
* Blocks release? Yes
== Documentation ==
Yes. There will need to be a review of the documentation pertaining to
ARMv7, in a lot of cases this will be deleting the old process so the
universal distribution defaults are the only docs.
== Release Notes ==
To be written once process is complete
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 3 months
Fedora 34 Change: SOF as default audio driver for Intel LPE hardware
(Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/SofDefaultForIntelLpe
== Summary ==
Intel LPE audio hardware has 2 drivers in the mainline kernel the SST
driver and the SOF driver, switch the default driver from SST to SOF.
== Owner ==
* Name: [[User:jwrdegoede| Hans de Goede]]
* Email: hdegoede(a)redhat.com
== Detailed Description ==
Intel x86 hardware based on the Bay Trail-T and Cherry Trails SoCs
does not come with the standard Intel HDA audio hardware. Instead it
has an audio block called the Low Power Engine or LPE. The LPE block
needs to have firmware loaded into it to function. There are 2
firmwares available the old proprietary SST firmware and recently the
open source SOF firmware has been released for the LPE engine.
There are also 2 kernel drivers for the LPE block, one for each
firmware, so we have a SST driver and a SOF driver. The upstream Intel
developers of these drivers, who are also part of the SOF team want to
deprecate and eventually remove the old SST driver in favor of the SOF
driver. Starting with the 5.11 kernel it is possible to build both
drivers into a single kernel and select which one will actually bind
to the LPE block using a kernel commandline parameter.
ATM the upstream default is the old SST driver, to avoid regressions.
This Fedora change will entail carrying a downstream patch which flips
the default to the SOF driver. This is being done in conclave with the
upstream devs who would like to see more testing of the SOF driver.
The upstream devs believe that the SOF driver is ready to replace the
SST driver, but they would appreciate this being tested by Fedora
first, before they flip the default for everyone.
== Benefit to Fedora ==
By consciously making the switch now, with extensive testing and
monitoring the situation we can safely make the switch without
regressions hitting users of the Fedora stable releases. Whereas if we
just wait for upstream to flip the default, then this may very well
land in the middle of a stable release when we rebase the kernel.
This helps strengthen our relationship with the upstream developers
and falls under the "First" part of the "Four Foundations".
This stops us from depending in the proprietary SST firmware-blobs,
replacing them with the Open Source SOF firmware, matching the
"Freedom" part of the "Four Foundations".
== Scope ==
* Proposal owners: This will require a small downstream kernel patch
to change the default driver when both are built (or an upstream patch
to make the default configurable). That's it, no other changes are
required.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: This falls under the "First" part of the
"Four Foundations".
== Upgrade/compatibility impact ==
The switch will automatically be made when booting a Fedora 34 kernel.
== How To Test ==
I (Hans de Goede) have an extensive collection of affected hardware.
The audio setup on these devices consists of the LPE block itself
combined with an external audio-codec. There are a number of
audio-codecs used / supported on these boards. The LPE block has 2
audio-links (called SSP0 and SSP2) and some of the codecs have 2
audio-links (called AIF1 and AIF2) not each board uses the same
audio-link on each side.
I plan to run the below test-plan on devices with the following SoC /
codec / link combinations:
* Bay Trail (CR) / RT5640 / SSP0<->AIF1
* Bay Trail (CR) / RT5640 / SSP0<->AIF2
* Bay Trail / RT5640 / SSP2<->AIF1
* Cherry Trail / RT5640 / SSP2<->AIF1
* Cherry Trail / RT5645 / SSP2
* Bay Trail (CR) / RT5651 / SSP0<->AIF1
* Cherry Trail / RT5651 / SSP2<->AIF1
* Bay Trail / RT5672 / SSP2
* Bay Trail (CR) / ESS8316 / SSP0
* Cherry Trail / ESS8316 / SSP2
* Cherry Trail / NAU8824 / SSP2
Each of these will be tested according to the following test-plan:
# Test speakers.
# Test internal mic.
# Plugin headset, test headphones.
# Test headset-mic
# Stop all audio, suspend + resume, test speakers.
# suspend + resume while playing audio, audio should resume playing
after resume.
Users who want to test this and who have the affected hardware can
also use this test-plan to test.
== User Experience ==
The SST driver has some suspend/resume problems around suspending with
audio playing. The SOF driver resolves these. Other then that the
user-experience should be unchanged.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
We can simply drop the patch flipping the default to get back to the
F33 state of things.
* Contingency mechanism: Revert the change
* Contingency deadline: Beta release
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
FIXME: TODO
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 3 months
Fedora 34 Change: Make selinux-policy up-to-date with the latest
kernel (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Make_selinux_policy_uptodate_with_...
== Summary ==
Add new permissions, classes, and capabilities to the selinux policy
so that system recognizes them, can boot without an error message, and
use them in the actual policy for confined services.
== Owner ==
* Name: Zdenek Pytela
* Email: zpytela(a)redhat.com
* Name: Ondrej Mosnacek
* Email: omosnace(a)redhat.com
== Detailed Description ==
Several new permissions, classes, and capabilities have been added to
Linux kernel recently. The current SELinux policy does not reflect all
the changes which means it does not make use of all the potential the
kernel provides.
The new features include:
* New classes: lockdown perf_event
* New permissions: watch watch_mount watch_reads watch_sb watch_with_perm
* New capabilities: bpf checkpoint_restore perfmon
With these new features, selinux-policy will be aligned with the current kernel.
== Benefit to Fedora ==
Adding support for the new features to selinux-policy brings better
granularity for granting permissions and have subsequent security
benefits.
Additionally, systems can be run with the mls selinux policy: this is
currently not possible as using mls policy may prevent a system from
starting when there are permissions unknown to the policy which is
true in the new kernels.
It will also allow for complex selinux testsuites run instead of
skipping parts of the tests, utilising not supported features.
List of the new features and bugzilla links:
* [https://bugzilla.redhat.com/show_bug.cgi?id=1901957 perf_event class ]
* [https://bugzilla.redhat.com/show_bug.cgi?id=1915034 watch permissions ]
* [https://bugzilla.redhat.com/show_bug.cgi?id=1915184 lockdown class ]
* [https://bugzilla.redhat.com/show_bug.cgi?id=1915264 bpf, perfmon,
checkpoint_restore capabilities ]
== Scope ==
* Proposal owners:
** Add all relevant patches to the current development fedora version
** Ensure the system boots with the targeted policy
** Ensure the system boots with the mls policy
** Ensure the permissions are recognized by the system
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
* Boot a system and check for error messages and audit records.
** ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts boot
** dmesg
** journalctl
* Optionally, install and boot the selinux-policy-mls package.
== User Experience ==
There's no visible change for end users.
Admins and custom policy authors may need to get familiar with the new
features for services which make use of them.
== Dependencies ==
N/A (not a System Wide Change)
== 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)
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 3 months
Fedora 35 Change: Retire python3.5 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RetirePython3.5
== Summary ==
The {{package|python3.5}} package will be retired without replacement
from [[Releases/35|Fedora 35]]. Python 3.5 has been End of Life since
September 2020 and was kept around only to test software targeting
Ubuntu 16.04 “Xenial Xerus” LTS and Debian 9 “Stretch” LTS. The
removal is more or less aligned with
[https://wiki.debian.org/LTS/Stretch Debian 9 EOL] (2022-06-30) --
Fedora 34 EOLs on 2022-05-17. Ubuntu 16.04 LTS EOLs sooner, in April
2021.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhroncok(a)redhat.com
== Detailed Description ==
The {{package|python3.5}} package with the Python interpreter in
version 3.5 is kept in Fedora only to make it possible for Fedora
users to test their software against the Python version shipped in
Ubuntu 16.04 “Xenial Xerus” LTS and Debian 9 “Stretch” LTS.
[https://wiki.ubuntu.com/Releases Ubuntu 16.04 “Xenial Xerus” LTS
standard support ends in April 2021].
[https://wiki.debian.org/LTS/Stretch Debian 9 “Stretch” LTS is End of
Life in 2022-06]. This very roughly corresponds with the
[https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
Fedora 34 EOL]. Hence, we decided to retire (completely remove)
{{package|python3.5}} from Fedora 35, before it gets released. Users
who target Debian 9 can use Fedora 34 until it EOLs.
== Feedback ==
This was announced on the Python list prior to submitting the change
proposal: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedorapr...
There was no pushback.
== Benefit to Fedora ==
The maintenance of Python 3.5 was getting harder and harder every
year. The support for Python 3.5 has disappeared from pip and
setuptools, and an older version of pip/setuptools has to be bundled
in {{package|python3.5}}, while pip and setuptools bundle even more
old libraries. Support from tox and virtualenv will eventually
disappear as well.
There is no direct benefit here, except that we don't want to maintain
it anymore and we don't think it's a good idea either.
Consider this change proposal a louder orphaning, except that we will
continue to maintain the package in older released and supported
Fedoras (33 and 34). If you wish to continue maintaining Python 3.5 in
Fedora, please [[SIGs/Python|speak to us]] first.
== Scope ==
* Proposal owners: Retire {{package|python3.5}}. Obsolete it from
{{package|fedora-obsolete-packages}} if it causes troubles on
upgrades. Make sure no Fedora package depends on it in any way (incl.
weak dependencies).
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The package will no longer be available from the repositories, but it
may remain on existing installations. If it causes troubles on
upgrade, it needs to be obsoleted.
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No more Python 3.5 to test user software on.
== Dependencies ==
N/A (not a System Wide Change)
== 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)
* Blocks product? product
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 3 months
Fedora 34 Change: Remove Python2 RPM Macros (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Remove_Python2_RPM_Macros
== Summary ==
The {{package|python2-rpm-macros}} package (containing
`/usr/lib/rpm/macros.d/macros.python2`) will be removed from Fedora 34
and newer. The python2 RPM macros will ceases to exist. Python 2
packages are already not allowed. Around a dozen of packages use the
macros in Fedora and will need to be adjusted either by expanding them
or by no longer using Python 2. The `python2.7dist()` and
`python2dist()` automatic provides/requires will no longer be
automatically generated.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhroncok(a)redhat.com
== Detailed Description ==
Python 2 is upstream dead, usage in Fedora packages is forbidden,
except for several package with an explicit FESCo approved exception.
The Python Maintenance team no longer wishes to support the python2
RPM macros from the {{package|python2-rpm-macros}} package (located at
`/usr/lib/rpm/macros.d/macros.python2`) and hence decided to remove
the package. The following macros will be undefined:
%{python2_sitelib}
%{python2_sitearch}
%{python2_version}
%{python2_version_nodots}
%{python2_platform}
%{py2_shbang_opts}
%{py2_shbang_opts_nodash}
%{py2_shebang_flags}
%py2_shebang_fix
%py2_build
%py2_build_egg
%py2_build_wheel
%py2_install
%py2_install_egg
%py2_install_wheel
The following macros will remain defined for the time being to not
break packages that are using Python 2 as build-time only dependency
(which is also not allowed, but happens more often):
%{__python2}
%{python2}
The [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix...
Python 2 section of Python packaging guidelines] will be removed.
{{package|python2.7}} will no longer require
{{package|python2-rpm-macros}} and {{package|python3-rpm-generators}}.
Provides/requires like this will no longer be automatically generated:
python2dist(...)
python2.7dist(...)
The changes will happen after the Fedora 34 mass rebuild and before branching.
Packages that used to use those macros in Fedora will need to be
adapted to expand the macros or switch to Python 3. In January 2021,
we have:
* several Python 2 trac plugins, but {{package|trac}} uses Python 3 now
** only those require `python2dist(...)`
* several Python 2 sugar packages, but they already don't build and/or
install as {{package|sugar}} uses Python 3 now
* 13 other affected packages in Fedora (some of them co-owned by Python Maint):
** avahi
** gimp-layer-via-copy-cut
** gimp-resynthesizer
** chromium
** NFStest
** offlineimap
** pygobject2
** pygtk2
** python-psutil
** python-six
** python2-cairo
** python2-dns
** python2-setuptools
Note: Many other packages use the macros in a disabled `%if` section.
Some of the listed ones might as well (and hence are not really
impacted), the list is an intersection of packages that (Build)Require
Python 2 and are greppable for the macros.
The removed macros and migration plan:
=== %{python2_sitelib} ===
Affected Fedora packages:
* avahi
* NFStest
* offlineimap
* python2-dns
* python2-setuptools
* python-six
Migration plan if not possible to switch to Python 3 / retire: Use
`%{_prefix}/lib/python2.7/site-packages`.
=== %{python2_sitearch} ===
Affected Fedora packages:
* chromium
* offlineimap
* pygobject2
* pygtk2
* python2-cairo
* python-psutil
Migration plan if not possible to switch to Python 3 / retire: Use
`%{_libdir}/python2.7/site-packages`.
=== %{python2_version} ===
Affected Fedora packages:
* offlineimap
* pygtk2
* python2-setuptools
Migration plan if not possible to switch to Python 3 / retire: Use `2.7`.
=== %{python2_version_nodots} ===
No affected Fedora packages.
Migration plan: Use `27`.
=== %{python2_platform} ===
No affected Fedora packages.
Migration plan: Use a glob like `linux-*`.
=== %{py2_shbang_opts}, %{py2_shbang_opts_nodash},
%{py2_shebang_flags}, %py2_shebang_fix ===
Affected Fedora packages:
* gimp-layer-via-copy-cut
* gimp-resynthesizer
* offlineimap
All use `pathfix.py -pni "%{__python2} %{py2_shbang_opts}" ...`
Migration plan: `pathfix.py -pni "%{_bindir}/python2" -kas ...`
=== %py2_build, %py2_install ===
Affected Fedora packages:
* NFStest
* offlineimap
* python2-cairo
* python2-dns
* python2-setuptools
* python-psutil
* python-six
Migration plan:
%build
%set_build_flags
python2 setup.py build
%install
python2 setup.py install --skip-build --root %{buildroot}
Note: Add additional `sleep 1` after/before the build if you also
build for Python 3.
=== %py2_build_egg, %py2_build_wheel, %py2_install_egg, %py2_install_wheel ===
No affected Fedora packages. There are no build dependencies in Fedora
to build a Python 2 wheel or install it.
Migration plan for egg: Please don't use this!
%build
%set_build_flags
python2 setup.py bdist_egg
%install
python2 -m easy_install -m --prefix %{buildroot}%{_prefix} -Z <path_to_egg>
== Benefit to Fedora ==
We tried to keep the macros as similar to their Python 3 counterparts
as possible, but we have decided that it is not worth it for 13
packages. We want to discourage building Python 2 packages. We want to
remove the package from RHEL 9 as well.
== Scope ==
* Proposal owners:
** Drop the macros. Disable the `python2dist()`/`python2.7dist()`
dependency generators.
** No longer require {{package|python2-rpm-macros}} and
{{package|python3-rpm-generators}} from {{package|python2.7}}.
** Fix packages with FESCo exceptions (except already broken trac
plugins), leave the other affected packages broken for the maintainers
to fix.
* Other developers:
** Fix their packages by migrating to Python 3 or expanding the macros.
* Release engineering: no impact on Release Engineering is anticipated
* Policies and guidelines: the Python 2 guidelines will be deleted
* Trademark approval: Not neccessary.
* Alignment with Objectives: Not really.
== Upgrade/compatibility impact ==
None.
== How To Test ==
Check the macros are not defined.
== Packager Experience ==
Mildly annoying (for the affected packagers), but expected to be
temporary as the number of Python 2 packages constantly decreases.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: If this fails, we'll introduce the macros as
a separate component and orphan it.
* Contingency deadline: Beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
This page is the documentation for the affected packagers.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 3 months
Delay in master->main changes for src.fedoraproject.org
by Kevin Fenzi
Greetings everyone.
You all may have noticed that we planned to do do Phase 2 of our change
( https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main )
on the 13th.
However, we have decided to delay changes to src.fedoraproject.org repos
until 2021-01-27, for the following reasons:
* We have changes pending for fedpkg and fedscmadmin to handle the
change and we would like there to be releases of both of them, in
stable updates for at least a little while so maintainers have time to
update.
* For various reasons we haven't been able to test our scripting in stg
yet, so we would like to do that and confirm all is working, as well
as provide stg with changes for everyone else to test against if they
like.
* We are tweaking some consmetic changes in pagure (mentioning the old
master branch in PR info, etc) and would like to get that released.
Thanks for your understanding,
kevin
3 years, 3 months