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
Is anyone making an effort to fix the package in the repos?
Package: openstack-debian-images
Version: 0.7
Severity: important
Dear Maintainer,
Without the sync flag in kpartx, the script continues and bombs before the
mapped dev node shows up.
I've added -s flag to "kpartx -asv", and that seems to work well.
Also, should fsck have "-y"?
*** Reporter, p
Package: dia-shapes
Version: 0.1
Severity: normal
Dear Maintainer, there is a spelling mistake in
/usr/share/dia/shapes/gradient/white_gray_horizontal.shape;
"horzontal" should be "horizontal".
Rafi
diff -U 1 old/usr/share/dia/shapes/gradient/white_gray_horizontal.shape new/usr/share/dia/shapes/
As far as I understand it, the wacom driver reports the different pens by the
serial number of the pen. They still report through the STYLUS and ERASER
devices. I do not know what tools can demonstrate the change of the pen.
As long as the art pen gives you basic functionality, I'd suggest check
Package: python-cxx
Version: 6.2.0-2
Severity: minor
The line in the description:
"your program will not make a reference-counting e rror and will not"
is missing a reference from the bug data base. Specifically the missing
reference should be to "e rror".
-- System Information:
Debian Release:
Package: libc6
Version: 2.11.1-2
Severity: normal
After updating libc6 users lost nis groups.
I verified on a machine which had not been updated for a while. On
request to update libc6, it installed:
libc-bin libc-dev-bin libc6 libc6-amd64 libc6-dev libc6-dev-amd64
libc6-i686 locales
Upgra
65457 normal
stop
On 16.01.10 Rafi Rubin (r...@ugcs.caltech.edu) wrote:
Hi,
floatflt.sty is missing from 2009-7. Its still listed as being in
this package in Contents file in the repository.
http://www.tug.org/pipermail/tex-live/2008-September/017640.html
Was removed by upstream due to lice
Package: texlive-latex-recommended
Version: 2009-7
Severity: important
floatflt.sty is missing from 2009-7. Its still listed as being in this
package in Contents file in the repository.
-- Package-specific info:
If you report an error when running one of the TeX-related binaries
(latex, pdftex
-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",
Looking at old and current upstream xinitrc's (
http://cgit.freedesktop.org/xorg/app/xinit/tree/xinitrc.cpp ), the mode maps
are loaded interleaved
with resources.
1. System resources
2. System modmap
3. User resources
4. User modmap
If that order isn't strictly necessary, it might make sens
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
17 matches
Mail list logo
