Processed: tagging 503571
Processing commands for [EMAIL PROTECTED]: > tags 503571 unreproducible Bug#503571: aqualung: does not run: crashes after start There were no tags set. Tags added: unreproducible > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503631: dx: Visual Program Editor doesn't shows networks
Package: dx Followup-For: Bug #503631 tags 503631 unreproducible severity 503631 important subscribe 503631 [EMAIL PROTECTED] thanks David, Daniel, I am unable to reproduce this RC bug on lenny. I obtain an empty window titled "Untitled" which allows me to add network components. As such I am reducing the severity of this bug report. Mark -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages dx depends on: ii lesstif21:0.95.0-2.1 OSF/Motif 2.1 implementation relea ii libbz2-1.0 1.0.5-1 high-quality block-sorting file co ii libc6 2.7-14 GNU C Library: Shared libraries ii libdx4 1:4.4.4-1OpenDX (IBM Visualization Data Exp ii libfontconfig1 2.6.0-1 generic font configuration library ii libfreetype62.3.7-2 FreeType 2 font engine, shared lib ii libgcc1 1:4.3.2-1GCC support library ii libgl1-mesa-glx [li 7.0.3-6 A free implementation of the OpenG ii libglu1-mesa [libgl 7.0.3-6 The OpenGL utility library (GLU) ii libhdf4g4.1r4-22 The Hierarchical Data Format libra ii libice6 2:1.0.4-1X11 Inter-Client Exchange library ii libjpeg62 6b-14The Independent JPEG Group's JPEG ii liblcms11.17.dfsg-1 Color management library ii libmagick10 7:6.3.7.9.dfsg1-2+b2 image manipulation library ii libnetcdf4 1:3.6.2-3.1 An interface for scientific data a ii libsm6 2:1.0.3-2X11 Session Management library ii libstdc++6 4.3.2-1 The GNU Standard C++ Library v3 ii libtiff43.8.2-11 Tag Image File Format (TIFF) libra ii libx11-62:1.1.5-2X11 client-side library ii libxext62:1.0.4-1X11 miscellaneous extension librar ii libxinerama12:1.0.3-2X11 Xinerama extension library ii libxmu6 2:1.0.4-1X11 miscellaneous utility library ii libxp6 1:1.0.0.xsf1-2 X Printing Extension (Xprint) clie ii libxpm4 1:3.5.7-1X11 pixmap library ii libxt6 1:1.0.5-3X11 toolkit intrinsics library ii zlib1g 1:1.2.3.3.dfsg-12compression library - runtime Versions of packages dx recommends: pn dx-doc (no description available) Versions of packages dx suggests: pn dxsamples (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed (with 1 errors): Bug#503631: dx: Visual Program Editor doesn't shows networks
Processing commands for [EMAIL PROTECTED]: > Package: dx Ignoring bugs not assigned to: dx > Followup-For: Bug #503631 Unknown command or malformed arguments to command. > tags 503631 unreproducible Bug#503631: dx: Visual Program Editor doesn't shows networks There were no tags set. Tags added: unreproducible > severity 503631 important Bug#503631: dx: Visual Program Editor doesn't shows networks Severity set to `important' from `grave' > subscribe 503631 [EMAIL PROTECTED] There is no Debian Bug mailing list. If you wish to review bug reports please do so via http://www.debian.org/Bugs/ or ask this mail server to send them to you. soon: MAILINGLISTS_TEXT > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503571: Unable to reproduce - Bug#503571 aqualung: does not run: crashes after start
Hello Mark, Ben I'm unable to reproduce this issue on my up to date lenny box either. Ben, are you sure you don't have sid/experimental parts or unofficial packages ? Regards, Adam. Mark Purcell a écrit : Package: aqualung Followup-For: Bug #503571 Ben, Adam, I am unable to reproduce here, aqualung works fine under lenny. Mark -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages aqualung depends on: ii libasound2 1.0.16-2 ALSA library ii libatk1.0-01.22.0-1 The ATK accessibility toolkit ii libavcodec51 3:20080706-0.2library to encode decode multimedi ii libavformat52 3:20080706-0.2ffmpeg file format library ii libavutil493:20080706-0.2avutil shared libraries ii libc6 2.7-14GNU C Library: Shared libraries ii libcairo2 1.6.4-6.1 The Cairo 2D vector graphics libra ii libcddb2 1.2.1-1 library to access CDDB data - runt ii libcdio-cdda0 0.78.2+dfsg1-3library to read and control digita ii libcdio-paranoia0 0.78.2+dfsg1-3library to read digital audio CDs ii libcdio7 0.78.2+dfsg1-3library to read and control CD-ROM ii libflac8 1.2.1-1.2 Free Lossless Audio Codec - runtim ii libglib2.0-0 2.16.6-1 The GLib library of C routines ii libgtk2.0-02.12.11-4 The GTK+ graphical user interface ii libifp41.0.0.2-3 communicate with iRiver iFP audio ii libjack0 0.109.2-3 JACK Audio Connection Kit (librari ii liblrdf0 0.4.0-1.1 a library to manipulate RDF files ii libmad00.15.1b-3 MPEG audio decoder library ii libmodplug0c2 1:0.8.4-1 shared libraries for mod music bas ii libmpcdec3 1.2.2-1 Musepack (MPC) format library ii libogg01.1.3-4 Ogg Bitstream Library ii liboggz1 0.9.8-1 convenience interface for Ogg stre ii libpango1.0-0 1.20.5-3 Layout and rendering of internatio ii libsamplerate0 0.1.4-1 audio rate conversion library ii libsndfile11.0.17-4 Library for reading/writing audio ii libspeex1 1.2~rc1-1 The Speex codec runtime library ii libstdc++6 4.3.2-1 The GNU Standard C++ Library v3 ii libusb-0.1-4 2:0.1.12-12 userspace USB programming library ii libvorbis0a1.2.0.dfsg-3.1The Vorbis General Audio Compressi ii libvorbisenc2 1.2.0.dfsg-3.1The Vorbis General Audio Compressi ii libvorbisfile3 1.2.0.dfsg-3.1The Vorbis General Audio Compressi ii libwavpack14.50.1-1 an audio codec (lossy and lossless ii libxml22.6.32.dfsg-4 GNOME XML library ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime aqualung recommends no packages. aqualung suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503367: [Debian-med-packaging] Bug#503367: plink: file conflict with putty-tools
On Tue, Oct 28, 2008 at 2:59 AM, Brian May <[EMAIL PROTECTED]> wrote: > Steffen Möller wrote: >> Teodor happened to have nicely explained my objections to rename plink. > > Except what he said is wrong, puttygen hasn't been renamed. Yes, puttygen hasn't been renamed. It was a wrong assumption from me .. >> Dear Colin, if you don't mind too much, or if you could be bribed with a >> few beers, please be so kind to rename the plink binary package. > > If we rename plink in putty (I think that is what you are asking?), that it > going to make our version of putty inconsistent with every other putty > package out there. This program is often used by scripts, they will break > too. I still believe it is best to rename 'plink' to 'puttylink' in putty-tools binary package. Anyway, this should be fixed for squeeze since in lenny there is no conflict (plink is not included in lenny). Thanks
Bug#503735: gnome-chess: menus only work in English language locales
severity 503735 important tags 503735 l10n thanks On Tuesday 28 October 2008 10:05:04 Peter De Wachter wrote: > Severity: grave > Justification: renders package unusable > > The File/New/Programs and the File/New/Servers menus don't work in > non-English locales. This makes it impossible to play against the > computer or on a chess server. Peter, While I can understand your desire for non-en locales, that fact that the menus work in English means that this RC bug should be classified as: severity important: has a major effect on the usability of a package, without rendering it completely unusable to everyone As the package isn't unusable for English locale users. Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503367: [Debian-med-packaging] Bug#503367: Bug#503367: plink: file conflict with putty-tools
Le Tue, Oct 28, 2008 at 09:32:42AM +0200, Teodor a écrit : > > I still believe it is best to rename 'plink' to 'puttylink' in > putty-tools binary package. Anyway, this should be fixed for squeeze > since in lenny there is no conflict (plink is not included in lenny). Hi all, Upstream documented the renaming on his website, so I think that that is the (happy) end of the story :) "Debian users: PLINK is available as a Debian package, see these notes. Note, the executable is named snplink in the Debian plink package." http://pngu.mgh.harvard.edu/~purcell/plink/download.shtml Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502725: gvfs hangs for mounts after heavy use
On Monday 20 October 2008 00:16:23 Thomas Viehmann wrote: > Package: gvfs > Version: 0.2.5-1 > Severity: serious > Reasoning: cripples things that might wait for it Thomas, I suspect that your report might be a duplicate of #496269 which has just been fixed by the upload of version 0.2.5-1.1 by Clint Adams. Can you confirm that 0.2.5-1.1 fixes your bug and your report is in fact a duplicate that can also be closed. Thanks, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501997: NMU?
On dim, 2008-10-26 at 10:17 +0100, Yves-Alexis Perez wrote:
> On dim, 2008-10-26 at 09:10 +0100, Yves-Alexis Perez wrote:
> > Hey,
> >
> > as I'm working on splashy, I guess he'll just do a quick NMU for
> this
> > bug. Or are you working on a MU anyway?
>
> Attached intended debdiff.
I've uploaded the attached debdiff to DELAYED/1. It does *not* fix the
breakage related to /etc/splashy replaced by a symlink, which bites
upgrades in lenny/sid.
Cheers,
--
Yves-Alexis
diff -u splashy-0.3.10/debian/splashy.preinst splashy-0.3.10/debian/splashy.preinst
--- splashy-0.3.10/debian/splashy.preinst
+++ splashy-0.3.10/debian/splashy.preinst
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/sh -e
# There was a bug in 0.2.x, it didn't remove /lib/splashy in postrm
if [ -d /lib/splashy ]; then
diff -u splashy-0.3.10/debian/control splashy-0.3.10/debian/control
--- splashy-0.3.10/debian/control
+++ splashy-0.3.10/debian/control
@@ -15,12 +15,13 @@
# - libglib2.0-dev (>> 2.0.1-2) - due the need of static library
# - perl - pod2man used to generate man pages
# - libmagic-dev - needed to detect mimetypes
+# - chrpath - for removing the rpath defined in /sbin/splashy
#
Build-Depends: cdbs (>= 0.4.23-1.1), quilt, autotools-dev, debhelper (>= 5),
libdirectfb-dev (>= 1.0.1-9), libglib2.0-dev (>> 2.0.1-2), libtool, perl,
- libmagic-dev
-Standards-Version: 3.7.3
-XS-Vcs-Git: git://git.debian.org/git/splashy/splashy.git
+ libmagic-dev, chrpath
+Standards-Version: 3.8.0
+XS-Vcs-Git: git://git.debian.org/git/splashy/debian/splashy.git
XS-Vcs-Browser: http://git.debian.org/?p=splashy/splashy.git;a=summary
# console-common is needed to not run keymap.sh on Debian earlier than Sid
diff -u splashy-0.3.10/debian/changelog splashy-0.3.10/debian/changelog
--- splashy-0.3.10/debian/changelog
+++ splashy-0.3.10/debian/changelog
@@ -1,3 +1,19 @@
+splashy (0.3.10-2.1) unstable; urgency=high
+
+ * Non-maintainer upload, urgency=high for RC bug fix.
+ * 02_add_missing_headers added, fix FTBFBS with
+DEB_BUILD_OPTIONS=noopt,nostrip. Thanks Bradley Smith closes: #501997
+ * debian/splashy.{preinst,postinst,postrm}: use sh -e to make sure errors are
+caught.
+ * debian/control:
+- update standards version to 3.8.0, no changes needed.
+- add build-dep on rpath.
+- use the debian splashy repository instead of upstream one.
+ * debian/rules:
+- remove rpath on /sbin/splashy.
+
+ -- Yves-Alexis Perez <[EMAIL PROTECTED]> Tue, 28 Oct 2008 08:43:57 +0100
+
splashy (0.3.10-2) unstable; urgency=low
* Add build-depends on quilt.
diff -u splashy-0.3.10/debian/rules splashy-0.3.10/debian/rules
--- splashy-0.3.10/debian/rules
+++ splashy-0.3.10/debian/rules
@@ -15,6 +15,7 @@
debian/splashy/usr/share/initramfs-tools/hooks/libsplashy \
debian/splashy/usr/share/initramfs-tools/scripts/init-top/splashy \
debian/splashy/etc/console-tools/config.d/splashy
+ chrpath -d $(CURDIR)/debian/splashy/sbin/splashy
# VERY UGLY HACK! See #297741
configure/splashy::
sed s/old_library=\'\'/old_library=\'libglib-2.0.a\'/ /usr/lib/libglib-2.0.la > src/libglib-2.0.la
diff -u splashy-0.3.10/debian/splashy.postinst splashy-0.3.10/debian/splashy.postinst
--- splashy-0.3.10/debian/splashy.postinst
+++ splashy-0.3.10/debian/splashy.postinst
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/sh -e
if [ -x "/etc/init.d/splashy" ]; then
# This is needed to put the splashy links in the new location
diff -u splashy-0.3.10/debian/splashy.postrm splashy-0.3.10/debian/splashy.postrm
--- splashy-0.3.10/debian/splashy.postrm
+++ splashy-0.3.10/debian/splashy.postrm
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/sh -e
# until we have a debconf question, we won't do this:
# for file in /boot/grub/menu.lst /boot/boot/grub/menu.lst; do
diff -u splashy-0.3.10/debian/patches/series splashy-0.3.10/debian/patches/series
--- splashy-0.3.10/debian/patches/series
+++ splashy-0.3.10/debian/patches/series
@@ -1,0 +2 @@
+02_add_missing_headers.patch
only in patch2:
unchanged:
--- splashy-0.3.10.orig/debian/patches/02_add_missing_headers.patch
+++ splashy-0.3.10/debian/patches/02_add_missing_headers.patch
@@ -0,0 +1,12 @@
+Index: splashy-0.3.10/src/splashy_config-main.c
+===
+--- splashy-0.3.10.orig/src/splashy_config-main.c 2008-10-12 16:28:15.0 +0100
splashy-0.3.10/src/splashy_config-main.c 2008-10-12 16:28:39.0 +0100
+@@ -41,6 +41,7 @@
+ #include /* getuid */
+ #include /* getopt_long */
+ #include
++#include
+
+ #include "common_macros.h"
+ #include "splashycnf.h"
signature.asc
Description: This is a digitally signed message part
Bug#500482: Segmentation fault in grub-probe (1.96+20081026-1)
Hi, thank you for the 1.96+20081026-1 binary - I just extracted the grub-probe binary and tested it on the target system. The output is somewhat different now, but it still ends with a segfault: whg:~/tmp# ./grub-probe -vvv -d /dev/md0 /home/fz/grub/grub2-1.96+20081026/kern/disk.c:220: Opening `hd0'... grub-probe: info: the size of hd0 is 488397168 /home/fz/grub/grub2-1.96+20081026/kern/disk.c:368: Reading `hd0'... /home/fz/grub/grub2-1.96+20081026/util/hostdisk.c:316: opening the device `/dev/sda' in open_device()/home/fz/grub/grub2-1.96+20081026/kern/disk.c:368: Reading `hd0'... [...] /home/fz/grub/grub2-1.96+20081026/kern/disk.c:220: Opening `hd3,3'... grub-probe: info: the size of hd3 is 488397168 /home/fz/grub/grub2-1.96+20081026/kern/disk.c:368: Reading `hd3,3'... /home/fz/grub/grub2-1.96+20081026/kern/disk.c:368: Reading `hd3,3'... /home/fz/grub/grub2-1.96+20081026/partmap/apple.c:129: bad magic (found 0xeb48; wanted 0x4552 /home/fz/grub/grub2-1.96+20081026/kern/disk.c:368: Reading `hd3,3'... /home/fz/grub/grub2-1.96+20081026/partmap/pc.c:143: partition 0: flag 0x80, type 0xfd, start 0x3f, len 0x950a21 /home/fz/grub/grub2-1.96+20081026/partmap/pc.c:143: partition 1: flag 0x0, type 0x82, start 0x950a60, len 0x772266 /home/fz/grub/grub2-1.96+20081026/partmap/pc.c:143: partition 2: flag 0x0, type 0xfd, start 0x10c2cc6, len 0x1bf0797a /home/fz/grub/grub2-1.96+20081026/kern/disk.c:368: Reading `hd3,3'... /home/fz/grub/grub2-1.96+20081026/util/hostdisk.c:316: opening the device `/dev/sdd3' in open_device()/home/fz/grub/grub2-1.96+20081026/util/hostdisk.c:316: opening the device `/dev/sdd3' in open_device()/home/fz/grub/grub2-1.96+20081026/kern/disk.c:368: Reading `hd3,3'... /home/fz/grub/grub2-1.96+20081026/util/hostdisk.c:316: opening the device `/dev/sdd3' in open_device()/home/fz/grub/grub2-1.96+20081026/util/hostdisk.c:316: opening the device `/dev/sdd3' in open_device()/home/fz/grub/grub2-1.96+20081026/kern/disk.c:368: Reading `hd3,3'... /home/fz/grub/grub2-1.96+20081026/util/hostdisk.c:316: opening the device `/dev/sdd3' in open_device()/home/fz/grub/grub2-1.96+20081026/kern/disk.c:368: Reading `hd3,3'... /home/fz/grub/grub2-1.96+20081026/kern/disk.c:312: Closing `hd3,3'. /home/fz/grub/grub2-1.96+20081026/partmap/pc.c:143: partition 3: flag 0x0, type 0x0, start 0x0, len 0x0 /home/fz/grub/grub2-1.96+20081026/kern/disk.c:312: Closing `hd3'. /home/fz/grub/grub2-1.96+20081026/disk/raid.c:604: Scanning for RAID devices /home/fz/grub/grub2-1.96+20081026/kern/disk.c:220: Opening `(null)'... Segmentation fault (full output and strace attached) Perhaps you could try to reproduce the bug by puting my partition dumps (attached) on some test partitions. Steve: If you still have the test setup, please try to dump my sda3 to your hda3, my sdb3 to your hdb3, my sdc3 to your hda4 and my sdd3 to your hdb4 and test again. best regards, Zrin grub-probe-1.96+20081026-strace.txt.gz Description: GNU Zip compressed data grub-probe-1.96+20081026-vvv.txt.gz Description: GNU Zip compressed data 500482-partition_dumps.tar.gz Description: GNU Zip compressed data
Bug#503311: monit: Client Certificate authentication fails with openssl-engine error
Quoting Martin Pala <[EMAIL PROTECTED]>: Please can you provide your monit configuration? (the "set httpd ..." part is sufficient). set httpd port 28000 and use address 123.123.123.123 ssl enable pemfile /etc/ssl/ca_priv_pub.pem clientpemfile /etc/monit/client_certificates.pem ALLOWSELFCERTIFICATION Is the certificate self-signed or using public CA? It's a self-signed certificate. Besides the version, nothing changed on the server. Firefox (32bit binary, 3.x, gentoo) seems to be the problem here. Certificate is correctly installed, including root (with correct cert-permissions set in firefox). Firefox doesn't even ask for me to choose a certificate. On other website it on the other hand does. Really strange... -- regards, Georges Toth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496954: [Re:] bind9: acl-related segfaults upgrading from bind 9.3.4 to 9.5.0-P2
tags 501800 +patch
thanks
After further discussions with upstream authors :
Evan Hunt wrotes :
--8<
Thanks to Emmanuel Bouthenot for the assistance, I was able to
reproduce the issue with his instructions. It turned out to be a bug
that was fixed in 9.5.1b2.
There are several other ACL problems that have been fixed in that
release and in 9.5.1b3, which is due out in a few days. I'd recommend
using 9.5.1 when it's complete (in about a month, most likely), but
I'm told Debian is planning is to release 9.5.0-P2 plus patches
instead. So I've rolled all the ACL fixes in the 9.5.1 pipeline up
into a single patch and attached it to this email. This reflects the
following changes:
2474. [bug] ACL structures could be allocated with insufficient
space, causing an array overrun. [RT #18765]
2470. [bug] Elements of the isc_radix_node_t could be incorrectly
overwritten. [RT# 18719]
2456. [bug] In ACLs, ::/0 and 0.0.0.0/0 would both match any
address, regardless of family. They now
correctly distinguish IPv4 from IPv6. [RT #18559]
2441. [bug] isc_radix_insert() could copy radix tree nodes
incompletely. [RT #18573]
2439. [bug] Potential NULL dereference in dns_acl_isanyornone().
[RT #18559]
(For the record, the bug you hit was 2441.)
Thanks again and let me know if you have any questions.
>8--
The patch is attached.
Cheers,
--
Emmanuel Bouthenot
mail : [EMAIL PROTECTED]
gpg : 0x414EC36E
jid : [EMAIL PROTECTED]
irc : kolter@(freenode|oftc)
Index: lib/dns/acl.c
===
RCS file: /proj/cvs/prod/bind9/lib/dns/acl.c,v
retrieving revision 1.37.2.7
diff -u -u -r1.37.2.7 acl.c
--- lib/dns/acl.c 29 Apr 2008 01:04:14 - 1.37.2.7
+++ lib/dns/acl.c 28 Oct 2008 00:25:02 -
@@ -148,7 +148,10 @@
return (ISC_FALSE);
if (acl->iptable->radix->head->prefix->bitlen == 0 &&
- *(isc_boolean_t *) (acl->iptable->radix->head->data[0]) == pos)
+ acl->iptable->radix->head->data[0] != NULL &&
+ acl->iptable->radix->head->data[0] ==
+ acl->iptable->radix->head->data[1] &&
+ *(isc_boolean_t *) (acl->iptable->radix->head->data[0]) == pos)
return (ISC_TRUE);
return (ISC_FALSE); /* All others */
@@ -220,8 +223,6 @@
/* Found a match. */
if (result == ISC_R_SUCCESS && node != NULL) {
- if (node->bit == 0)
- family = AF_INET;
match_num = node->node_num[ISC_IS6(family)];
if (*(isc_boolean_t *) node->data[ISC_IS6(family)] == ISC_TRUE)
*match = match_num;
@@ -491,9 +492,8 @@
isc_boolean_t secure;
int bitlen, family;
- /* Bitlen 0 means "any" or "none", which is always treated as IPv4 */
bitlen = prefix->bitlen;
- family = bitlen ? prefix->family : AF_INET;
+ family = prefix->family;
/* Negated entries are always secure. */
secure = * (isc_boolean_t *)data[ISC_IS6(family)];
Index: lib/dns/iptable.c
===
RCS file: /proj/cvs/prod/bind9/lib/dns/iptable.c,v
retrieving revision 1.5.46.3
diff -u -u -r1.5.46.3 iptable.c
--- lib/dns/iptable.c 21 Jan 2008 21:02:24 - 1.5.46.3
+++ lib/dns/iptable.c 28 Oct 2008 00:25:02 -
@@ -70,22 +70,39 @@
NETADDR_TO_PREFIX_T(addr, pfx, bitlen);
- /* Bitlen 0 means "any" or "none", which is always treated as IPv4 */
- family = bitlen ? pfx.family : AF_INET;
-
result = isc_radix_insert(tab->radix, &node, NULL, &pfx);
-
- if (result != ISC_R_SUCCESS)
+ if (result != ISC_R_SUCCESS) {
+ isc_refcount_destroy(&pfx.refcount);
return(result);
+ }
- /* If the node already contains data, don't overwrite it */
- if (node->data[ISC_IS6(family)] == NULL) {
- if (pos)
- node->data[ISC_IS6(family)] = &dns_iptable_pos;
- else
- node->data[ISC_IS6(family)] = &dns_iptable_neg;
+ /* If a node already contains data, don't overwrite it */
+ family = pfx.family;
+ if (family == AF_UNSPEC) {
+ /* "any" or "none" */
+ INSIST(pfx.bitlen == 0);
+ if (pos) {
+ if (node->data[0] == NULL)
+ node->data[0] = &dns_iptable_pos;
+ if (node->data[1] == NULL)
+ node->data[1] = &dns_iptable_pos;
+ } else {
+ if (node->data[0] == NULL)
+ node->data[0] = &dns_iptable_neg;
+ if (node->data[1] == NULL)
+ node->data[1] = &dns_iptable_neg;
+ }
+ } else {
+ /* any other prefix */
+ if (node->data[ISC_IS6(family)] == NULL) {
+ if (pos)
+ node->data[ISC_IS6(family)] = &dns_iptable_pos;
+ else
+ node->data[ISC_IS6(family)] = &dns_iptable_neg;
+ }
}
+ isc_refcount_destroy(&pfx.refcount);
return (ISC_R_SUCCESS);
}
Index: lib/isc/radix.c
===
RCS file: /proj/cvs/prod/bind9/lib/isc/radix.c,v
retrieving revision 1.9.6.5.2.1
diff -u -u -r1.9.6.5.
Bug#503645: jhead: CVE-2008-4640, CVE-2008-4641 command injection via filename and insecure file handling
On Mon, Oct 27, 2008 at 5:03 PM, Nico Golde <[EMAIL PROTECTED]> wrote: > Hi Ludovic, > * Ludovic Rousseau <[EMAIL PROTECTED]> [2008-10-27 16:47]: >> On Mon, Oct 27, 2008 at 1:06 PM, Matthias Wandel <[EMAIL PROTECTED]> wrote: >> > So what is the security vulnerability? >> > >> > You can use it to delete files, but why not just use "rm"? >> >> If I understand correctly we have two problems (from [1]) >> 2 - unsafe temp file creation > > Yes but this is not exactly the same problem like the static > name that was used before. > >> 4 - shell escapes >> >> I think "unsafe temp file creation" is referring to the use of >> unlink() at line 329 of jhead.c. I don't think it is a grave problem. > > Correct. > >> "shell escapes" is more serious since you use system() at line 339 of >> jhead.c without escaping any special characters a file name could >> contain. > > Correct, that is the problem. Crafted file names can execute > commands in the shell. > >> For example if you have a file named "foo.jpg ; rm -rf ~" you could >> make bad things without noticing. >> Yes, you should be stupid to use such a file name. > > All the issues recently released for jhead are not really > important, the problem are non-interactive setups where > jhead is called from scripts. > >> > Unless of course you run it as setuid root, but why would you go out ot >> > your >> > way to do that? >> >> A solution would be to use one of the exec(3) system calls instead of >> system(3). > > Yes or to filter the string. I may try to implement a filter mechanism. I think the idea is to stop the execution with an error message if a special character is found. What would be the list of normal characters? [a-z][A-Z][0-9][-.]? How to filter file names in UTF-8? with accents or non ASCII characters? An easier solution is to refuse special characters like & and ; but that may not completely solve the problem. I need help here. Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed (with 5 errors): Re: Bug#503735: gnome-chess: menus only work in English language locales
Processing commands for [EMAIL PROTECTED]: > severity 503735 grave Bug#503735: gnome-chess: menus only work in English language locales Severity set to `grave' from `grave' > On Tue, Oct 28, 2008 at 06:35:15PM +1100, Mark Purcell wrote: Unknown command or malformed arguments to command. > > On Tuesday 28 October 2008 10:05:04 Peter De Wachter wrote: Unknown command or malformed arguments to command. > > > Severity: grave Unknown command or malformed arguments to command. > > > Justification: renders package unusable Unknown command or malformed arguments to command. > > > Unknown command or malformed arguments to command. Too many unknown commands, stopping here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503735: gnome-chess: menus only work in English language locales
severity 503735 grave On Tue, Oct 28, 2008 at 06:35:15PM +1100, Mark Purcell wrote: > On Tuesday 28 October 2008 10:05:04 Peter De Wachter wrote: > > Severity: grave > > Justification: renders package unusable > > > > The File/New/Programs and the File/New/Servers menus don't work in > > non-English locales. This makes it impossible to play against the > > computer or on a chess server. > While I can understand your desire for non-en locales, that fact that the > menus work in English means that this RC bug should be classified as: > > severity important: has a major effect on the usability of a package, without > rendering it completely unusable to everyone > > As the package isn't unusable for English locale users. Did you even try it? I get failed assertions in the console and the program does neither work with LANG=C nor LC_ALL=C for me. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Release Assistant `. `' xmpp:[EMAIL PROTECTED] Stable Release Manager `-finger pkern/[EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#500418: istanbul Please also re-enable hppa
severity 500418 important thanks On Tuesday 28 October 2008 10:57:39 Thiemo Seufer wrote: > severity 500418 serious [...] > Please add hppa mips mipsel to the allowed architectures in debian/control. Thiemo, Whilst I agree is is important for hppa mips & mipsel to be supported architectures I don't think the build of istanbul on these arches is release critical for lenny nor does it make the package unfit for release, given that the package already in lenny hasn't been build for these arches. However, if Luca or Florian are able to build/ upload a new package that would be welcome. However that shouldn't effect the severity of this bug report. Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#393837: More informations..
Hi all !
The issue can be isolated in this line:
window.openDialog('chrome://pippki/content/deletecert.xul', "",
'chrome,centerscreen,modal', params);
in certManager.js.
If you remove this line, and comment the next if, then you simply remove the
confirmation box. Could be a workaround perhaps if nothing better can be
find ?
If you remove from the file delecert.js everything related to gParams, then it
works, but does nothing.
I'm strongly suspecting some sort of javascript failure, related to the
gParams variable, but, as usual, it really lacks a good damn javascript
debugging console.
Romain
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503790: lucene2: java bytecode / java runtime version mismatch
Package: lucene2
Version: 2.4.0+ds1-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503769: aspectwerkz2: java bytecode / java runtime version mismatch
Package: aspectwerkz2
Version: 2.0.dfsg.2-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503782: jcc: java bytecode / java runtime version mismatch
Package: jcc
Version: 1.9-8
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503804: tinylaf: java bytecode / java runtime version mismatch
Package: tinylaf
Version: 1.3.8-3
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503780: electric: java bytecode / java runtime version mismatch
Package: electric
Version: 8.07-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503802: weka: java bytecode / java runtime version mismatch
Package: weka
Version: 3.5.8-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503797: solr: java bytecode / java runtime version mismatch
Package: solr
Version: 1.2.0+ds2-2
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503775: glassfish: java bytecode / java runtime version mismatch
Package: glassfish
Version: 1:2ur2-b04-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503786: libjgroups-java: java bytecode / java runtime version mismatch
Package: libjgroups-java
Version: 2.6.3.GA+dfsg1-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503783: libcodemodel-java: java bytecode / java runtime version mismatch
Package: libcodemodel-java
Version: 2.0-2
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503799: libhamcrest-java: java bytecode / java runtime version mismatch
Package: libhamcrest-java
Version: 1.1-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503770: carmetal: java bytecode / java runtime version mismatch
Package: carmetal
Version: 2.8.9.dakbug-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503785: java-access-bridge: java bytecode / java runtime version mismatch
Package: java-access-bridge
Version: 1.23.0-2
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503788: libcobra-java: java bytecode / java runtime version mismatch
Package: libcobra-java
Version: 0.98.2-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503789: libxstream-java: java bytecode / java runtime version mismatch
Package: libxstream-java
Version: 1.3-3
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503773: azureus: java bytecode / java runtime version mismatch
Package: azureus
Version: 3.1.1.0-3.1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503795: libjdic-java: java bytecode / java runtime version mismatch
Package: libjdic-java
Version: 0.9.5-3
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503791: javassist: java bytecode / java runtime version mismatch
Package: javassist
Version: 1:3.8.1-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503776: freeguide: java bytecode / java runtime version mismatch
Package: freeguide
Version: 0.10.9-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503772: easymock: java bytecode / java runtime version mismatch
Package: easymock
Version: 2.4+ds1-2
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503796: sat4j: java bytecode / java runtime version mismatch
Package: sat4j
Version: 2.0.2-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503774: commons-csv: java bytecode / java runtime version mismatch
Package: commons-csv
Version: 0.1-SNAPSHOT+svn678580-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503771: coco-java: java bytecode / java runtime version mismatch
Package: coco-java
Version: 20081001-2
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503793: liquidlnf: java bytecode / java runtime version mismatch
Package: liquidlnf
Version: 2.9.1-6
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503798: libjboss-serialization-java: java bytecode / java runtime version mismatch
Package: libjboss-serialization-java
Version: 1.0.3.GA+dak1-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503778: dom4j: java bytecode / java runtime version mismatch
Package: dom4j
Version: 1.6.1+dfsg-3
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503792: mina: java bytecode / java runtime version mismatch
Package: mina
Version: 1.1.7.dfsg-4
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503800: libgdata-java: java bytecode / java runtime version mismatch
Package: libgdata-java
Version: 1.20.0+dak1-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503779: groovy: java bytecode / java runtime version mismatch
Package: groovy
Version: 1.5.6-2
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503801: josm: java bytecode / java runtime version mismatch
Package: josm
Version: 0.0.0.20080713-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503777: imagej: java bytecode / java runtime version mismatch
Package: imagej
Version: 1.41n-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503781: dbus-java: java bytecode / java runtime version mismatch
Package: dbus-java
Version: 2.5-4
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503784: freecol: java bytecode / java runtime version mismatch
Package: freecol
Version: 0.7.4.dfsg+1-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503803: simplyhtml: java bytecode / java runtime version mismatch
Package: simplyhtml
Version: 0.12.3+dfsg-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502725: gvfs hangs for mounts after heavy use
Hi Mark, thank you for looking into the bug I filed. On 2008-10-28 08:47:49.00 Mark Purcell <[EMAIL PROTECTED]> wrote: I suspect that your report might be a duplicate of #496269 which has just been fixed by the upload of version 0.2.5-1.1 by Clint Adams. Can you confirm that 0.2.5-1.1 fixes your bug and your report is in fact a duplicate that can also be closed. While it certainly is not a duplicate of #496269 as the bug report tries to explain with embarrassing verbosity, it is entirely possible that Clint's NMU contains patches that fix #502725 as well. The obvious, correct way of verifying this is take a broken gvfs-fuse-daemon and a -1.1 gvfsd and see if the instructions to reproduce the bug and illustrate that it is not #496269 do not allow the same conclusion in this partially upgraded setup, i.e. have gvfs-fuse-daemon turn belly up but verify that gvfsd keeps working e.g. when accessed via gvfs-ls. That said, do proceed as you see fit. If merging the bug with #496269 seems like the best choice to you, that is fine with me even if I do not entirely understand how you arrive at that conclusion. Best of luck T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503787: libwoodstox-java: java bytecode / java runtime version mismatch
Package: libwoodstox-java
Version: 1:3.9.2.dfsg-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503807: protobuf: java bytecode / java runtime version mismatch
Package: protobuf
Version: 2.0.2-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503794: pylucene: java bytecode / java runtime version mismatch
Package: pylucene
Version: 2.3.1-1.1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503623: python-support: Fails during the Setting Up step of installation
Le mardi 28 octobre 2008 à 11:38 +1100, Tim Lyth a écrit : > iU python-gobject 2.14.2-1 > Python bindings for the GObject library > iU python-gtk22.12.1-6 > Python bindings for the GTK+ widget set > > > -rw-r--r-- 1 root root 8 2008-06-07 23:41 > > > /usr/share/python-support/python-gobject/pygtk.pth > > > -rw-r--r-- 1 root root 8 2006-08-06 06:58 > > > /usr/share/python-support/python-gtk2/pygtk.pth The latter file is not present in the python-gtk2 package at this version. Please check the contents of python-gtk2 (dpkg -L python-gtk2) and the origin of this file (dpkg -S python-gtk2/pygtk.pth). It is highly probable that this file has been put here by a user error or a filesystem error (file not correctly unlinked after a crash/fsck for example). -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Bug#500418: istanbul Please also re-enable hppa
Mark, am Tue, Oct 28, 2008 at 07:09:02PM +1100 hast du folgendes geschrieben: > Whilst I agree is is important for hppa mips & mipsel to be supported > architectures I don't think the build of istanbul on these arches is > release critical for lenny nor does it make the package unfit for > release, given that the package already in lenny hasn't been build > for these arches. there was a hppa build in etch which now isn't anymore. Policy 5.6.8 (`Architecture') footnote [2] says: [2] This is a setting used for a minority of cases where the program is not portable. Generally, it should not be used for new packages. Assuming that the package is in fact portable. The maintainer of the package worked around some buildd problem, obviously, albeit the infrasture ought to handle this failure gracefully: istanbul (0.2.2-3) unstable; urgency=low . [...] * Disabling those architectures where python-gst isn't available I.e. the packages would be available now that python-gst is there, too (through dep-wait). Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Release Assistant `. `' xmpp:[EMAIL PROTECTED] Stable Release Manager `-finger pkern/[EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#393837: More informations..
Le mardi 28 octobre 2008 à 10:17 +0200, Romain Beauxis a écrit :
> Hi all !
>
> The issue can be isolated in this line:
> window.openDialog('chrome://pippki/content/deletecert.xul', "",
> 'chrome,centerscreen,modal', params);
>
> in certManager.js.
>
> If you remove this line, and comment the next if, then you simply remove the
> confirmation box. Could be a workaround perhaps if nothing better can be
> find ?
>
> If you remove from the file delecert.js everything related to gParams, then
> it
> works, but does nothing.
>
> I'm strongly suspecting some sort of javascript failure, related to the
> gParams variable, but, as usual, it really lacks a good damn javascript
> debugging console.
Yes, the params are correctly passed to the chrome dialog, but they are
removed by some later call in the stack. The window is probably missing
permissions to obtain them but I don’t know how it should get them. As
this happens for all gtkmozembed applications I suspect this is
something gtkmozembed should do.
Cheers,
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`-our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
Bug#503784: marked as done (freecol: java bytecode / java runtime version mismatch)
Your message dated Tue, 28 Oct 2008 09:49:02 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#503784: freecol: java bytecode / java runtime version
mismatch
has caused the Debian Bug report #503784,
regarding freecol: java bytecode / java runtime version mismatch
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
503784: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503784
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: freecol
Version: 0.7.4.dfsg+1-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--- End Message ---
--- Begin Message ---
Hello,
On Tue, Oct 28, 2008 at 9:26 AM, Matthias Klose <[EMAIL PROTECTED]> wrote:
> This package builds with openjdk-6 or cacao-oj6, which is not the
> default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
> creates java bytecode for version 50, which cannot be used by older
> jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
> must not depend on java-runtime{,1,2,5}{,-headless}, but only on
> java-runtime6{,-headless} or any of the non-virtual packages providing
> a java6 runtime.
Depends: openjdk-6-jre | icedtea-java7-jre | sun-java6-jre | j2re1.6,
Where is a dependency on java-runtime5 or earlier in here ??
> It is preferred to build the bytecode so that it runs on older jvms.
> This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
> setting ANT_OPTS to -Dant.build.javac.source=1.[45].
In the case it builds. Which is not the case for freecol.
I don't see where the problem is in this case, I'm therefore closing this bug
Cheers,
Vincent
--- End Message ---
Bug#503781: dbus-java: java bytecode / java runtime version
close 503781
thanks
On Tue Oct 28 09:26, Matthias Klose wrote:
> Package: dbus-java
> Version: 2.5-4
> Severity: serious
> User: [EMAIL PROTECTED]
> Usertags: jbc-mismatch
>
> This package builds with openjdk-6 or cacao-oj6, which is not the
> default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
> creates java bytecode for version 50, which cannot be used by older
> jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
> must not depend on java-runtime{,1,2,5}{,-headless}, but only on
> java-runtime6{,-headless} or any of the non-virtual packages providing
> a java6 runtime.
Yes, and it depends on only openjdk-6-jre.
First of all, thanks for introducing a java-runtime6 virtual package. I
should add this automatic detection to jh_depends to produce an
appropriate alternate depends.
> Note: this report may be a false positive, if all bytecode files have
> version 49 or less.
Or if an appropriate depends already exists. Please take care not to
have false positives when filing RC-severity bugs this close to a
release (or at all).
Thanks,
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
Processed: Re: Bug#503781: dbus-java: java bytecode / java runtime version
Processing commands for [EMAIL PROTECTED]: > close 503781 Bug#503781: dbus-java: java bytecode / java runtime version mismatch 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to Matthias Klose <[EMAIL PROTECTED]> > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#449497: foo2zjs dispute
reassgin 449497 tech-ctte,foo2zjs thanks Dear Technical Committee Members Currently, there is a dispute about a certain part of the foo2zjs package. Unfortunately, we do not seem to be able to solve it and thus require your assistance. We have tried to get a paragraph together to state the problem, but it seems we ended up with two different paragraphs. The first one is from the maintainer (myself) and the second one belongs to the bug submitter (Michael Gilbert). Could you please pass your judgement on this case? You will find further information in the bugreport and I am sure that the submitter as well as the maintainers are happy to answer any follow-up questions. At the moment, the bug is marked as RC, which might have an impact for the lenny release. Thanks in advance for your time and judgement. Cheers Steffen Maintainer: -- The problem is as follows. The submitter sees the inclusion of the getweb script as a violation of the DFSG. The script is provided by upstream to download non-free firmware from his upstream webpage. The package includes documentation in README.Debian and a GUI interface (hannah-foo2zjs) around the getweb script for the user's convenience. Some printers need this non-free firmware to run, others don't. More information can be found in the bugreport. Could we please ask you to settle this dispute? Submitter: -- The submitter sees the getweb script's dependencies on external data/files as potentially dangerous. Once the package enters stable, upstream changes (moving/modifying files, etc.) can break functionality -- leading to a package that can no longer be considered "stable." External dependencies also potentially leave users vulnerable to security risks (the upstream site could be spoofed or hijacked and malicious files hosted instead of the legitimate firmware files). Also, the submitter views external dependencies as a possible violation of the spirit of the debian policy, which currently is not explicitly clear on the issue. Section 2.2.1 says "... the packages in main must not require a package outside of main for compilation or execution (thus, the package must not declare a 'Depends', 'Recommends', or 'Build-Depends' relationship on a non-main package)." This makes the policy clear about "packages," but it does not address dependencies on other external non-packaged non-free files. It is the submitter's belief that Debian's policy should be reworded for clarity on situations such as this. signature.asc Description: This is a digitally signed message part.
Bug#503735: gnome-chess: menus only work in English language locales
On Tuesday 28 October 2008 19:02:02 Philipp Kern wrote: > Did you even try it? Philipp, Yes I have tried the menus do work. I can setup a number of remote servers with the Preferences menu. Then when I click on File/New/Servers it presents the list of servers I setup. Selecting one attempts a connection. The menus do work as advertised with local en. > I get failed assertions in the console and the > program does neither work with LANG=C nor LC_ALL=C for me. What exactly do you mean the program doesn't work. Perhaps that is a different issue to the locales in this bug report. It is true however that this app isn't the most intuitive and the interface isn't very graceful in its usage. > severity grave While I don't want to start flapping severity between grave/ important I stand by my original claim that whilst important locale support isn't RC. However you have set it to grave so I will leave it to you to set as you see fit. Of course if the application doesn't work as advertised, or there are better alternatives then that is a different issue (and should be a different RC bug) and I would support removal if the maintainer isn't able to address these issues. Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#393837: More informations..
On Tue, Oct 28, 2008 at 09:44:49AM +0100, Josselin Mouette <[EMAIL PROTECTED]>
wrote:
> Le mardi 28 octobre 2008 à 10:17 +0200, Romain Beauxis a écrit :
> > Hi all !
> >
> > The issue can be isolated in this line:
> > window.openDialog('chrome://pippki/content/deletecert.xul', "",
> > 'chrome,centerscreen,modal', params);
> >
> > in certManager.js.
> >
> > If you remove this line, and comment the next if, then you simply remove
> > the
> > confirmation box. Could be a workaround perhaps if nothing better can be
> > find ?
> >
> > If you remove from the file delecert.js everything related to gParams, then
> > it
> > works, but does nothing.
> >
> > I'm strongly suspecting some sort of javascript failure, related to the
> > gParams variable, but, as usual, it really lacks a good damn javascript
> > debugging console.
>
> Yes, the params are correctly passed to the chrome dialog, but they are
> removed by some later call in the stack. The window is probably missing
> permissions to obtain them but I don’t know how it should get them. As
> this happens for all gtkmozembed applications I suspect this is
> something gtkmozembed should do.
It's either a gtkmozembed bug or a embedding bug, where the js context
for the windows doesn't do the right thing. The problem is: we don't know,
upstream doesn't know, and mozilla doesn't (seem to) care.
I'd say the best thing to do for epiphany would be to *not* use the
xul cert manager, but have its own native one, calling the proper
components. But this doesn't look like a solution that can be ready for
Lenny.
So maybe all we can do in the end is probably to use the workaround.
The problem with doing the workaround on xulrunner's end is that it will
also change behaviour in iceweasel, which is not really expected...
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#478105: seperate issue?
Will do. /J 2008/10/27 sean finney <[EMAIL PROTECTED]>: > notfound 478105 1.06-7 > thanks > > hi johan, > > as far as i can tell, your problem seems to be an entirely different issue. > > i downloaded the latest funguloids and both by default and with your config > it worked for me, so it seems something likely different with your client > system. therefore if you continue to experience this problem please open a > new (non RC) bug. > > > thanks >sean > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iD8DBQFJBjUaynjLPm522B0RAv9FAJkBDRGE+jChXjTpu1QFzOqMLw5lRACeKP3t > zmjc3P+2ig6m/00PQbU8p14= > =eZIK > -END PGP SIGNATURE- > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: creating a bug for the tech-ctte as requested via http://www.debian.org/devel/tech-ctte
Processing commands for [EMAIL PROTECTED]: > clone 449497 -1 -2 Bug#449497: foo2zjs: getweb script depends on non-free firmware Bug 449497 cloned as bugs 503813-503814. > reassign -1 foo2zjs Bug#503813: foo2zjs: getweb script depends on non-free firmware Bug reassigned from package `foo2zjs' to `foo2zjs'. > reassign -2 tech-ctte Bug#503814: foo2zjs: getweb script depends on non-free firmware Bug reassigned from package `foo2zjs' to `tech-ctte'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500418: istanbul Please also re-enable hppa
On Tuesday 28 October 2008 19:39:16 Philipp Kern wrote: > The maintainer of the package worked around some buildd problem, Philipp, I agree. The question remains, is it RC, ie serious, or important for the maintainer to restore the missing archs - hppa mips mipsel. Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503571: Unable to reproduce - Bug#503571 aqualung: does not run: crashes after start
Hi, thanks for your feedback. Sorry for not reporting this - I'm using Debian testing and the Debian multimedia (deb http://www.debian-multimedia.org/ testing main) packages - maybe it's related to these libraries... I just compiled Aqualung R-1032 from source and it works fine for me. So if it's not an issue in the Debian testing but rather a compatibility issue with multimedia and testing, I apologize and you may close this report. I must admit that this could really be the case, since I remember that VLC was once broken because of some incompatible multimedia libs. Regards Benjamin Adam Cécile (Le_Vert) schrieb: > Hello Mark, Ben > > I'm unable to reproduce this issue on my up to date lenny box either. > > Ben, are you sure you don't have sid/experimental parts or unofficial > packages ? > > Regards, Adam. > > > Mark Purcell a écrit : >> Package: aqualung >> Followup-For: Bug #503571 >> >> Ben, Adam, >> >> I am unable to reproduce here, aqualung works fine under lenny. >> >> Mark >> >> >> -- System Information: >> Debian Release: lenny/sid >> APT prefers testing >> APT policy: (500, 'testing') >> Architecture: i386 (i686) >> >> Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) >> Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) >> Shell: /bin/sh linked to /bin/bash >> >> Versions of packages aqualung depends on: >> ii libasound2 1.0.16-2 ALSA library >> ii libatk1.0-01.22.0-1 The ATK accessibility >> toolkit >> ii libavcodec51 3:20080706-0.2library to encode decode >> multimedi >> ii libavformat52 3:20080706-0.2ffmpeg file format library >> ii libavutil493:20080706-0.2avutil shared libraries >> ii libc6 2.7-14GNU C Library: Shared >> libraries >> ii libcairo2 1.6.4-6.1 The Cairo 2D vector >> graphics libra >> ii libcddb2 1.2.1-1 library to access CDDB >> data - runt >> ii libcdio-cdda0 0.78.2+dfsg1-3library to read and >> control digita >> ii libcdio-paranoia0 0.78.2+dfsg1-3library to read digital >> audio CDs ii libcdio7 0.78.2+dfsg1-3library to >> read and control CD-ROM >> ii libflac8 1.2.1-1.2 Free Lossless Audio >> Codec - runtim >> ii libglib2.0-0 2.16.6-1 The GLib library of C >> routines >> ii libgtk2.0-02.12.11-4 The GTK+ graphical user >> interface ii libifp41.0.0.2-3 communicate >> with iRiver iFP audio ii libjack0 0.109.2-3 >> JACK Audio Connection Kit (librari >> ii liblrdf0 0.4.0-1.1 a library to manipulate >> RDF files ii libmad00.15.1b-3 MPEG audio >> decoder library >> ii libmodplug0c2 1:0.8.4-1 shared libraries for mod >> music bas >> ii libmpcdec3 1.2.2-1 Musepack (MPC) format >> library >> ii libogg01.1.3-4 Ogg Bitstream Library >> ii liboggz1 0.9.8-1 convenience interface >> for Ogg stre >> ii libpango1.0-0 1.20.5-3 Layout and rendering of >> internatio >> ii libsamplerate0 0.1.4-1 audio rate conversion >> library >> ii libsndfile11.0.17-4 Library for >> reading/writing audio ii libspeex1 1.2~rc1-1 >> The Speex codec runtime library >> ii libstdc++6 4.3.2-1 The GNU Standard C++ >> Library v3 >> ii libusb-0.1-4 2:0.1.12-12 userspace USB >> programming library >> ii libvorbis0a1.2.0.dfsg-3.1The Vorbis General Audio >> Compressi >> ii libvorbisenc2 1.2.0.dfsg-3.1The Vorbis General Audio >> Compressi >> ii libvorbisfile3 1.2.0.dfsg-3.1The Vorbis General Audio >> Compressi >> ii libwavpack14.50.1-1 an audio codec (lossy >> and lossless >> ii libxml22.6.32.dfsg-4 GNOME XML library >> ii zlib1g 1:1.2.3.3.dfsg-12 compression library - >> runtime >> >> aqualung recommends no packages. >> >> aqualung suggests no packages. >> >> -- no debconf information >> >> >> > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503571: Unable to reproduce - Bug#503571 aqualung: does not run: crashes after start
On Tuesday 28 October 2008 20:11:20 Benjamin Scherrer wrote: > So if it's not an issue in the Debian testing but rather a compatibility > issue with multimedia and testing, I am using testing & multimedia as well and have no issue. Adam, If you could close the report that would help the lenny release as this is showing up on the list of RC bugs. Thanks, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501306: update-grub fails silently with wrong device.map
On Mon, 27 Oct 2008, Robert Millan wrote:
> On Thu, Oct 23, 2008 at 05:45:40PM +0200, Felix Zielcke wrote:
> > Attached is now an ugly patch which would display the grub-probe error
> > "Check your device.map" if it fails.
> >
> > Else I had the idea to make an environment variable like
> > GRUB_PROBE_HIDE_ERRORS=1 which would hide the output of
> > grub_print_error() but then we would need to change grub-common and grub
> > package to fix this bug.
> >
> > What do you think Robert?
>
> Sounds like a good idea. Except that the message in first hunk is not correct
> (it should say Cannot find a device for $1 or something like that).
I have two concerns with this:
- grub-probe can possibly fail in other circumstances and we will display
a misleading error message in those cases
- the installation will still fail and most users have no idea what
device.map really is. If you go that route, you should at least give
them the command-line to execute to regenerate the device.map
On the long term, the best would be to use UUID instead of partition names
to be able to reliably find the device name of the intended partition/and
hence drive. I think this is already done for grub2.
But in the mean time for Grub 1, wouldn't the best solution simply be
to regenerate the device.map in case of errors and try again ?
Someone with a customized but working device.map wouldn't get it rewritten
but someone with a bad file would get it fixed.
> > + GRUB_LEGACY_0_BASED_PARTITIONS=1 grub-probe --device-map=${device_map}
> > -t drive -d "$1" 2> /dev/null || \
> > +(echo "Cannot find a GRUB drive for $1. Check your device.map."
> > && exit 1)
We would then have something like this:
GRUB_LEGACY_0_BASED_PARTITIONS=1 grub-probe --device-map=${device_map} -t drive
-d "$1" 2> /dev/null || \
(grub-mkdevicemap --device-map=${device_map} --no-floppy >/dev/null 2>&1 ||
true; \
GRUB_LEGACY_0_BASED_PARTITIONS=1 grub-probe --device-map=${device_map} -t
drive -d "$1")
If it fails, we regenerate the device.map and try again but this time we
won't hide any error so that if it fails again the user has a chance to
debug it but with the real error message instead.
Does that sound reasonable ?
I'll try that and post a patch if my test shows that it works.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#393837: More informations..
Le mardi 28 octobre 2008 à 10:05 +0100, Mike Hommey a écrit : > > Le mardi 28 octobre 2008 à 10:17 +0200, Romain Beauxis a écrit : > > > If you remove this line, and comment the next if, then you simply remove > > > the > > > confirmation box. Could be a workaround perhaps if nothing better can be > > > find ? > So maybe all we can do in the end is probably to use the workaround. > The problem with doing the workaround on xulrunner's end is that it will > also change behaviour in iceweasel, which is not really expected... Idea #1: use the confirm() Javascript function instead. Idea #2: for epiphany, provide a certManager2.xul that has the changes so that Iceweasel is not affected. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Bug#393837: More informations..
Le mardi 28 octobre 2008 à 10:36 +0100, Mike Hommey a écrit : > > Idea #1: use the confirm() Javascript function instead. > > > > Idea #2: for epiphany, provide a certManager2.xul that has the changes > > so that Iceweasel is not affected. > > Idea #3: override certManager.xul with a custom version in epiphany. That’s almost the same as #2, I don’t have a problem with that. How should it be shipped? A .jar and a .manifest in /usr/share/xulrunner-1.9/chrome ? -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Bug#393837: More informations..
On Tue, Oct 28, 2008 at 10:40:29AM +0100, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le mardi 28 octobre 2008 à 10:36 +0100, Mike Hommey a écrit : > > > Idea #1: use the confirm() Javascript function instead. > > > > > > Idea #2: for epiphany, provide a certManager2.xul that has the changes > > > so that Iceweasel is not affected. > > > > Idea #3: override certManager.xul with a custom version in epiphany. > > That’s almost the same as #2, I don’t have a problem with that. How > should it be shipped? A .jar and a .manifest > in /usr/share/xulrunner-1.9/chrome ? Take a look at /usr/share/epiphany-browser/chrome/app-chrome.manifest Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503408: #503408: mxallowd: doesn't preserve local changes to /etc/mxallowd.conf
On Sat, Oct 25, 2008 at 09:17:04PM +0300, Niko Tyni wrote: > I'm leaving the local changes one at 'serious' because it affects upgrades > from earlier versions like the one currently in Ubuntu (1.5a-1). I just > tested the upgrade, and it indeed ignores local changes. I don't think > 'important' is the right severity, even though mxallowd has never been > in a stable Debian release. Just to be clear: 'local changes' above should be read as 'manual changes to /etc/mxallowd.conf'. One more problem is that the package both ships /etc/mxallowd.conf as a dpkg conffile and modifies it with maintainer scripts. This is explicitly forbidden by the policy, see section 10.7.3. Michael, sorry to be the bearer of bad news. As a compensation, I've got a proposed patch almost ready and will send it hopefully tonight. I had a look at your update package on mentors.debian.net, please note that there's a version discrepancy with the Debian archive (both are currently at 1.6a-2). -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503311: monit: Client Certificate authentication fails with openssl-engine error
Georges Toth wrote: Quoting Martin Pala <[EMAIL PROTECTED]>: Please can you provide your monit configuration? (the "set httpd ..." part is sufficient). set httpd port 28000 and use address 123.123.123.123 ssl enable pemfile /etc/ssl/ca_priv_pub.pem clientpemfile /etc/monit/client_certificates.pem ALLOWSELFCERTIFICATION Is the certificate self-signed or using public CA? It's a self-signed certificate. Besides the version, nothing changed on the server. Firefox (32bit binary, 3.x, gentoo) seems to be the problem here. Certificate is correctly installed, including root (with correct cert-permissions set in firefox). Firefox doesn't even ask for me to choose a certificate. On other website it on the other hand does. Really strange... I tried to replicate ... using self-compiled monit-5.0_beta4 with libssl-0.9.8g-13 on Debian-unstable with Iceweasel-3.0.3-2 works fine. Configuration: --8<-- set httpd port 2812 and use address 127.0.0.1 ssl enable pemfile /var/certs/monit.pem clientpemfile /var/certs/monit_client.pem allowselfcertification allow localhost --8<-- I can see the same error logged which you saw as well: --8<-- monit: Openssl engine error: error:140D9115:SSL routines:func(217):reason(277) --8<-- ... but the authentication works, and i don't see the error which you mentioned and which is root cause of the problem: --8<-- monit[2067]: monit: The client did not supply a required client certificate! --8<-- When i switched the Iceweasel's certificate setting: Edit->Preferences->Advanced->Encryption->"When a server requests my personal certificate" to "Ask me every time" i get the dialog which reports that Monit asked for certificate and allows to select the certificate. Summary: it's quite strange problem - in Monit there were no changes in SSL related code between 4.10.1 and 5.0_beta4 so they should work the same. It's possible that it's browser problem (on your side, konqueror worked and i have tested with Iceweasel alias Firefox without problem). Thanks, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#503770: carmetal: java bytecode / java runtime version mismatch
Processing commands for [EMAIL PROTECTED]: > close 503770 Bug#503770: carmetal: java bytecode / java runtime version mismatch 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to Matthias Klose <[EMAIL PROTECTED]> > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503770: carmetal: java bytecode / java runtime version mismatch
Hello,
Matthias Klose wrote:
Package: carmetal
Version: 2.8.9.dakbug-1
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
I dont understand where is the mismatch ? CarMetal binary depends on
openjdk-6-jre | java6-runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
Should the package support sun's or ibm's debian packaged java5 ? If i
change compilation option, i suppose i should add dependancy on sun's or
ibm's java5. java5-runtime is not a solution, as gcj fails to run carmetal.
--
yves
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503770: carmetal: java bytecode / java runtime version mismatch
close 503770
thanks
On Tue Oct 28 10:35, Yves Combe wrote:
>> This package builds with openjdk-6 or cacao-oj6, which is not the
>> default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
>> creates java bytecode for version 50, which cannot be used by older
>> jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
>> must not depend on java-runtime{,1,2,5}{,-headless}, but only on
>> java-runtime6{,-headless} or any of the non-virtual packages providing
>> a java6 runtime.
>>
> I dont understand where is the mismatch ? CarMetal binary depends on
> openjdk-6-jre | java6-runtime.
>
Looks like another false positive to me, so I've closed the bug.
_please_ can you make sure to eliminate any false positives before
filing RC-severity bugs, particularly this close to a release.
You seem to have filed quite a lot of these. Did I miss the -devel
thread about this mass bug filing? Particularly for RC bugs it is really
important to do that before filing them all.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
Bug#393837: More informations..
On Tue, Oct 28, 2008 at 10:32:44AM +0100, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le mardi 28 octobre 2008 à 10:05 +0100, Mike Hommey a écrit : > > > Le mardi 28 octobre 2008 à 10:17 +0200, Romain Beauxis a écrit : > > > > If you remove this line, and comment the next if, then you simply > > > > remove the > > > > confirmation box. Could be a workaround perhaps if nothing better can > > > > be > > > > find ? > > > So maybe all we can do in the end is probably to use the workaround. > > The problem with doing the workaround on xulrunner's end is that it will > > also change behaviour in iceweasel, which is not really expected... > > Idea #1: use the confirm() Javascript function instead. > > Idea #2: for epiphany, provide a certManager2.xul that has the changes > so that Iceweasel is not affected. Idea #3: override certManager.xul with a custom version in epiphany. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503571: Unable to reproduce - Bug#503571 aqualung: does not run: crashes after start
Mark Purcell a écrit : On Tuesday 28 October 2008 20:11:20 Benjamin Scherrer wrote: So if it's not an issue in the Debian testing but rather a compatibility issue with multimedia and testing, I am using testing & multimedia as well and have no issue. Adam, If you could close the report that would help the lenny release as this is showing up on the list of RC bugs. Thanks, Mark Do you mean I should close the bug right now, even Ben has still this issue ? Adam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503367: [Debian-med-packaging] Bug#503367: Bug#503367: Bug#503367: plink: file conflict with putty-tools
Charles Plessy schrieb: > Le Tue, Oct 28, 2008 at 09:32:42AM +0200, Teodor a écrit : > >> I still believe it is best to rename 'plink' to 'puttylink' in >> putty-tools binary package. Anyway, this should be fixed for squeeze >> since in lenny there is no conflict (plink is not included in lenny). >> > > Hi all, > > Upstream documented the renaming on his website, so I think that that is the > (happy) end of the story :) > > "Debian users: PLINK is available as a Debian package, see these notes. > Note, the > executable is named snplink in the Debian plink package." > > http://pngu.mgh.harvard.edu/~purcell/plink/download.shtml > To me, the renaming to snplink is an exceptionally unfortunate way to address the name-conflict we experienced. This way, we render Debian incompatible with scripts distributed in the community and incompatible with computational grids, too. I am just writing from a grid conference and plink was indeed referenced on one slide. I don't want either plink to be renamed, completely following the points brought up Brian and definitely prefer a conflict between the two plink packages. Those users who _really_ need both and _really_ need to work with Debian packages only, they can have a chroot environment for the bioinformatics-plink. Besides: there is a SNPLINK already: http://bioinformatics.oxfordjournals.org/cgi/content/full/21/13/3060 The executable in either package should not be renamed. I don't see a reasonable way around it. The only problem that I originally understood from skimming over the thread was that Debian packages would be named equally and I was too busy to wonder for too long how this could be allowed by the Debian infrastructure. But embarrassingly, after checking things manually, I just spotted that putty's plink is not coming as a package with that name but that it is wrapped up to the package putty-tools. This is just fine to me. I'll add a "Conflicts: putty-tools" to the plink control file, upload plink's new version 1.04 and we are set. To summarise things up: the renaming of the executable of plink to snplink renders the plink package inferior to a manual installation of plink under the proper name. What I'll do now unless I hear some objections that I am mentally prepared to follow: I'll prepare the new version, add the conflict to debian/control to close 503367 (won't fix) and herewith truly apologize for all these emails. Best, Steffen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503367: [Debian-med-packaging] Bug#503367: Bug#503367: Bug#503367: plink: file conflict with putty-tools
Steffen Möller schrieb am Dienstag, dem 28. Oktober 2008: > To summarise things up: the renaming of the executable of plink to > snplink renders the plink package inferior to a manual installation of > plink under the proper name. What I'll do now unless I hear some > objections that I am mentally prepared to follow: I'll prepare the new > version, add the conflict to debian/control to close 503367 (won't fix) > and herewith truly apologize for all these emails. The packages provide different functionality. They should therefore not conflict. If you cannot agree on who should rename their binary, both packages will have to rename it. See http://www.debian.org/doc/debian-policy/ch-files.html first paragraph. Tho I think that putty being the more senior one should have the right of the name and not be forced to rename its binaries. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500418: istanbul Please also re-enable hppa
severity 500418 serious thanks Mark Purcell wrote: > severity 500418 important > thanks > > On Tuesday 28 October 2008 10:57:39 Thiemo Seufer wrote: > > severity 500418 serious > [...] > > Please add hppa mips mipsel to the allowed architectures in debian/control. > > Thiemo, > > Whilst I agree is is important for hppa mips & mipsel to be supported > architectures I don't think the build of istanbul on these arches is release > critical for lenny nor does it make the package unfit for release, given that > the package already in lenny hasn't been build for these arches. For hppa it is a regression over etch and therefore RC. > However, if Luca or Florian are able to build/ upload a new package that > would > be welcome. However that shouldn't effect the severity of this bug report. I can do a NMU if they are short on time. (And iff the bugs remains flagged as RC, as Developer's Reference 5.10.2.2 recommends.) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#500418: istanbul Please also re-enable hppa
Processing commands for [EMAIL PROTECTED]: > severity 500418 serious Bug#500418: Please re-enable istanbul builds on mips/mipsel Severity set to `serious' from `serious' > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503821: linux-image-2.6.26-1-xen-amd64: Kernel crash in Dom0 (Eeek! page_mapcount(page) went negative! (-1))
Package: linux-image-2.6.26-1-xen-amd64 Version: 2.6.26-9 Severity: grave Justification: renders package unusable I'm trying to run Xen in Lenny with the new 2.6.26-kernel as Dom0. It seems to be some problems on the amd64 architecture. After approx 10-20 hours of uptime, the Dom0 crash (even if there is no DomU running) with the following error: [50079.669383] Eeek! page_mapcount(page) went negative! (-1) [50079.669383] page pfn = 5 [50079.669383] page->flags = 0 [50079.669383] page->count = 0 [50079.669383] page->mapping = [50079.669383] vma->vm_ops = 0x0 [50079.669383] [ cut here ] [50079.669383] kernel BUG at mm/rmap.c:673! [50079.669383] invalid opcode: [1] SMP [50079.669383] CPU 0 [50079.669383] Modules linked in: xt_tcpudp xt_physdev iptable_filter ip_tables x_tables bridge netloop video output ac battery microcode firmware_class nfsd auth_rpcgss exportfs nfs lockd nfs_acl sunrpc ipv6 xfs reiserfs ext2 sha256_generic aes_x86_64 aes_generic cbc dm_crypt crypto_blkcipher raid456 async_xor async_memcpy async_tx xor loop iTCO_wdt serio_raw i2c_i801 psmouse pcspkr i2c_core rng_core container button i3000_edac edac_core shpchp pci_hotplug evdev joydev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod raid1 md_mod ide_cd_mod cdrom ide_pci_generic usbhid hid ff_memless piix ide_core ata_piix sd_mod floppy ata_generic ehci_hcd uhci_hcd sata_sil24 e1000e libata dock 3w_9xxx scsi_mod thermal processor fan thermal_sys [50079.669383] Pid: 9197, comm: mutt Not tainted 2.6.26-1-xen-amd64 #1 [50079.669383] RIP: e030:[] [] page_remove_rmap+0xfb/0x117 [50079.669383] RSP: e02b:880074601dc8 EFLAGS: 00010246 [50079.669383] RAX: RBX: 880002359118 RCX: 51510001509d [50079.669383] RDX: ff5f7000 RSI: 0001 RDI: 805aaab0 [50079.669383] RBP: 8800746d1918 R08: 0023 R09: 880074601800 [50079.669383] R10: R11: 014221337ed7 R12: 880002359118 [50079.669383] R13: 880014e61320 R14: 88007ff34b80 R15: 8800027eb548 [50079.669383] FS: 7f2b26ff4700() GS:80539000() knlGS: [50079.669383] CS: e033 DS: ES: [50079.669383] DR0: DR1: DR2: [50079.669383] DR3: DR6: 0ff0 DR7: 0400 [50079.669383] Process mutt (pid: 9197, threadinfo 88007460, task 8800745929f0) [50079.669383] Stack: 880014e610e8 5100 05e64000 80273239 [50079.669383] 88007475c000 880074601ec8 [50079.669383] 8800746d1918 880074601ed0 003b9000 [50079.669383] Call Trace: [50079.669383] [] ? unmap_vmas+0x744/0xa49 [50079.669383] [] ? exit_mmap+0x7b/0xf7 [50079.669383] [] ? mmput+0x2c/0xc0 [50079.669383] [] ? do_exit+0x25a/0x6ce [50079.669383] [] ? do_group_exit+0xa6/0xdc [50079.669383] [] ? system_call+0x68/0x6d [50079.669383] [] ? system_call+0x0/0x6d [50079.669383] [50079.669383] [50079.669383] Code: 80 e8 18 0c fd ff 48 8b 85 90 00 00 00 48 85 c0 74 19 48 8b 40 20 48 85 c0 74 10 48 8b 70 58 48 c7 c7 e1 52 4b 80 e8 f3 0b fd ff <0f> 0b eb fe 8b 77 18 41 58 5b 5d 83 e6 01 f7 de 83 c6 04 e9 64 [50079.669383] RIP [] page_remove_rmap+0xfb/0x117 [50079.669383] RSP [50079.673388] ---[ end trace c445527cbda75056 ]--- [50079.673479] Fixing recursive fault but reboot is needed! The same system is stable when running linux-image-2.6.26-1-amd64. I've also successfully ran linux-image-2.6.26-1-xen-686 using i386-architecture on the same hardware, so it seems to happen only in Xen-variants on amd64 architecture. I have no reliable way of forcing the error to occur. The best way I've found so far to get this crash is to do a couple of kernel-recompilations, but sometimes I can do a couple of compile-runs without crash. The hardware on this box is a Supermicro PDSME+-motherboard, with a E6600 Core2Duo and 8 Gigs of RAM (ECC) I've run memtest86+ for over 24 hours with no problems reported. I'm not sure if I should tag this as grave or critical, but I feel that it's impossible to run a Xen-system on AMD64 with Debian Lenny currently. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-1-xen-amd64 depends on: ii initramfs-tools 0.92j tools for generating an initramfs ii linux-modules-2.6.26-1-xen-am 2.6.26-9 Linux 2.6.26 modules on AMD64 linux-image-2.6.26-1-xen-amd64 recommends no packages. Versions of packages linux-image-2.6.26-1-xen-amd64 suggests: ii grub 0.97-47GRand Unified Bootloader (Legacy v ii linux-doc
Bug#501306: grub: diff for NMU version 0.97-47.1
tags 501306 + patch
thanks
Hello,
here's the patch that I announced sooner. I tested here by changing
device.map to not reference my /boot and / partitions. Running
udpdate-grub still works but it displays one line more saying that
device.map got regenerated.
I don't think that find_device() needs any change.
If you want me to upload this as NMU, please say so, otherwise I'll let
you handle it.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
diff -u grub-0.97/debian/update-grub grub-0.97/debian/update-grub
--- grub-0.97/debian/update-grub
+++ grub-0.97/debian/update-grub
@@ -152,7 +152,11 @@
if ! test -e ${device_map} ; then
echo quit | grub --batch --no-floppy --device-map=${device_map} > /dev/null
fi
- GRUB_LEGACY_0_BASED_PARTITIONS=1 grub-probe --device-map=${device_map} -t drive -d "$1" 2> /dev/null
+ GRUB_LEGACY_0_BASED_PARTITIONS=1 grub-probe --device-map=${device_map} -t drive -d "$1" 2> /dev/null || {
+ echo "Can't find drive for $1, will regenerate ${device_map} and try again." >&2
+ grub-mkdevicemap --device-map=${device_map} --no-floppy >/dev/null 2>&1 || true
+ GRUB_LEGACY_0_BASED_PARTITIONS=1 grub-probe --device-map=${device_map} -t drive -d "$1"
+ }
}
# Usage: convert_default os_device
diff -u grub-0.97/debian/changelog grub-0.97/debian/changelog
--- grub-0.97/debian/changelog
+++ grub-0.97/debian/changelog
@@ -1,3 +1,13 @@
+grub (0.97-47.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Regenerate /boot/grub/device.map if update-grub is about to fail due to a
+grub-probe failure that is likely caused by an invalid device.map. Do not
+hide the error on the second try to let a chance to the user to diagnose
+the real problem. Closes: #501306
+
+ -- Raphael Hertzog <[EMAIL PROTECTED]> Tue, 28 Oct 2008 11:23:27 +0100
+
grub (0.97-47) unstable; urgency=high
* update-grub: Send grub-probe stderr output to /dev/null. (Closes: #495909)
Bug#503408: mxallowd: doesn't preserve local changes to /etc/mxallowd.conf
Hi Niko, * [28.10.08 11:29]: > One more problem is that the package both ships /etc/mxallowd.conf > as a dpkg conffile and modifies it with maintainer scripts. This > is explicitly forbidden by the policy, see section 10.7.3. Thanks for the hint. I'll rebuild the package later without the entry in conffiles. > Michael, sorry to be the bearer of bad news. As a compensation, I've > got a proposed patch almost ready and will send it hopefully tonight. No problem. I'm thankful for getting the package right. A complete patch for the problems to 1.6a-2 would be great. Thanks in advance > I had a look at your update package on mentors.debian.net, please note > that there's a version discrepancy with the Debian archive (both are > currently at 1.6a-2). I've already fixed it and got a mail that 1.6a-2 was uploaded. Best regards, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: grub: diff for NMU version 0.97-47.1
Processing commands for [EMAIL PROTECTED]: > tags 501306 + patch Bug#501306: update-grub fails silently with wrong device.map There were no tags set. Tags added: patch > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502757: marked as done (nut-cgi: piuparts test fails: chmod: cannot access `/etc/nut': No such file or directory)
Your message dated Tue, 28 Oct 2008 10:30:32 + with message-id <[EMAIL PROTECTED]> and subject line Bug#502757: fixed in nut 2.2.2-6.2 has caused the Debian Bug report #502757, regarding nut-cgi: piuparts test fails: chmod: cannot access `/etc/nut': No such file or directory to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 502757: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502757 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems --- Begin Message --- Package: nut-cgi Version: 2.2.2-6 Severity: serious User: [EMAIL PROTECTED] Usertags: piuparts-20081019 piuparts Hi, During tests using piuparts of all packages in lenny, I ran into the following problem: > Reading package lists... > Building dependency tree... > Reading state information... > The following packages were automatically installed and are no longer > required: > libgc1c2 > Use 'apt-get autoremove' to remove them. > The following extra packages will be installed: > adduser apache2-mpm-itk apache2-utils apache2.2-common defoma file > fontconfig-config ifupdown libapr1 libaprutil1 libcap2 libdb4.5 libexpat1 > libfontconfig1 libfreetype6 libfribidi0 libgcrypt11 libgd2-xpm libgdbm3 > libgnutls26 libgpg-error0 libgpm2 libjpeg62 libkeyutils1 libkrb53 > libldap-2.4-2 libmagic1 libmysqlclient15off libncursesw5 libnewt0.52 > libpcre3 libpng12-0 libpopt0 libpq5 libsasl2-2 libsasl2-modules > libsqlite3-0 > libssl0.9.8 libtasn1-3 libupsclient1 libx11-6 libx11-data libxau6 > libxcb-xlib0 libxcb1 libxdmcp6 libxpm4 mime-support mysql-common net-tools > netbase openssl openssl-blacklist perl perl-doc perl-modules procps psmisc > python python-minimal python2.5 python2.5-minimal ssl-cert ttf-dejavu > ttf-dejavu-core ttf-dejavu-extra ucf whiptail x11-common > Suggested packages: > www-browser apache2-doc apache2-suexec apache2-suexec-custom defoma-doc > dfontmgr psfontmgr x-ttcidfont-conf iproute dhcp3-client dhcp-client ppp > libfreetype6-dev rng-tools libgd-tools gnutls-bin gpm krb5-doc krb5-user > libsasl2-modules-otp libsasl2-modules-ldap libsasl2-modules-sql > libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-heimdal nut > ca-certificates libterm-readline-gnu-perl libterm-readline-perl-perl > man-browser groff python-doc python-tk python-profiler python2.5-doc > binfmt-support > Recommended packages: > libft-perl apache httpd > The following NEW packages will be installed: > adduser apache2-mpm-itk apache2-utils apache2.2-common defoma file > fontconfig-config ifupdown libapr1 libaprutil1 libcap2 libdb4.5 libexpat1 > libfontconfig1 libfreetype6 libfribidi0 libgcrypt11 libgd2-xpm libgdbm3 > libgnutls26 libgpg-error0 libgpm2 libjpeg62 libkeyutils1 libkrb53 > libldap-2.4-2 libmagic1 libmysqlclient15off libncursesw5 libnewt0.52 > libpcre3 libpng12-0 libpopt0 libpq5 libsasl2-2 libsasl2-modules > libsqlite3-0 > libssl0.9.8 libtasn1-3 libupsclient1 libx11-6 libx11-data libxau6 > libxcb-xlib0 libxcb1 libxdmcp6 libxpm4 mime-support mysql-common net-tools > netbase nut-cgi openssl openssl-blacklist perl perl-doc perl-modules > procps > psmisc python python-minimal python2.5 python2.5-minimal ssl-cert > ttf-dejavu > ttf-dejavu-core ttf-dejavu-extra ucf whiptail x11-common > 0 upgraded, 70 newly installed, 0 to remove and 0 not upgraded. > Need to get 46.0MB of archives. > After this operation, 121MB of additional disk space will be used. > WARNING: The following packages cannot be authenticated! > python2.5-minimal mime-support libdb4.5 libncursesw5 libsqlite3-0 > libssl0.9.8 python2.5 python-minimal python openssl openssl-blacklist > x11-common adduser net-tools ifupdown libgpg-error0 libgcrypt11 libgdbm3 > libtasn1-3 libgnutls26 libnewt0.52 libpopt0 libsasl2-2 netbase whiptail > procps libmagic1 file libgpm2 libkeyutils1 libkrb53 libpcre3 perl-modules > perl libapr1 libexpat1 libldap-2.4-2 mysql-common libmysqlclient15off > libpq5 > libaprutil1 apache2-utils apache2.2-common defoma ucf ttf-dejavu-core > ttf-dejavu-extra ttf-dejavu fontconfig-config libcap2 libfreetype6 > libfontconfig1 libfribidi0 libjpeg62 libpng12-0 libxau6 libxdmcp6 libxcb1 > libxcb-xlib0 libx11-data libx11-6 libxpm4 libgd2-xpm libsasl2-modules > libupsclient1 nut-cgi perl-doc psmisc ssl-cert apache2-mpm-itk > Authentication warning overridden. > Get:1 http://127.0.0.1 lenny/main python2.5-minimal 2.5.2-11.1 [1180kB] > Get:2 http://127.0.0.1 lenny/main mime-support 3.44-1 [33.3kB] > Get
Bug#482140: marked as done (docbook-xml: Package does not install: update-xmlcatalog: error: entity already registered)
Your message dated Tue, 28 Oct 2008 10:27:36 + with message-id <[EMAIL PROTECTED]> and subject line Bug#482140: fixed in docbook-xml 4.5-6 has caused the Debian Bug report #482140, regarding docbook-xml: Package does not install: update-xmlcatalog: error: entity already registered to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 482140: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482140 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems --- Begin Message --- Package: docbook-xml Version: 4.5-5 Severity: serious When configuring docbook-xml after installation, I get the error -- update-xmlcatalog: error: entity already registered dpkg: error processing docbook-xml (--configure): subprocess post-installation script returned error exit status 1 -- This happened on a just installed box, upgrading from stable -> testing -> unstable. Sami -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages docbook-xml depends on: ii sgml-base 1.26 SGML infrastructure and SGML catal ii sgml-data 2.0.3 common SGML and XML data ii xml-core 0.11 XML infrastructure and XML catalog docbook-xml recommends no packages. -- no debconf information --- End Message --- --- Begin Message --- Source: docbook-xml Source-Version: 4.5-6 We believe that the bug you reported is fixed in the latest version of docbook-xml, which is due to be installed in the Debian FTP archive: docbook-xml_4.5-6.diff.gz to pool/main/d/docbook-xml/docbook-xml_4.5-6.diff.gz docbook-xml_4.5-6.dsc to pool/main/d/docbook-xml/docbook-xml_4.5-6.dsc docbook-xml_4.5-6_all.deb to pool/main/d/docbook-xml/docbook-xml_4.5-6_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Daniel Leidert (dale) <[EMAIL PROTECTED]> (supplier of updated docbook-xml package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 26 Oct 2008 15:13:10 +0100 Source: docbook-xml Binary: docbook-xml Architecture: source all Version: 4.5-6 Distribution: unstable Urgency: low Maintainer: Debian XML/SGML Group <[EMAIL PROTECTED]> Changed-By: Daniel Leidert (dale) <[EMAIL PROTECTED]> Description: docbook-xml - standard XML documentation system, for software and systems Closes: 482140 Changes: docbook-xml (4.5-6) unstable; urgency=low . * debian/compat: Raised to v5. * debian/control: Vcs fields transition. Added DM-Upload-Allowed. (Vcs-Svn): Fixed location. (Build-Depends): Raised debhelper to v5. (Depends): Moved xml-core to Pre-Depends and increased the version to 0.12 (closes: #482140). (Standards-Version): Raised to 3.7.3. * debian/rules (debian/docbook-xml.install): Fixed to not put non-existent files into the .install file. (debian/docbook-xml.xmlcatalogs): Use `sed -i' and do not create a temporary file. * debian/source.lintian-overrides: Added to override patch-system-but-direct-changes-in-diff warning, because file creation is intended. Checksums-Sha1: 68b92c15f02f4f8dacc9422d377ed612b5e26c99 1360 docbook-xml_4.5-6.dsc e9b51f69a434a01e4958f66c9f02eb2babc280b4 22059 docbook-xml_4.5-6.diff.gz 8bb8f3d77c37feec07d8741e3475a5668f752384 344524 docbook-xml_4.5-6_all.deb Checksums-Sha256: 38154040e8edd4dae1d7adc25b414e4d52842a3c823efaf77a68e1737a6a9755 1360 docbook-xml_4.5-6.dsc dc7e54c743140feccdd0a9ce69ad1c0860c5959ce97f4d25de20e6e58dc14de5 22059 docbook-xml_4.5-6.diff.gz 056aff9e8ed20753035cd42f44ad26f6f8ab0cb2ab9da9c686744979b9c1a138 344524 docbook-xml_4.5-6_all.deb Files: 7b31a7d0ca136613b423e1afe00f19cc 1360 text optional docbook-xml_4.5-6.dsc 308664c0b3dca46430e0f47731323f0a 22059 text optional docbook-xml_4.5-6.diff.gz a61a49447bb3888c04a9ef07af0d6487 344524 text optional docbook-xml_4.5-6_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD
Bug#502781: marked as done (docbook-xml: upgrading from etch to lenny - need to remove this package)
Your message dated Tue, 28 Oct 2008 10:27:36 + with message-id <[EMAIL PROTECTED]> and subject line Bug#482140: fixed in docbook-xml 4.5-6 has caused the Debian Bug report #482140, regarding docbook-xml: upgrading from etch to lenny - need to remove this package to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 482140: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482140 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems --- Begin Message --- Package: docbook-xml Version: 4.5-5 Severity: normal hi, as written in "What you can do for Lenny ?" (seems to be a very good version !) , i would like to inform you that i had to remove this package to upgrade my recently installed etch to Lenny. After removing this package, dist-upgrade has been succesfull. Thanks. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages docbook-xml depends on: ii sgml-base 1.26 SGML infrastructure and SGML catal ii sgml-data 2.0.3 common SGML and XML data ii xml-core 0.11 XML infrastructure and XML catalog docbook-xml recommends no packages. Versions of packages docbook-xml suggests: pn docbook(no description available) pn docbook-defguide (no description available) pn docbook-dsssl (no description available) pn docbook-xsl(no description available) -- no debconf information --- End Message --- --- Begin Message --- Source: docbook-xml Source-Version: 4.5-6 We believe that the bug you reported is fixed in the latest version of docbook-xml, which is due to be installed in the Debian FTP archive: docbook-xml_4.5-6.diff.gz to pool/main/d/docbook-xml/docbook-xml_4.5-6.diff.gz docbook-xml_4.5-6.dsc to pool/main/d/docbook-xml/docbook-xml_4.5-6.dsc docbook-xml_4.5-6_all.deb to pool/main/d/docbook-xml/docbook-xml_4.5-6_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Daniel Leidert (dale) <[EMAIL PROTECTED]> (supplier of updated docbook-xml package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 26 Oct 2008 15:13:10 +0100 Source: docbook-xml Binary: docbook-xml Architecture: source all Version: 4.5-6 Distribution: unstable Urgency: low Maintainer: Debian XML/SGML Group <[EMAIL PROTECTED]> Changed-By: Daniel Leidert (dale) <[EMAIL PROTECTED]> Description: docbook-xml - standard XML documentation system, for software and systems Closes: 482140 Changes: docbook-xml (4.5-6) unstable; urgency=low . * debian/compat: Raised to v5. * debian/control: Vcs fields transition. Added DM-Upload-Allowed. (Vcs-Svn): Fixed location. (Build-Depends): Raised debhelper to v5. (Depends): Moved xml-core to Pre-Depends and increased the version to 0.12 (closes: #482140). (Standards-Version): Raised to 3.7.3. * debian/rules (debian/docbook-xml.install): Fixed to not put non-existent files into the .install file. (debian/docbook-xml.xmlcatalogs): Use `sed -i' and do not create a temporary file. * debian/source.lintian-overrides: Added to override patch-system-but-direct-changes-in-diff warning, because file creation is intended. Checksums-Sha1: 68b92c15f02f4f8dacc9422d377ed612b5e26c99 1360 docbook-xml_4.5-6.dsc e9b51f69a434a01e4958f66c9f02eb2babc280b4 22059 docbook-xml_4.5-6.diff.gz 8bb8f3d77c37feec07d8741e3475a5668f752384 344524 docbook-xml_4.5-6_all.deb Checksums-Sha256: 38154040e8edd4dae1d7adc25b414e4d52842a3c823efaf77a68e1737a6a9755 1360 docbook-xml_4.5-6.dsc dc7e54c743140feccdd0a9ce69ad1c0860c5959ce97f4d25de20e6e58dc14de5 22059 docbook-xml_4.5-6.diff.gz 056aff9e8ed20753035cd42f44ad26f6f8ab0cb2ab9da9c686744979b9c1a138 344524 docbook-xml_4.5-6_all.deb Files: 7b31a7d0ca136613b423e1afe00f19cc 1360 text optional docbook-xml_4.5-6.dsc 308664c0b3dca46430e0f47731323f0a 22059 text optional docb
Bug#503571: Unable to reproduce - Bug#503571 aqualung: does not run: crashes after start
On Tuesday 28 October 2008 21:30:12 Adam Cécile (Le_Vert) wrote: > Do you mean I should close the bug right now, even Ben has still this > issue ? No if Ben still has the issue, then we shouldn't close, but from the tone of his last email I was under the impression that the problem has gone away. Ben. Can you confirm? Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#484838: [sysprof-module-source] Fixed upstream
Package: sysprof-module-source Version: 1.0.10-1 Hi, I informed Soeren Sandmann, the upstream author of the package. He indicated that the bug should be fixed in the now available version 1.0.11 of the package. With kind regards, Lutz Lehmann -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421332: marked as done (epiphany-extensions: can't delete certificate using certificate manager)
Your message dated Tue, 28 Oct 2008 11:47:06 + with message-id <[EMAIL PROTECTED]> and subject line Bug#393837: fixed in epiphany-browser 2.22.3-6 has caused the Debian Bug report #393837, regarding epiphany-extensions: can't delete certificate using certificate manager to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 393837: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393837 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems --- Begin Message --- Package: epiphany-extensions Version: 2.18.1-2 Severity: normal I have two certificates from Massachusetts Institute of Technology installed in epiphany, one expired and one active. When I try using the certificate manager extension to delete the expired certificate by activating the extension and going to Tools -> Certificate manager, selecting the correct certificate and clicking the "delete" button, I am presented with a blank popup window with two buttons. Clicking on the "OK" button in this window does nothing. In fact, clicking the "cancel" button in this window also does nothing. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-3-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages epiphany-extensions depends on: ii epiphany-browser 2.18.1-2 Intuitive GNOME web browser ii gconf22.18.0.1-3 GNOME configuration database syste ii libc6 2.5-4 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-21 GCC support library ii libnspr4-0d 4.6.6-3NetScape Portable Runtime Library ii libosp5 1.5.2-3Runtime library for OpenJade group ii libpcre3 6.7-1 Perl 5 Compatible Regular Expressi ii libxul0d 1.8.0.11-4 Gecko engine library ii python-elementtree1.2.6-10 Light-weight toolkit for XML proce ii python-gnome2 2.18.2-1 Python bindings for the GNOME desk ii python-gtk2 2.10.4-2 Python bindings for the GTK+ widge ii python-support0.6.3 automated rebuilding support for p ii python2.4 2.4.4-4An interactive high-level object-o ii sgml-data 2.0.3 common SGML and XML data ii w3c-dtd-xhtml 1.1-5 W3C eXtensible HyperText Markup La epiphany-extensions recommends no packages. -- no debconf information --- End Message --- --- Begin Message --- Source: epiphany-browser Source-Version: 2.22.3-6 We believe that the bug you reported is fixed in the latest version of epiphany-browser, which is due to be installed in the Debian FTP archive: epiphany-browser-data_2.22.3-6_all.deb to pool/main/e/epiphany-browser/epiphany-browser-data_2.22.3-6_all.deb epiphany-browser-dbg_2.22.3-6_amd64.deb to pool/main/e/epiphany-browser/epiphany-browser-dbg_2.22.3-6_amd64.deb epiphany-browser-dev_2.22.3-6_all.deb to pool/main/e/epiphany-browser/epiphany-browser-dev_2.22.3-6_all.deb epiphany-browser_2.22.3-6.diff.gz to pool/main/e/epiphany-browser/epiphany-browser_2.22.3-6.diff.gz epiphany-browser_2.22.3-6.dsc to pool/main/e/epiphany-browser/epiphany-browser_2.22.3-6.dsc epiphany-browser_2.22.3-6_all.deb to pool/main/e/epiphany-browser/epiphany-browser_2.22.3-6_all.deb epiphany-gecko_2.22.3-6_amd64.deb to pool/main/e/epiphany-browser/epiphany-gecko_2.22.3-6_amd64.deb epiphany-webkit_2.22.3-6_amd64.deb to pool/main/e/epiphany-browser/epiphany-webkit_2.22.3-6_amd64.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Josselin Mouette <[EMAIL PROTECTED]> (supplier of updated epiphany-browser package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 28 Oct 2008 12:17:03 +0100 Source: epiphany-browser Binary: epiphany-browser epiphany-gecko epiphany-webkit epiphany-browser-data epiphany-browser-dev epiphany-browser-dbg Architecture: source amd64 all Version: 2.
Bug#393837: marked as done (epiphany-extensions: Unable to edit or delete certificates)
Your message dated Tue, 28 Oct 2008 11:47:06 + with message-id <[EMAIL PROTECTED]> and subject line Bug#393837: fixed in epiphany-browser 2.22.3-6 has caused the Debian Bug report #393837, regarding epiphany-extensions: Unable to edit or delete certificates to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 393837: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393837 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems --- Begin Message --- Package: epiphany-extensions Version: 2.14.1.1-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The certificate manager extension is currently unusable. The OK and Cancel buttons in the Edit Certificate dialog do nothing, and the Delete Certificate dialog contains no text, only similarly non-functional OK and Cancel buttons. - -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (530, 'testing'), (520, 'unstable'), (510, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-k7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages epiphany-extensions depends on: ii epiphany-browser 2.14.3-2Intuitive GNOME web browser ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-13 GCC support library ii libnspr4-0d 1.8.0.7-1 NetScape Portable Runtime Library ii libosp5 1.5.2-3 Runtime library for OpenJade group ii libpcre3 6.7-1 Perl 5 Compatible Regular Expressi ii libxul0d 1.8.0.7-1 Gecko engine library ii python-gnome22.12.4-5Python bindings for the GNOME desk ii python-gtk2 2.8.6-6 Python bindings for the GTK+ widge ii sgml-data2.0.3 common SGML and XML data ii w3c-dtd-xhtml1.1-5 W3C eXtensible HyperText Markup La epiphany-extensions recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFNW/pshl/216gEHgRAlbMAKDRjS4ou+4hP2qbb6Oc9mptvGCYUQCePtmz 3RDJFD5ZTJIw2QQw9ZMWLWI= =v8iu -END PGP SIGNATURE- --- End Message --- --- Begin Message --- Source: epiphany-browser Source-Version: 2.22.3-6 We believe that the bug you reported is fixed in the latest version of epiphany-browser, which is due to be installed in the Debian FTP archive: epiphany-browser-data_2.22.3-6_all.deb to pool/main/e/epiphany-browser/epiphany-browser-data_2.22.3-6_all.deb epiphany-browser-dbg_2.22.3-6_amd64.deb to pool/main/e/epiphany-browser/epiphany-browser-dbg_2.22.3-6_amd64.deb epiphany-browser-dev_2.22.3-6_all.deb to pool/main/e/epiphany-browser/epiphany-browser-dev_2.22.3-6_all.deb epiphany-browser_2.22.3-6.diff.gz to pool/main/e/epiphany-browser/epiphany-browser_2.22.3-6.diff.gz epiphany-browser_2.22.3-6.dsc to pool/main/e/epiphany-browser/epiphany-browser_2.22.3-6.dsc epiphany-browser_2.22.3-6_all.deb to pool/main/e/epiphany-browser/epiphany-browser_2.22.3-6_all.deb epiphany-gecko_2.22.3-6_amd64.deb to pool/main/e/epiphany-browser/epiphany-gecko_2.22.3-6_amd64.deb epiphany-webkit_2.22.3-6_amd64.deb to pool/main/e/epiphany-browser/epiphany-webkit_2.22.3-6_amd64.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Josselin Mouette <[EMAIL PROTECTED]> (supplier of updated epiphany-browser package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 28 Oct 2008 12:17:03 +0100 Source: epiphany-browser Binary: epiphany-browser epiphany-gecko epiphany-webkit epiphany-browser-data epiphany-browser-dev epiphany-browser-dbg Architecture: source amd64 all Version: 2.22.3-6 Distribution: unstable Urgency: low Maintainer: Josselin Mouette <[EMAIL PROTECTED]> Changed-By: Josselin Mouette <[EMAIL PROTECTED]> Description: epiphany-browser - Intuitive web browser - dummy package epiphany-browser-data - Data files for the GNOME web browser epiphany-browser-dbg - Debugging symbols for the GNOME web browser epiphany-browser-dev - Development files for the GNOME
Bug#503645: jhead: CVE-2008-4640, CVE-2008-4641 command injection via filename and insecure file handling
Hi Ludovic, * Ludovic Rousseau <[EMAIL PROTECTED]> [2008-10-28 12:27]: > On Mon, Oct 27, 2008 at 5:03 PM, Nico Golde <[EMAIL PROTECTED]> wrote: > > * Ludovic Rousseau <[EMAIL PROTECTED]> [2008-10-27 16:47]: > >> On Mon, Oct 27, 2008 at 1:06 PM, Matthias Wandel <[EMAIL PROTECTED]> wrote: > >> > So what is the security vulnerability? > >> > > >> > You can use it to delete files, but why not just use "rm"? > >> > >> If I understand correctly we have two problems (from [1]) > >> 2 - unsafe temp file creation [...] > >> > Unless of course you run it as setuid root, but why would you go out ot > >> > your > >> > way to do that? > >> > >> A solution would be to use one of the exec(3) system calls instead of > >> system(3). > > > > Yes or to filter the string. > > I may try to implement a filter mechanism. > I think the idea is to stop the execution with an error message if a > special character is found. > What would be the list of normal characters? [a-z][A-Z][0-9][-.]? > How to filter file names in UTF-8? with accents or non ASCII characters? That's the problem, that is possible but there are a lot of problems that don't arise when using exec. > An easier solution is to refuse special characters like & and ; but > that may not completely solve the problem. > I need help here. I can look into this probably in the next days. Cheers Nico -- Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgpJTdvevdtqj.pgp Description: PGP signature
Processed: severity of 503821 is important
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.9.26 > severity 503821 important Bug#503821: linux-image-2.6.26-1-xen-amd64: Kernel crash in Dom0 (Eeek! page_mapcount(page) went negative! (-1)) Severity set to `important' from `grave' > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503367: [Debian-med-packaging] Bug#503367: Bug#503367: Bug#503367: plink: file conflict with putty-tools
Hi Steffen! Disclaimer: I'm a biologist [1] and I performed genome-wide analyses. On Tue, 28 Oct 2008 12:00:02 +0100, Peter Palfrader wrote: > Steffen Möller schrieb am Dienstag, dem 28. Oktober 2008: >> To summarise things up: the renaming of the executable of plink to >> snplink renders the plink package inferior to a manual installation of >> plink under the proper name. From a *very* quick read of the plink webpage [2], I understand that plink mainly deals with SNPs [3]. Thus I don't see the rename as something inferior, on the contrary it helps better understanding what the binary does [4]. >> What I'll do now unless I hear some objections that I am mentally >> prepared to follow: I'll prepare the new version, add the conflict to >> debian/control to close 503367 (won't fix) and herewith truly >> apologize for all these emails. > > The packages provide different functionality. They should therefore not > conflict. [...] > Tho I think that putty being the more senior one should have the right > of the name and not be forced to rename its binaries. Fully ACK, on both sentences. FWIW, according to [5], plink has been included in PuTTY since version beta 0.50 (released 2000/10/16). The oldest Debian version I could find is 0.57-1 (2005/03/13), which already contains /usr/bin/plink. Thx, bye, Gismo / Luca Footnotes: [1] http://www.unige.ch/irlab [2] http://pngu.mgh.harvard.edu/~purcell/plink/index.shtml [3] http://en.wikipedia.org/wiki/Single_nucleotide_polymorphism [4] I agree that for someone not in genetics this is not true [5] http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html [6] http://snapshot.debian.net/putty pgpb8a9kMjmnK.pgp Description: PGP signature
Processed: tagging 503750
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.35 > tags 503750 + experimental Bug#503750: Save directory defaults to /tmp/balazar3_v0.1_saves Tags were: security Tags added: experimental > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503739: wicd: Missing many dependencies
Hi, > wicd needs dependencies on some of the external tools it uses. In > particular, it should have a dependency on dhcpcd | dhcp3-client | > pump, a dependency on net-tools | ethtool, and a dependency on > net-tools | iproute. Are this really dependencies or are this tool commonly needed in usual usage scenarios? > In theory, wicd could operate without a DHCP client if you used it > with static address information only. Similarly, wicd could operate > without a wired link detection mechanism. Thus, you could choose to > make them Recommends. which particular tools are _needed_ and which ones are usually _wanted_? This is not clear from your mail. From what I can guess you say that Depends += net-tools | iproute Recommends += net-tools | ethtool, dhcpcd | dhcp3-client as change would be suffice? > However, almost all users of wicd likely want this functionality; > I'd personally argue for Depends. Well, the "almost all users would want this"-usecase is exactly the one we have Recommends for [1] and it is the reason that Recommends are installed by default these days. Regards, Patrick [1] http://www.debian.org/doc/debian-policy/ch-relationships.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
