Bugzilla Bug 113923

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 an attachment (id=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 an attachment (id=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 an attachment (id=76513) [details]
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 an attachment (id=83065) [details]
kino-0.8.0 ebuild including the second patch (checking for dirname... no)

Created an attachment (id=83066) [details]
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