mplayer

T-u-N-i-X · 2007-12-06 01:57:10

mplayer should be recompiled against libx264 since:

[03:56] (tunix@penguix ~)$ mplayer
mplayer: error while loading shared libraries: libx264.so.55: cannot open shared object file: No such file or directory

in my system, /usr/lib/libx264.so.57 exist.

skottish · 2007-12-06 03:44:07

Looks like you're using x264 from testing. There are quiet a few programs that are going to need to be rebuilt, not just Mplayer.

Last edited by skottish (2007-12-06 03:46:19)

shining · 2007-12-06 12:24:49

I was going to ask you to report a bug, but you did it already
http://bugs.archlinux.org/task/8847
So thanks for doing it, but giving a link to it here would have been even better

Acid7711 · 2007-12-06 21:48:11

Yeah, had this problem myself, was hoping it was going to be caught and resolved with a mplayer compiled against it with the new version of x264 in Testing....so far hasn't so I reverted back to the extra-repo version.

skottish · 2007-12-06 22:09:16

Personally, I'd be patient unless you want to have a bunch of custom packages on your system. Mplayer, FFmpeg, VLC, Gnash, Swfdec, gstreamer-ffmpeg are all packages that use x264 directly or a package that uses it. There are a lot more. Upgrading will be a major undertaking for the devs.

Last edited by skottish (2007-12-06 22:11:32)

T-u-N-i-X · 2007-12-06 22:18:10

The devs closed the bugreport I've entered.. They say that it ain't a bug which we already know.. Not everyone can compile mplayer but want bleeding edge software So it would be nice to do it.. Any way; doing

ln -s /usr/lib/libx264.so.57 /usr/lib/libx264.so.55

solves the problem temporarily..

Acid7711 · 2007-12-07 01:23:34

skottish wrote:

Personally, I'd be patient unless you want to have a bunch of custom packages on your system. Mplayer, FFmpeg, VLC, Gnash, Swfdec, gstreamer-ffmpeg are all packages that use x264 directly or a package that uses it. There are a lot more. Upgrading will be a major undertaking for the devs.

I have no problem waiting, I would just think that when packages depend upon another specifically being compiled against it, those would be added the same time into the testing repo as the package that's causing the recompilation. I'm not trying to be an ass, I understand people are busy and there are other priorities, but then the package that causes it could be delayed for a while.

Yes, the symlinking stuff works, but it's awfully messy imo. I recommend just reverting by hand back.

Last edited by Acid7711 (2007-12-07 01:24:50)

maveric7911 · 2007-12-07 15:09:16

Acid your exactly right. I'm not sure why that made it into the repo when its well know that it will break many packages. Its completely understandable that the devs do not have a mass amount of time to fix all the packages that have deps on it, however that being said its not very understandable why arch would release that package into testing knowing what problems it will cause. These kinds of packages should be held until useful testing can be done on them.

toofishes · 2007-12-07 15:32:20

maveric7911 wrote:

Acid your exactly right. I'm not sure why that made it into the repo when its well know that it will break many packages. Its completely understandable that the devs do not have a mass amount of time to fix all the packages that have deps on it, however that being said its not very understandable why arch would release that package into testing knowing what problems it will cause. These kinds of packages should be held until useful testing can be done on them.

Wait...so we shouldn't use the testing repo for testing?

shining · 2007-12-07 15:59:29

toofishes wrote:

maveric7911 wrote:
Acid your exactly right. I'm not sure why that made it into the repo when its well know that it will break many packages. Its completely understandable that the devs do not have a mass amount of time to fix all the packages that have deps on it, however that being said its not very understandable why arch would release that package into testing knowing what problems it will cause. These kinds of packages should be held until useful testing can be done on them.
Wait...so we shouldn't use the testing repo for testing?

No, you should use the unstable repo for testing the testing packages, that way we would have a second debian

Seriously now, I wasn't even aware bugs couldn't be reported when a package needs to be rebuilt for testing. I thought it helped to make sure no packages are forgotten during the rebuild, before moving them to core/extra.
What I'm trying to say is that it might not be obvious at first sight that this kind of bugs should never be reported. But if there is already a clear guideline about it somewhere, I guess it's alright.

maveric7911 · 2007-12-07 16:02:19

The package isn't being tested if most things that use it become broken... Thats all I am stating, however I do understand your point and where you are coming from as well. Just seems more sensible even in testing to not release things that won't really be tested until devs have a chance to rebuild its deps. Its kinda like releasing a gnome update but only actually updating a single package. Wouldn't make a whole ton of sense. This isn't a blame game or yell at the devs flame fest, just a policy question that's all.

Last edited by maveric7911 (2007-12-07 16:05:09)

Arch Linux

#1 2007-12-06 01:57:10

mplayer

#2 2007-12-06 03:44:07

Re: mplayer

#3 2007-12-06 12:24:49

Re: mplayer

#4 2007-12-06 21:48:11

Re: mplayer

#5 2007-12-06 22:09:16

Re: mplayer

#6 2007-12-06 22:18:10

Re: mplayer

#7 2007-12-07 01:23:34

Re: mplayer

#8 2007-12-07 15:09:16

Re: mplayer

#9 2007-12-07 15:32:20

Re: mplayer

#10 2007-12-07 15:59:29

Re: mplayer

#11 2007-12-07 16:02:19

Re: mplayer

Board footer