Re: [Ekiga-devel-list] Ekiga and x264 in Debian main (was Re: Trunk: OPAL Fax problem)

[Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>]

Hi Matthias,

Thanks for answer.  See below.

Matthias Schneider wrote:
> Hi Eugen,
> see my answers inline.
>
>
>
> --- Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr> schrieb am So, 18.5.2008:
>
> > Von: Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>
> > Betreff: Re: [Ekiga-devel-list] Ekiga and x264 in Debian main (was Re: Trunk: OPAL Fax problem)
> > An: "Ekiga development mailing list" <ekiga-devel-list gnome org>
> > Datum: Sonntag, 18. Mai 2008, 15:53
> > Matthias Schneider wrote:
> > > Quoting Luca Capello <luca pca it>:
> > >
> > > > Hi there!
> > > >
> > > > On Thu, 08 May 2008 11:47:38 +0200, Damien Sandras
> > wrote:
> > > > > Le jeudi 08 mai 2008 Ã  11:45 +0200, Torsten
> > Schlabach a écrit :
> > > > > > Gismo / Luca wrote:
> > > > > >
> > > > > > > If ekiga build-depends on
> > > > > > > x264 (which, BTW, is *still* not
> > present as a Debian package, neither in
> > > > > > > non-free), ekiga itself will have to
> > be put in non-free, which is
> > > > > > > something I won't prefer.
> > > > > > No, we don't want that I think.
> > > > > It is a pwlib plugin, so it can be packaged
> > separately, and that
> > > > > specific plugin can be put in non-free.
> > > > Isn't instead an OPAL dependency?  However,
> > this won't solve anything,
> > > > as far as I understood Matthias at [1].  But as a
> > disclaimer, I haven't
> > > > checked ekiga trunk lately.
> > > >
> > > > Please re-read the definition of the Debian
> > categories [2]: a Debian
> > > > package to be in main (thus distributed with
> > official CDs) must
> > > > build-depend only on software present in main.
> > > >
> > > > This means that if opal build-depends on x264
> > (which is, let's say, in
> > > > non-free), then opal cannot be part of main.  My
> > previous statement that
> > > > in this case opal (well, I wrote ekiga...) has to
> > be put in non-free is
> > > > wrong: opal can go into contrib, since opal itself
> > is a "free package
> > > > which requires [...]  a non-free package for
> > compilation".  As a result,
> > > > ekiga has to be put in contrib, since ekiga
> > build-depends on opal, which
> > > > isn't in main.
> > > >
> > > > This situation will slow ekiga adoption, which is
> > something I don't want
> > > > to see.
> > > >
> > > > Thx, bye,
> > > > Gismo / Luca
> > > >
> > > > Footnotes:
> > > > [1]
> > http://mail.gnome.org/archives/ekiga-devel-list/2008-May/msg00023.html
> > > > [2]
> > http://www.debian.org/doc/debian-policy/ch-archive.html#s-sections
> > > Sorry, forgot to send the following mail to the
> > list...:
> > > About the packages issue, I suppose that there should
> > be packages like this:
> > > ekiga
> > > opal includes h.261 & theora or depends opal-h261
> > & oapl-theora
> > > ptlib
> > > opal-h263p depends libavcodec
> > > opal-mpeg4 depends libavcodec
> > > opal-h264 depends libavcodec & libx264
> > > opal / opal-theora depends libtheora
> > >
> > > ekiga/opal recommends opal-h263p, mpeg4, x264
> > >
> > > The opal-x packages can have different states on
> > ubuntu or debian, whether there
> > > is a non-free or whatever repository or some
> > unofficial add-on repository...
> >
> > Hi,
> >
> > I am doing the proposed modifications, thanks for the idea.
> >
> > 1. I grouped all libpt-snapshot-plugins-* packages into one
> > package, 
> > libpt-snapshot-plugins.
>
> Is this a good idea? I think stable has many separate plugins, since each plugin has different dependencies, at least I think so...

In Kilian's debs and in actual debian ones, all libpt-plugins-* depend 
on the same packages.  So it should be ok.

> > 2. Does opal, which is a library, depend on libspeex, or
> > ekiga?
> OPAL does, for echo cancelation, and of course the speex plugin does for the speex codec itself.

Ok.

> > 3. For opal, I see the following video codecs:
> > libopal-snapshot/usr/lib/ptlib-snapshot/opal-3.3.0/codecs/video:
> > total 776
> > -rw-r--r-- 1 dedu 344240 May 17 22:16
> > h261-vic_video_pwplugin.so
> > -rw-r--r-- 1 dedu 107144 May 17 22:16
> > h263-1998_video_pwplugin.so
> > -rw-r--r-- 1 dedu  63000 May 17 22:16
> > h263-ffmpeg_video_pwplugin.so
> > -rw-r--r-- 1 dedu  79352 May 17 22:16
> > h264_video_pwplugin.so
> > -rwxr-xr-x 1 dedu  40168 May 17 22:16
> > h264_video_pwplugin_helper
> > -rw-r--r-- 1 dedu  81624 May 17 22:16
> > mpeg4-ffmpeg_video_pwplugin.so
> > -rw-r--r-- 1 dedu  65088 May 17 22:16
> > theora_video_pwplugin.so
> >
> > Should both h263-1998 and h263-ffmpeg be put in the
> > opal-h263 package? 
> > What's the difference between them?  Is there one
> > better than another, 
> > and the other can be removed?
>
> Consider them different codecs. H.263+ (1998) is the newer one, not compatible withe H.263 (at least their encapsulation). H.263 has been declared obsolete by IETF, but not by ITU. H.263 depends on a hackish patched version of ffmpeg, while all the other codecs depend on "normal" ffmpeg. I propose to leave it out for now (and stick only to H.263+), if it is ok for damien.

Ok, I wait Damien's reply.

> > Also, is the h264_video_pwplugin_helper file useful or is a
> > packaging error?
> Both 
> h264_video_pwplugin.so
> and
> h264_video_pwplugin_helper
> belong to the h264 package. The helper is the gpled executable that loads the x264 library.

Ok.

> > Finally, is it possible to compile h264 only?  If yes, what
> > is the 
> > ./configure or ./autogen.sh command line?  I will look
> > myself too, but 
> > if you already know the answer, please tell me.
>
> No, not really... Does this help in the package building? I will probably revise the build system in the future, but I do not know if I want to put so much effort in the current one...

Not really, in fact...  Anyway, there should be two different diff.gz 
for debian and ubuntu...

Eugen