Online Update throws millions of conflicts

English Hardware
#1

I haven’t touched this 11.3 KDE system for a few months, came back to update it and now Online Update throws me endless “conflict” errors that need manual response, you know - radio buttons with “break/change architecture/do not install” options.

I cleared the first screen but it flashed a new one with even more conflicts, and then the third one, and then I gave up.

It is humanely impossible to go through all of them one by one and read up on all the conflicting libraries and find the best solutions.

Right now I have only three repos enabled, OSS, non-OSS and Updates, but I get enough errors even without Packman etc. to see that the problem can’t be solved just by tackling it head on.

KDE update applet reported the same errors, too. I haven’t tried but zypper would probably do the same.

Something else is seriously wrong here, I shouldn’t get so many errors.

I am at a loss what to do.

#2

Even so, please post result of

zypper lr -d

to get the detail up here. :slight_smile:

#3

| Alias | Name | Enabled | Refresh | Priority | Type | URI | Service

—±--------------------------------------±--------------------------------------±--------±--------±---------±-------±-------------------------------------------------------------------------±-------
1 | 11.3 | 11.3 | No | No | 99 | rpm-md | Index of /update/11.3 |
2 | Libdvdcss repository | Libdvdcss repository | No | No | 99 | rpm-md | http://opensuse-guide.org/repo/11.3/ |
3 | Updates_for_openSUSE_11.3_11.3-1.82 | Updates for openSUSE 11.3 11.3-1.82 | Yes | No | 99 | rpm-md | Index of /update/11.3 |
4 | google-chrome | google-chrome | No | No | 99 | rpm-md | http://dl.google.com/linux/chrome/rpm/stable/x86_64 |
5 | Index of /suse/11.3 | Index of /suse/11.3 | No | No | 99 | rpm-md | Index of /suse/11.3 |
6 | openSUSE-11.3 11.3-1.82 | openSUSE-11.3 11.3-1.82 | No | No | 99 | yast2 | cd:///?devices=/dev/sr0 |
7 | openSUSE-11.3-Non-Oss | openSUSE-11.3-Non-Oss | Yes | No | 99 | yast2 | Index of /distribution/11.3/repo/non-oss |
8 | openSUSE-11.3-Oss | openSUSE-11.3-Oss | Yes | No | 99 | yast2 | Index of /distribution/11.3/repo/oss |
9 | openSUSE_11.3 | openSUSE_11.3 | No | No | 99 | rpm-md | Index of /repositories/Emulators:/Wine/openSUSE_11.3 |
10 | packman.inode.at-suse | Packman Repository | No | No | 99 | rpm-md | Index of /suse/11.3/ |
11 | repo-debug | openSUSE-11.3-Debug | No | No | 99 | NONE | Index of /debug/distribution/11.3/repo/oss |
12 | repo-source | openSUSE-11.3-Source | No | No | 99 | NONE | Index of /source/distribution/11.3/repo/oss |

#4 
1 | 11.3 | 11.3 | No | No | 99 | rpm-md | Index of /update/11.3 |
2 | Libdvdcss repository | Libdvdcss repository | No | No | 99 | rpm-md | http://opensuse-guide.org/repo/11.3/ |
3 | Updates_for_openSUSE_11.3_11.3-1.82 | Updates for openSUSE 11.3 11.3-1.82 | Yes | No | 99 | rpm-md | Index of /update/11.3 |
4 | google-chrome | google-chrome | No | No | 99 | rpm-md | http://dl.google.com/linux/chrome/rpm/stable/x86_64 |
5 | Index of /suse/11.3 | Index of /suse/11.3 | No | No | 99 | rpm-md | Index of /suse/11.3 |
6 | openSUSE-11.3 11.3-1.82 | openSUSE-11.3 11.3-1.82 | No | No | 99 | yast2 | cd:///?devices=/dev/sr0 |
7 | openSUSE-11.3-Non-Oss | openSUSE-11.3-Non-Oss | Yes | No | 99 | yast2 | Index of /distribution/11.3/repo/non-oss |
8 | openSUSE-11.3-Oss | openSUSE-11.3-Oss | Yes | No | 99 | yast2 | Index of /distribution/11.3/repo/oss |
9 | openSUSE_11.3 | openSUSE_11.3 | No | No | 99 | rpm-md | Index of /repositories/Emulators:/Wine/openSUSE_11.3 |
10 | packman.inode.at-suse | Packman Repository | No | No | 99 | rpm-md | Index of /suse/11.3/ |
11 | repo-debug | openSUSE-11.3-Debug | No | No | 99 | NONE | Index of /debug/distribution/11.3/repo/oss |
12 | repo-source | openSUSE-11.3-Source | No | No | 99 | NONE | Index of /source/distribution/11.3/repo/oss |

Why those ‘No’ marked red (especially the first one)?

#5

oss and non-oss do not need to be refreshed as they are static repositories anyway.

Stan_Ice, conflicts are not necessarily a problem, usually zypper / YaST suggest solutions for them. Either way, could you post the output of either of them when attempting the update?

#6

The enabled repos are not set for being auto refreshed, unless you are doing a “zypper refresh” on the repos. Suggest you set at least the update repo to auto refresh and try again. I would have used #1 for the update repo.

If it was me, I would enable packman repo (#5) give it a higher priority (e.g. 80) so you have only the four repos. Then as root (su -):

zypper refresh
zypper dup

That will take care of the vendor changes to packman (with zypper dup).

#7

There is/was a long standing DNS problem in Thailand and so while I keep OSS etc repos, they are disabled, and the enabled ones have actual IP address for the servers (195…). You can’t see it in the zypper output, though.

I refreshed all enabled repositories before updating, went without errors. Now, with Packman disabled, I get this when trying to update, from conflicts file saved by Yast Online Update:

YaST2 conflicts list - generated 2011-01-21 20:55:05

poppler-tools-0.12.3-5.1.1.x86_64 requires libpoppler.so.5()(64bit), but this requirement cannot be provided
uninstallable providers: libpoppler5-0.12.3-5.1.1.x86_64[Updates_for_openSUSE_11.3_11.3-1.82]
libpoppler5-0.12.3-4.1.x86_64[openSUSE-11.3-Oss]
] break poppler-tools by ignoring some of its dependencies

 ] do not install patch:libpoppler-devel-3335.noarch

 ] architecture change of libpoppler5-0.12.3-4.1.i586 to libpoppler5-0.12.3-5.1.1.x86_64

 ] Following actions will be done:

architecture change of poppler-tools-0.12.3-4.1.x86_64 to poppler-tools-0.12.3-5.1.1.i586
install poppler-tools-0.12.3-5.1.1.i586 despite the inferior architecture
architecture change of libpoppler-glib4-0.12.3-4.1.x86_64 to libpoppler-glib4-0.12.3-5.1.1.i586
install libpoppler-glib4-0.12.3-5.1.1.i586 despite the inferior architecture
deinstallation of evince-2.30.1-2.6.x86_64
architecture change of gimp-2.6.8-6.1.x86_64 to gimp-2.6.8-6.1.i586
install gimp-2.6.8-6.1.i586 despite the inferior architecture
install libgegl-0_1-0-0.1.2-4.2.i586 despite the inferior architecture
architecture change of libtracker-miner-0_8-0-0.8.5-2.7.x86_64 to libtracker-miner-0_8-0-0.8.5-3.3.1.i586
install libtracker-miner-0_8-0-0.8.5-3.3.1.i586 despite the inferior architecture
install libtracker-client-0_8-0-0.8.5-3.3.1.i586 despite the inferior architecture
install tracker-0.8.5-3.3.1.i586 despite the inferior architecture
install libdevkit-power-gobject1-0.9.1-1.26.i586 despite the inferior architecture
install libenca0-1.13-1.5.i586 despite the inferior architecture
install libiptcdata0-1.0.4-6.1.i586 despite the inferior architecture
install libtracker-extract-0_8-0-0.8.5-3.3.1.i586 despite the inferior architecture
install totem-pl-parser-2.30.1-1.7.i586 despite the inferior architecture
architecture change of libtracker-extract-0_8-0-0.8.5-2.7.x86_64 to libtracker-extract-0_8-0-0.8.5-3.3.1.i586
deinstallation of gnome-python-desktop-2.30.0-1.13.x86_64
install libbrasero-burn0-2.30.1-2.10.i586 despite the inferior architecture
install brasero-2.30.1-2.10.i586 despite the inferior architecture
architecture change of xsane-0.997-7.1.x86_64 to xsane-0.997-7.1.i586
install xsane-0.997-7.1.i586 despite the inferior architecture
architecture change of gimp-plugins-python-2.6.8-6.1.x86_64 to gimp-plugins-python-2.6.8-6.1.i586
install gimp-plugins-python-2.6.8-6.1.i586 despite the inferior architecture
architecture change of gimp-module-hal-2.6.8-6.1.x86_64 to gimp-module-hal-2.6.8-6.1.i586
install gimp-module-hal-2.6.8-6.1.i586 despite the inferior architecture
architecture change of gimp-help-browser-2.6.8-6.1.x86_64 to gimp-help-browser-2.6.8-6.1.i586
install gimp-help-browser-2.6.8-6.1.i586 despite the inferior architecture
architecture change of libgegl-0_1-0-0.1.2-4.2.x86_64 to libgegl-0_1-0-0.1.2-4.2.i586
architecture change of libbrasero-burn0-2.30.1-2.10.x86_64 to libbrasero-burn0-2.30.1-2.10.i586
architecture change of brasero-2.30.1-2.10.x86_64 to brasero-2.30.1-2.10.i586
architecture change of totem-pl-parser-2.30.1-1.7.x86_64 to totem-pl-parser-2.30.1-1.7.i586
architecture change of upower-0.9.1-1.26.x86_64 to upower-0.9.1-1.26.i586
install upower-0.9.1-1.26.i586 despite the inferior architecture
install libupower-glib1-0.9.1-1.26.i586 despite the inferior architecture
architecture change of libupower-glib1-0.9.1-1.26.x86_64 to libupower-glib1-0.9.1-1.26.i586
deinstallation of MPlayer-1.0rc2_r30099-4.pm.10.1.x86_64
deinstallation of smplayer-0.6.9-1.pm.3.1.x86_64
architecture change of libenca0-1.13-1.5.x86_64 to libenca0-1.13-1.5.i586
architecture change of librcc0-0.2.9-2.3.x86_64 to librcc0-0.2.9-2.3.i586
install librcc0-0.2.9-2.3.i586 despite the inferior architecture
deinstallation of vlc-noX-1.1.1-1.pm.1.4.x86_64
deinstallation of vlc-1.1.1-1.pm.1.4.x86_64
deinstallation of vlc-qt-1.1.1-1.pm.1.4.x86_64
architecture change of libass4-0.9.7-7.2.x86_64 to libass4-0.9.7-7.2.i586
install libass4-0.9.7-7.2.i586 despite the inferior architecture
architecture change of unzip-5.52-148.1.x86_64 to unzip-5.52-148.1.i586
architecture change of libiptcdata0-1.0.4-6.1.x86_64 to libiptcdata0-1.0.4-6.1.i586
architecture change of libtracker-client-0_8-0-0.8.5-2.7.x86_64 to libtracker-client-0_8-0-0.8.5-3.3.1.i586

tracker-0.8.5-3.3.1.x86_64 requires libexempi.so.3()(64bit), but this requirement cannot be provided
uninstallable providers: libexempi3-2.1.1-5.1.x86_64[openSUSE-11.3-Oss]
] Following actions will be done:
deinstallation of tracker-0.8.5-2.7.x86_64
deinstallation of libtracker-extract-0_8-0-0.8.5-2.7.x86_64
deinstallation of libtracker-miner-0_8-0-0.8.5-2.7.x86_64
] break tracker by ignoring some of its dependencies

 ] do not install patch:evolution-tracker-3621.noarch

 ] Following actions will be done:

architecture change of libexempi3-2.1.1-5.1.i586 to libexempi3-2.1.1-5.1.x86_64
architecture change of libgee2-0.5.0-1.8.i586 to libgee2-0.5.0-1.8.x86_64

kopete-4.4.4-2.3.1.x86_64 requires libgadu.so.3()(64bit), but this requirement cannot be provided
uninstallable providers: libgadu3-1.9.0-1.4.x86_64[openSUSE-11.3-Oss]
] Following actions will be done:
architecture change of libgadu3-1.9.0-1.4.i586 to libgadu3-1.9.0-1.4.x86_64
architecture change of libmsn0_3-4.1-2.9.i586 to libmsn0_3-4.1-2.9.x86_64
architecture change of libotr2-3.2.0-5.1.i586 to libotr2-3.2.0-5.1.x86_64
architecture change of meanwhile-1.0.2-116.2.i586 to meanwhile-1.0.2-116.2.x86_64
] do not install patch:kdenetwork4-3560.noarch

 ] break kopete by ignoring some of its dependencies

 ] deinstallation of kopete-4.4.4-1.4.x86_64

YaST2 conflicts list END

And that’s just the first screen. If I click it through manually I get next screen which is even longer and has the next batch of conflicts. It was even more with Packman.

In the end I just cancel the update because I have no idea what this breaking dependencies and changing architecture can do to my system.

#8

You did say KDE system? You seem to have a number of Gnome apps in that output? Those architecture changes from 64bit to 32bit are strange. If you are doing this manually with YaST, it’s difficult to know what you are doing to get this?

If you disable packman, any packman apps will be deinstalled and some will be replaced from oss repo resulting in a vendor change (packman>openSUSE oss), which causes dependency conflicts where you must make the decisions and answer the solver’s questions.

When you enable packman, and there are many updates in waiting, even if an existing packman package is being updated, some dependencies may need to change vendor so you will need to confirm the appropriate actions by interaction with YaST.

When you upgrade a system from one release to another, this can be tedious and complicated to do it manually with large numbers of updates and vendor changes. That’s why “zypper dup” was provided to do a distribution upgrade. Your system has been left unmaintained for so long, that it is similar in complexity to a distribution upgrade. However you can use “zypper dup” to achieve an 11.3 to 11.3 update.

In addition to my previous suggestion, you could disable packman repo and do a “zypper dup”, that should lead to an updated 11.3 system but without fully working multimedia apps. It will take care of the vendor changes (assuming your repos are the right ones, and refreshed). However you will then have to go through the multimedia installation process/guide from scratch.

Of course you can do nothing and run a system without updating it. If you do and connect to the internet, there are the obvious security risks.

#9

I enabled Packman and did zypper dup. There were lots of “unable to retrieve” messages, mostly from Packman repo, and I chose ignore to all of them. When it finished I refreshed Packman, just in case I forgot to do so when I started this thread, and did zypper dup again. This time it picked up only two problems with proposed solutions, I choose to keep old versions of some xine and mplayer libraries.

Now the “Online Update” is finally empty, nothing to do.

I had no idea that “distribution update” would work in a totally different way from “online update” I tried first.

What’s the secret? For the future reference.

Also, is there anything I can do to check if all my “ingore” and “keep old” choices had damaged the system in some way? Dependencies are all ok, Yast reports, but maybe zypper has some other magic command?

#10

Good. Probably a refresh issue, but well done for re-running zypper dup. To reduce that complexity down to only two remaining issues with one command, must be a relief to you and a very good result. With just a couple of problems left to check out, I would normally look at those with YaST, as you can display a lot of info and quickly switch between the tabs. Viewing by repository, selecting packman, is a good idea to home in on those xine and mplayer libraries to see if an update (best if possible) can be achieved. With packman, sometimes the 64bit rpm updates arrive a bit later than the 32bit rpm’s. Wait for the 64bit versions before updating.

Now the “Online Update” is finally empty, nothing to do.

Ok, but xine and mplayer libraries are important and should be kept up to date along with the multimedia packages that use them. You can probably find out which packages from a zypp log file located at /var/log/zypp/history. It’s a very long, plain text file, so click to view it.

I had no idea that “distribution update” would work in a totally different way from “online update” I tried first.

What’s the secret? For the future reference.

To be correct, you just did an online distribution upgrade (zypper dup) which allows vendor changes. You can do an online update that doesn’t allow vendors to change i.e. zypper update (or zypper up). You can read about those and other useful zypper commands in a Wiki document, and here is the link:

SDB: Zypper usage 11.3

BTW, using the “Online Update” facility of YaST allows you to apply official patches from the Update repo only, to openSUSE distributed packages.

The next step step is to find out the exact package names for those you ignored/kept old versions using the log and/or YaST. Please post back here with any further questions on that. :slight_smile:

#11

I get lots and lots of entries in that log file that all look like this

warning: /var/cache/zypp/packages/http:__packman.iu-bremen.de_suse_11.3/x86_64/vlc-1.1.5-5.pm.10.5.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 9a795806: NOKEY

2011-01-22 13:12:04|install|vlc|1.1.5-5.pm.10.5|x86_64||http://packman.iu-bremen.de/suse/11.3|016270a43b40c98a69be4d0b6c69f8d2b0359664

Is this something I have to worry about? Not vlc in particular but the warnings themselves. There are too many to post on the forum.

All other messages in the log look perfectly normal.

#12

Thank you, one example is enough. We all see those messages when updating packman packages. They are only warnings that their packagers are supposed to provide signature keys. It’s not best practice that they don’t, but the practice continues in spite of some users reminding them. So far so good, without real problems, and we are grateful for the packages., so generally we choose not to worry.

Did you find any entries for those packages you kept/ignored during the last zypper dup?

#13

No, nothing. The last update was very short and had two problems but there’s no sign of their record in the log file. They were kind of “keep old version/break/deinstall” choices where I chose the older versions of xine and mplayer libraries than they ones required.

As far as mplayer in concerned, it’s working fine.

#14

If it helps, for comparison here are my updated 11.3 xine libraries:

libxine1-pulse-1.1.19-2.pm.48.14.x86_64
libxine1-1.1.19-2.pm.48.14.x86_64
libxine1-gnome-vfs-1.1.19-2.pm.48.14.x86_64
libxine1-codecs-1.1.19-2.pm.48.14.x86_64

and mplayer packages:

MPlayer-1.0rc4_r32749-1.pm.2.2.x86_64
gmplayer-1.0rc4_r32749-1.pm.2.2.x86_64
smplayer-0.6.9+r3597-1.pm.2.2.x86_64

BTW, I did notice an available update for libxine1-codecs, but didn’t update it because of a conflict with missing 64-bit package dependencies. I will not change to a lesser architecture package, so will await the 64bit versions.

#15

Actually we do not. In fact, Packman does use signature keys as well.

#16

The repo signature key is accepted here, but individual package updates do throw up warning messages here.

#17

If it helps, for comparison here are my updated 11.3 xine libraries:

libxine1-pulse-1.1.19-2.pm.48.14.x86_64
…

Interesting. All my libxine1 packages are 1.1.18.1-1.37

libxine1-codecs package, however, shows up 1.1.19-2.pm.48.15 being available (I guess that’s what “alternative” means in this context) but trying to update it via Yast gives me

YaST2 conflicts list - generated 2011-01-22 22:39:16

libxine1-codecs-1.1.19-2.pm.48.15.i586 requires libpostproc.so.51, but this requirement cannot be provided
uninstallable providers: libpostproc51-0.6.26387svn-1.pm.2.1.i586[http://packman.iu-bremen.de/suse/11.3]
] do not install libxine1-codecs-1.1.19-2.pm.48.15.i586

 ] Following actions will be done:

install libpostproc51-0.6.26387svn-1.pm.2.1.i586 despite the inferior architecture
install libavcodec52-0.6.26387svn-1.pm.2.1.i586 despite the inferior architecture
install libavutil50-0.6.26387svn-1.pm.2.1.i586 despite the inferior architecture
…

The list goes on and on and on. Yast reported there were 496 problems like this altogether, I’m not posting it all.

Some lines, however, are slightly different, like this one:

architecture change of libpostproc51-0.6.26387svn-1.pm.1.1.x86_64 to libpostproc51-0.6.26387svn-1.pm.2.1.i586

My Packman is Index of /suse/11.3 and at the moment I run the system on Google DNS so as to avoid local name resolution issues.

My mplayer packages seem to be the same and there are no better available but in the dependencies for gmlayer I found this:

rpmlib(CompressedFileNames) <= 3.0.4-1

whereas “alternate”, I suppose expected, version is

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

It looks like one of those things where I clicked “keep the old version” when the conflict came up during zypper dup earlier today. I can’t find rpmlib itself anywhere in Yast, btw. There are tons of packages depending on it, though and all I checked requre <= 4.0-1

Shouldn’t affect mplayer’s work, should it? It’s <= afterall.

#18

The problem is that you did an update without packman attached at some point hence the libxine packages without “pm” in the name, and there may be others. Check with the Multimedia Guide in the Howto forum.

Also note my comment at the bottom of post #14 about waiting for the 64bit packages that are missing in the packman repo. Don’t do any updates now, wait unti the problem is fixed. You can check a package availability under the Version tab in Yast>software management.

#19

Ok, I see, libxine1 1.1.19-2.pm are available from Packman in Versions tab but not in 64 bit yet. Same goes for other packages xine packages.

I remember your advice to wait for Packman, but how did you get your 1.1.19? Did you go through all those “architecture change” offers?

#20

My gmplayer info is the same as yours, so ignore it. “rpmlib” is not the name of a package. Don’t worry about that now, and yes lots of package refer to it. It shouldn’t affect mplayer working.