Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1889732 - Python 3.10: automake truncates 3.10 to 3.1
Summary: Python 3.10: automake truncates 3.10 to 3.1
Alias: None
Product: Fedora
Classification: Fedora
Component: automake
Version: 33
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Ondrej Dubaj
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: PYTHON3.10 1893652
TreeView+ depends on / blocked
Reported: 2020-10-20 13:25 UTC by Tomáš Hrnčiar
Modified: 2023-09-12 03:48 UTC (History)
13 users (show)

Fixed In Version: automake-1.16.2-3.fc34 automake-1.16.2-3.eln105 automake-1.16.2-4.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-07-11 01:02:55 UTC
Type: Bug

Attachments (Terms of Use)

Description Tomáš Hrnčiar 2020-10-20 13:25:27 UTC
rpm fails to build with Python 3.10.0a1.

Here is the error, seems like RPM has a problem with detecting the double-digit version of Python 3.10.

configure: error: Package requirements (python-3.1) were not met:

Package 'python-3.1', required by 'virtual:world', not found

For the build logs, see:

For all our attempts to build rpm with Python 3.10, see:

Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.10:

Let us know here if you have any questions.

Python 3.10 will be included in Fedora 35. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.10.
A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon.
We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.

Comment 1 Miro Hrončok 2020-10-20 13:39:31 UTC
This is a problem in automake. The documentation says: 

The Python version number, in the form major.minor (e.g., ‘2.5’). This is currently the value of ‘sys.version[:3]’.

The code seem to actually use this naïve construct:

[automake (master)]$ rg -F 'sys.version'
94:    [am_cv_python_version=`$PYTHON -c "import sys; sys.stdout.write(sys.version[[:3]])"`])
127:    if python_implementation() == 'CPython' and sys.version[[:3]] == '2.7':
230:# word of sys.version), in order to cope with versions such as 2.2c1.


46:py_version=$(python -c 'import sys; print("%u.%u" % tuple(sys.version_info[:2]))')

31:PYTHON_VERSION=$($PYTHON -c 'import sys; print(sys.version[:3])') || exit 1

Patrik, could you please report this to upstream? I am not subscribed to their mailing lists.

Comment 2 Miro Hrončok 2020-10-22 20:10:10 UTC
Here's my attempted fix:

It moves the build of the rpm package further, but there are some new failures (most likely unrelated):

Comment 3 Miro Hrončok 2020-10-23 07:15:55 UTC
The rpm failures are mostly:

error: /build/RPMS/noarch/....rpm: open failed: No such file or directory
error: cannot open ... index using sqlite - Operation not permitted (1)
error: cannot open Packages database in /var/lib/rpm
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (No such file or directory)
error: failed to stat /data/SPECS/....spec: No such file or directory
error: open of /build/RPMS/noarch/....rpm failed: No such file or directory
error: package ... is not installed
error: Unable to open sqlite database /var/lib/rpm/rpmdb.sqlite: unable to open database file

Comment 4 Miro Hrončok 2020-10-23 07:44:14 UTC
I get the same failures when I try to build rpm in a clean copr (first build with defaults, second with mock bootstrap):

Same results with local mock build.

The test failures are not automake nor Python 3.10 related at all.

My proposed automake fix should be enough to fix the build failure.

Comment 5 Panu Matilainen 2020-10-23 08:53:42 UTC
Ough, something broke fakechroot big time. I remember seeing something about recent glibc changes breaking this and that, and whenever something changes, fakechroot is one of the first things to blow up...

Comment 6 Patrik Novotný 2020-10-27 13:24:40 UTC
Upstream bug report:

Comment 7 Fedora Update System 2020-11-03 12:26:19 UTC
FEDORA-2020-5bc8c37539 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 8 Miro Hrončok 2020-11-03 12:34:10 UTC
This needs to be backported, because developers will use automake on stable Fedoras to generate tarballs to be used in rawhide packages.

Comment 9 Fedora Update System 2020-11-03 12:59:20 UTC
FEDORA-2020-6e4db46b53 has been pushed to the Fedora ELN stable repository.
If problem still persists, please make note of it in this bug report.

Comment 10 Ben Cotton 2021-02-09 15:20:45 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Comment 11 Miro Hrončok 2021-06-14 09:47:23 UTC
The Fedora 33 and 32 build were garbage collected. Could this please be backported to Fedora 33?

Comment 12 Fedora Admin user for bugzilla script actions 2021-07-01 15:22:32 UTC
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

Comment 13 Fedora Update System 2021-07-02 07:31:39 UTC
FEDORA-2021-d5291e5172 has been submitted as an update to Fedora 33.

Comment 14 Ondrej Dubaj 2021-07-02 07:41:12 UTC
Patch was already backported to f33. Made a rebuild and submitted to Bodhi.

Comment 15 Fedora Update System 2021-07-03 01:04:29 UTC
FEDORA-2021-d5291e5172 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-d5291e5172`
You can provide feedback for this update here:

See also for more information on how to test updates.

Comment 16 Fedora Update System 2021-07-11 01:02:55 UTC
FEDORA-2021-d5291e5172 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 17 Red Hat Bugzilla 2023-09-12 03:48:14 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days

Note You need to log in before you can comment on or make changes to this bug.