Re: [Ekiga-devel-list] ekiga-snapshot Debian package

Hi Matthias!

On Wed, 29 Aug 2007 08:04:30 +0200, Matthias Schneider wrote:
> --- Luca Capello <luca pca it> schrieb:
>> First of all, I started to investigate because on a clean and
>> up-to-date sid (created as described at [1]) ekiga-snapshot doesn't
>> depend on libopal-cvs and indeed:
>> root gismo:/# su luca
>> luca gismo:/$ ekiga-snapshot
>> ekiga-snapshot: error while loading shared libraries: \
>>  cannot open shared object file: No such file or directory
>> luca gismo:/$root gismo:/#
>> =====
>> What's strange is the following:
>> =====
>> luca gismo:~$ dpkg-shlibdeps /usr/bin/ekiga-snapshot
>> dpkg-shlibdeps: warning: could not find any packages for
>> dpkg-shlibdeps: warning: unable to find dependency information for \
>>  shared library libopal (soname 2.3, path, dependency \
>>  field Depends)
>> dpkg-shlibdeps: failure: open new substvars file \
>>  debian/': No such file or directory
>> luca gismo:~$

This *is* a problem.

>> I'd say that libopal-cvs is definitively broken.
> No, it is not.  Actually a desired behaviour, is
> loaded dynamically on runtime, and if it is not found, some of
> ekiga's codecs (i.e. MPEG4 P 2, H.264, H.263+) will simply be
> deactivated (like you wrote in your first email), but ekiga will br
> completely functional.

As I said, I'm not a library expert, so thank you for the

> So I would say points 1) and 2) of your original email is normal
> behavior. The debug output just tells you where it looks for
> and if it finds it.

Perfectly understandable.  Kilian, IMHO libopal-cvs should at least
Suggests: libavcodec1d, maybe even Recommends:.

> The same should be true for x264, ekiga/opal executes a helper
> process that is dynamically linked to x264. In case that execution
> fails, H.264 should simply be deactivated, and ekiga should start up
> anyway...

I didn't look into the code (most of which I cannot understand), but
I'm a bit surprised: shouldn't x264 acts the same as libavcodec?  I
mean, without libavcodec the H.264 codec is deactivated, thus I don't
see the point in having libx264 installed while it's not used.  So,
I'd like libopal-cvs to not depends on, but only suggests or
recommends, all the libraries/codecs which need libavcodec.

Please pay attention that if libopal-cvs depends on libx264, this
creates a big problem for Debian, since libx264 has patent issues (and
thus ATM cannot be redistributed in Debian, maybe in non-free [1]).
This causes libopal-cvs (or any other official libopal depending on
libx264) to be put in contrib, according to [2].

> So your crashes have absolutely nothing to do with ffmpeg or
> x264. The casue is always your gnome problem...

And I completely agree here, in fact my post was specifically about
the Debian packages, nothing about my crashes (which I reported on the
"old" thread).

> Why is the libavcodec library's file called ? How
> shall the loader know that? I was under the impression that usually
> we have a symlink pointo to the correct library...

Well, I wouldn't say so on Debian, is in the -dev
luca gismo:~$ dlocate
libc6-i386: /emul/ia32-linux/lib/
libc6: /lib/
libc6-dev: /usr/lib/

luca gismo:~$ dlocate
libavcodec-dev: /usr/lib/
libavcodec1d: /usr/lib/
libavcodec1d: /usr/lib/

luca gismo:~$ dlocate
libpt-cvs: /usr/lib/
libpt-cvs: /usr/lib/debug/usr/lib/
libpt-cvs-dev: /usr/lib/
libpt-cvs-dev: /usr/lib/
libpt-cvs-dev: /usr/lib/

luca gismo:~$ dlocate
libopal-cvs-dev: /usr/lib/
libopal-cvs-dev: /usr/lib/
libopal-cvs: /usr/lib/
luca gismo:~$

Thx, bye,
Gismo / Luca

[1] it seems quite strangely, however, that the package has been
    removed if it could have been available in non-free

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