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
I noticed due to an upstream bug report for a project I am on that the Fedora packaging guidelines still say that GUI applications should install their files as appdata.xml files and not metainfo.xml files (https://docs.fedoraproject.org/en-US/packaging-guidelines/AppData/). The upstream spec for the appstream says that everything should be installed as metainfo.xml files and there are no more appdata.xml files.
I found that there was an issue opened to the packaging committee a year ago (https://pagure.io/packaging-committee/issue/944), but there has been no comment/follow-up since then. Should the Fedora guidelines be updated to match the current spec?
Hi,
On behalf of RPM and DNF teams, I would like to highlight changes that
have appeared in our packages in 2020. Thanks everyone for your bug
reports and patches!
RPM
---
$ rpm --eval '%[0 < 1 ? "true" : "false"]'
* Support for complex expressions and conditionals with short-circuit
logic etc in macros via %[...] and %{expr:...}
$ rpm --eval '%[v"1.10" > v"1.2"]'
* Rpm versions as native objects in expressions, eg v"3.1-1"
$ rpmbuild
* Parametric macro dependency generators offer a lightning fast way
to generate dependencies where applicable
* Meta dependencies, eg Requires(meta) allow specifying dependencies
without introducing ordering constraints
* Dependency generation based on MIME types
$ rpm --rebuilddb
* New sqlite3 backend
* More robust than the Berkley DB backend
* SQLite3 has also a more permissive license than the latest BDB
* NDB backend promoted to stable
* Support for migration (reading) from BDB databases without linking
to BDB
DNF
---
$ dnf needs-restarting
* Introduced the needs-restarting.d drop-in directory
$ dnf reposync
* Fixed modularity issues, able to sync modular repos correctly
$ dnf groups-manager
* yum-groups-manager is back
* Upstream only, to be released in Fedora soon
* https://github.com/rpm-software-management/dnf-plugins-core/pull/412
$ dnf module switch-to
* Switches the module stream and also performs distro-sync on the new
stream content
$ dnf history store/replay
* New commands for storing a transaction and replaying it on another
system
$ dnf system-upgrade
* The code was refactored to use the store/replay feature in the
background
* Landing in Fedora now
$ dnf system-upgrade
* Comps groups are upgraded during the system upgrades
$ dnf offline-upgrade
$ dnf offline-distrosync
* New commands to upgrade your system on reboot
MICRODNF
--------
$ microdnf module <enable|reset|disable>
* New commands for managing modules
$ microdnf --config
* Microdnf reads values from dnf.conf
* It is possible to specify a path to the config
$ microdnf --refresh
* Force repodata refresh
* Microdnf also honors the metadata_expire configuration option
LIBDNF
------
* Many changes to make the DNF features available in microdnf and
PackageKit (and Gnome Software)
DNF 5
-----
* The goal is to remove redundant code and make sure all tools built
on top libdnf work the same (DNF currently uses a different code path
than microdnf and PackageKit)
* We're behind the plan because we spent the time fixing DNF 4 stack
instead (modularity, new features, crashes, etc.)
* There's a COPR repo with unstable nightlies:
* dnf copr enable rpmsoftwaremanagement/dnf5-unstable
* dnf install microdnf5
* dnf install python3-libdnf5 perl5-libdnf ruby-libdnf
* WARNING: Here be dragons! The software is not ready for general
use yet.
* The next steps are: finish the core functionality, stabilize the
API and make the package available in Fedora in parallel with the DNF 4
stack
Hello folks,
I write this to request review of the most recent PR https://pagure.io/fedora-gather-easyfix/pull-request/9 made to modernize the overall experience and functioning of the site. The changelog is listed in the PR body includes rewrite of the template in Bootstrap 5, in-page active searching using Javascript, adding placeholders to template logic, removal of obsolete JQuery and Bootstrap assets and much more. The logo design is requested at https://pagure.io/design/issue/714 and the design is put to review at https://pagure.io/design/issue/715 too.
With that, I also wish to note that being Easyfix an entrypoint to the community to a lot of new contributors - who feel like they can get started quickly by solving self-contained and well-documented issues - there should be an added attention to tag issues with Easyfix whenever they come under the above classification. It is understandable that there are multiple projects with tasks that could use a greater involvement but there can also be some issues, if you look closely, that you can pass on to someone who is relatively new to the project. Feel free to discuss about the same in the thread.
Thanks and regards,
Akashdeep Dhar
t0xic0der
Hi,
I've recently been experimenting with Quantum computing and learning
about its uses and benefits. There are currently libraries available
in python to experiment with this technology so I thought it would be
interesting to see if others in the community were working in this
area.
I've checked and there is no #fedora-quantum so I've created it, and
if there's enough interest maybe we can form a SIG and get some
working projects going together. I'd love to throw some ideas around
to see how we can use this technology.
For the moment, I'm concentrating on getting the QISKIT [1] libraries
packaged in Fedora. I should hopefully have some updates together for
this very soon.
Thanks, hope to see you in #fedora-quantum,
Stephen
[1] https://github.com/Qiskit/qiskit
Hi all.
From what are activated these rpmlint warnings of pioneer.spec file [1]?
pioneer.spec: E: specfile-error warning: This package uses obsolete
macros that will go away soon. Please convert to the spec templates
provided by fonts-rpm-templates!
pioneer.spec: E: specfile-error warning: This package uses obsolete
macros that will go away soon. Please convert to the spec templates
provided by fonts-rpm-templates!
pioneer.spec: E: specfile-error warning: This package uses obsolete
macros that will go away soon. Please convert to the spec templates
provided by fonts-rpm-templates!
pioneer.spec: E: specfile-error warning: This package uses obsolete
macros that will go away soon. Please convert to the spec templates
provided by fonts-rpm-templates!
pioneer.spec: E: specfile-error warning: This package uses obsolete
macros that will go away soon. Please convert to the spec templates
provided by fonts-rpm-templates!
pioneer.spec: E: specfile-error warning: This package uses obsolete
macros that will go away soon. Please convert to the spec templates
provided by fonts-rpm-templates!
[1] https://src.fedoraproject.org/rpms/pioneer/blob/master/f/pioneer.spec
Thanks.
--
---
Antonio Trande
Fedora Project
mailto: sagitter(a)fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/
Hi,
Before going into the official steps, I would like to have some feedback if some of you would be interested in having Gemato (https://github.com/mgorny/gemato) packaged. This is a tool that Gentoo uses for managing Manifest files and for verifying the integrity and authenticity of the Gentoo ebuild repository. At first for Fedora side, this is useful for some of you like me who work on Gentoo packaging but also, among others, it provides (https://github.com/mgorny/gemato/blob/master/gemato/openpgp.py) very nice python module for GPG verification. For example, you can import only this GPG module to rely on for all your GPG verifications in other projects. The author of Gemato is very active and security focused especially for GPG stuff.
I've notified him about this and he is very happy about this perspective.
Best regards,
Frédéric
Hi all! I haven't contributed much to open source yet, but I really
appreciate the contribution of the Fedora community to FOSS.
I want to be part of the community and offer a package useful for managing
UEFI Secure Boot keys.
My review request of efitools:
https://bugzilla.redhat.com/show_bug.cgi?id=1917128
I prepared a protobuf update for rawhide to 3.14. It requires a rebuild
of all dependencies and of the 54 dependencies currently only 3 fail to
rebuild in COPR:
https://copr.fedorainfracloud.org/coprs/adrian/protobuf-3-14/packages/
paraview: timeout after 10 hours, should work in koji
community-mysql: test failure, this usually does not happen in koji
libgadu: actual build failures, but seems unrelated to protobuf:
/usr/bin/ld: sha1.o (symbol from plugin): undefined reference to symbol 'SHA1_Init@@OPENSSL_1_1_0'
/usr/bin/ld: /usr/lib64/libcrypto.so.1.1: error adding symbols: DSO missing from command line
I will start the rebuilds in rawhide in a side-tag in about a week
Adrian
One of my packages has started to use CPM.cmake
(https://github.com/TheLartians/CPM.cmake) which is a "Setup-free
CMake dependency management" addon script for cmake.
I'm hoping someone out there has some expertise and can coach me
through this - I'm frankly bewildered by it.
My problem is that CPM.cmake requires the use of the network at build
time to download CPM.cmake itself and then to download the source of
various dependency libraries. This is forbidden in fedora by
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_build_time_netw…
- fedora builds must be done offline.
Any ideas how to overcome this?
I had thought of building it on my local machine, doing a 'make clean'
equiv and using that as a tarball including all the dependency
libraries. But that seems rather naff.
TIA
Bob