Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

copr-frontend built failed after upgrading python3.11 #3637

Open
pkking opened this issue Feb 19, 2025 · 3 comments
Open

copr-frontend built failed after upgrading python3.11 #3637

pkking opened this issue Feb 19, 2025 · 3 comments

Comments

@pkking
Copy link
Contributor

pkking commented Feb 19, 2025

here's two different build log:
the succeed log

the failed log

after some investigate, seems the py_compile command line change the behavior
in python3.9

$ python3 -V
python 3.9.9
$ python3 -m py_compile
$ echo $?
0

in python3.11

$ python3 -V
python 3.11.6
$ python3 -m py_compile
usage: py_compile.py [-h] [-q] filenames [filenames ...]
py_compile.py: error: the following arguments are required: filenames
$ echo $?
2
@github-project-automation github-project-automation bot moved this to Needs triage in CPT Kanban Feb 19, 2025
@xsuchy xsuchy moved this from Needs triage to Someday in future in CPT Kanban Feb 19, 2025
@pkking
Copy link
Contributor Author

pkking commented Feb 19, 2025

a quick fix is comment this line:

%py_byte_compile %{__python3} %{buildroot}%{_datadir}/copr/coprs_frontend/tests

then the build succeed

@FrostyX
Copy link
Member

FrostyX commented Feb 20, 2025

That's strange. We regularly rebuild the packages and didn't notice this. I just submitted
https://copr.fedorainfracloud.org/coprs/g/copr/copr/build/8675417/

I didn't test specifically for Python 3.11 but it worked fine for Python 3.12 (F40) and Python 3.13 (F41)

@pkking
Copy link
Contributor Author

pkking commented Feb 21, 2025

That's strange. We regularly rebuild the packages and didn't notice this. I just submitted https://copr.fedorainfracloud.org/coprs/g/copr/copr/build/8675417/

I didn't test specifically for Python 3.11 but it worked fine for Python 3.12 (F40) and Python 3.13 (F41)

The root cause:
py_compile.py distributed with python failed when no valid params provides instead of succeed before

the logs below maybe show the magic:

+ [[ /usr/bin/python3 =~  - ]]
+ clamp_source_mtime /usr/bin/python3 /builddir/build/BUILD/copr-frontend-2.1-build/BUILDROOT/usr/share/copr/coprs_frontend/tests
+ python_binary='env /usr/bin/python3'
+ bytecode_compilation_path=/builddir/build/BUILD/copr-frontend-2.1-build/BUILDROOT/usr/share/copr/coprs_frontend/tests
+ PYTHONPATH=/usr/lib/rpm/redhat
+ env /usr/bin/python3 -s -B -m clamp_source_mtime /builddir/build/BUILD/copr-frontend-2.1-build/BUILDROOT/usr/share/copr/coprs_frontend/tests
Listing '/builddir/build/BUILD/copr-frontend-2.1-build/BUILDROOT/usr/share/copr/coprs_frontend/tests'...
Can't list '/builddir/build/BUILD/copr-frontend-2.1-build/BUILDROOT/usr/share/copr/coprs_frontend/tests'
++ /usr/bin/python3 -c 'import sys; sys.stdout.write('\''{0.major}{0.minor}'\''.format(sys.version_info))'
+ python_version=313
+ '[' 313 -ge 39 ']'
+ py39_byte_compile /usr/bin/python3 /builddir/build/BUILD/copr-frontend-2.1-build/BUILDROOT/usr/share/copr/coprs_frontend/tests
+ python_binary='env PYTHONHASHSEED=0 /usr/bin/python3'
+ bytecode_compilation_path=/builddir/build/BUILD/copr-frontend-2.1-build/BUILDROOT/usr/share/copr/coprs_frontend/tests
+ env PYTHONHASHSEED=0 /usr/bin/python3 -s -B -m compileall -j4 -o 0 -o 1 -s /builddir/build/BUILD/copr-frontend-2.1-build/BUILDROOT -p / --hardlink-dupes --invalidation-mode=timestamp /builddir/build/BUILD/copr-frontend-2.1-build/BUILDROOT/usr/share/copr/coprs_frontend/tests
Listing '/builddir/build/BUILD/copr-frontend-2.1-build/BUILDROOT/usr/share/copr/coprs_frontend/tests'...
Can't list '/builddir/build/BUILD/copr-frontend-2.1-build/BUILDROOT/usr/share/copr/coprs_frontend/tests'

seems Fedora shipped a py39_byte_compile and it keep the old version of py_compile.py to make the build happy, im not sure this is a fedora specific workaround or a more common solution in the entire RPM-based ecosystem

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Someday in future
Development

No branches or pull requests

2 participants