Thanks for providing the workaround, works now for me.
Just wanted to share I had to add the configure-option
--disable-valgrind-tests
in order to successfully rebuild the package without libgcrypt, because the
valgrind tests found some lost bytes.
--
Dipl.-Inform. Felix Palmen
Package: mp3splt-gtk
Version: 0.5.6-1.2+b1
Severity: grave
Justification: renders package unusable
mp3splt-gtk won't start on my clean wheezy installation (no locally
installed or self compiled software) giving the following error:
Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+
Package: irssi
Version: 0.8.12-3
Severity: wishlist
Tags: patch
I think the decision to pre-create generated files via debian/rules
"patch" target is flawed: e.g. an irrsi patch extending the perl
interface by patching docs/signals.txt won't work with the debian
package. As stated in the changelog
* Andreas Metzler <[EMAIL PROTECTED]> [20061217 12:42]:
> | gnutls_certificate_set_x509_key_file - Used to set keys in a
[...]
> | Currently only PKCS-1 encoded RSA and DSA private keys are accepted
> | by this function.
>
> Some gnutls functions seem to handle PKCS-8 automatically (e.g.
* James Westby <[EMAIL PROTECTED]> [20061215 18:24]:
> However I think there is still a bug. GnuTLS can create PKCS#8 keys
> (certtool -p -8), so I think it should be able to read them. I just
> generated one with the above command, and then certtool -k failed with a
> base64 decoding error.
At le
Hallo James,
please forget the last infos, this backtrace was corrupted, I don't know
why. I got a correct backtrace by compiling the original upstream source
of 1.6.0 in developer-mode and running gdb with libtool.
The error was thrown from x509_b64.c:449. The reason was very obvious
then: My ke
Hallo James,
* James Westby <[EMAIL PROTECTED]> [20061214 18:44]:
> Assuming that that tells us nothing could I provide you with an
> instrumented GnuTLS library that will reveal the real problem? Looking
> at the code there are many points that will throw this error, so first
> it would be good t
Sorry, I forgot to mention:
I obtained the backtrace using the experimental source package 1.6.0-1
and inserting an abort() in every place where a base64 decoding error
can occur.
--
| /"\ ASCII Ribbon | Felix M. Palmen (Zirias)http://zirias.ath.cx/ |
| \ / Campaign Against | [EMAIL PR
Hallo Marc,
* Marc Haber <[EMAIL PROTECTED]> [20061214 16:45]:
> Ok. Can you please install gnutls-bin and try starting gnutls-serv
> with the appropriate --x509keyfile and --x509certfile options. If that
> gives the same error message, we have a gnutls-issue and this bug
> needs to be reassigned
Hallo Marc,
* Marc Haber <[EMAIL PROTECTED]> [20061214 15:22]:
> What happens when you use a current version of GnuTLS? Using exim 4.50
> suggests that you're working on sarge, which has a rather old version
> of gnutls.
I tried to do this right now, but found it would require to many
backports a
Package: exim4-daemon-light
Version: 4.50-8sarge2
When trying to use the equifax key/cert, STARTTLS triggers the following
log:
2006-12-14 13:03:29 TLS error on connection from pd9e39091.dip.t-dialin.net
(palmen.homeip.net) [217.227.144.145] (cert/key setup:
cert=/etc/exim4/exim.c
11 matches
Mail list logo
