smplayer: break new or retain old version

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...
Reading installed packages...
Computing distribution upgrade...

Problem: nothing provides libtinfo.so.5(NCURSES_TINFO_5.0.19991023) needed by MPlayer-1.1.1.r37373-1.2.i586
 Solution 1: keep obsolete MPlayer-1.1.1.r37373-1.1.x86_64
 Solution 2: break MPlayer-1.1.1.r37373-1.2.i586 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/c] (c): c


This is the only update I can see from today’s dup and as you can see there is a problem.

I saw a response in 2010 to a remarkably similar problem here:https://forums.opensuse.org/showthread.php/446927-missing-library-libtinfo-so-5

the solution indicates the following:

cd /lib64
sudo ln -s libncurses.so.5.7 libtinfo.so.5

I don’t mind doing that - except - the thread is 5 years old and I would have thought that whatever was bothering ncurses or whatever back then would have surely been picked up and mended by now.

So I haven’t done anything yet.

edit: just reread my own error output - one of the smplayers referred to is not a 64 bit version!! Now how did that sneak in?
Hiugh

Well, I suppose you should just wait until the new libncurses5 (against which Packman’s MPlayer is already built against) hits the Tumbleweed repo (should happen when the next Tumbleweed snapshot is published).
Then this conflict should resolve itself…

IOW: a new libncurses5 has been accepted to Factory yesterday (after it passed testing). Packman already built their MPlayer package against it, but it isn’t in the Tumbleweed repo yet.
Just be patient, and keep the old version for now.
The other option would install the 32bit version of MPlayer anyway, which probably is not at all a good idea on your 64bit system… :wink:

No. I did the update with retain 64Bit version and there were no errors.

The mystery (forme, it may not be a mystery for anybody else!) is where did the non-64 bit package come from?
I use your factory frameworks repos by the way.
Should I go back to your tumbleweed repos?

cheers,

Hugh

That’s no mystery at all. The 32bit package comes from the same repo as the 64bit one.
There are no specific repos for 32bit/64bit (i586/x86_64), zypper chooses itself which version to install.

In your case, it couldn’t install the 64bit version because of the conflict, so it tried the 32bit version instead. This gave a conflict as well, so it reported that and asked for how to resolve it.

And you can run 32bit applications on a 64bit system. You just need all dependencies in 32bit as well, and the question is whether it will make sense if there is a 64bit available.

In this case, the 32bit version wouldn’t have worked anyway, because of the missing ncurses update. Exactly the same as for the 64bit version.

I use your factory frameworks repos by the way.
Should I go back to your tumbleweed repos?

That’s irrelevant in this case.
And both should work fine.

But I’ll shortly describe the difference:
The Factory flavour is built against KDE:Frameworks5, while the Tumbleweed one is only built against standard Tumbleweed.
That means that with the Factory repo you absolutely need the KDE:Frameworks5 repo as well, whereas for the Tumbleweed flavour no additional repo is needed (just add my repo to your standard Tumbleweed system).

Otherwise there’s not much difference, as the packages from KDE:Frameworks5 are submitted to Tumbleweed anyway (KDE:Frameworks5 is the devel repo for Factory/Tumbleweed). But as they need to go through testing and are only published if the whole Factory/Tumbleweed passes all tests, this needs a few days, simetimes even weeks. So you’ll get new KF5 or Plasma updates some time later.
E.g. at the moment Plasma 5.2.1 is being prepared in KDE:Frameworks5 (and in my repo), “Factory” will get it on Tuesday. They will probably submit it to Factory/Tumbleweed on Tuesday as well, but you will only get it a week (or something like that) later in the Tumbleweed repo.
KF 5.7.0 is available in KDE:Frameworks5 since 2 weeks already. This has been submitted to Factory/Tumbleweed back then, but only was accepted to Factory/Tumbleweed 6 days ago (after review/testing).

In the end you have to choose what you prefer.

Factory is bleeding edge, Tumbleweed is the same after testing/review, but that testing/review process causes a delay.
Not that it makes much difference for the additional applications (those that are not available in KDE:Frameworks5 and Factory/Tumbleweed) in my repo though, those are bleeding edge/unstable git snapshots anyway… :wink:

PS: OTOH, if you choose to use my Tumbleweed repo, you should not add KDE:Qt5 nor KDE:Frameworks5 repos and should rather remove them. Else you will experience temporary problems when KF5 or Plasma5 is updated.

a new libncurses5 has been accepted to Factory yesterday (after it passed testing). Packman already built their MPlayer package against it, but it isn't in the Tumbleweed repo yet.

Thanks for this information I did a fresh install of the latest tumbleweed iso yesterday and had the same issue trying to install mplayer from the packman repo. I just installed the previous packman mplayer version but it is good to understand what the issue was.

Excellent info.
Thanks.
Sorry I didn’t reply earlier but the new kernel - 3.19 - has upset my nvidia proprietary drivers
and I spent most of yesterday afternoon hunting down patches for my 340.xx driver.
So after breaking the driver - patch installed but was clearly useless as on this occasion the load nvidia the hard way method failed.
There were many reboots in action yesterday and much tearing of hair.

Upshot is I’m back with gallium and desperately unhappy.

Now this morning I am awake and alert and also relentless so I have downloaded the latest nvidia driver 340.76 did all the things we propietary driver users do - no need to list the method here: it is well documented and we take full responsibility for wanting the best drivers for our systems.

The dratted thing exited with error code status of 1.

I’m going to try another patch shortly and see how that goes.

All the best and thanks once again,

Hugh

You should still have the previous kernel installed. Select it in the boot menu (Advanced Options) and the nvidia driver should work. Although, with your actions you might have broken/removed the driver already…
But you could just uninstall kernel 3.19 for now and use the 3.18.x one again if you still have it installed. Then you should also succeed in reinstalling the nvidia driver.
Unfortunately, that one is not in the repo any more (it was yesterday).

Btw, the ncurses update has hit the repos meanwhile.

The latest issue of tumbleweed (released today) resolves the ncurses issue.

My humble apologies - I wasn’t looking for help with the Nvidia breakage. I would have started a new thread if that were the case - but Thanks anyway.

Hugh