Mplayer SVN new snapshot

[Armin K]

Tarball: ​http://www.linuxfromscratch.org/~krejzi/mplayer-1.0~rc4+svn20120427.tar.xz md5sum: ​http://www.linuxfromscratch.org/~krejzi/mplayer-1.0~rc4+svn20120427.tar.xz.md5sum

Snapshot from today. Builds and works on LFS 7.0!

[ken@…]

Builds and works for me on 7.1 with the current instructions (see issue below), on x86_64, using *old* glib2, gtk2; dvdnav and dvdread from the book (--with-dvdnav-config=/usr/bin etc), cdparanoia, libcdio, rtmpdump, alsa, libpng, jpeg (8c), giflib, openjpeg, libmad, libtheora, faad2, xvid, libvpx, lame, x264, fontconfig, freetype, fribidi, libxslt, docbook*. So, not testing *all* the deps :)

Only tested with local video files (various formats), but feel free to add my '&lfs71_checked;' if you are still using 7.0 when you do this.

Issue:

The instructions say to untar the skin as root. This causes the files to be owned by root:root, so the chown seems redundant. More importantly, the chmod 755 is unnecessary - almost all of the files in skins/Blue are png, I *really* would not want to have executable graphics files and icons, nor the README, and it seems that none of them need to be executable.

[Armin K]

I don't use GTK+ interface, only cli. I use gnome-mplayer and gecko-mediaplayer (browser plugins) for that. That means there is no need for skins here. I'd like someone else to do the upgrade stuff, I still have about 30 packages to handle to get all of gnome upgraded.

Yay, responded to email instead of here.

[ken@…]

I could probably pick this up in a few days, when I've built an up-to-date LFS-svn system (my current builds of that are just testing that things build in /scratch/lfs so I can't actually run any desktop progs there). I'm not willing to do it until I'm running the glib/gtk/etc versions from the book.

But: the version in the book is only about 7 weeks old - is there some reason that the book _needs_ a newer version ? When a package doesn't make formal releases, I find it hard to justify making frequent updates to the book unless it solves a real problem.

[bdubbs@…]

Replying to ken@…:

I could probably pick this up in a few days

But: the version in the book is only about 7 weeks old - is there some reason that the book _needs_ a newer version ? When a package doesn't make formal releases, I find it hard to justify making frequent updates to the book unless it solves a real problem.

No big hurry. Just accept the ticket and do it when you get the chance.

[ken@…]

Unless Armin explains why a newer version is needed, I'm not touching this. It isn't a package I normally use - I much prefer applications using my system version of ffmpeg.

[Armin K]

I have no good reason about why new version is needed. Previous one works too, right. I just took an opportunity to upload new version while I was upgrading mine. No one said this one is a must in the book. Just mark it as wontfix or whatever if you feel like that, or let it stay here. Eventualy, myself or someone else will pick this one, or even I or someone else will make new snapshot when necesary.

As for the system ffmpeg - mplayer can be built against system ffmpeg, but I fear it has to be latest snapshot of ffmpeg or you might get "undefined reference" when linking mplayer. Debian has got mplayer snapshot that builds fine with external libav 0.8 (ffmpeg 0.8?). Just pass --disable-ffmpeg_a --enable-ffmpeg_so or something like that to the mplayer configure line.

[andy@…]

I think you had the right idea, updating Mplayer every so often is good. Once a month doesn't seem too often to me, it's just that everyone's busy right now (I think I'll be busy for a week).

As for compiling Mplayer against a system FFmpeg, I used to do that about 2 years ago but it got to be so crashy it was unusable. The statically linked blob we do now is not ideal but it does work. Working is good ;)

[ken@…]

Replying to andy@…:

I think you had the right idea, updating Mplayer every so often is good. Once a month doesn't seem too often to me, it's just that everyone's busy right now (I think I'll be busy for a week).

As for compiling Mplayer against a system FFmpeg, I used to do that about 2 years ago but it got to be so crashy it was unusable. The statically linked blob we do now is not ideal but it does work. Working is good ;)

But, but, but - once a month - that's more often than I update firefox! OK, you guys know this package better than I do. Maybe I've been spoiled by ffmpeg's stable releases. I'll pick it up.

[ken@…]

I'll be a bit delayed with this (want to test it with current LFS-svn and current BLFS, but sound is broken - looks like the glibc bug which has bitten some people since glibc-2.14. Will try the patch for (e)glibc from cross-lfs, but I need to rebuild the whole system.

[Armin K]

Wow ... You people seem never to test anything new. Who told you that you need to rebuild whole system if you rebuild glibc?

I've tested three situations: You don't need to rebuild whole system nor anything else when: Upgrading glibc minor versions (eg 2.14 to 2.14.1) or recompile same version (eg with patch applied) You might need to recompile some/most of the stuff when: Upgrading glibc major versions (eg from 2.13 to 2.14). Then you needed to recompile stuff that was using rpc and some obsolete functions that maybe were removed in next release. You need to recompile everything when: Downgrading glibc (eg from 2.14 to 2.13) and everything was compiled with 2.14 and when the library soname changes (libc.so.5 to libc.so.6 change happened quite long time ago, I was a little boy back then I think!).

[ken@…]

Fixed in r10064, URL points to Armin's webspace, but URL for anduin has been updated and commented.

[bdubbs@…]

Milestone current deleted