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. 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. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B