When I update from Tumbleweed I receive the following message:
Loading repository data...
Warning: Repository 'openSUSE Current non-OSS updates' appears to outdated. Consider using a different mirror or server.
Reading installed packages...
Computing distribution upgrade...
2 Problems:
Problem: python-kde4-4.11.1-3.2.x86_64 requires python-sip(api) = 10.0, but this requirement cannot be provided
Problem: python-kde4-4.11.1-3.2.x86_64 requires python-sip(api) = 10.0, but this requirement cannot be provided
Problem: python-kde4-4.11.1-3.2.x86_64 requires python-sip(api) = 10.0, but this requirement cannot be provided
deleted providers: python-sip-4.14.7-3.1.x86_64
Solution 1: Following actions will be done:
downgrade of python-kde4-4.11.1-3.2.x86_64 to python-kde4-4.10.5-1.101.3.x86_64
install python-kde4-4.10.5-1.101.3.x86_64 (with vendor change)
obs://build.opensuse.org/openSUSE:Tumbleweed --> openSUSE
install python-kde4-4.10.5-1.101.3.x86_64 from excluded repository
install python-kdebase4-4.10.5-1.111.1.x86_64 from excluded repository
install python-kde4-soprano-4.10.5-1.101.3.x86_64 from excluded repository
install python-kde4-plasma-4.10.5-1.101.3.x86_64 from excluded repository
install python-kde4-phonon-4.10.5-1.101.3.x86_64 from excluded repository
install python-kde4-nepomuk-4.10.5-1.101.3.x86_64 from excluded repository
install python-kde4-knewstuff-4.10.5-1.101.3.x86_64 from excluded repository
install python-kde4-khtml-4.10.5-1.101.3.x86_64 from excluded repository
Solution 2: keep obsolete python-sip-4.14.7-3.1.x86_64
Solution 3: keep obsolete python-sip-4.14.7-3.1.x86_64
Solution 4: break python-kde4-4.11.1-3.2.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] (c): 3
I think this is due to the “openSUSE Current non-OSS updates” being outdated. But it might not be. Any guidance?
No it’s not. That message is harmless, especially in this case it’s just that the non-OSS updates repo hasn’t get new packages for a long time (because there were no updates necessary. You can just ignore that.
Regarding your dependency problem:
I see python-sip-4.15.1-4.1 now in the Tumbleweed repo. Maybe it wasn’t there yet when you tried to update? (you have an older version installed)
Just try again. If it still doesn’t work, try to run “zypper ref” first to refresh your repos.
If that doesn’t help either, try “zypper in -f python-sip-4.15.1”. Do you get an error?
I performd the zypper ref and zupper up. I still get an error when trying to install python-sip-4.15.1:
sudo zypper in -f python-sip-4.15.1
Loading repository data...
Warning: Repository 'openSUSE Current non-OSS updates' appears to outdated. Consider using a different mirror or server.
Reading installed packages...
Forcing installation of 'python-sip-4.15.1-4.1.x86_64' from repository 'Tumbleweed'.
Resolving package dependencies...
Problem: python-kde4-4.11.1-3.2.x86_64 requires python-sip(api) = 10.0, but this requirement cannot be provided
deleted providers: python-sip-4.14.7-3.1.x86_64
Solution 1: Following actions will be done:
downgrade of python-kde4-4.11.1-3.2.x86_64 to python-kde4-4.10.5-1.101.3.x86_64
install python-kde4-4.10.5-1.101.3.x86_64 (with vendor change)
obs://build.opensuse.org/openSUSE:Tumbleweed --> openSUSE
downgrade of python-kde4-soprano-4.11.1-3.2.x86_64 to python-kde4-soprano-4.10.5-1.101.3.x86_64
install python-kde4-soprano-4.10.5-1.101.3.x86_64 (with vendor change)
obs://build.opensuse.org/openSUSE:Tumbleweed --> openSUSE
downgrade of python-kde4-plasma-4.11.1-3.2.x86_64 to python-kde4-plasma-4.10.5-1.101.3.x86_64
install python-kde4-plasma-4.10.5-1.101.3.x86_64 (with vendor change)
obs://build.opensuse.org/openSUSE:Tumbleweed --> openSUSE
downgrade of python-kde4-phonon-4.11.1-3.2.x86_64 to python-kde4-phonon-4.10.5-1.101.3.x86_64
install python-kde4-phonon-4.10.5-1.101.3.x86_64 (with vendor change)
obs://build.opensuse.org/openSUSE:Tumbleweed --> openSUSE
downgrade of python-kde4-nepomuk-4.11.1-3.2.x86_64 to python-kde4-nepomuk-4.10.5-1.101.3.x86_64
install python-kde4-nepomuk-4.10.5-1.101.3.x86_64 (with vendor change)
obs://build.opensuse.org/openSUSE:Tumbleweed --> openSUSE
downgrade of python-kde4-knewstuff-4.11.1-3.2.x86_64 to python-kde4-knewstuff-4.10.5-1.101.3.x86_64
install python-kde4-knewstuff-4.10.5-1.101.3.x86_64 (with vendor change)
obs://build.opensuse.org/openSUSE:Tumbleweed --> openSUSE
downgrade of python-kde4-khtml-4.11.1-3.2.x86_64 to python-kde4-khtml-4.10.5-1.101.3.x86_64
install python-kde4-khtml-4.10.5-1.101.3.x86_64 (with vendor change)
obs://build.opensuse.org/openSUSE:Tumbleweed --> openSUSE
deinstallation of python-kde4-akonadi-4.11.1-3.2.x86_64
Solution 2: do not install python-sip-4.15.1-4.1.x86_64
Solution 3: break python-kde4-4.11.1-3.2.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c] (c): c
I suspected there is a dependency problem, but YAST and Zypper do not report any.
Why are you using “–from Tumbleweed”, as in your thread title? It’s not the recommended/supported method of update, but a plain “zypper dup” is. I only use --from for specific situations to overcome certain issues.
Right. So that python-sip-4.15.1-4.1 is too new for the python-kde4 in the repo. python-sip provides python-sip(api) = 10.1 whereas python-kde4 still requires python-sip(api) = 10.0.
Well, I guess you just have to wait until python-kde4 gets rebuilt against the newer python-sip, and keep the “obsolete” python-4.14.7-3.1 for now.
I do that because there I have other repos enabled.
In any case, the package I need is in Tumbleweed and I cannot update because no provider is available.
So I disabled the pacman-essential repo I am using and ran the ***sudo zypper dup ***command and I get the following error:
sudo zypper dup
sudo zypper dup
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Loading repository data...
Warning: Repository 'openSUSE Current non-OSS updates' appears to outdated. Consider using a different mirror or server.
Reading installed packages...
Computing distribution upgrade...
Problem: akonadi-runtime-1.10.2-2.1.x86_64 requires libakonadiprotocolinternals1 = 1.10.2, but this requirement cannot be provided
Solution 1: deinstallation of kdepim4-runtime-4.11.1-3.2.x86_64
Solution 2: deinstallation of libkgapi1-2.0.1-2.2.x86_64
Solution 3: deinstallation of python-kde4-akonadi-4.11.1-3.2.x86_64
Solution 4: keep obsolete python-sip-4.14.7-3.1.x86_64
Solution 5: break akonadi-runtime-1.10.2-2.1.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/4/5/c] (c): 4
Resolving dependencies...
Computing distribution upgrade...
Problem: python-qt4-4.10.3-4.1.x86_64 requires python-sip(api) = 10.1, but this requirement cannot be provided
uninstallable providers: python-sip-4.15.1-4.1.i586[Tumbleweed]
python-sip-4.15.1-4.1.x86_64[Tumbleweed]
Solution 1: keep obsolete python-qt4-4.10.2-3.2.x86_64
Solution 2: do not keep python-sip-4.14.7-3.1.x86_64 installed
Solution 3: do not keep python-sip-4.14.7-3.1.x86_64 installed
Solution 4: break python-qt4-4.10.3-4.1.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/4/c] (c): c
So, we are back at the starting point. it seems to me, and I may be wrong, that a package is missing, or I cannot download it for some reason.
libakonadiprotocolinternals1 version 1.10 is available in Factory. I suspect that will be in Tumbleweed soon.
I haven’t added Packman yet, but I will very soon. I already made python update on standard 12.2 ok. Just booted my Tw for a dry run dup with this result:
Problem: akonadi-runtime-1.10.2-2.1.x86_64 requires libakonadiprotocolinternals1 = 1.10.2, but this requirement cannot be provided
Solution 1: Following actions will be done:
deinstallation of kaddressbook-4.11.1-3.2.x86_64
deinstallation of kdepim4-runtime-4.11.1-3.2.x86_64
deinstallation of konversation-lang-1.5~rc1-2.4.noarch
deinstallation of kdepim4-4.11.1-3.2.x86_64
Solution 2: deinstallation of libkgapi1-2.0.1-2.2.x86_64
Solution 3: deinstallation of python-kde4-akonadi-4.11.1-3.2.x86_64
Solution 4: keep obsolete python-sip-4.14.7-3.1.x86_64
Solution 5: break akonadi-runtime-1.10.2-2.1.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/4/5/c] (c):
The only one I might have tried is Solution 2, and this is what would happen as a result:
108 packages to upgrade, 31 to downgrade, 1 new, 1 to remove, 36 to change
vendor.
Overall download size: 260.7 MiB. After the operation, 3.4 MiB will be freed.
But I’m not sure about that - there is a lot of detail to go through which I haven’t quoted.
The following NEW package is going to be installed:
libkgapi0
The following package is going to be REMOVED:
libkgapi1
and results in this:
108 packages to upgrade, 31 to downgrade, 1 new, 1 to remove, 36 to change
vendor.
Overall download size: 260.7 MiB. After the operation, 3.4 MiB will be freed.
Not here. I went ahead and selected “Solution 2” for my real “zypper dup”, with no further issues, and the python updates plus many others were successful. Rebooted and posting this from the KDE desktop.
I did this, everything seemed to go fine until I started kmail. Should I re-install akonadi?
kmail2(1764)/libakonadi Akonadi::AgentManagerPrivate::createDBusInterface: AgentManager failed to get a valid AgentManager DBus interface. Error is: 1 "org.freedesktop.DBus.Error.NameHasNoOwner" "Could not get owner of name 'org.freedesktop.Akonadi.Control': no such name"
kmail2(1764)/libakonadi Akonadi::SessionPrivate::socketError: Socket error occurred: "QLocalSocket::connectToServer: Connection refused"
kmail: symbol lookup error: /usr/lib64/libakonadi-kde.so.4: undefined symbol: _ZN7Akonadi21NotificationMessageV217registerDBusTypesEv
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
unnamed app(1763): Communication problem with "kmail2" , it probably crashed.
Error message was: "org.freedesktop.DBus.Error.NoReply" : " "Message did not receive a reply (timeout by message bus)" "
And much more…
Added:
This seems to be the problem. I upgraded akonadi from YaST, but I get this error when I run akonadiconsole:
ebreiss@linux-6c9j:~> akonadiconsole
akonadiconsole: symbol lookup error: /usr/lib64/libakonadi-kde.so.4: undefined symbol: _ZN7Akonadi21NotificationMessageV217registerDBusTypesEv
OK, I fixed it. Apparently, Kontact 4.10 and its rpm children were installed. I ran zypper dup again and nothing changed. I enabled vendor change in YaST and ran zypper dup again and now everything is fine.
In case anyone else goes for Solution 2, it resulted in problems even though it threw up no errors on restart. Kontact and components failed to start, although I don’t use them much on this test system. Given that there had been more KDE related updates since, I decided to reverse the Solution’s basic change to libkgapi by using YaST to remove libkgapi0 and reinstall libkgapi1.
That was successful as far as being able to restart Kontact etc, but YaST’s resolver removed python-kde4-akonadi, also the main action proposed by Solution 3. Hopefully the original dependency issue will be resolved soon.
python-kde4-akonadi should only be needed for plasmoids (or other programs) written in python that use akonadi. So chances are that you don’t need it anyway…
Regarding the dependency conflict: python-kde4 fails to build against the newer python-sip, that’s why this conflict is still there.
This already has been fixed in the KDE repos a few days ago. So hopefully the fix will be commited to Tumbleweed as well soon.
Still, I would say, the best way to solve this conflict for now is choosing “keep obsolete python-sip-4.14.7-…”.
Regarding the dependency conflict: python-kde4 fails to build against the newer python-sip, that’s why this conflict is still there.
This already has been fixed in the KDE repos a few days ago. So hopefully the fix will be commited to Tumbleweed as well soon.
When I looked earlier on the Factory mailing list, the latest comment was that some of the packages were still waiting to build hence the original problem. That didn’t impress me, as a reason. The process is too slow for a rolling distro and the dependency hell of KDE4.
Still, I would say, the best way to solve this conflict for now is choosing “keep obsolete python-sip-4.14.7-…”.
As per the other thread and the mailing list, Solution 4 is the best of a bad situation when the update is carried out properly by zypper dup. However, I used to get safer results when I upgraded Tumbleweed manually using YaST owing to space limitations on a 10GB partition, and left KDE stuff until all dependency troubles were finally cleared.
Well, I couldn’t name anything that would need it right now…
When I looked earlier on the Factory mailing list, the latest comment was that some of the packages were still waiting to build hence the original problem. That didn’t impress me, as a reason. The process is too slow for a rolling distro and the dependency hell of KDE4.
When I replied on Friday, the package was waiting to be rebuilt.
But meanwhile it has been rebuilt (on Saturday, early morning) and the build failed, see here: Welcome - openSUSE Build Service
As I said, this build failure has already been fixed in the KDE repos, the fix just has to be committed to Tumbleweed as well.
Ok, but since you quoted my comments, that doesn’t really address the problem of why a partial release of co-dependent package upgrades (most probably kde4 fixes now, not real upgrades) is useful to a rolling release. If a build failure happens on one component, the dependants shouldn’t get into the repo either.
The only safe response is for the user to “Cancel” i.e. not Solution 4, taking none of the resolver’s “Solutions”, and wait! Then keep waiting until there are no questions to answer. In other words, especially if KDE or Gnome are involved, and “zypper dup” can’t solve it alone, then proceeding risks borking the system, either this time or the next, as more component updates dribble in. That is the solution for now, and advice we gave in the past on this forum and elsewhere.
