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

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
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

Sorry, forgot to send the following mail to the
About the packages issue, I suppose that there should
be packages like this:
opal includes h.261 & theora or depends opal-h261
& oapl-theora
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...


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
OPAL does, for echo cancelation, and of course the speex plugin does for the speex codec itself.


3. For opal, I see the following video codecs:
total 776
-rw-r--r-- 1 dedu 344240 May 17 22:16
-rw-r--r-- 1 dedu 107144 May 17 22:16
-rw-r--r-- 1 dedu  63000 May 17 22:16
-rw-r--r-- 1 dedu  79352 May 17 22:16
-rwxr-xr-x 1 dedu  40168 May 17 22:16
-rw-r--r-- 1 dedu  81624 May 17 22:16
-rw-r--r-- 1 dedu  65088 May 17 22:16

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?
belong to the h264 package. The helper is the gpled executable that loads the x264 library.


Finally, is it possible to compile h264 only?  If yes, what
is the ./configure or ./ 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...


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]