Installing XINE
Bill Fink
yellowdog-general@lists.terrasoftsolutions.com
Thu May 22 11:09:00 2003
Hi Matthias,
On Thu May 22 2003, Matthias Saou wrote:
> Bill Fink wrote :
>
> > > - You usually get something "known to work"
> >
> > Presumably known to work on the system of the binary RPM builder, and
> > thus hopefully (but not necessarily) will also work fine on the user's
> > system.
>
> Once again the same assumption : The builder _must_ use a clean default
> system to build, just like most (if not all) of the original binaries from
> the main distributions were built.
And assuming that the user hasn't made any incompatible upgrades.
> > > - You usually get support for useful extra features (faad2, xvid,
> > > flac...)
> >
> > This has a flip side. Even if you have no interest in these extra
> > features, you're forced to install all the extra RPMs to satisfy all
> > the dependencies.
>
> True, but for the average end user, having a few extras that can come in
> handy some day is generally better than not having any. If you're an
> "experienced" user, you can rebuild most of my packages trivially,
> disabling or enabling options to your liking. Just look at the description.
> For xine-lib you have for instance :
>
> --with : rte ext-dvdnav
> --without : alsa aalib libfame flac esound arts gnomevfs2 xvid
>
> Which you can use like this :
> rpmbuild --rebuild --with foo --without bar yourpackage.src.rpm
I agree this is a relatively minor point, and mainly just means wasting
some disk space for things you may never use (but disk is cheap nowadays
and the main distro wastes lots more disk space on scores of packages
that won't ever be used).
> > > - You usually get better system integration (init script, menu entry)
> >
> > If the package developer includes a SPEC file so that you can do
> > the "rpm -ta", then they have probably taken care of this. In any
> > event this depends again on whoever created the SPEC file.
>
> Most developers don't include distro specific files, the best example would
> be recent "freedesktop" desktop files that aren't present in many tarballs.
> This is a typical "added value" of good rpm packages.
Good point.
> > And there are some reasons for having to build from a source RPM
> > rather than using a binary RPM, foremost among them being if your
> > system has an incompatible environment from that of the binary RPM
> > builder, such as a different glibc or XFree86 (for the xine case).
>
> Hmmm, if you use a different distribution or a different version of the
> distribution that the package was compiled for, I agree. But if the
> packages are meant for the exact distro and version you're running, there
> is really no point on recompiling source packages unless you've "messed up"
> your system in an incompatible way, or you really want to add/remove a
> feature as explained above.
Agreed.
> > I did try out the freshrpms binary xine RPMs and they worked quite
> > well on all my test streams, but in the end I decided not to use
> > them. First, there was a minor problem with using the CDDA plugin,
> > which complained about not being able to find the libcdda shared
> > library (which I don't get with the xine RPMs I built myself).
> > However, this was just a minor annoyance since the CDDA plugin
> > still worked fine to play a CD despite spitting out this error
> > message.
>
> This is really weird! Possibly a missing cdparanoia dependency because of
> an ugly way of using it from within xine, thus not getting linked nor
> detected as a dependency by rpm... Do you have cdparanoia installed? Could
> you eventually try my package again with then without cdparanoia installed?
I have cdparanoia already installed.
gwiz% rpm -q cdparanoia
cdparanoia-alpha9.8-11
Here are the xine messages when using the CDDA plugin to play a CD.
gwiz% xine
This is xine (X11 gui) - a free video player v0.9.21
(c) 2000-2003 by G. Bartsch and the xine project team.
Built with xine library 1.0.0 (1-beta12)
Found xine library version: 1.0.0 (1-beta12).
XServer Vendor: The XFree86 Project, Inc. Release: 40300000,
Protocol Version: 11, Revision: 0,
Available Screen(s): 1, using 0
Depth: 24.
XShmQueryVersion: 1.1.
-[ xiTK version 0.10.3 ]-
-[ xiTK will use XShm ]-
-[ WM type: (EWMH) KWIN {KWin} ]-
Display is not using Xinerama.
xine_interface: unknown param 10
xine_interface: unknown param 10
xine_interface: unknown param 10
xine_interface: unknown param 10
vo_scale: invalid ratio, using 4:3
vo_scale: unknown aspect ratio (0) in stream => using 4:3
(process:25912): libgnomevfs-WARNING **: Cannot load module `/usr/lib/gnome-vfs-2.0/modules/libcdda.so' (/usr/lib/gnome-vfs-2.0/modules/libcdda.so: cannot open shared object file: No such file or directory)
(process:25912): libgnomevfs-WARNING **: Cannot load module `/usr/lib/gnome-vfs-2.0/modules/libcdda.so' (/usr/lib/gnome-vfs-2.0/modules/libcdda.so: cannot open shared object file: No such file or directory)
Sure enough I don't have:
/usr/lib/gnome-vfs-2.0/modules/libcdda.so
> > The more serious issue is that the freshrpms xine RPMs don't use
> > the "official" package names (as defined by the xine provided SPEC
> > files). I first got bit by this when I tried using the freshrpms
> > xine-skins RPM with my personally built xine RPMs, and couldn't use
> > it because it has a dependency on xine rather than xine-ui.
>
> I would start with trying to define what an "official name" is... when you
> have "xine-lib" that becomes "libxine1", you can start wondering. This
> naming is clearly not the one used by Red Hat nor Yellow Dog, though it is
> by Mandrake and a few others (for rpm, as it is for Debian's debs). For my
> packages, I prefer going the Red Hat way, and having "user friendly" names,
> which is why I have "xine" and not "xine-ui".
I figured that was probably the reason.
> > I then replaced my personally built xine RPMs with the ones from
> > freshrpms, and as I mentioned earlier, the xine/xine-lib combo
> > worked very well (with just the minor CDDA plugin glitch). But
> > then I decided to try out the freshrpms gxine RPM. I quickly
> > discovered that gxine always immediately segfaults on my system
> > when trying to play any media stream.
Actually the segfault was probably my error. I tried upgrading to
the new 0.3.3 freshrpms gxine RPM and was still getting the segfaults.
Some further investigation revealed I had an old version of gxine in
/usr/local. After removing all traces of that, the 0.3.3 version of
gxine ran OK except it produces the following errors which I don't
have in my personally built version.
gwiz% gxine basketba.mpg
server: trying to connect to already running instance of gxine (/me/bill/.gxine/socket)...
connect: Connection refused
server: socket '/me/bill/.gxine/socket' created
lirc: lirc_init failed. Make sure that you have lircd running
lirc: and that you have the permissions to connect to the socket
(gxine:25947): GLib-CRITICAL **: file ghash.c: line 225 (g_hash_table_lookup): assertion `hash_table != NULL' failed
(gxine:25947): libgnomevfs-WARNING **: Internal error: the configuration system was not initialized. Did you call _gnome_vfs_configuration_init?
(gxine:25947): GLib-CRITICAL **: file ghash.c: line 225 (g_hash_table_lookup): assertion `hash_table != NULL' failed
(gxine:25947): libgnomevfs-WARNING **: Internal error: the configuration system was not initialized. Did you call _gnome_vfs_configuration_init?
vo_scale: unknown aspect ratio (12) in stream => using 4:3
The latter errors look like they would mess up using the gxine
configuration widget, although I haven't actually tried it. I've
switched back to my personally built versions of xine-ui/gxine/xine-lib
for now. At this point it's fairly easy for me to switch back and
forth between the freshrpms versions and my personally built versions.
> > Since this is a known problem with the 0.3.2 version of gxine (which
> > is what freshrpms provides), I decided to upgrade to the 0.3.3 version.
> > This is another obvious case where you need to build from source, i.e.
> > there is no binary RPM available.
> [...]
>
> Argh. Well, I'd be grateful if you'd also notify me that I've missed a ppc
> package rebuild ;-) If you look carefully, the 0.3.3 package has been
> available for i386 for a while. I'll rebuild it for ppc right away.
Thanks.
> > In summary, for most users (including myself) and most circumstances,
> > using binary RPMs is the easiest and preferred method, but there are
> > some cases where building from a source RPM or source tar.gz file is
> > either necessary or desirable.
>
> ...but please don't forget that I'm always lurking, and that mentioning
> eventual mistakes in my packages, releases I forgot to update, suggesting
> improvements (patches to my specs ;-)) is all very welcome!
I'll keep that in mind for the future. You do seem to be very
responsive at making updates.
-Bill