Packaging ansible-builder for SLES15 with python310: How to properly build subunit (aka python310-subunit) for SLES15 using the Python3-SLE-Module?
Hi all, ansible-builder pulls in python-subunit somewhere in the chain. As I am already building the other ansible-* tools for Leap 15 / SLES15 using the Python3-SLE-Module, I tried packaging ansible-builder too. I managed to get subunit (branched from Factory) to build. But only because I butchered it. :-) Forgot for now that I had to disable the %checks. I added a BuildRequires for the python base module, as the configure step did not find a proper python interpreter. (The project is setup to only build against python3.10, as most of the tools require something a lot newer than 3.6. So no python3.6 is installed at first). But that did not help. It still complained, although /usr/bin/python3.10 was existing. I guess it is looking for something called "python3". So I also added python3-base. Which made the configure happy, but that somehow feels wrong. I want to avoid that somehow python3.6 is being used for building this package. What would be the proper way? Patch the configure step to accept the python3.10 executable? I know that is not something usual, but to not interfere with the standard python installation python3.10 does not provide /usr/bin/python3 and I am fine with that. I just would like to avoid errors in this package. Thanks in advance! Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi again, Am 21.03.23 um 17:05 schrieb Johannes Kastl:
Hi all,
ansible-builder pulls in python-subunit somewhere in the chain. ...
It still complained, although /usr/bin/python3.10 was existing. I guess it is looking for something called "python3".
subunit or ansible-builder?
So I also added python3-base. Which made the configure happy, but that somehow feels wrong. I want to avoid that somehow python3.6 is being used for building this package.
What would be the proper way? Patch the configure step to accept the python3.10 executable?
Decent configuration systems have a way to provide the path to the python executable and libraries/headers (from python3X-devel). Sometimes it is enough to provide PYTHON=/usr/bin/python3.10 or similar. If that is not the case yet, consider adding a patch and submit it upstream.
I know that is not something usual, but to not interfere with the standard python installation python3.10 does not provide /usr/bin/python3 and I am fine with that. I just would like to avoid errors in this package.
Thanks in advance! Johannes
- Ben
Good morning Ben, On 21.03.23 at 20:24 Ben Greiner wrote:
Am 21.03.23 um 17:05 schrieb Johannes Kastl:
It still complained, although /usr/bin/python3.10 was existing. I guess it is looking for something called "python3".
subunit or ansible-builder?
subunit.
So I also added python3-base. Which made the configure happy, but that somehow feels wrong. I want to avoid that somehow python3.6 is being used for building this package.
What would be the proper way? Patch the configure step to accept the python3.10 executable?
Decent configuration systems have a way to provide the path to the python executable and libraries/headers (from python3X-devel). Sometimes it is enough to provide PYTHON=/usr/bin/python3.10 or similar. If that is not the case yet, consider adding a patch and submit it upstream.
OK, I'll have a look, thanks. Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi Ben, hi Dirk, On 22.03.23 at 07:05 Johannes Kastl wrote:
Decent configuration systems have a way to provide the path to the python executable and libraries/headers (from python3X-devel). Sometimes it is enough to provide PYTHON=/usr/bin/python3.10 or similar. If that is not the case yet, consider adding a patch and submit it upstream.
I may have missed it in the large number of macros, but is there a macro that contains the paths like /usr/bin/python3.10? One that is set based on the %pythons definition? Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Good morning, On 22.03.23 at 07:54 Johannes Kastl wrote:
On 22.03.23 at 07:05 Johannes Kastl wrote:
Decent configuration systems have a way to provide the path to the python executable and libraries/headers (from python3X-devel). Sometimes it is enough to provide PYTHON=/usr/bin/python3.10 or similar. If that is not the case yet, consider adding a patch and submit it upstream.
I may have missed it in the large number of macros, but is there a macro that contains the paths like /usr/bin/python3.10? One that is set based on the %pythons definition?
The best I could come up with was using export PYTHON=/usr/bin/python%{python_version} Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Am 24.03.23 um 07:07 schrieb Johannes Kastl:
Good morning,
On 22.03.23 at 07:54 Johannes Kastl wrote:
On 22.03.23 at 07:05 Johannes Kastl wrote:
Decent configuration systems have a way to provide the path to the python executable and libraries/headers (from python3X-devel). Sometimes it is enough to provide PYTHON=/usr/bin/python3.10 or similar. If that is not the case yet, consider adding a patch and submit it upstream.
I may have missed it in the large number of macros, but is there a macro that contains the paths like /usr/bin/python3.10? One that is set based on the %pythons definition?
The best I could come up with was using export PYTHON=/usr/bin/python%{python_version}
Don't do this. You never really know what the flavor-agnostic %python_version might be by default. https://github.com/openSUSE/python-rpm-macros#flavor-specific-macros There are a couple of options: If you have just python310, nothing else: export PYTHON=%__python310 If you iterate of multiple flavors in %pythons: %{python_expand # iterate over all flavors in buildset. Special macro handling of "$python"! # $python is python3.10 here export PYTHON=$(command -v $python) # $python is python310 here export PYTHON=%{__$python} # Do your configure and build steps inside the expand make }
Kind Regards, Johannes
- Ben
Hi Ben, On 24.03.23 at 10:22 Ben Greiner wrote:
Am 24.03.23 um 07:07 schrieb Johannes Kastl:
The best I could come up with was using export PYTHON=/usr/bin/python%{python_version}
Don't do this. You never really know what the flavor-agnostic %python_version might be by default.
If you have just python310, nothing else: export PYTHON=%__python310
If you iterate of multiple flavors in %pythons: %{python_expand # iterate over all flavors in buildset. Special macro handling of "$python"! # $python is python3.10 here export PYTHON=$(command -v $python) # $python is python310 here export PYTHON=%{__$python} # Do your configure and build steps inside the expand make }
I am not sure what is needed for subunit. It is not a pure python package, but has python subpackages:
https://build.opensuse.org/project/show/home:ojkastl_buildservice:branches:d...
https://build.opensuse.org/package/rdiff/home:ojkastl_buildservice:branches:...
To me it looked like the configure only runs once. And apparently it picks python3 on Tumbleweed, so I daresay it is enough that it finds a python, but it does not fail if it is "the wrong one".
%configure \ --enable-shared \ --disable-static
%make_build %pyproject_wheel
I will gladly rework the SR, no problem. Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Am 24.03.23 um 13:19 schrieb Johannes Kastl:
I am not sure what is needed for subunit. It is not a pure python package, but has python subpackages:
https://build.opensuse.org/project/show/home:ojkastl_buildservice:branches:d...
https://build.opensuse.org/package/rdiff/home:ojkastl_buildservice:branches:...
To me it looked like the configure only runs once. And apparently it picks python3 on Tumbleweed, so I daresay it is enough that it finds a python, but it does not fail if it is "the wrong one".
%configure \ --enable-shared \ --disable-static
%make_build %pyproject_wheel
I will gladly rework the SR, no problem.
I see now. The problems don't arise from the python subpackages but from the configuration of the non-python stuff. Any python3 interpreter will be good for it. export PYTHON=$(find %_bindir -name 'python3*[0-9]' -print -quit) The wheel and installed python subpackages (%files %{python_files python-%{name}}) are pure python. Nothing to configure there, no need to have it in the same expand iteration as the configure.
Kind Regards, Johannes
- Ben
On 24.03.23 at 19:09 Ben Greiner wrote:
I see now. The problems don't arise from the python subpackages but from the configuration of the non-python stuff. Any python3 interpreter will be good for it.
export PYTHON=$(find %_bindir -name 'python3*[0-9]' -print -quit)
The wheel and installed python subpackages (%files %{python_files python-%{name}}) are pure python. Nothing to configure there, no need to have it in the same expand iteration as the configure.
Perfect, thanks. https://build.opensuse.org/request/show/1074251 -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
participants (2)
-
Ben Greiner -
Johannes Kastl