Hello Lubos, thanks for pushing this! Am Mittwoch, 16. März 2022, 07:49:48 CET schrieb Lubos Kocman: ....

We've unforked all pytest packages from Backports, which was a source of big pain but we still seem to have problems with mypy and python base https://build.opensuse.org/request/show/953761 but seems like we need to update quite some few packages on SLE side to meed dependencies.

unresolvable: nothing provides if, nothing provides %python-base < 3.8,

I had seen a similar issue before, and seem to remember that it was related to some basic packages (like python-setuptools, rpm-macros and similar). Can one check the status on the SLE side and push an upgrade? Leap 15.4 beta: python3-setuptools 44.1 (in TW: 58.3) python-rpm-macros seems to be up-to-date

nothing provides python3-importlib-metadata >= 4.6.1, (got version 1.5.0-3.3.5), nothing provides python3-pytest >= 6.2, (got version 5.4.3-150400.1.2), (got version 5.4.3-1.24 provided by python3-pytest5), (got version 4.6.9-3.3.4 provided by python3-pytest4), nothing provides python3-pytest-xdist >= 1.34, (got version 1.32.0-150400.1.2), nothing provides python3-virtualenv >= 20.6, (got version 16.1.0-1.13)

these should be manageable. I will check on the oS side of life.... Cheers Axel

Hello Matěj. Am Mittwoch, 16. März 2022, 20:19:10 CET schrieb Matěj Cepl:

Dne 16. 03. 22 v 15:36 Axel Braun napsal(a):

...

I had seen a similar issue before, and seem to remember that it was related to some basic packages (like python-setuptools, rpm-macros and similar). Can one check the status on the SLE side and push an upgrade?

If you need something changed on SLE side, please, let us know SOON, SP4 development is basically done.

It is difficult for me to judge which of the problems need to be solved first, but clearly the Python Stack on 15.4 is outdated. Even worse, as openSUSE Contributor I cant just fix things on the SLE side. From your experience, how could the error be resolved? is it the setuptools package (as first start)? Cheers Axel

Hi Axel, Am 16.03.22 um 15:36 schrieb Axel Braun:

...

unresolvable: nothing provides if, nothing provides %python-base < 3.8, I had seen a similar issue before, and seem to remember that it was related to some basic packages (like python-setuptools, rpm-macros and similar). Can one check the status on the SLE side and push an upgrade?

Leap 15.4 beta: python3-setuptools 44.1 (in TW: 58.3) python-rpm-macros seems to be up-to-date

There is still no prjconf definition for the "if" syntax found in the specfile. I have warned about this in various places. - https://bugzilla.opensuse.org/show_bug.cgi?id=1187473#c15 - https://bugzilla.opensuse.org/show_bug.cgi?id=1194422#c7 - Big fat warning box in https://en.opensuse.org/openSUSE:Packaging_Python#BuildRequires - https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org/messag... So again, one last time: Dear Leap/SLE 15.4 Python maintainers: You need the following section in the appropriate prjconf for the distribution: Macros: ## PYTHON MACROS BEGIN # adapted form of https://github.com/openSUSE/python-rpm-macros/blob/master/default-prjconf for SLE/Leap 15.4 # requires python-rpm-macros >= 20210204 %pythons %{?!skip_python3:python3} %add_python() %{expand:%%define pythons %1 %pythons} # This method for generating python_modules gets too deep to expand for rpm at about 5 python flavors. # Hence, python_module_iter is replaced by python_module_lua in macros.lua. # However, OBS cannot expand lua, but has a much higher expansion depth, so this works fine for the server side resolver. %python_module_iter(a:) %{expand:%%define python %{-a*}} ( %python-%args ) %{expand:%%{?!python_module_iter_%1:%%{python_module_iter -a%*}}%%{?python_module_iter_%1}} # pseudo-undefine for obs: reset for the next expansion within the next call of python_module %python_module_iter_STOP %global python %%%%python %python_module() %{?!python_module_lua:%{expand:%%define args %{**}} %{expand:%%{python_module_iter -a %{pythons} STOP}}}%{?python_module_lua:%python_module_lua %{**}} ## PYTHON MACROS END :Macros - Ben

Am 19.03.22 um 22:07 schrieb Axel Braun:

I'm getting closer, but I'm now stuck with a missing dependency: nothing provides python3-backports.entry_points_selectable >= 1.0.4

Leap 15.4 ships a python-backports version 4.0.0 https://pypi.org/project/backports/1.1/ The python-backports package in Leap 15.4 is just a namespace package. A remnant of old packaging errors it seems. And the version number is wrong, too.

https://build.opensuse.org/package/show/openSUSE:Leap:15.4/python-backports

- so what is it asking for?

The real backports.* packages are separate projects: https://pypi.org/search/?q=backports&o= It is asking for https://build.opensuse.org/package/show/devel:languages:python/python-backpo...

Am 21.03.22 um 10:47 schrieb Axel Braun:

With the prjconf settings and all dependencies I could finally buils python- tinydb and MyGNUHealth in Application:ERP:GNUHealth:Factory

Packages/versions (that still work with python 3.6) needed:

@Lubos - how do we now continue? SR from A:E:G:F into openSUSE:Backports:SLE-15-SP4? Do SLE maintainers care about this?

In case it is not obvious: The prjconf settings need to go into the projects as well. It is not enough to have them in A:E:G:F. They need to be accessible by the staging and at the final build of the GA. Since python-rpm-macros-20220106.80d3756 is in https://build.opensuse.org/package/show/SUSE:SLE-15-SP4:GA/python-rpm-macros, this one needs an update: https://build.opensuse.org/projects/SUSE:SLE-15-SP4:GA/prjconf Look at lines 121 through 132. They are outdated. The correct entry is: # PYTHON STUFF %define skip_python2 1 %define _without_python2 1 Macros: ## PYTHON MACROS BEGIN # adapted form of https://github.com/openSUSE/python-rpm-macros/blob/master/default-prjconf for SLE/Leap 15.4 # requires python-rpm-macros >= 20210204 %pythons %{?!skip_python3:python3} %add_python() %{expand:%%define pythons %1 %pythons} %_without_python2 1 # This method for generating python_modules gets too deep to expand for rpm at about 5 python flavors. # Hence, python_module_iter is replaced by python_module_lua in macros.lua. # However, OBS cannot expand lua, but has a much higher expansion depth, so this works fine for the server side resolver. %python_module_iter(a:) %{expand:%%define python %{-a*}} ( %python-%args ) %{expand:%%{?!python_module_iter_%1:%%{python_module_iter -a%*}}%%{?python_module_iter_%1}} # pseudo-undefine for obs: reset for the next expansion within the next call of python_module %python_module_iter_STOP %global python %%%%python %python_module() %{?!python_module_lua:%{expand:%%define args %{**}} %{expand:%%{python_module_iter -a %{pythons} STOP}}}%{?python_module_lua:%python_module_lua %{**}} ## PYTHON MACROS END :Macros # END PYTHON STUFF If you don't do it, you have to modify all the %{python_module .... if %python...} entries from specfiles submitted to openSUSE:Backports:SLE-15-SP4 such as https://build.opensuse.org/request/show/953761 And clean out https://build.opensuse.org/projects/openSUSE:Backports:SLE-15-SP4/prjconf ! - Ben

Am Montag, 21. März 2022, 21:32:14 CET schrieb Matěj Cepl:

Dne 21. 03. 22 v 10:47 Axel Braun napsal(a):

...

python-appdirs 1.4.4 python-backports.entry_points_selectable 1.1.1 python-importlib-metadata 4.10.1 python-iniconfig 1.1.1 python-mypy 0.941 python-mypy_extensions 0.4.3 python-packaging 21.3 python-platformdirs 2.4.0 python-py 1.11 python-pytest 6.2.5 python-pytest-isort 1.1.0 (fix build error for python-pydyf) python-pytest-mock 3.6.1 python-pytest-mypy 0.8.1 python-pytest-xdist 2.5.0 python-setuptools 58.3.0 python-setuptools_scm 6.4.2 python-sphinx-autodoc-typehints 1.12 python-virtualenv 20.13.3

And now remove from that project all packages which are already in SLE-15. There is just no way you would be allowed to upgrade setuptools packaging, mypy, importlib-metadata, or pytest, or anything else which is already in SLE-15. What exact reasons you have for these upgrades?

The versions in SLE are simply too old!

Could you patch around them?

Maybe you can, I cant (beyond my skills I would say) Axel

Dne 21. 03. 22 v 22:02 Matěj Cepl napsal(a):

Then GNUHealth won't be in Leap, if it cannot be ported to libraries there.

I am sorry about that.

BTW, why do you even bother with 15.3? 15.4 is lurking behind a curtain and it would be probably much easier to port it there. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Be kind, for everyone you meet is fighting a hard battle. -- Ian MacLaren

We can always make SRs against SLE packages via SUSE:SLE "mirrored proejcts" in OBS (see relevant list of origins bellow). Simply sr them against particular SUSE:SLE-15* project in OBS, I can mirror them with osc jumpreview into IBS. You'd need to reference jsc#SLE-23990 (our request in Jira to add tinydb) in the SR text, or it will be rejected. But this is one of the last Feature releases we'll have. If Matej sees a way in (not a complete backwards incompatible breakage), then I can talk to Product Management about our usecase. I'm not really concerned about these old packages from SP0 GA etc, that are let's say forgotten, but about big jumps in packages we regularly update (typically these from SP4) Current origin of packages. We should always make SR to relevant :Update project instead of GA. There is an issue with sr to SUSE:SLE-15-SP4:Update at the moment, there just ping me with SR and I can do it for you manually. And we should not push any changes to SP:GA unless we're talking P1/P2 bugs or persuade PM/SLE Release Manager.  We can always make SP4:Update request and ask for release with SP4 GA to make it available. That would also imply that mygnuhealth has to be released as maint update to Leap or we'd have to temporarily fork that packages. I'm also "willing to go this road", as long as we have commitment from SLE side to take it with GA timeframe. SLE Package origins: python-appdirs SUSE:SLE-15:GA python-importlib-metadata SUSE:SLE-15-SP1:Update python-packaging SUSE:SLE-15-SP2:GA python-py SUSE:SLE-15-SP1:Update python-pytest SUSE:SLE-15-SP4:GA python-pytest-isort SUSE:SLE-15-SP1:Update python-pytest-mock SUSE:SLE-15-SP1:Update python-pytest-xdist SUSE:SLE-15-SP4:GA python-setuptools SUSE:SLE-15-SP4:GA python-virtualenv SUSE:SLE-15-SP1:GA Rest seems to be in Backports, there I'd be supportive as long as it builds. Axel Braun píše v Po 21. 03. 2022 v 21:37 +0100:

Am Montag, 21. März 2022, 21:32:14 CET schrieb Matěj Cepl:

...

Dne 21. 03. 22 v 10:47 Axel Braun napsal(a):

...

python-appdirs 1.4.4 python-backports.entry_points_selectable 1.1.1 python-importlib-metadata 4.10.1 python-iniconfig 1.1.1 python-mypy 0.941 python-mypy_extensions 0.4.3 python-packaging 21.3 python-platformdirs 2.4.0 python-py 1.11 python-pytest 6.2.5 python-pytest-isort 1.1.0 (fix build error for python-pydyf) python-pytest-mock 3.6.1 python-pytest-mypy 0.8.1 python-pytest-xdist 2.5.0 python-setuptools 58.3.0 python-setuptools_scm  6.4.2 python-sphinx-autodoc-typehints 1.12 python-virtualenv 20.13.3

And now remove from that project all packages which are already in SLE-15. There is just no way you would be allowed to upgrade setuptools packaging, mypy, importlib-metadata, or pytest, or anything else which is already in SLE-15. What exact reasons you have for these upgrades?

The versions in SLE are simply too old!

...

Could you patch around them?

Maybe you can, I cant (beyond my skills I would say) Axel

-- Best regards Lubos Kocman openSUSE Leap Release Manager

Am Dienstag, 22. März 2022, 01:55:36 CET schrieb Simon Lees:

On 3/22/22 07:07, Axel Braun wrote:

...

Am Montag, 21. März 2022, 21:32:14 CET schrieb Matěj Cepl:

...

Dne 21. 03. 22 v 10:47 Axel Braun napsal(a):

...

python-appdirs 1.4.4 python-backports.entry_points_selectable 1.1.1 python-importlib-metadata 4.10.1 python-iniconfig 1.1.1 python-mypy 0.941 python-mypy_extensions 0.4.3 python-packaging 21.3 python-platformdirs 2.4.0 python-py 1.11 python-pytest 6.2.5 python-pytest-isort 1.1.0 (fix build error for python-pydyf) python-pytest-mock 3.6.1 python-pytest-mypy 0.8.1 python-pytest-xdist 2.5.0 python-setuptools 58.3.0 python-setuptools_scm 6.4.2 python-sphinx-autodoc-typehints 1.12 python-virtualenv 20.13.3

And now remove from that project all packages which are already in SLE-15. There is just no way you would be allowed to upgrade setuptools packaging, mypy, importlib-metadata, or pytest, or anything else which is already in SLE-15. What exact reasons you have for these upgrades?

The versions in SLE are simply too old!

This really doesn't tell us anything, what we need to know is "Why are they too old?" Some upstreams set there minimum version requirements based on what they test, in which case they may not actually be too old and we are fine. Some upstreams bump the minimum version because they know there are bugs that are fixed in the newer versions, in which case in most cases we can just backport the bugfixes to the older versions without too much issue.

My procedure was to determine the unresovleables, and from there take the latest available version, resp, the latest version that supports Python 3.6 Your proposal is to take the least required version. Is this approach better? Not necessarily. You miss fixes and new functionality. Is it less effort? Maybe. For your convenience, I have disabled all builds for the mentioned packages and cleaned out the binaries, so we are back at start: python-tinydb: nothing provides python3-pytest-mypy python-pytest-mypy (0.8.1): nothing provides python3-mypy >= 0.900, (got version 0.670 provided by mypy) nothing provides python3-mypy_extensions >= 0.4.3 needed by python3-mypy, (got version 0.4.1-bp154.1.9) python3-mypy_extensions (0.4.3) (builds) pyton3-mypy (0.941): nothing provides python3-importlib-metadata >= 4.6.1, (got version 1.5.0-3.3.5), nothing provides python3-pytest >= 6.2, (got version 5.4.3-150400.1.2), (got version 5.4.3-1.24 provided by python3-pytest5), (got version 4.6.9-3.3.4 provided by python3-pytest4), nothing provides python3-pytest-xdist >= 1.34, (got version 1.32.0-150400.1.2), nothing provides python3-virtualenv >= 20.6, (got version 16.1.0-1.13) And so on. If you let me know your user in OBS, I add you as maintainer and you can try to find out the lowest needed version (branch-in packages with different name) Cheers Axel

In many cases they might actually use newer features in some cases we might still be able to backport these although it would have been much easier for that to be done pre beta. In other cases we might need to modify MyGNUHealth to work with older versions but we need to know where those places are. Taking the simplest set of packages pytest as an example, presumably with the older version of the pytest packages most test will pass and a few will fail, so if you now remove just the newer pytest packages it will be easy to see which tests these are and we will probably just have to live with skipping those parts of the test suite.

Next try building against the older setup tools and tell us what / how it fails. There is a decent chance we can find a way to work around whatever fails while we can't work around "Its simply too old". python-setuptools has been able to build packages for year so I don't see how using an older version will make that not possible it might just be slightly harder.

After that we can look at how we resolve the other packages which may or may not be harder.

...

...

Could you patch around them?

Maybe you can, I cant (beyond my skills I would say)

I can probably help to some level here but you'll need to start with the stuff above so I have a decent idea of what i'm looking at.

Hi, Am 16.03.22 um 07:49 schrieb Lubos Kocman:

I can help with mirroring SRs to SUSE:SLE side, as the pytest packages really need to be updated on the SLE side. Project management is willing to take changes in to make sure we have a succesful story with latest GNU Health/MyGNUHealth as long as we reference jsc#SLE-23990 in SR text.

Am 22.03.22 um 08:50 schrieb Axel Braun:

python-tinydb: nothing provides python3-pytest-mypy

python-pytest-mypy (0.8.1): nothing provides python3-mypy >= 0.900, (got version 0.670 provided by mypy) nothing provides python3-mypy_extensions >= 0.4.3 needed by python3-mypy, (got version 0.4.1-bp154.1.9) python3-mypy_extensions (0.4.3) (builds)

pyton3-mypy (0.941): nothing provides python3-importlib-metadata >= 4.6.1, (got version 1.5.0-3.3.5), nothing provides python3-pytest >= 6.2, (got version 5.4.3-150400.1.2), (got version 5.4.3-1.24 provided by python3-pytest5), (got version 4.6.9-3.3.4 provided by python3-pytest4), nothing provides python3-pytest-xdist >= 1.34, (got version 1.32.0-150400.1.2), nothing provides python3-virtualenv >= 20.6, (got version 16.1.0-1.13)

And so on.

I don't think you need mypy at all. It is a static typing checker and is not used by GNUHealth or any of its dependencies during runtime. Just skip the typing checks in tinydb. That should clear out your requirment chain quite a bit. - Ben

Am 22.03.22 um 09:48 schrieb Simon Lees:

Yeah so the next step would be to just require everything without the version numbers, but I agree with Ben and we should probably try and make tinydb work without pytest-mypy as a starting point.

Easy. https://build.opensuse.org/request/show/963857 If you have to go through openSUSE:Factory: https://build.opensuse.org/request/show/963862

Am 22.03.22 um 15:15 schrieb Axel Braun:

Indeed, yes, Thanks for your help. So I guess you are submitting the latest tinydb into Leap 15.4 and I clean up the pending (and now uneeded) SR

The necessary tinydb update is on its way into openSUSE:Factory: https://build.opensuse.org/request/show/963919 Please monitor it and submit it from there into the correct 15.4 repo yourself (or Lubos, Matej, Simon, ...). I have no interest in 15.4. Too many obstacles thrown into my (and your) attempts to support a decent Python stack. - Ben