Kino-0.8.0 is, tried to copy the 0.7.6 ebuild but fails on quicktime errors. Tried -quicktime but still fails. Tried the ln -s /usr/include/lqt /usr/include/quicktime trick from the forums but still fails Reproducible: Always Steps to Reproduce: 1. 2. 3.
I discovered, after an extensive search on internet, that kino depends on cinelerra-cvs. libquicktimehv seems to be a internal library of cinelerra 2.0.x. To check this I emerged cinelerra-cvs and used the copied kino-0.7.6 ebuild (now kino-0.8.0), After this Kino compiled without an error.
It seems additional changes are required, since Kino 0.8 has its gnome dependencies removed and requires gtk+ 2.6
Most importantly, kino-0.8.0 introduces support for ALSA which is a must for KDE-3.5.x. kino-0.7.6 competes with artsd for /dev/dsp and won't produce output with ALSA's aoss wrapper :-(
Created attachment 75653 [details] Bumped ebuild. This ebuild works. Includes the cinelerra-cvs dependendency. Not positive everything is in the dep listing due to the fact I may have some deps already installed. The cinelerra dep is an ugly one but with it Kino 0.8.0 compiles and starts up.
The bumped ebuild #75653 is didn't quite work first time - media-libs/libdv needs to be >=1.03 (which is currently still in testing) according to configure.in. I also see it claims to depend on sys-libs/libraw1394>=1.00, sys-libs/libavc1394>=0.4.1 (both currently stable), and some more complicated dependancies on alsa, gtk and others - I don't know if they need to be expressed in the ebuild (they weren't in eariler ones). Otherwise this seems to work on my AMD64.
(In reply to comment #5) > I also see it claims to depend on sys-libs/libraw1394>=1.00, > sys-libs/libavc1394>=0.4.1 (both currently stable), and some more complicated > dependancies on alsa, gtk and others - I don't know if they need to be > expressed in the ebuild (they weren't in eariler ones). I would expect that all dependencies should be expressed in the ebuild either directly or conditionally on USE settings. ALSA support is new to kino-0.8.0 and the gtk dependencies are probably a result of dropping the GNOME dependencies in favour of GTK-2.6. I'm a little alarmed at the dependency on cinelerra-cvs for quicktime support. Is there no way to achieve the same functionality using quicktime libraries that are already available in portage?
http://svn.rpmforge.net/svn/trunk/rpms/kino/kino-0.8.0-libquicktime.patch suggests we can switch the lib dependancy to a normal libquicktime, and this certainly allows configuration & compilation to work. (I'd previously upped my libquicktime to the testing version as configure.in suggests 0.9.5 as a minimum.) But this was outside portage as I don't know how to make an ebuild which corrects the configure.in & regenerates the configure script. I didn't want to mess up my system with old files in stupid places by make-installing from outside portage, but Kino won't run without it (glade errors) so I don't know if will actually work. BTW, using a non-standard prefix when configuring showed up another error in configure.in - the LIBQUICKTIME_CFLAGS are dependant on $prefix when I suspect they should be on something about where the header was found instead. We could change dependency to libquicktime explicitly (as some other ebuilds are rather than virtual/quicktime - openquicktime is a little old) & drop that whole first block...
Created attachment 76512 [details] New ebuild with quicktime fix I've added this ebuild (including a patch to follow) to correctly use libquicktime, and improve dependancies & their versions. Seeing as we don't have a proper quicktime4linux ebuild (only cinelerra-cvs), I'm still open to patching that out entirely & forcing libquicktime only. (BTW, not using virtual/quicktime to enable the version spec & as openquicktime is pretty old - not sure if it works.) I've left the ALSA dependancy (>=1.0.9) unspecified to allow those without to keep using OSS - the existing configure script should cope.
Created attachment 76513 [details, diff] Patch to configure.in for quicktime & ffmpeg This patch to go with my ebuild (attachment 76512 [details]) to enable compilation with/without quicktime and ffmpeg/avcodec. Have sent upstream for review, but thought I'd let you guys see it also, along with the ebuild. Save in files subdir of your local portage overlay for the ebuild to find it.
(In reply to comment #8) > I've left the ALSA dependancy (>=1.0.9) unspecified to allow those without to > keep using OSS - the existing configure script should cope. Reading the News for kino-0.8.0 on kinodv.org suggests that ALSA and OSS can coexist and you select which is used in the specification of the audio device in the kino preferences e.g. default vs. /dev/dsp That being the case, I would have thought that existing useflags could be used to conditionally include support for either or both.
Kino will link in ALSA libs if detected by the configure script, no need for USE flags unless you want USE="alsa" to force the dependancy on alsa-lib>=1.09. No way to turn *off* ALSA, e.g. when USE="-alsa", unless I expand the configure.in patch - but that seems dumb. Turning off OSS means patching the code, which seems even more unnecessary for no real effect. The only thing that would be nice is changing the default setting, which is what you had before or ALSA if nothing. As you say, you just change the audio device in the preferences to just the word "default" to start using ALSA. It has to be "/dev/dsp" (or whatever) to use OSS - either for real or actually ALSA's emulation. P.S. I had some trouble with using kino & ALSA proper (rather than OSS-emulation) on my AMD64 with SonicFury, but switching from gentoo-sources in-kernel drivers which are ALSA version 1.0.9rc2 (according to 'cat /proc/asound/version') to the latest mm-sources at 1.0.11rc2 fixed it. Hence this slow reply...
I tried this ebuild today but ran into the same problem this person has posted about: http://sourceforge.net/mailarchive/forum.php?thread_id=9092534&forum_id=5545 I obtained the patch in this response: http://sourceforge.net/mailarchive/forum.php?thread_id=9092536&forum_id=5545 The patch fixed the configuration issue. If desired, I can provide an updated ebuild and also that patch.
Created attachment 83065 [details] kino-0.8.0 ebuild including the second patch (checking for dirname... no)
Created attachment 83066 [details, diff] patch for kino-0.8.0 ebuild including the second patch (checking for dirname... no)
this is in portage, thanks to everyone who contributed on this bug
