The dependencies for 3.8.1-11 end up requiring libequinox-osgi-java >=
3.9.1 (through eclipse-rcp), which doesn't have
/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar
Going back to stable, 3.8.1-10 for the eclipse packages at least catches
that jar, but fails after an illegal reflection
For what its worth, building the package from source results in a
functional binary. That makes it a bit harder to debug if its something
in the code.
On the upside, if this is just some binary/library incompatibility, the
solution might just be incrementing the version and forcing the build
syste
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The problem seems to be the "***" in the header gets escaped to "*" and
doesn't get unescaped later. This patch simply
changes the sequence to "---". And it seems to work fine that way.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux
Package: pidgin-encryption
Version: 3.0-4
Severity: grave
Justification: renders package unusable
For quite a while, encryption has been non-functional. It fails at the
key exchange state. No messages are sent until encryption is dissabled.
There is an upstream bug report stating that it died a
Michael Meskes wrote:
> On Thu, May 28, 2009 at 04:06:42AM -0400, Rafi Rubin wrote:
>> I suspect this might be related to bug #518096, which was closed without
>> identifying the source of the problem.
>
> Eh? What do you mean? Do you want me to list upstream's progr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Package: watchdog
Version: 5.6-2
Justification: breaks the whole system
Severity: critical
I suspect this might be related to bug #518096, which was closed without
identifying the source of the problem.
Line 258 of watchdog.c does not initialize "n",
From the cvs log:
1 $Id: NEWS,v 1.10 2007/02/06 18:12:08 akorty Exp $
2
3 Version 1.92
4
5
6 SECURITY FIX: The allow_blank_passphrase option was defeatable simply
7 by entering a random but non-blank passphrase. Thanks to Rob
8 Henderson for the repor
Package: libpam-ssh
Version: 1.91.0-9.1
Severity: critical
If pam-ssh tries to decrypt a key which is not protected by a
passphrase, it will succede with any arbitrary string, not just the
empty string. As such, dissallowing null does not protect the user.
Since it is likely that a user may
8 matches
Mail list logo
