Opensuse 15.6 issues before it is released

English Forums Feedback
1

First of all i understand that 15.6 is in alpha, that is part of why i am right this now. Hopefully it can be fixed before release.
Second, Suse leap is my favorite distro, because of a number of reasons.(desktop behavior, colour scheme, YAST) and most of the way it is.

However OpenSUSE leap or tumbleweed has a major flaw that is (to be blunt) pissing me off. Every library and piece of software available in alpha is already obsolete.
I tried to install one of my favorite reverse engineering pieces of software “PINCE” but i can’t because every required package version in the repo is obsolete, or doesn’t exist under suse.
eg.
Req package version | Opensuse available version
PyQt6==6.6.0 || Leap15.6 version 6.4.2(obsolete)
PyQt6-Qt6==6.6.0
pexpect==4.9.0 || Leap15.6 version 4.8.0(obsolete)
distorm3==3.5.2 || Leap15.6 version 3.4.2(obsolete)
keystone-engine==0.9.2 || No package available
pygdbmi==0.11.0.0 || No package available
keyboard==0.13.5 || No Package available
pygobject==3.46.0 || No Package available

And that’s just 1 program.
There are dozens of packages i use and they either don’t exist on suse or are obsolete versions.
Even Tumbleweed has this issue.
Opensuse MUST have lastes version to be viable, Even under leap.

2

@Linrox Hi, that’s how Leap works (stability, bug fixes and security updates)… however since it’s still Alpha, there may be some leeway for updates, but that’s something your going to have to do (as in branch/update/submit) or ask the package maintainer(s), for missing ones

Also some packages your looking for are not necessarily named pyfoo it might be python311-[py]foo…

3

May I change your demand to –

The latest tested and verified package version.

Please be aware of, the Open Build Service and the openSUSE Build Service.
<https://openbuildservice.org/>
<https://build.opensuse.org/>

And, openQA – <https://open.qa/>.

If you really want to have the very latest untested and not verified version of a package then, you’re free to build it yourself by means of the openSUSE Build Service but, pleas, be aware that, if you haven’t written any test cases then, you’ll be accepting the quality of the package offered “as is” …

4

Thanks for the reply.
I am not a dev, don’t know enough about the backend to program to fix any of these issues.
Just annoyed that a real great distro that i have used since its beginnings (9.0) is satisfied with using obsolete versions even in alpha.
I know leap is going the way of the dinosaurs, guess if i want a up to date distro i should look else where.

5

@Linrox Maybe MicroOS, Aeon or Kapla is an alternative?

6

I don’t think these would work for me, as they are just renamed versions. I enjoy the amount of customization that leap has.
As i mentioned, I loved everything about leap, except the obsolete nature of it.
I have been using kubuntu for the last 18 months and while it was EOL 6 months ago it is still more up to date than leap 15.6.
I just don’t like that kubuntu has no yast and does not use the root user the same.
I am currently look into Mageia 9. But it does not appear to be up to date either.
Guess i will keep looking.

7

@Linrox No, different releases, immutable filesystem, use flatpaks and distrobox… they trach Tumbleweed, or maybe even Tumbleweed Slowroll…

8

“I know leap is going the way of the dinosaurs,”…
Not commenting your problem, but is Leap really going away?

https://news.opensuse.org/2024/01/15/clear-course-is-set-for-os-leap/
https://news.opensuse.org/2024/01/19/clarifying-misunderstandings-of-slowroll/

9

@rogerf Leap as it is now, yes, there may be a Leap 15.7. The proposed Leap 16 will be different, but that’s way in the future so who knows what it will be like…

Enjoy Leap 15.6 and remember to have fun!

10

It’s a feature, not a bug. Examples you give are one or two minor versions behind, I would certainly not call that obsolete. In return you get enterprise grade stability.

It seems like Tumbleweed is a better match for your needs, where you do get bleeding edge versions. As for scripting languages, I recommend rolling your own local package tree. All languages allow for user-level installation of packages (R: install.packages, perl: cpanm, python: pip, …).

11

True and it wouldn’t be an issue if it didn’t stop programs from compiling/working.

 ERROR: Could not find a version that satisfies the requirement PyQt-builder<2,>=1.15 (from versions: 1.0.0, 1.0.1, 1.1.0, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.9.1, 1.10.0, 1.10.1, 1.10.2, 1.10.3, 1.11.0, 1.12.0, 1.12.1, 1.12.2)
  ERROR: No matching distribution found for PyQt-builder<2,>=1.15

This wouldn’t be so annoying if it could be easily fixed, but it happens with programs after every reinstall of leap.

As for using Tumbleweed, I stopped using opensuse because of another issue.
Everytime i updated, Something would break.

Before i changed to kubuntu 22.10 i was on leap 15.4. I had only just finished reinstalling leap and getting the look just right. The next day my system updated and when it rebooted it failed. from what i could tell the system had been corrupted after the update. I thought it might be a unlucky fluke so i tried again, reinstalled, updated, corrupted. That’s when i changed distro’s
The time before that, the update kill several programs, because file version where no longer compatible.This is what usually happens, fixing a system after every update is not fun.

So if that happens on LEAP which is meant to be stable, why would i want to use tumbleweed when it updates everyday or even several times a day.
I would prefer using my system, not fixing it after every update.

And Tumbleweed might say bleeding edge, but when i first tried it (15.1) it was still causing issues with old revisions.

12

I understand that this is inconvenient. As mentioned, I would recommend using pip in this case. This allows you to satisfy the exact dependencies of your project.

13

You seem to be complaining about a Python PyQt version issue.
But, you’ve mentioned the following:

I am not a dev, don’t know enough about the backend to program to fix any of these issues.

So, what’s going on here?

I suspect that, you’re pulling Python scripts from somewhere and then, attempting to execute them.

  • It would be better if, you could, possibly, be more specific …

So, now, check with supplier of the scripts you’re grabbing from wherever and, check the required PyQt version.

It’s now going to get bad, really bad and, wild – really wild –

Looking in that repository directory, there’re packages in there for the upcoming KDE Plasma 6 (Qt6) and, the current KDE Plasma 5 (Qt5) –

There is however, one thing I’m having difficulty with –

  • KDE Plasma 6 – with Qt6 – is “work in progress”.
  • Most of the Python PyQt libraries are for PyQt6 – presumably preparation for the future KDE Plasma 6 …

So, you’ve admitted that, you’re not a developer but, you’ve found some Python PyQt scripts somewhere which seem to have been prepared for a future version of KDE Plasma …

  • Please be aware that, the future is just that: the future …
14

@Linrox:

Taking the PyQt issue further, there’s this post in the KDE Discuss Forum: <https://discuss.kde.org/t/new-programming-language-needed-for-kde/9728/44>

16

As mentioned further up, this is from the pince project on github. Not just a random py script.
I have tried to help the dev of this project by test his pince program on leap versions 15.5 and now leap 15.6.

With the devs help i managed to updated 15.6 alpha to pyqt6.6.0 without issue.

Requirement already satisfied: PyQt6-Qt6==6.6.0 in ./.venv/PINCE/lib64/python3.11/site-packages (from -r requirements.txt (line 2)) (6.6.0)
Requirement already satisfied: pexpect==4.9.0 in ./.venv/PINCE/lib64/python3.11/site-packages (from -r requirements.txt (line 3)) (4.9.0)
Requirement already satisfied: distorm3==3.5.2 in ./.venv/PINCE/lib64/python3.11/site-packages (from -r requirements.txt (line 4)) (3.5.2)
Requirement already satisfied: keystone-engine==0.9.2 in ./.venv/PINCE/lib64/python3.11/site-packages (from -r requirements.txt (line 5)) (0.9.2)
Requirement already satisfied: pygdbmi==0.11.0.0 in ./.venv/PINCE/lib64/python3.11/site-packages (from -r requirements.txt (line 6)) (0.11.0.0)
Requirement already satisfied: keyboard==0.13.5 in ./.venv/PINCE/lib64/python3.11/site-packages (from -r requirements.txt (line 7)) (0.13.5)
Requirement already satisfied: pygobject==3.46.0 in ./.venv/PINCE/lib64/python3.11/site-packages (from -r requirements.txt (line 8)) (3.46.0)
Requirement already satisfied: PyQt6-sip<14,>=13.6 in ./.venv/PINCE/lib64/python3.11/site-packages (from PyQt6==6.6.0->-r requirements.txt (line 1)) (13.6.0)
Requirement already satisfied: ptyprocess>=0.5 in ./.venv/PINCE/lib64/python3.11/site-packages (from pexpect==4.9.0->-r requirements.txt (line 3)) (0.7.0)
Requirement already satisfied: pycairo>=1.16.0 in ./.venv/PINCE/lib64/python3.11/site-packages (from pygobject==3.46.0->-r requirements.txt (line 8)) (1.25.1)

Guess the dev of the project was more helpful in fixing the pyqt version issue.
While i might not be a dev, if someone wanted to actually help, then there is no issue, even without a dangerous repo change.

@sboehringer And Thank you, you were on the correct path.

17

It’s the developer’s responsibility to ensure that, it’s clearly defined which library versions are required.

  • Nobody else can guess or mind-read which versions the developer wishes to be used …
18

I find that if I am downloading/using or compiling that absolute latest version of a piece of software it often does not run or compile on leap 15.5. This is because, very often, that versions of dependencies required by the software are too new for leap. I keep tumbleweed in a vm to use in these situations and this has worked thus far.

But, it think the dev are too lazy to test their software on anything but the latest version of dependencies that they use for their build. I can’t believe that the dev are using the latest features of all the dependencies so as to require their use. The dev probably don’t even know the latest feature of a dependency but dictate it’s use anyway. A little more testing could make more current software run on leap.

19

Actually, there’s a view that, about 50 % of the development staff have to be involved with testing … :smiling_imp: