Package: linphone-desktop
Version: 5.2.6+dfsg-1
Severity: grave
Justification: renders package unusable
Linphone 5.2.6+dfsg-1 crashes during startup:
$ linphone
linphone: error while loading shared libraries: libapp-plugin.so: cannot
open shared object file: No such file or directory
The file e
As your log shows, libflac12t64 and libopenh264-7 were installed from
testing, not sid. Sid has libflac14 and libopenh264-8.
On Mon, 18 Nov 2024 12:08:36 +0500 Andrey Rakhmatullin
wrote:
I checked the upstream and found that the packaged version already claims
to support 3.13, and they indeed run 3.13 tests on CI. So this is weird.
Looking at the code of the GenericIterator class [1], the error is
correct: It's missi
Output from firefox-esr 102.12.0esr-1:
$ firefox-esr
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: defau
Am 10.01.23 um 20:03 schrieb Martin:
Btw. thanks for testing the latest nbxmpp master!
You're welcome!
After testing the patch I also tried installing nbxmpp and gajim in a
virtualenv. And there Gajim starts! "pip3 list" output within the
virtualenv:
Package Version Edit
In that case python3-nbxmpp 4.x must not migrate either, because it
breaks Gajim 1.5.x. I'm not sure what's the proper way to achieve that,
should I file another bug or is there some "blocks" mechanism in the BTS?
The bug affects a few more libraries. I found that creating symlinks for
all of them in /usr/lib/firefox/ is a workaround:
/usr/lib/x86_64-linux-gnu/libnssutil3.so
/usr/lib/x86_64-linux-gnu/libnss3.so
/usr/lib/x86_64-linux-gnu/libsmime3.so
/usr/lib/x86_64-linux-gnu/libssl3.so
This issue has been fixed in upstream version 0.10.0 (out just now).
This is caused by recent GnuTLS versions (since 3.6.11 AFAIK) listing
the peer's certificate type in the session description so they aren't
identical on anonymous client and authenticated server, so backporting
shouldn't be neces
This has been fixed upstream since version 0.9.1.
Hi Nico,
I tried to reproduce the issue but couldn't. Exactly how are you sending
the requests? I've tried both curl and hand-typing over gnutls-cli.
If you still have this issue, could you try enabling the appropriate
debug repositories (see https://wiki.debian.org/AutomaticDebugPackages)
and in
On Wed, 23 Jan 2019 22:46:59 +0100 Fiona Klute wrote:
> The easiest solution for the mod-gnutls package should be to remove the
> PDF documentation,
I realized the PDF documentation doesn't get installed anyway, so the
easiest workaround will be to remove the pdf_DATA line in
doc/Mak
That looks like a bug in pandoc to me. There's no PDF template
configuration in mod_gnutls, so this seems to affect PDF generation with
pandoc's default settings.
The easiest solution for the mod-gnutls package should be to remove the
PDF documentation, and maybe replace it with the manual page av
These test failures look like they are due to the switch to GnuTLS 3.6
(different default algorithms, OpenPGP removal), and should be fixed in
mod_gnutls 0.9.0 (released today).
The issue is fixed in the 0.8.4 upstream release, please update the
package. :-)
Regards,
Fiona
14 matches
Mail list logo
