January 2021 - devel-announce - Fedora Mailing-Lists

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

1
0
0 / 0

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

1
0
0 / 0

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

1
0
0 / 0

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

1
0
0 / 0

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

1
0
0 / 0

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

1
0
0 / 0

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

1
0
0 / 0

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

1
0
0 / 0

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

1
0
0 / 0

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

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce January 2021