Dear Community,
The command I’m using is:
The RPMs build are:
python311-3.11.10-150600.3.9.2.x86_64.rpm
None of these contains the actual python3.11 binary.
The overall goal of the endeavour is to create a python RPM which will not install into /usr/bin.
So any hints on how to best accomplish this are well appreciated. Installations cannot be done based on any repository, though. I do need an RPM file which is stored localy on the machine where python needs to be installed.
Best Regards and Thanks for any help !
hui
February 14, 2025, 5:07pm
2
The binaries are built from another source package. You need the python311-core source to build the python311-base package which contains the binary…
Thank you hui.
I though I had this installed. Currently I get:
:/usr/src/packages/SOURCES # zypper search python311-core
S | Name | Summary | Type
:/usr/src/packages/SOURCES # zypper source-install python311-core
/usr/src/packages/SRPMS stays empty though.
I did this successfully before, I’m sure.
Where should the python311-core sources go?
Thank you for your support so far!!!
I downloaded python311-core-3.11.9-150600.1.5.src.rpm and deleted all contents in the ~/rpmbuild … directories were I try to build the RPMs.
=> So I had a completely fresh start.
I ran rpmbuild -ba python311.spec
and get:
error: Installed (but unpackaged) file(s) found:
/usr/lib64/python3.11/lib-dynload/_curses.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/lib-dynload/_curses_panel.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/lib-dynload/_dbm.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/lib-dynload/_gdbm.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/lib-dynload/_sqlite3.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/lib-dynload/_tkinter.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/lib-dynload/readline.cpython-311-x86_64-linux-gnu.so
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/lib64/python3.11/lib-dynload/_curses.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/lib-dynload/_curses_panel.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/lib-dynload/_dbm.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/lib-dynload/_gdbm.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/lib-dynload/_sqlite3.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/lib-dynload/_tkinter.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/lib-dynload/readline.cpython-311-x86_64-linux-gnu.so
The content of SOURCES is:
baselibs.conf externally_managed.in macros.python3 python-3.3.0b1-fix_date_time_compiler.patch skip-test_pyobject_freed_is_freed.patch
bluez-devel-vendor.tar.xz F00251-change-user-install-location.patch no-skipif-doctests.patch python-3.3.0b1-localpath.patch subprocess-raise-timeout.patch
bpo-31046_ensurepip_honours_prefix.patch fix_configure_rst.patch PACKAGING-NOTES python-3.3.0b1-test-posix_fadvise.patch support-expat-CVE-2022-25236-patched.patch
bsc1221260-test_asyncio-ResourceWarning.patch idle3.appdata.xml pre_checkin.sh python.keyring
CVE-2023-27043-email-parsing-errors.patch idle3.desktop Python-3.11.9.tar.xz README.SUSE
CVE-2023-52425-libexpat-2.6.0-backport.patch import_failed.map Python-3.11.9.tar.xz.asc skip_if_buildbot-extend.patch
distutils-reproducible-compile.patch import_failed.py python311-rpmlintrc skipped_tests.py
Any ideas?
Thanks and Best Regards,
See in the files Section of the spec-file.
Hello,
%if %{with general}
%files -n %{python_pkg_name}-tk
%defattr(644, root, root, 755)
%{sitedir}/tkinter
%exclude %{sitedir}/tkinter/test
**%{dynlib _tkinter}**
in it.
~/rpmbuild/BUILDROOT
has
./python311-core-3.11.9-150600.1.5.x86_64/usr/lib64/python3.11/lib-dynload/_tkinter.cpython-311-x86_64-linux-gnu.so
in it.
Shouldn’t the %{dynlib _tkinter} entry in the files section put ./python311-core-3.11.9-150600.1.5.x86_64/usr/lib64/python3.11/lib-dynload/_tkinter.cpython-311-x86_64-linux-gnu.so into the RPM?
Best Regards,
The actual line in the .spec file is:
%{dynlib _tkinter}
without the **, these were ment to format the line here in the post.
Hello,
%if %{with general}
%files -n %{python_pkg_name}-tk
%defattr(644, root, root, 755)
%{sitedir}/tkinter
%exclude %{sitedir}/tkinter/test
%{dynlib _tkinter}
%{_libdir}/python3.11/lib-dynload/_tkinter.cpython-311-*.so
to the %files -n %{python_pkg_name}-tk section.
Still I get the
error: Installed (but unpackaged) file(s) found:/usr/lib64/python3.11/lib-dynload/_tkinter.cpython-311-x86_64-linux-gnu.so
Where have you got it from? general is not used anywhere as the value of flavor.
You are right, flavor “general” is not defined in pypthon311.spec
%global flavor base%{nil}
%if "%{flavor}" == "doc"
%define psuffix -documentation
%bcond_without doc
%bcond_with base
%bcond_with general
%endif
%if "%{flavor}" == "base"
%define psuffix -core
%bcond_with doc
%bcond_without base
%bcond_with general
%endif
%if "%{flavor}" == ""
%define psuffix %{nil}
%bcond_with doc
%bcond_with base
%bcond_without general
%endif
But calling rpmpuild both as
rpmbuild -ba pypthon311.spec (which should build “general” if I get this right)
or
rpmbuild -ba python312.spec --define “flavor base”
returns with the above mentioned errors.
One additional hint I get is:
The necessary bits to build these optional modules were not found:
_curses_panel
To find the necessary bits, look in configure.ac and config.log.
Checked 111 modules (31 built-in, 78 shared, 1 n/a on linux-x86_64, 0 disabled, 1 missing, 0 failed on import)
But I can’t really identify the root cause of this - and if this eventually leads to / is related to the “error: Installed (but unpackaged) file(s) found” messages I get.
is a typo.
I tested with python312.spec as well and do get the same errors.
Could the .spec files of the SRPMs potentially be flawed?
OK. I was able to build the RPMs:
I added
# binary parts
%dir %{sitedir}/lib-dynload
%{_libdir}/python3.11/lib-dynload/readline.cpython-311-*.so
%{_libdir}/python3.11/lib-dynload/_tkinter.cpython-311-*.so
%{_libdir}/python3.11/lib-dynload/_curses.cpython-311-*.so
%{_libdir}/python3.11/lib-dynload/_curses_panel.cpython-311-*.so
%{_libdir}/python3.11/lib-dynload/_sqlite3.cpython-311-*.so
%{_libdir}/python3.11/lib-dynload/_dbm.cpython-311-*.so
%{_libdir}/python3.11/lib-dynload/_gdbm.cpython-311-*.so
to the python3.11.spec file.
But having to do so, seems kind of odd.
Does this qualify to send send a note to bugs.suse.com ?
Best Regards,
This defaults to building without general so everything under
thorsten.henrici:
%if %{with general}
is skipped. You need
rpmbuild ... --with general
Building “base” is sufficient. The issue is / was, that both “general” and “base” didn’t build without modifying the .spec file.
After adding the missing files to the %files section of “base” the RPMs are building correctly now.
I just wonder if this isn’t a bug in the .spec file, as the package(s) should build just by issuing prmbuild -ba python311.spec, shouldn’t they?
Well …
Package is intended to be built in the clean environment. When you build base flavor without general, no Tk is installed by OBS, so no Tk bindings will be built and everything is OK.
You build on your own system with a lot of unexpected packages installed that normally would not be present. Yes, package SPEC file does not handle it. I presume it could (by conditionally choosing configure options or by cleaning out the make results). But as long as you are the only one who demands it, I’d say - do not waste developers time, implement and test these changes and submit SR. Or, better, use osc to build package in the same environment as developers.
And BTW, you posted this in OBS category while your question is not related to OBS in any way. It is general question about building a RPM package.
That’s correct. I had the assumption, that general questions about building RPMs are best put here. Sorry for the misunderstanding.
Could you advise on which forum would be the correct one?
Best Regards,
system
February 26, 2025, 7:02pm
18
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.