Snapshot 20230614 updates most of the packages?
Apparently there was full rebuild; any reason for this? The update was from 20230613, so it was not lack of intermediate updates.
I started a zypper dup this a.m. (20230612 -> 20230616) but noticed it apparently wipes out java19 and apparently back levels to java11 so I terminated the update. On Sat, Jun 17, 2023 at 7:54 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Apparently there was full rebuild; any reason for this?
The update was from 20230613, so it was not lack of intermediate updates.
субота, 17 червня 2023 р. 18:34:35 EEST Chuck Davis написано:
I started a zypper dup this a.m. (20230612 -> 20230616) but noticed it apparently wipes out java19 and apparently back levels to java11 so I terminated the update.
On Sat, Jun 17, 2023 at 7:54 AM Andrei Borzenkov <arvidjaar@gmail.com>
wrote:
Apparently there was full rebuild; any reason for this?
The update was from 20230613, so it was not lack of intermediate updates.
Install java20 and remove 19, and then use dup. Java19 is unsupported already. I've used this: `sudo zypper in java-20-openjdk-devel java-20-openjdk-jmods -java-19-openjdk - java-19-openjdk-devel -java-19-openjdk-headless -java-19-openjdk-jmods` Modify command for your needs. -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський
I can survive it by using something similar to your suggestion but it seems a shoddy thing to do to users to take away the Java their development environment depends on without installing the upgrade at the same time.... On Sat, Jun 17, 2023 at 12:56 PM Mykola Krachkovsky <w01dnick@gmail.com> wrote:
субота, 17 червня 2023 р. 18:34:35 EEST Chuck Davis написано:
I started a zypper dup this a.m. (20230612 -> 20230616) but noticed it apparently wipes out java19 and apparently back levels to java11 so I terminated the update.
On Sat, Jun 17, 2023 at 7:54 AM Andrei Borzenkov <arvidjaar@gmail.com>
wrote:
Apparently there was full rebuild; any reason for this?
The update was from 20230613, so it was not lack of intermediate updates.
Install java20 and remove 19, and then use dup. Java19 is unsupported already.
I've used this: `sudo zypper in java-20-openjdk-devel java-20-openjdk-jmods -java-19-openjdk - java-19-openjdk-devel -java-19-openjdk-headless -java-19-openjdk-jmods`
Modify command for your needs.
-- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський
Andrei Borzenkov wrote:
Apparently there was full rebuild; any reason for this? The update was from 20230613, so it was not lack of intermediate updates.
I wondered the same thing, looking here: https://build.opensuse.org/packages/MozillaFirefox/build_reason/openSUSE:Fac... as an example (since Firefox didn't have another obvious reason to update), the addition of python311 / removal of python310 associated packages seems to have triggered it
On 17.06.23 16:46, Andrei Borzenkov wrote:
Apparently there was full rebuild; any reason for this?
The update was from 20230613, so it was not lack of intermediate updates.
Yesterdays update ( to 20230616 ?) included an update of glibc to 2.37-4.4. Without full rebuild. Might it be that this update triggered the full rebuild but the update of glibc was delayed ?
I am trying to `zypper dup` my Tumbleweed to 20230619, as per standard practice and to see if it has the long-awaited upstream fix for the broken-on-old-hardware nouveau driver. I hadn't "dup'd" since 20230605 and am now getting dozens if not hundreds of errors, for example: ``` Problem: the installed python3-pyside2-5.15.9-1.2.x86_64 requires 'libQt5Charts.so.5(Qt_5.15.9_PRIVATE_API)(64bit)', but this requirement cannot be provided Problem: the installed python3-pyside2-5.15.9-1.2.x86_64 requires 'libQt5Core.so.5(Qt_5.15.9_PRIVATE_API)(64bit)', but this requirement cannot be provided Problem: the installed python3-pyside2-5.15.9-1.2.x86_64 requires 'libQt5Charts.so.5(Qt_5.15.9_PRIVATE_API)(64bit)', but this requirement cannot be provided deleted providers: libQt5Charts5-5.15.9+kde0-1.1.x86_64 ``` and: ``` Problem: the installed python310-matplotlib-qt5-3.6.3-2.1.x86_64 requires 'python310-qt5', but this requirement cannot be provided deleted providers: python310-qt5-5.15.9-1.5.x86_64 not installable providers: python310-qt5-5.15.9-2.3.x86_64[download.opensuse.org-oss] ``` I was doing "--dry-run" and canceled after several dozen of these, all seemingly about python310 and/or libQt5 (but not always both at once). I thought I had seen here that the default Python was changing to 3.11 -- if so, could that be part of my problem? What should I do to solve it? I tried disabling two repositories (Packman and Nvida) which I thought might be causing conflicts, and also added "--allow-vendor-change", but although the errors changed there were still a seemingly infinite number of them. Should I do "--allow-downgrade" and/or "--no-confirm"? Thanks for any advice.
Hi, Am 20.06.23 um 21:33 schrieb Mark Rubin via openSUSE Factory:
I am trying to `zypper dup` my Tumbleweed to 20230619, as per standard practice and to see if it has the long-awaited upstream fix for the broken-on-old-hardware nouveau driver.
I hadn't "dup'd" since 20230605 and am now getting dozens if not hundreds of errors, for example:
``` Problem: the installed python3-pyside2-5.15.9-1.2.x86_64 requires 'libQt5Charts.so.5(Qt_5.15.9_PRIVATE_API)(64bit)', but this requirement cannot be provided Problem: the installed python3-pyside2-5.15.9-1.2.x86_64 requires 'libQt5Core.so.5(Qt_5.15.9_PRIVATE_API)(64bit)', but this requirement cannot be provided Problem: the installed python3-pyside2-5.15.9-1.2.x86_64 requires 'libQt5Charts.so.5(Qt_5.15.9_PRIVATE_API)(64bit)', but this requirement cannot be provided deleted providers: libQt5Charts5-5.15.9+kde0-1.1.x86_64 ```
For python3-pyside2 you have to wait for the next snapshot: https://build.opensuse.org/request/show/1093899
and:
``` Problem: the installed python310-matplotlib-qt5-3.6.3-2.1.x86_64 requires 'python310-qt5', but this requirement cannot be provided deleted providers: python310-qt5-5.15.9-1.5.x86_64 not installable providers: python310-qt5-5.15.9-2.3.x86_64[download.opensuse.org-oss] ```
I was doing "--dry-run" and canceled after several dozen of these, all seemingly about python310 and/or libQt5 (but not always both at once). I thought I had seen here that the default Python was changing to 3.11 -- if so, could that be part of my problem?
Most probably, yes. However, you did not post the line where it says *why* python310-qt5-5.15.9-2.3 is not installable. The difference between -1.5 and -2.3 is that the latter no longer provides the "primary" python3-qt5. python311-qt5 now provides python3-qt5. But actually you should find out why python310-matplotlib-qt5 is still required and cannot be replaced by python311-matplotlib-qt5 during the `zypper dup`.
Thanks for any advice.
- Ben
Ben Greiner wrote:
For python3-pyside2 you have to wait for the next snapshot: https://build.opensuse.org/request/show/1093899
Thanks for the explanation. I probably will wait but am afraid that it won't fix the many other errors not related to python310 I'm getting, like: ``` Problem: the to be installed libqt5-qttools-5.15.10+kde3-1.1.x86_64 requires 'libQt5DBus.so.5(Qt_5.15.10_PRIVATE_API)(64bit)', but this requirement cannot be provided not installable providers: libQt5DBus5-5.15.10+kde129-1.1.x86_64[download.opensuse.org-oss] Solution 1: Following actions will be done: keep obsolete libqt5-qttools-5.15.9+kde1-1.1.x86_64 keep obsolete libQt5DesignerComponents5-5.15.9+kde1-1.1.x86_64 keep obsolete libqt5-qttools-qhelpgenerator-5.15.9+kde1-1.1.x86_64 Solution 2: deinstallation of libqt5-qttools-5.15.9+kde1-1.1.x86_64 Solution 3: remove lock to allow removal of libQt5DBus5-5.15.9+kde154-1.3.x86_64 Solution 4: break libqt5-qttools-5.15.10+kde3-1.1.x86_64 by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c/d/?] (c): 1 ```
Most probably, yes. However, you did not post the line where it says *why* python310-qt5-5.15.9-2.3 is not installable. The difference between -1.5 and -2.3 is that the latter no longer provides the "primary" python3-qt5. python311-qt5 now provides python3-qt5. .
I'm sorry, but I don't understand. The first mention of python310-qt5-5.15.9-1.5.x86_64 is in the conflict regarding python310-matplotlib-qt5-3.6.3-2.1.x86_64. The full text is: ``` Problem: the installed python310-matplotlib-qt5-3.6.3-2.1.x86_64 requires 'python310-qt5', but this requirement cannot be provided deleted providers: python310-qt5-5.15.9-1.5.x86_64 not installable providers: python310-qt5-5.15.9-2.3.x86_64[download.opensuse.org-oss] Solution 1: Following actions will be done: remove lock to allow removal of python310-matplotlib-qt5-3.6.3-2.1.x86_64 deinstallation of python310-qt5-5.15.9-1.5.x86_64 deinstallation of cura-4.13.1-2.3.noarch Solution 2: keep obsolete python310-qt5-5.15.9-1.5.x86_64 Solution 3: remove lock to allow removal of libQt5Core5-5.15.9+kde154-1.3.x86_64 Solution 4: break python310-matplotlib-qt5-3.6.3-2.1.x86_64 by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c/d/?] (c): 2 ``` I didn't want solution 1 because I don't want to lose "cura". But again, this was a "--dry-run". If I was doing it with "--dry-run" and kept python310-qt5-5.15.9-1.5.x86_64, would some of the other conflicts resolve themselves?
But actually you should find out why python310-matplotlib-qt5 is still required and cannot be replaced by python311-matplotlib-qt5 during the `zypper dup`
Can you suggest how to do that? It seems to me that this might be some kind of deadlock situation, where installed packages have 3.10 dependencies which can't be replaced by 3.11 versions until they're resolved. Again, what's my best way out of this? I'd prefer not to have to remove a large number of packages, do the "dup", and then reinstall them, but if that's the only solution I guess I'll have to. Or, even worse, get the latest ISO and reinstall Tumbleweed from scratch and then add all my desired packages (hundreds) again. Or is maybe "--force" what I need to add?
On 21.06.2023 00:02, Mark Rubin via openSUSE Factory wrote:
Ben Greiner wrote:
For python3-pyside2 you have to wait for the next snapshot: https://build.opensuse.org/request/show/1093899
Thanks for the explanation. I probably will wait but am afraid that it won't fix the many other errors not related to python310 I'm getting, like:
``` Problem: the to be installed libqt5-qttools-5.15.10+kde3-1.1.x86_64 requires 'libQt5DBus.so.5(Qt_5.15.10_PRIVATE_API)(64bit)', but this requirement cannot be provided not installable providers: libQt5DBus5-5.15.10+kde129-1.1.x86_64[download.opensuse.org-oss] Solution 1: Following actions will be done: keep obsolete libqt5-qttools-5.15.9+kde1-1.1.x86_64 keep obsolete libQt5DesignerComponents5-5.15.9+kde1-1.1.x86_64 keep obsolete libqt5-qttools-qhelpgenerator-5.15.9+kde1-1.1.x86_64 Solution 2: deinstallation of libqt5-qttools-5.15.9+kde1-1.1.x86_64 Solution 3: remove lock to allow removal of libQt5DBus5-5.15.9+kde154-1.3.x86_64
Did you lock some packages to prevent their updates?
Hi, Am 20.06.23 um 23:02 schrieb Mark Rubin via openSUSE Factory:
Ben Greiner wrote:
For python3-pyside2 you have to wait for the next snapshot: https://build.opensuse.org/request/show/1093899 Thanks for the explanation. I probably will wait but am afraid that it won't fix the many other errors not related to python310 I'm getting, like: Solution 3: remove lock to allow removal of libQt5DBus5-5.15.9+kde154-1.3.x86_64
You have a lock that you did not mention before. It prevents the update of Qt5. Probably from a Solution selection "keep" for python3-pyside2 before.
I'm sorry, but I don't understand. The first mention of python310-qt5-5.15.9-1.5.x86_64 is in the conflict regarding python310-matplotlib-qt5-3.6.3-2.1.x86_64. The full text is:
``` Problem: the installed python310-matplotlib-qt5-3.6.3-2.1.x86_64 requires 'python310-qt5', but this requirement cannot be provided deleted providers: python310-qt5-5.15.9-1.5.x86_64 not installable providers: python310-qt5-5.15.9-2.3.x86_64[download.opensuse.org-oss] Solution 1: Following actions will be done: remove lock to allow removal of python310-matplotlib-qt5-3.6.3-2.1.x86_64 deinstallation of python310-qt5-5.15.9-1.5.x86_64 deinstallation of cura-4.13.1-2.3.noarch Solution 2: keep obsolete python310-qt5-5.15.9-1.5.x86_64 Solution 3: remove lock to allow removal of libQt5Core5-5.15.9+kde154-1.3.x86_64
Same. python310-qt5-5.15.9-2.3 requires libQt5Core5 to be updated.
Solution 4: break python310-matplotlib-qt5-3.6.3-2.1.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c/d/?] (c): 2 ```
I didn't want solution 1 because I don't want to lose "cura". But again, this was a "--dry-run". If I was doing it with "--dry-run" and kept python310-qt5-5.15.9-1.5.x86_64, would some of the other conflicts resolve themselves?
There is your answer. As of now you can only keep the distribution package for Cura if you stay on the old snapshot. The Cura package system broke apart with the switch to python311: Cura requires the libraries libArcus and libSavitar. They need to be updated first, because the old versions in the distribution still require obsolete python3-sip < 5 which is not compatible with python311. Cura upstream did switch to more modern tools months ago, but the openSUSE Tumbleweed package did not keep up. I suggest switching to Cura flatpak, appimage or the like. https://build.opensuse.org/package/show/openSUSE:Factory/cura : Fails because it cannot find `UM` from uranium in the python311 sitelib, the old package still has it in python310 https://build.opensuse.org/package/show/openSUSE:Factory/uranium: Fails to build. https://build.opensuse.org/package/show/openSUSE:Factory/cura-engine : Unresolvable https://build.opensuse.org/package/show/openSUSE:Factory/libArcus : Unresolvable https://build.opensuse.org/package/show/openSUSE:Factory/libSavitar : Unresolvable
Again, what's my best way out of this? I'd prefer not to have to remove a large number of packages, do the "dup", and then reinstall them, but if that's the only solution I guess I'll have to. Or, even worse, get the latest ISO and reinstall Tumbleweed from scratch and then add all my desired packages (hundreds) again.
Remove cura and the likes (as well as python3-pyside2) before the dup. There is no way around it if you want to keep a sane system. Of course you could force keeping stuff, but that does not mean that the software keeps running. Cura won't, because there will be a mixture of python311 and python310. With a lot of manual intervention, you could reinstall the old packages after the dup. I get this: #LANG=C zypper in cura Loading repository data... Reading installed packages... Resolving package dependencies... The following 9 recommended packages were automatically selected: python310 python310-curses python310-dbm python310-numpy python310-pip python311-geoip2 python311-hiredis python311-pylibmc python311-pymemcache The following 57 NEW packages are going to be installed: cura cura-engine libArcus3 libSavitar0 libmemcached11 libmemcachedutil2 libpolyclipping22 libpython3_10-1_0 python3-Arcus python3-pynest2d python310 python310-Shapely python310-base python310-cffi python310-cryptography python310-curses python310-dbm python310-gobject python310-gobject-Gdk python310-gobject-cairo python310-numpy python310-pip python310-pycairo python310-pycparser python310-setuptools python311-Django python311-Flask python311-Shapely python311-Werkzeug python311-amqp python311-asgiref python311-bcrypt python311-billiard python311-blinker python311-bottle python311-cached-property python311-celery python311-click-didyoumean python311-click-plugins python311-click-repl python311-falcon python311-geoip2 python311-hiredis python311-itsdangerous python311-kombu python311-maxminddb python311-pylibmc python311-pymemcache python311-pymongo python311-pyserial python311-redis python311-rq python311-sentry-sdk python311-sqlparse python311-starlette python311-vine uranium 57new packages to install. Overall download size: 64.8 MiB. Already cached: 0 $ cura Traceback (most recent call last): File "/usr/bin/cura", line 24, in <module> from UM.Platform import Platform ModuleNotFoundError: No module named 'UM' That is because the shebang has /usr/bin/python3 which is pointing to python3.11 now. Instead do: $/usr/bin/python3.10 cura Traceback (most recent call last): File "/usr/bin/cura", line 22, in <module> from PyQt5.QtNetwork import QSslConfiguration, QSslSocket ModuleNotFoundError: No module named 'PyQt5.QtNetwork' ... now install python310-qt5 and everything python310- that is not found. If you want to go down that route, good luck. - Ben
Andrei Borzenkov wrote:
Did you lock some packages to prevent their updates?
Yes, I see now that I did, due to my misunderstandings about zypper conflict resolution. Thanks for pointing it out, and apologies for my newbie errors. Ben Greiner wrote:
You have a lock that you did not mention before. It prevents the update of Qt5. Probably from a Solution selection "keep" for python3-pyside2 before.
As per the comment above, yes, I understand that now. Again, I apologize.
There is your answer. As of now you can only keep the distribution package for Cura if you stay on the old snapshot. The Cura package system broke apart with the switch to python311: Cura requires the libraries libArcus and libSavitar. They need to be updated first, because the old versions in the distribution still require obsolete python3-sip < 5 which is not compatible with python311. Cura upstream did switch to more modern tools months ago, but the openSUSE Tumbleweed package did not keep up. I suggest switching to Cura flatpak, appimage or the like. ... With a lot of manual intervention, you could reinstall the old packages after the dup. I get this:
Thanks very much for the detailed explanation and tutorial. Disappointing that nobody is maintaining openSUSE Cura, but that's how it goes with open source software. I browsed the Cura codebase a year or two ago when it stopped working with direct USB connections to 3D printers and Ultimaker said they wouldn't address that as a bug because none of theirs use USB. Fair enough, and at least they do contribute their industry-leading software as open source.
If you want to go down that route, good luck.
Yes, I'd need it. ;) But in a massive example of irony, I went back to try all of these suggestions today, and with 20230620 vs the 20230619 I was using yesterday, Cura *did* update successfully. (Yes, I understand that Tumbleweed is a moving target.) The only problem I had was that FreeCAD broke in almost the same way Cura was doing yesterday. But with my newfound knowledge (thanks again) I accepted deinstallation of it and the "dup" with 4086 packages completed successfully. (It also removed 8 other packages, all of which I need as well as FreeCAD, but hopefully the Tumbleweed churn will eventually bring them back.) Once again, thanks for all the help. I think my problems were a lack of understanding combined with my "dup"s straddling the very large Python 3.10 -> 3.11 change. The final irony is that I had delayed "dup"-ing while waiting for the nouveau driver patch, and despite the fact that it was committed both upstream and in https://github.com/openSUSE/kernel, it isn't in kernel-source-6.3.7-1.2.noarch nor (I assume because I'm still getting the lockup/kernel-fault) the running Tumbleweed vmlinuz-6.3.7-1-default kernel. So now I'm off to fight that battle. :( Thanks again for everyone's help.
Hi, Am 21.06.23 um 22:38 schrieb Mark Rubin via openSUSE Factory:
Ben Greiner wrote:
Cura upstream did switch to more modern tools months ago, but the openSUSE Tumbleweed package did not keep up. I suggest switching to Cura flatpak, appimage or the like. ... With a lot of manual intervention, you could reinstall the old packages after the dup. I get this: Thanks very much for the detailed explanation and tutorial. Disappointing that nobody is maintaining openSUSE Cura, but that's how it goes with open source software. I browsed the Cura codebase a year or two ago when it stopped working with direct USB connections to 3D printers and Ultimaker said they wouldn't address that as a bug because none of theirs use USB. Fair enough, and at least they do contribute their industry-leading software as open source.
There is a designated maintainer for science/cura. Not sure why he did not bother to update to Cura 5, which came out 1 year ago. You could try to branch, update, and submit it yourself and hope you can spark his interest or take over from him. You could try starting with a bug report.
If you want to go down that route, good luck. Yes, I'd need it. ;) But in a massive example of irony, I went back to try all of these suggestions today, and with 20230620 vs the 20230619 I was using yesterday, Cura *did* update successfully. (Yes, I understand that Tumbleweed is a moving target.)
Just as with the commands and outputs I posted, it may have updated but it won't work. Unless the maintainer, you, or someone else interested to contribute fixes the unresolvables and build failures in openSUSE:Factory, it will automatically be removed from Tumbleweed in a few weeks.
The only problem I had was that FreeCAD broke in almost the same way Cura was doing yesterday. But with my newfound knowledge (thanks again) I accepted deinstallation of it and the "dup" with 4086 packages completed successfully. (It also removed 8 other packages, all of which I need as well as FreeCAD, but hopefully the Tumbleweed churn will eventually bring them back.)
Incidentally, FreeCAD has the same person as Cura listed as maintainer. With python3-pyside2 being fixed in the meantime it should however work without any further actions. The test flavor in https://build.opensuse.org/package/show/openSUSE:Factory/FreeCAD failed and thus FreeCAD is not in the last snapshot, but a build retrigger probably fixes it soon. In the meantime you can directly download the successfully built package from openSUSE:Factory/standard and use that one: $ osc getbinaries openSUSE:Factory FreeCAD standard x86_64 # zypper in binaries/FreeCAD-0.20.2-5.3.x86_64.rpm
Thanks again for everyone's help.
- Ben
On Tue, 20 Jun 2023 19:33:08 -0000, Mark Rubin via openSUSE Factory <factory@lists.opensuse.org> wrote:
I am trying to `zypper dup` my Tumbleweed to 20230619, as per standard practice and to see if it has the long-awaited upstream fix for the broken-on-old-hardware nouveau driver.
I hadn't "dup'd" since 20230605 and am now getting dozens if not hundreds of errors, for example:
``` Problem: the installed python3-pyside2-5.15.9-1.2.x86_64 requires 'libQt5Charts.so.5(Qt_5.15.9_PRIVATE_API)(64bit)', but this requirement cannot be provided Problem: the installed python3-pyside2-5.15.9-1.2.x86_64 requires 'libQt5Core.so.5(Qt_5.15.9_PRIVATE_API)(64bit)', but this requirement cannot be provided Problem: the installed python3-pyside2-5.15.9-1.2.x86_64 requires 'libQt5Charts.so.5(Qt_5.15.9_PRIVATE_API)(64bit)', but this requirement cannot be provided deleted providers: libQt5Charts5-5.15.9+kde0-1.1.x86_64 ```
and:
``` Problem: the installed python310-matplotlib-qt5-3.6.3-2.1.x86_64 requires 'python310-qt5', but this requirement cannot be provided deleted providers: python310-qt5-5.15.9-1.5.x86_64 not installable providers: python310-qt5-5.15.9-2.3.x86_64[download.opensuse.org-oss] ```
I was doing "--dry-run" and canceled after several dozen of these, all seemingly about python310 and/or libQt5 (but not always both at once). [...]
You could check your current dependencies: zypper --non-interactive verify --dry-run --details --solver-focus Installed -- Robert Webb
Robert Webb wrote:
You could check your current dependencies: zypper --non-interactive verify --dry-run --details --solver-focus Installed
Thanks for the suggestion. Not sure what to make of the result: ``` $ sudo zypper --non-interactive verify --dry-run --details --solver-focus Installed [sudo] password for root: Loading repository data... Reading installed packages... Dependencies of all installed packages are satisfied. ``` I also tried "--solver-focus Update" and "Job" with the same result.
participants (8)
-
Andrei Borzenkov -
Ben Greiner -
Chuck Davis -
John Kizer -
Mark Rubin -
Markus Koßmann -
Mykola Krachkovsky -
Robert Webb