Am Donnerstag, 8. Juni 2023, 10:08:20 CEST schrieb Daniel Garcia:

...

In addition, only 311 Python is built with Suse projectconfig. This means that no upgrade from 15.4 to 15.5 would work.

What do I have to enter in my projectconfig so that 15.4 is built and that 3.6 and 3.11 are built for 15.5?

Can anyone help me?

The only change is the new macro to build for modern python. The idea is to try to make it easier to build packages from tumbleweed in 15.4 and newer, but that will be with python3.11.

To build for python3.6, you can override the macro in your custom project or modify the .spec file to remove the macro call.

What we're doing in SLES15-SP4 is to "rename" python 3.6 packages from python-foo to python3-foo, and those packages doesn't have the %sle15_python_module_pythons, so the new packages are similar to what we've in the openSUSE:Factory project.

Hello, first of all thank you for the quick answer. What you describe, customize ProjectConfig or psec, I have now already done for 15.4. But I had to do that after the new macro %sle15_python_module_pythons() was introduced. But what you describe does not work for packages I need for 15.4 and 15.5. Hence my question. What do I have to do to build the same Python package in the following way: For Leap 15.4 only as python3, so with python3.6. For Leap 15.5 as python3 and as pyton311 package. Because only then I can upgrade from Leap 15.4 to 15.5. Or is there any other way I can do this? Have now adjusted my ProjectConfig like this: %if "%_repository" == "15.3" || "%_repository" == "15.4" || "%_repository" == "openSUSE_Leap_15.3" macros: %sle15_python_module_pythons() %global pythons python3 macros %endif so without 15.5. But it doesn't work 100%. Because in 15.5 python311 is built, but not python3. But I need both versions for a clean upgrade. Maybe someone here has a tip? I can't be alone with this problem? I have about 100s of python packages. And I never had such an upgrade problem until now. And I have been doing my update for about decades in the following or similar way: sudo zypper --releasever=15.5 dup -d sudo zypper --releasever=15.5 dup I have never had a problem with this. And certainly not such a serious one. Does anyone else have this problem? And maybe has a solution? Greetings Eric

Am Donnerstag, 8. Juni 2023, 11:13:11 CEST schrieb Daniel Garcia:

On jue, 2023-06-08 at 10:59 +0200, Eric Schirra wrote:

...

Because in 15.5 python311 is built, but not python3. But I need both versions for a clean upgrade. Maybe someone here has a tip? I can't be alone with this problem?

You can find also another macro in the project config [1], that's %sle15allpythons so if you use that one, the package will be built for python311 and python3, the same python module.

[1] https://build.opensuse.org/projects/SUSE:SLE-15-SP4:Update/prjconf

Okay. Thanks. I will give it a try. Do I have to put %sle15allpythons() in all spec then? And if so, do I need to include it in addition to %sle15_python_module_pythons() or instead of %sle15_python_module_pythons()? Regards Eric

Am Donnerstag, 8. Juni 2023, 12:14:47 CEST schrieb Daniel Garcia:

You can use one or another macro, not both at the same time. * %sle15_python_module_pythons: is to build just for python3.11 * %sle15allpythons: is to build for python3.6 and python3.11

So if a .spec contains the second macro, OBS will produce python3-foo.rpm and python311-foo.rpm.

At the end these macros just set the %pythons define, so by default it's "python3", but sle15_python_module_pythons set it to be "python311" and sle15allpythons set it to "python311 python3".

So if you need to build for a different python, you can override this macro, in your project or even don't use any of these macros and just set the pythons that you need in every .spec file, something like "%global pythons pythonX pythonY pythonZ"

The idea to use the macros instead of direct python version is to be able to adapt in the future, if we change the python version, we'll just need to change the macro and not every package, and it can be modified at project level for customization.

Okay. Have now played around a little and tried. Have now in my spec files only the following: %if 0%{?sle_version} == 150500 && 0%{?is_opensuse} %{?sle15allpythons} %endif Means for 15.4 python3.6 will be built, for 15.5 36 and 3.11 and for Tumbleweed 3.9, 3.10 and 3.11. But for me this means that you don't need any macro for 15.4. For 15.5 sle15allpythons and for Tumbleweed also none. Is that correct? I have to use the above if-loop, because otherwise I get an error when building 15.4. But 15.5 and Tumbleweed build. Is this also correct? Then one last question. How do I prevent a build conflict in my repo when there is an update in the devel project? Then it says in the devel spec: %{?sle15_python_module_pythons} and in mine: %if 0%{?sle_version} == 150500 && 0%{?is_opensuse} %{?sle15allpythons} %endif Sorry if I'm being annoying but would you still answer these questions for me? Regards Eric

Am Mittwoch, 14. Juni 2023, 19:53:58 CEST schrieb Johannes Kastl:

Hi Eric,

On 14.06.23 at 15:32 Eric Schirra wrote:

...

Then one last question. How do I prevent a build conflict in my repo when there is an update in the devel project?

I am not sure if I fully understood your problem, but my approach would be to **not*** touch hundreds of packages, but handle this on repository level in the prjconf.

I.e. set sle15_python_module_pythons to the desired list of pythons you want to build against. Assuming all packages have the sle15_python_module_pythons macro in their spec.

Or did I miss a part in the thread?

Sorry, yes. :-) The macro sle15_python_module_pythons is already entered in the ProjektConf by Suse. You just don't see it. It is in a "hidden area" of the ProjectConf. But you can read it via the console and with OSC. And the is already on python3.11 But only on 3.11. You can see this when you create a new project and build a Python package in it. This is then pyton3.11-* and not python3-*. If you want to build multiple versions, like Tumbleweed, you need %{? sle15allpythons}, which is set to python3 and python3.11. Also in the "hidden area". But you can "overwrite" it. So if I want to build a package for 15.5, then that is a python3.11 package. The default packages for 15.5 are still python3.6. I don't understand the complete sense behind this either. Why didn't they just do the configuration like Tumbleweed or at least like we did with %{?sle15allpythons}. But the whole thing was not my question. My question was about what happens in my packages, with my change using %{? sle15allpythons}, when the source pact gets an update. Regards Eric

Am Donnerstag, 15. Juni 2023, 08:42:15 CEST schrieb Johannes Kastl:

Good morning Eric,

On 14.06.23 at 20:54 Eric Schirra wrote:

...

The macro sle15_python_module_pythons is already entered in the ProjektConf by Suse. You just don't see it. It is in a "hidden area" of the ProjectConf. But you can read it via the console and with OSC. And the is already on python3.11 But only on 3.11.

But you can just overwrite it in your project's prjconf? And set whatever python versions you want?

I wanted to keep building for 3.10 until 3.11 is fully usable. Hence I set it in

If I understood it correctly, you would have to use the %{?sle15allpythons}. The macro %{?sle15_python_module_pythons} builds only one version. In the case of Leap 15.5, this is 3.11. But I am not sure about that either. I also still don't understand why you can't just build all python versions, like with Tumbleweed. Regards Eric

Am Freitag, 16. Juni 2023, 09:07:29 CEST schrieb Daniel Garcia:

...

The macro %{?sle15_python_module_pythons} builds only one version. In the case of Leap 15.5, this is 3.11.

But I am not sure about that either.

I also still don't understand why you can't just build all python versions, like with Tumbleweed.

The macro %{?sle15_python_module_pythons} defaults to "%global pythons python311" in Leap15.4 and it's empty in TW. %pythons is "python3" in Leap 15.4 and "python39 python310 python311" in TW. This macro is just to override the default "%pythons", so if you've a custom project and want to build for something different you can just override this macro in the project configuration.

For example: %sle15_python_module_pythons() %global pythons python311 python310 python3

Will build all packages with that macro for python311, python310 and python3 in your project.

This macro is there to make it easy to build modern packages for different python versions in SLES and Leap, without touching stable packages, so the "%pythons" macro is not modified at project level.

Okay. Thank you for the explanation. Do I understand it correctly then? If the spec of the python package contains %{?sle15_python_module_pythons}, then I don't need to modify the spec file if I need the package for python3 and python3.11. Instead, I adjust my ProjectConfig as follows: %sle15_python_module_pythons() %global pythons python311 python3 Right? Regards Eric

Am Freitag, 16. Juni 2023, 11:37:19 CEST schrieb Daniel Garcia:

...

Do I understand it correctly then? If the spec of the python package contains %{?sle15_python_module_pythons}, then I don't need to modify the spec file if I need the package for python3 and python3.11.

Instead, I adjust my ProjectConfig as follows:

%sle15_python_module_pythons() %global pythons python311 python3

Right?

Yes, that's correct

This solution would also have been too nice. But unfortunately this does not work with the vast majority of packages (about 80%). If one has in his ProjectConf: %sle15_python_module_pythons() %global pythons python311 python3 and is in the spec of the package: BuildRequires: %{python_module devel >= 3.7} or BuildRequires: %{python_module base >= 3.7} Then only not the python3 package is not built, but unfortunately the complete package. So no python 3.11 package will be built either. And so the above solution is not usable. So what else can I do to build python3 and python3.11 under 15.5? And if version 3.7 is required in the spec, that then only the python3.11 version is built and the python3 is ignored? Is there also a solution for this that I may not know? Regards Eric

On 16.06.23 at 11:16 Eric Schirra wrote:

...

Do I understand it correctly then? If the spec of the python package contains %{?sle15_python_module_pythons},

Am Freitag, 16. Juni 2023, 13:02:59 CEST schrieb Johannes Kastl: then I don't need to modify the spec

...

file if I need the package for python3 and python3.11.

Instead, I adjust my ProjectConfig as follows:

%sle15_python_module_pythons() %global pythons python311 python3

Yes!

That's what I wanted to tell, but obviously did not get the wording right.

Unfortunately, it doesn't always work that way. Or rather not most of the time. Please read my other contribution. But maybe you have a solution? Regards Eric