That update showed up yesterday, but I noticed that one package was changing from x86_64 to i585 arch. This change pulled in over 40 i586 packages. Obviously, waiting for that to be fixed seemed wise. That problem is gone today, but at least one new one popped up. Currently, I have this package installed:
Information for package libx265-188:
------------------------------------
Repository : @System
Name : libx265-188
Version : 3.3-1.3
Arch : x86_64
Vendor : http://packman.links2linux.de
Installed Size : 15.3 MiB
Installed : Yes
Status : up-to-date
Source package : x265-3.3-1.3.src
Summary : A free H265/HEVC encoder - encoder binary
Description :
x265 is a free library for encoding next-generation H265/HEVC video
streams.
The update wants to keep that package (!?) and install this package:
Information for package libx265-192:
------------------------------------
Repository : Packman repository (openSUSE_Tumbleweed)
Name : libx265-192
Version : 3.4-1.2
Arch : x86_64
Vendor : http://packman.links2linux.de
Installed Size : 15.3 MiB
Installed : No
Status : not installed
Source package : x265-3.4-1.2.src
Summary : A free H265/HEVC encoder - encoder binary
Description :
x265 is a free library for encoding next-generation H265/HEVC video
streams.
Shouldn’t the package ownership switch repos and the original package be replaced by the new one?
Yesterday’s package is the same as today’s one (libx265), right? I guess there was some outdated dependency on *-188, which was updated in the meantime.
$ zypper se --requires-pkg libx265-188
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
--+--------------+--------------------------------------------+--------
i | libavcodec58 | FFmpeg codec library | package
i | vlc-codecs | Additional codecs for the VLC media player | package
Although both packages depend already on libx265-192. So after the upgrade it should be possible to remove the *-188 package. I suppose there’s a technical reason why the old package wasn’t marked for removal. nrickert’s message confirms nothing is pulling the old one as dependency.
Technically, the old package was named “libx265-188” and the new package is named “libx265-192”. The “188” and “192” are part of the package name, and not just a version number.
Here’s my guess as to what happened (which might be wrong).
Packman was replacing “libx265-188” with the newer “libx265-192”. So it got to the point where the 64-bit version of “libx265-188” was removed, but the newer replacement was not yet there. And then Packman had problems – I think I saw mention of a disk failure. So we were doing our Tumbleweed update at a time when Packman was a bit messed up. And that’s why we were switched to the 32-bit version. But all was fixed for today’s update, and we installed the 64-bit version of “libx265-192”.
Problem: problem with installed package libx265-188-3.3-1.3.x86_64
Problem: calibre-4.17.0-1.1.x86_64 requires libQt5Core.so.5(Qt_5.14.1_PRIVATE_API)(64bit), but this requirement cannot be provided
If I click the option “keep obsolete libx265-188-3.3-1.3.x86_64” it comes with more and more problems to Keep other obsolete packages. I don’t want to break calibre. I had these messages 7 times with more and more "keep obsolete package … " before I cancelled out. SO what is the option? I had before:
Solution 2: deinstallation of calibre-4.17.0-1.1.x86_64
Solution 3: break calibre-4.17.0-1.1.x86_64 by ignoring some of its dependencies
Shall I uninstall calibre and install afterwards or wait for the update or just try to remove the libx265-188-3.3-1.3.x86_64 and intall the 192 version even though it might break any dependencies?
I installed libx265-192 and tried zypper dup and had messages as before (previouos post) and if I try to remove libx265-188 I have the same messages that 163 packages need removing as above.
OK there are obviously none of your knowledgeable guys available so I tried a few things. First the command zypper se --requires-package for libx265-188 showed the same packages as for libx266-192 so I removed libx265-188 with the command
rpm -e --nodeps libx265-188
now the zypper dup command comes up with the following problem:
Problem: calibre-4.17.0-1.1.x86_64 requires libQt5Core.so.5(Qt_5.14.1_PRIVATE_API)(64bit), but this requirement cannot be provided
deleted providers: libQt5Core5-5.14.1-2.2.x86_64
Solution 1: Following actions will be done:
keep obsolete libQt5Core5-5.14.1-2.2.x86_64
keep obsolete libQt5Gui5-5.14.1-2.2.x86_64
keep obsolete libQt5DBus5-5.14.1-2.2.x86_64
Solution 2: deinstallation of calibre-4.17.0-1.1.x86_64
Solution 3: break calibre-4.17.0-1.1.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): 1
Resolving dependencies...
Computing distribution upgrade...
4 Problems:
Problem: libQt5Network5-5.15.0-1.2.x86_64 requires libQt5Core5 = 5.15.0, but this requirement cannot be provided
Problem: libQt5Widgets5-5.15.0-1.2.x86_64 requires libQt5Gui5 = 5.15.0, but this requirement cannot be provided
Problem: plasma5-workspace-libs-5.18.5-2.2.x86_64 requires libQt5DBus5 >= 5.15.0, but this requirement cannot be provided
Problem: vlc-qt-3.0.10-5.4.x86_64 requires libQt5Core.so.5(Qt_5.
When I again try to keep the obsolete package it goes on and on and asks to keep more obsolete packages. What now?
The Tumbleweed systems that I recently updated don’t have calibre installed. But maybe I will run into that problem tomorrow when I update another system.
I did run into a calibre problem a few weeks ago. I checked for orphaned packages, and then tried to remove them. And removing would have caused issues for calibre. But that problem seems to have gone away. I think it was because some needed packages had not yet been updated.
Given the factory mailing list note about the recent update, it is probably a similar issue. Some of the packages needed by calibre may be among those that are not successfully building with gcc10. So you probably have to wait for it to clear up.
I guess solution 3 is the easy out. It might make calibre unusable. Or maybe it just makes a few calibre functions not work for now. But it keeps it there for future updates to pull in what is needed when they become available.