Bug#288554: mozilla-firefox: Firefox sometimes hangs within futex() calls for a long time.
> Did you say you were running on not very powerful hardware? Opening 30 > tabs is certainly going to put a strain on an older machine. Yes, but 30 tabs *should* consume a lot of cpu. I'd said nothing if it just took very long. But firefox sometimes even fails to redraw within 5 seconds *although* the cpu is idle. What prevents firefox from redrawing? I could use a faster cpu, but this doesn't solve my problem, as firefox sometimes refuses to use it. It's not like resources are missing. Firefox just stops using them although it definitely has to do the redraw. The same bahaviour could be achieved by putting sleep() calls into the source. As I said it hangs within futex() this is probably a locking problem. Greetings Helmut Grohne signature.asc Description: Digital signature
Bug#337995: slang-curl: The description seems to contain a spelling mistake.
Package: slang-curl Severity: minor Description: transfer files using HTPP and FTP from S-Lang HTTP should be spelled with one P and two T. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) signature.asc Description: Digital signature
Bug#311410: pinentry-curses segfaults after confirm
Package: pinentry-curses Version: 0.7.2-1 Severity: important On my system i can make pinentry-curses segfault by doing the following: - start pinentry without options - request confirmation by sending a single line "confirm\n" to it - answer that confirmation request in any way -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.9 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages pinentry-curses depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libncurses5 5.4-4Shared libraries for terminal hand -- no debconf information signature.asc Description: Digital signature
Bug#299460: udev should create a symlink from vbi0 to vbi to cooperate with scantv
Package: udev Version: 0.054-2 Severity: minor udev created /dev/vbi0 on probing the module correctly. Unfortunately the corresponding symbolic link to /dev/vbi which is needed by applications like scantv is missing. I therefore suggest to add a line to one of the rules files. It might look like this: NAME="vbi0", SYMLINK="vbi" -- Package-specific info: -- /etc/udev/rules.d/: /etc/udev/rules.d/: total 4 lrwxrwxrwx 1 root root 19 2004-12-05 10:39 cd-aliases.rules -> ../cd-aliases.rules -rw-r--r-- 1 root root 145 2004-12-29 15:52 twinmos.rules lrwxrwxrwx 1 root root 13 2004-10-24 13:04 udev.rules -> ../udev.rules -- /sys/: /sys/block/hda/dev /sys/block/hda/hda1/dev /sys/block/hda/hda2/dev /sys/block/hda/hda3/dev /sys/block/hda/hda5/dev /sys/block/hda/hda6/dev /sys/block/hda/hda7/dev /sys/block/hda/hda8/dev /sys/block/hda/hda9/dev /sys/block/hdb/dev /sys/block/hdc/dev /sys/block/hdd/dev /sys/block/hde/dev /sys/block/hde/hde1/dev /sys/block/hde/hde2/dev /sys/block/hde/hde3/dev /sys/block/hde/hde5/dev /sys/block/hde/hde6/dev /sys/block/hde/hde7/dev /sys/block/hde/hde8/dev /sys/block/hdg/dev /sys/block/hdg/hdg1/dev /sys/class/input/event0/dev /sys/class/input/event1/dev /sys/class/input/event2/dev /sys/class/input/mice/dev /sys/class/input/mouse0/dev /sys/class/misc/device-mapper/dev /sys/class/misc/psaux/dev /sys/class/netlink/arpd/dev /sys/class/netlink/dnrtmsg/dev /sys/class/netlink/fwmonitor/dev /sys/class/netlink/ip6_fw/dev /sys/class/netlink/nflog/dev /sys/class/netlink/route6/dev /sys/class/netlink/route/dev /sys/class/netlink/skip/dev /sys/class/netlink/tap0/dev /sys/class/netlink/tap10/dev /sys/class/netlink/tap11/dev /sys/class/netlink/tap12/dev /sys/class/netlink/tap13/dev /sys/class/netlink/tap14/dev /sys/class/netlink/tap15/dev /sys/class/netlink/tap1/dev /sys/class/netlink/tap2/dev /sys/class/netlink/tap3/dev /sys/class/netlink/tap4/dev /sys/class/netlink/tap5/dev /sys/class/netlink/tap6/dev /sys/class/netlink/tap7/dev /sys/class/netlink/tap8/dev /sys/class/netlink/tap9/dev /sys/class/netlink/tcpdiag/dev /sys/class/netlink/usersock/dev /sys/class/netlink/xfrm/dev /sys/class/printer/lp0/dev /sys/class/sound/adsp/dev /sys/class/sound/audio/dev /sys/class/sound/controlC0/dev /sys/class/sound/controlC1/dev /sys/class/sound/controlC2/dev /sys/class/sound/controlC3/dev /sys/class/sound/dmmidi/dev /sys/class/sound/dsp/dev /sys/class/sound/midiC0D0/dev /sys/class/sound/midi/dev /sys/class/sound/mixer/dev /sys/class/sound/pcmC0D0c/dev /sys/class/sound/pcmC0D0p/dev /sys/class/sound/pcmC0D1p/dev /sys/class/sound/timer/dev /sys/class/video4linux/radio0/dev /sys/class/video4linux/vbi0/dev /sys/class/video4linux/video0/dev -- Kernel configuration: -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages udev depends on: ii hotplug 0.0.20040329-17 Linux Hotplug Scripts ii initscripts 2.86.ds1-1 Standard scripts needed for bootin ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii makedev 2.3.1-76creates device files in /dev ii sed 4.1.4-2 The GNU sed stream editor -- debconf information: udev/devfs-warning: udev/reboot-warning: signature.asc Description: Digital signature
Bug#316160: libmailtools-perl: qmail is listed twice in man 3pm Mail::Mailer
Package: libmailtools-perl Version: 1.62-1 Severity: normal man 3pm Mail::Mailer lists qmail twice in the description. Suggested fix: Remove the second one as it is exactly the same as above. As we are already fixing bugs, please use "built in" instead of "build in" (environment section). Thanks to Peter Palfrader reporting this to me when writing this bug report. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.9 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages libmailtools-perl depends on: ii libnet-perl 1:1.19-1 Implementation of Internet protoco ii libtimedate-perl 1.1600-4 Time and date functions for Perl ii perl 5.8.7-3Larry Wall's Practical Extraction ii perl-modules [libnet-perl]5.8.7-3Core Perl modules libmailtools-perl recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#288554: mozilla-firefox: Firefox sometimes hangs within futex() calls for a long time.
This bug seems to be fixed in 1.0.5-1. I cannot reproduce the described behaviour anymore. The bug should therefore be marked as closed. Helmut signature.asc Description: Digital signature
Bug#316724: libao: oss plugin assumes malloc not to return NULL
Package: libao
Severity: normal
The function _open_default_oss_device is a whole mess. It has some
unneeded maybe historical variables and doesn't handle strdup to return
NULL. A suggested fix is attached.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.9
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
diff -ruN libao-0.8.6.old/src/plugins/oss/ao_oss.c
libao-0.8.6/src/plugins/oss/ao_oss.c
--- libao-0.8.6.old/src/plugins/oss/ao_oss.c2004-11-09 09:20:26.0
+0100
+++ libao-0.8.6/src/plugins/oss/ao_oss.c2005-07-03 12:39:36.023915834
+0200
@@ -78,11 +78,10 @@
int _open_default_oss_device (char **dev_path, int blocking)
{
int fd;
- char *err = NULL;
- char *dev = NULL;
/* default: first try the devfs path */
- *dev_path = strdup("/dev/sound/dsp");
+ if(!(*dev_path = strdup("/dev/sound/dsp")))
+ return -1;
#ifdef BROKEN_OSS
fd = open(*dev_path, O_WRONLY | O_NONBLOCK);
#else
@@ -93,10 +92,9 @@
if(fd < 0)
{
/* no? then try the traditional path */
- err = strdup(strerror(errno));
- dev = strdup(*dev_path);
free(*dev_path);
- *dev_path = strdup("/dev/dsp");
+ if(!(*dev_path = strdup("/dev/dsp")))
+ return -1;
#ifdef BROKEN_OSS
fd = open(*dev_path, O_WRONLY | O_NONBLOCK);
#else
@@ -125,8 +123,6 @@
" %s - %s\n",
err, dev,
strerror(errno), *dev_path); */
- free(err);
- free(dev);
free(*dev_path);
*dev_path = NULL;
}
@@ -185,7 +181,8 @@
if (!strcmp(key, "dsp")) {
/* Free old string in case "dsp" set twice in options */
free(internal->dev);
- internal->dev = strdup(value);
+ if(!(internal->dev = strdup(value)))
+ return 0;
}
return 1;
signature.asc
Description: Digital signature
Bug#316747: apt-key: the update command is broken and not mentioned by manpage
Package: apt
Version: 0.6.38
Severity: normal
The manpage of apt-key should mention the update command. Using apt-key
help we can see it exists. Another problem might be that apt-key update
currently does not work.
# apt-key help
Usage: apt-key [command] [arguments]
Manage apt's list of trusted keys
apt-key add - add the key contained in ('-' for stdin)
apt-key del - remove the key
apt-key update - update keys using the keyring package
apt-key list- list keys
# apt-key update
ERROR: Can't find the archive-keyring
Is the debian-keyring package installed?
# dpkg -l debian-keyring
...
ii debian-keyring 2005.05.28 GnuPG (and obsolete PGP) keys of Debian Deve
#
Did you perhaps mean
ARCHIVE_KEYRING=/usr/share/keyrings/debian-keyring.gpg
instead of
ARCHIVE_KEYRING=/usr/share/keyrings/debian-archive-keyring.gpg
in /usr/bin/apt-key line 12?
Btw. apt-key fingerprint isn't even documented in apt-key help.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.9
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages apt depends on:
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libgcc1 1:4.0.0-11 GCC support library
ii libstdc++5 1:3.3.6-7The GNU Standard C++ Library v3
apt recommends no packages.
-- no debconf information
signature.asc
Description: Digital signature
Bug#329413: mozilla-firefox-webdeveloper: postinst is broken (update-mozilla-firefox-chrome: command not found)
Package: mozilla-firefox-webdeveloper Version: 0.9.3-4 Severity: grave Justification: renders package unusable During aptitude upgrade: Setting up mozilla-firefox-webdeveloper (0.9.3-4) ... /var/lib/dpkg/info/mozilla-firefox-webdeveloper.postinst: line 8: update-mozilla-firefox-chrome: command not found dpkg: error processing mozilla-firefox-webdeveloper (--configure): subprocess post-installation script returned error exit status 127 Errors were encountered while processing: mozilla-firefox-webdeveloper E: Sub-process /usr/bin/dpkg returned an error code (1) Ack! Something bad happened while installing packages. Trying to recover: Setting up mozilla-firefox-webdeveloper (0.9.3-4) ... /var/lib/dpkg/info/mozilla-firefox-webdeveloper.postinst: line 8: update-mozilla-firefox-chrome: command not found dpkg: error processing mozilla-firefox-webdeveloper (--configure): subprocess post-installation script returned error exit status 127 Suggested solutions: 1) Depend on mozilla-firefox (<< 1.4.99) 2) Find out how Deer Park wants to update the chrome and fix postinst. 3) Forward this bug to mozilla-firefox and make them put them install some shell script for update-mozilla-firefox-chrome. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages mozilla-firefox-webdeveloper depends on: ii mozilla-firefox1.4.99+1.5beta1-1 lightweight web browser based on M mozilla-firefox-webdeveloper recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#323126: slate: ftbfs [sparc] Bus error
forwarded 323126 [EMAIL PROTECTED] thanks > cd /build/buildd/slate-0.3.4.3 && echo "repl reset. Image saveNamed: > 'slate.image'. quit." | ./vm "`debian/endianess`.image" > /bin/sh: line 1: 15728 Doneecho "repl reset. Image > saveNamed: 'slate.image'. quit." > 15729 Bus error | ./vm "`debian/endianess`.image" This seems to be a known bug. I'll forward it to the mailinglist. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407181: silky: segfaults when pressing TAB on amd64
Package: silky Version: 0.5.4-0.1 Severity: important I started silky without parameters, connected to a (private) network, joined a channel and pressed the TAB key. The result is a segmentation fault: (gdb) bt #0 0x2b4778ecff93 in g_utf8_pointer_to_offset () from /usr/lib/libglib-2.0.so.0 #1 0x2b4778ecffb5 in g_utf8_pointer_to_offset () from /usr/lib/libglib-2.0.so.0 #2 0x00420b2f in channel_tab_completion () #3 0x0040e378 in on_key_press () #4 0x2b477718464d in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #5 0x2b4778a40479 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #6 0x2b4778a4fae1 in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #7 0x2b4778a50b5e in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #8 0x2b4778a50f73 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #9 0x2b477725adae in gtk_widget_get_default_style () from /usr/lib/libgtk-x11-2.0.so.0 #10 0x2b477717e395 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #11 0x2b477717f357 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #12 0x2b47774c752c in _gdk_events_init () from /usr/lib/libgdk-x11-2.0.so.0 #13 0x2b4778eaec73 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #14 0x2b4778eb1abd in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #15 0x2b4778eb1da6 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #16 0x2b477717f6b2 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #17 0x0041483d in main () (gdb) Maybe this is a glib2.0 oder gtk bug. In that case please forward the bug. Please tell me if any further information is needed. Helmut -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages silky depends on: ii libatk1.0-01.12.4-1 The ATK accessibility toolkit ii libc6 2.3.6.ds1-10 GNU C Library: Shared libraries ii libcairo2 1.2.4-4 The Cairo 2D vector graphics libra ii libfontconfig1 2.4.2-1 generic font configuration library ii libglade2-01:2.6.0-4 library to load .glade files at ru ii libglib2.0-0 2.12.6-2 The GLib library of C routines ii libgtk2.0-02.8.20-4 The GTK+ graphical user interface ii libpango1.0-0 1.14.8-4 Layout and rendering of internatio ii libsilc-1.0-2 0.9.12-6 SILC library (silc-toolkit) ii libx11-6 2:1.0.3-4 X11 client-side library ii libxcursor11.1.7-4 X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxfixes3 1:4.0.1-5 X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-4 X11 Input extension library ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library ii libxml22.6.27.dfsg-1 GNOME XML library ii libxrandr2 2:1.1.0.2-5 X11 RandR extension library ii libxrender11:0.9.1-3 X Rendering Extension client libra ii mime-support 3.39-1MIME files 'mime.types' & 'mailcap silky recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#407251: qemu: recommends transitional package vde
Package: qemu Version: 0.8.2-5 Severity: minor Tags: patch The package vde2 replaced vde, which as a result is a transitional package. qemu should now depend on vde2 instead of vde. Helmut -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages qemu depends on: ii bochsbios 2.3-2BIOS for the Bochs emulator ii libasound2 1.0.13-1 ALSA library ii libc6 2.3.6.ds1-10 GNU C Library: Shared libraries ii libncurses5 5.5-5Shared libraries for terminal hand ii libsdl1.2debian 1.2.11-7 Simple DirectMedia Layer ii openhackware0.4.1-2 OpenFirmware emulator for PowerPC ii proll 18-2 JavaStation PROM 2.x compatible re ii vgabios 0.6a-1 VGA BIOS software for the Bochs an ii zlib1g 1:1.2.3-13 compression library - runtime Versions of packages qemu recommends: ii debootstrap 0.3.3.1Bootstrap a basic Debian system ii sharutils 1:4.2.1-15 shar, unshar, uuencode, uudecode pn vde(no description available) -- no debconf information signature.asc Description: Digital signature
Bug#402592: gnupg: allocates arbitary amounts of memory on verifying a "signature"
Package: gnupg Version: 1.4.6-1 Severity: important Tags: security Justification: remote dos I somehow found this signature (which seems to be too large to append to a mail): http://subdivi.de/~helmut/gpg-outofmemory.sig Running gpg --verify gpg-outofmemory.sig will cause gpg try to allocate over 1G of memory. I consider this to be a denial of service attack as the file could cause gpg allocate up to 4G of memory which could cause the Linux kernel to OOM kill arbitrary applications which might cause data loss. gpg is used with software like mutt to automatically verify signatures, so the user might not know what the bad signature does. I have some more files of this kind. Please contact me in case you need additional information. Helmut Grohne -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages gnupg depends on: ii gpgv 1.4.6-1 GNU privacy guard - signature veri ii libbz2-1.0 1.0.3-6 high-quality block-sorting file co ii libc62.3.6.ds1-9 GNU C Library: Shared libraries ii libldap2 2.1.30-13.2 OpenLDAP libraries ii libreadline5 5.2-1 GNU readline and history libraries ii libusb-0.1-4 2:0.1.12-2 userspace USB programming library ii makedev 2.3.1-83creates device files in /dev ii zlib1g 1:1.2.3-13 compression library - runtime gnupg recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#402600: gpg: Ohhhh jeeee: pop_filter(): filter function not found
Package: gnupg Version: 1.4.6-1 Severity: normal I found another file doing harm to gpg. It is located at: http://subdivi.de/~helmut/gpg-oj.sig $ gpg --verify gpg-oj.sig gpg: DBG: pop_filter called in set_partial_block_mode - please report gpg: O j: pop_filter(): filter function not found secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 Aborted $ echo $? 134 $ Helmut Grohne -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages gnupg depends on: ii gpgv 1.4.6-1 GNU privacy guard - signature veri ii libbz2-1.0 1.0.3-6 high-quality block-sorting file co ii libc62.3.6.ds1-9 GNU C Library: Shared libraries ii libldap2 2.1.30-13.2 OpenLDAP libraries ii libreadline5 5.2-1 GNU readline and history libraries ii libusb-0.1-4 2:0.1.12-2 userspace USB programming library ii makedev 2.3.1-83creates device files in /dev ii zlib1g 1:1.2.3-13 compression library - runtime gnupg recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#403324: vde2: wirefilter manpage contains mistakes
Package: vde2 Version: 2.1.4-1 Severity: minor First of all: thanks for getting vde2 in Debian! The manpage for wirefilter contains some mistakes though: Below DESCRIPTION: ... dpipe vde_plug /tmp/s1 = wirefilter -l 10 = vde_plug /tmp/s1 creates a wire between two vde_switches (with sockets /tmp/s1 and /tmp/s2 respectively). This cable looses 10% of the packets in each ... Looks like the second s1 from the dpipe command should have been s2. Below OPTIONS: 0percentage of loss as a floating point number. It is possible to spec- ify different loss percentage for the two channels: LR20.5 means ... Looks like a formatting mistake. There should probably have been a -l (which is later referenced). Helmut -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages vde2 depends on: ii libc62.3.6.ds1-9 GNU C Library: Shared libraries ii libvdeplug2 2.1.4-1 Virtual Distributed Ethernet - Plu vde2 recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#403809: nanoblogger: BROWSER environment variable conflicts with sensible-browser
Package: nanoblogger Version: 3.3~rc5-3 Severity: wishlist The sensible-browser program from debianutils relies on the $BROWSER variable which is set to firefox -remote openurl(%s,new-tab):firefox:w3m on my system. This results in Error: Failed to send command: 500 command not parseable when nanoblogger tries to invoke $BROWSER. Setting $BROWSER to sensible-browser within nb results in sensible-browser invoking itself. It would therefore be cool if either nanoblogger or debianutils could use another variable name. I report this to nanoblogger as I used debianutils before. Please forward the bug to debianutils if you think it would be better to change sensible-browser. Helmut -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) nanoblogger depends on no packages. Versions of packages nanoblogger recommends: pn tidy (no description available) Other packages that might be of interest: ii debianutils2.17.4 Miscellaneous utilities specific to Debian -- no debconf information signature.asc Description: Digital signature
Bug#402057: psi: segfault when closing a window too fast (with shortcuts)
Package: psi Version: 0.10-2 Severity: important Do the following: * Receive a chat message from a contact. * Open the chat window. * Now quickly close the window (about 1/4 second maximum). Using the ESC key or other shortcuts should work. * If psi did not segfault yet, it presents you a question window asking you if you really want to close the window. * It most often segfaults when pressing yes and sometimes also for no. Any further information needed? Helmut -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages psi depends on: ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-20 GCC support library ii libqca1c21.0-8 Qt Cryptographic Architecture - sh ii libqt3-mt3:3.3.7-1 Qt GUI Library (Threaded runtime v ii libstdc++6 4.1.1-20The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-4 X11 client-side library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii zlib1g 1:1.2.3-13 compression library - runtime Versions of packages psi recommends: ii qca-tls 1.0-3 TLS plugin for the Qt Cryptographi ii sox 12.17.9-1 A universal sound sample translato -- no debconf information signature.asc Description: Digital signature
Bug#402057: psi: segfault when closing a window too fast (with shortcuts)
Hi Jan, > How often does the segfault happen? I can't reproduce it, but it may of > course be architecture dependent and I only have x86 (32bit) available. Thanks for your quick reply. On my amd64 machine it segfaulted always after pressing the yes button and sometimes on other actions. I don't think it ever segfaulted on my i386 (testing) machine. It segfaulted only once after using the no button yet. Another point I forgot to add is that the dialog says something like "Really close the window?" and whatever I answer the window is gone even when it does not segfault. I experienced about 15 segfaults in total, but I try to avoid them. ;-) Do you think a gdb backtrace, strace or similar stuff would be helpful? Helmut signature.asc Description: Digital signature
Bug#402057: psi: segfault when closing a window too fast (with shortcuts)
> That matches my experience, I tried it >100 times but didn't get a > single segfault. But OTOH perhaps it's only the timing that is > different, so I wouldn't be sure that only the amd64 version is buggy. For testing I added another user and started with a fresh config on the same account. It never segfaulted. > Yes, sure! Anything that may point to the buggy code would be helpful. I > already had a short look at the source but didn't see an obvious > problem. Still I managed to quickly reproduce a segfault within gdb. Looks like we might want to forward the bug to qt or something similar: $ gdb psi ... (gdb) run ... Program received signal SIGSEGV, Segmentation fault. 0x005c1230 in QTextEdit::setCurrentFont () (gdb) bt #0 0x005c1230 in QTextEdit::setCurrentFont () #1 0x005cb448 in QTextEdit::setCurrentFont () #2 0x005cbb2a in QTextEdit::setCurrentFont () #3 0x005cbe39 in QTextEdit::setCurrentFont () #4 0x2b87b663691b in QWidget::event () from /usr/lib/libqt-mt.so.3 #5 0x2b87b659d212 in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3 #6 0x2b87b659facb in QApplication::notify () from /usr/lib/libqt-mt.so.3 #7 0x0060f821 in QListView::removeItem () #8 0x2b87b6530824 in QApplication::sendSpontaneousEvent () from /usr/lib/libqt-mt.so.3 #9 0x2b87b65a1a6c in QApplication::setActiveWindow () from /usr/lib/libqt-mt.so.3 #10 0x2b87b652da03 in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3 #11 0x2b87b654386a in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3 #12 0x2b87b65b679e in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3 #13 0x2b87b659ec8e in QApplication::enter_loop () from /usr/lib/libqt-mt.so.3 #14 0x2b87b67a7787 in QDialog::exec () from /usr/lib/libqt-mt.so.3 #15 0x2b87b67cac91 in QMessageBox::QMessageBox () from /usr/lib/libqt-mt.so.3 #16 0x2b87b67cae33 in QMessageBox::information () from /usr/lib/libqt-mt.so.3 #17 0x005caa79 in QTextEdit::setCurrentFont () #18 0x2b87b6636647 in QWidget::event () from /usr/lib/libqt-mt.so.3 #19 0x2b87b659d212 in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3 #20 0x2b87b659facb in QApplication::notify () from /usr/lib/libqt-mt.so.3 #21 0x0060f821 in QListView::removeItem () #22 0x2b87b65307b2 in QApplication::sendEvent () from /usr/lib/libqt-mt.so.3 #23 0x2b87b6638dfa in QWidget::close () from /usr/lib/libqt-mt.so.3 #24 0x005cbf90 in QTextEdit::setCurrentFont () #25 0x2b87b663639a in QWidget::event () from /usr/lib/libqt-mt.so.3 #26 0x2b87b659d212 in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3 #27 0x2b87b659f1ab in QApplication::notify () from /usr/lib/libqt-mt.so.3 #28 0x0060f821 in QListView::removeItem () #29 0x2b87b6530824 in QApplication::sendSpontaneousEvent () from /usr/lib/libqt-mt.so.3 #30 0x2b87b652211d in QETWidget::translateKeyEvent () from /usr/lib/libqt-mt.so.3 #31 0x2b87b652d921 in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3 #32 0x2b87b654386a in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3 #33 0x2b87b65b679e in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3 #34 0x2b87b65b65a7 in QEventLoop::exec () from /usr/lib/libqt-mt.so.3 #35 0x2b87b659ecf0 in QApplication::exec () from /usr/lib/libqt-mt.so.3 #36 0x0053eeb3 in QLabel::metaObject () #37 0x2b87b75c04ca in __libc_start_main () from /lib/libc.so.6 #38 0x0043b90a in ?? () #39 0x74bf43e8 in ?? () #40 0x in ?? () (gdb) bt full doesn't give more information. Maybe font settings are interesting, too. So this is my lookandfeel section from .psi/profiles/default/config.xml: false 100 95 true #00 #ff #004bb4 #7e #646464 #ff #969696 #5a5a5a #f0f0f0 #00 #969696 DejaVu Sans Condensed,12,-1,5,50,0,0,0,0,0 DejaVu Sans Condensed,12,-1,5,50,0,0,0,0,0 DejaVu Sans Condensed,12,-1,5,50,0,0,0,0,0 DejaVu Serif Condensed,10,-1,5,50,0,0,0,0,0 Uhm. It might also be interesting to know what fonts currently are installed: $ dpkg -l '*font*' | grep ^ii ii fontconfig 2.4.2-1generic font configuration library - support ii fontconfig-con 2.4.2-1generic font configuration library - configu ii gsfonts8.11+urwcyr1.0 Fonts for the Ghostscript interpreter(s) ii gsfonts-x110.20 Make Ghostscript fonts available to X11 ii latex-xft-font 0.1-5 Xft-compatible versions of some LaTeX fonts ii libfontconfig1 2.4.2-1generic font configuration library - runtime ii libfontenc11.0.2-2X11 font encoding library ii libxfont1 1.2.2-1X11 font rasterisation library ii psfontmgr 0.11.10PostScript font manager -- part of Defoma, D ii x-ttcidfont-co 25 Configure TrueTyp
Bug#405928: xserver-xephyr: segfaults while startup on amd64
Package: xserver-xephyr
Version: 2:1.1.1-13
Severity: important
$ gdb Xephyr
...
(gdb) run :1
...
Extended Input Devices not yet supported. Impelement it at line 625 in
../../../../hw/kdrive/src/kinput.c
xkb_keycodes { include "xfree86+aliases(qwerty)" };
xkb_types{ include "complete" };
xkb_compatibility{ include "complete" };
xkb_symbols { include "pc(pc105)+us" };
xkb_geometry { include "pc(pc101)" };
Could not init font path element /usr/share/fonts/X11/cyrillic, removing from
list!
Could not init font path element /usr/X11R6/lib/ X11/fonts/Type1, removing
from list!
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x006a822c in PictureDestroyWindow ()
#2 0x004477ad in FreeColormap ()
#3 0x00447ac3 in FreeColormap ()
#4 0x00437f6a in NotImplemented ()
#5 0x2b8c8d6004ca in __libc_start_main () from /lib/libc.so.6
#6 0x0041f45a in ?? ()
#7 0x7fff1e025808 in ?? ()
#8 0x in ?? ()
(gdb)
Helmut Grohne
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages xserver-xephyr depends on:
ii libc62.3.6.ds1-9 GNU C Library: Shared libraries
ii libfontenc1 1:1.0.2-2 X11 font encoding library
ii libx11-6 2:1.0.3-4 X11 client-side library
ii libxau6 1:1.0.1-2 X11 authorisation library
ii libxdmcp61:1.0.1-2 X11 Display Manager Control Protoc
ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar
ii libxfont11:1.2.2-1 X11 font rasterisation library
ii zlib1g 1:1.2.3-13 compression library - runtime
Versions of packages xserver-xephyr recommends:
ii xbase-clients 1:7.1.ds-3 miscellaneous X clients
-- no debconf information
signature.asc
Description: Digital signature
Bug#288554: mozilla-firefox: Firefox sometimes hangs within futex() calls for a long time.
> Give it a shot, try uninstalling them. As I told you it doesn't matter whether plugins or extensions are installed. I removed all of them and reproduced the described behaviour. To start with a "clean" firefox i moved .mozilla out of the way. To browse the web I had to enter a proxy autoconfiguration script (a squid proxy). Opening 30 tabs simultaneously made firefox freeze for about ten seconds. With freezing I mean to do nothing, but hanging within a futex call. As I told you other programs (like mozilla) show a similar behaviour, so this might be the wrong place. Greetings Helmut Grohne signature.asc Description: Digital signature
Bug#288554: mozilla-firefox: Firefox sometimes hangs within futex() calls for a long time.
> Is it swapping heavily? That doesn't use CPU. No. It simply hangs. One workaround for this problem is sending a lot of SIGCONTs to firefox-bin using a little perl one-liner. As far as I know futex() calls get interrupted when signals arrive. If I remember correctly I had some similar problems on a FreeBSD head installation. Don't rely on this. Greetings Helmut Grohne signature.asc Description: Digital signature
Bug#288554: mozilla-firefox: Firefox sometimes hangs within futex() calls for a long time.
> I would guess it's some sort of race condition then. Did you give the > upstream bugzilla a once over to see if anyone had reported something > similar? Good suggestion. See https://bugzilla.mozilla.org/show_bug.cgi?id=227168 that describes what i observed. Greetings Helmut Grohne signature.asc Description: Digital signature
Bug#286825: fixed in experimental
tags 286825 = fixed-in-experimental thanks This bug seems to be fixed in experimental. Helmut Grohne signature.asc Description: Digital signature
Bug#310445: More information needed
tag 310445 moreinfo severity 310445 normal thanks There are new versions of glibc available. Could you perhaps recheck whether this bug is reproducible? Furthermore the source for that binary would be helpful if available. Helmut Grohne signature.asc Description: Digital signature
Bug#336843: adduser: removes user from group if /etc/group file ends with ":"
tags 336843 wontfix thanks > >Judged that ":" is the field separator in /etc/group, and that > >/etc/group might change its format to include more fields, and that a > >colon is not a valid character in a user name (it would wreck havoc in > >/etc/passwd), I would expect that perl would consider the ":" a > >delimiter here and not return it as part of the group name. > perl doesn't parse /etc/group directly, it just calls libc's getgrname, > which returns a list as gr_mem (the last entry of which has a trailing > colon in this case). There is specified behaviour on invalid passwd files, so whatever glibc does here is within the specs. The function could also segfault at that point. This could maybe reported to the upstream but they'll probably think the same way. Helmut Grohne signature.asc Description: Digital signature
Bug#331405: Accidential activation of nscd is too simple
reassign 331405 libpam-ldap tags 331405 patch thanks > It would be libpam-ldap which suggests libnss-ldap in my case. But > running apt-rdepends and analyzing it's output suggests that there are > 35 packages which depends on nscd in etch today. That's depends as in > any of the relationships that drags a package along, either directly or > as a consequence of a second or higer order dependency. The package description of nscd clearly states when nscd should be installed. A "wrong" dependency on nscd is no bug with nscd, but with the software depending on it. Most packages seem to have changed their behaviour since there are only 5 packages in apt-cache rdepends nscd of which at least one is a conflict. So maybe libpam-ldap could suggest nscd instead of recommending it. Otherwise this bug should be tagged wontfix. Helmut Grohne signature.asc Description: Digital signature
Bug#352139: getopt optional arg does not work as documented
tag 352139 -wontfix reassign 352139 manpages-dev thanks > Now. This case is difficult. The string "hello" could also be just a > normal filename argument. I think the glibc handles this case correctly > and thus mark the bug as wontfix. Actually it would be even better if the documentation could be adapted. Thanks to Aurelien Jarno for pointing this out. Helmut Grohne signature.asc Description: Digital signature
Bug#416211: sunbird: FTBFS on amd64
Package: sunbird Version: 0.2.99+0.3alpha1 Severity: serious Justification: Policy 4.2 ftbfs on amd64 using pbuilder c++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O -fPIC -shared -Wl,-h,libxpcom_core.so -o libxpcom_core.so pldhash.o nsCOMPtr.o nsCOMArray.o nsCRTGlue.o nsComponentManagerUtils.o nsDebug.o nsID.o nsIInterfaceRequestorUtils.o nsINIParser.o nsMemory.o nsTraceRefcnt.o nsWeakReference.o nsGREGlue.o nsVersionComparator.o nsTHashtable.o nsQuickSort.o nsVoidArray.o nsGenericFactory.o nsXPComInit.o nsStringAPI.o -Wl,--whole-archive ../../dist/lib/libxpcomds_s.a ../../dist/lib/libxpcomio_s.a ../../dist/lib/libxpcomcomponents_s.a ../../dist/lib/libxpcomthreads_s.a ../../dist/lib/libxpcomproxy_s.a ../../dist/lib/libxpcombase_s.a ../../dist/lib/libxptcall.a ../../dist/lib/libxptinfo.a ../../dist/lib/libxpt.a ../../dist/lib/libxptcmd.a ../../dist/lib/libstring_s.a -Wl,--no-whole-archive -L../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm /usr/bin/ld: nsCOMPtr.o: relocation R_X86_64_PC32 against `nsGetServiceByContractIDWithError::operator()(nsID const&, void**) const' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[5]: *** [libxpcom_core.so] Error 1 make[5]: Leaving directory `/tmp/buildd/sunbird-0.2.99+0.3alpha1/build-dir/mozilla/xpcom/build' Helmut Grohne -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20.1 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) signature.asc Description: Digital signature
Bug#416211: sunbird: FTBFS on amd64
tag 416211 patch thanks > c++ [...] Looks like it should have been build with g++-3.4. Adding export CC=gcc-3.4 export CXX=g++-3.4 to debian/rules seems solve the problem. Helmut Grohne signature.asc Description: Digital signature
Bug#416618: cpufreqd: I'd like to see acpi lid support
Package: cpufreqd Version: 2.2.1-2 Severity: wishlist We already got ac=on and ac=off in cpufreqd. Now it would be cool if I could tell cpufreqd to put my box on powersave when closing the lid. This is pretty easy as it's just another button. An easy way achieve this is to copy cpufreqd_acpi_ac.c to cpufreqd_acpi_lid.c and modify some names. Maybe there is a better way. Please tell me if you'd like to have a patch for that (maybe tag -1 patch?). Helmut Grohne -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-rc2 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages cpufreqd depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libcpufreq0 002-2shared library to deal with the cp ii libsensors3 1:2.10.1-3 library to read temperature/voltag ii libsysfs2 2.1.0-1 interface library to sysfs ii lsb-base3.1-23.1 Linux Standard Base 3.1 init scrip Versions of packages cpufreqd recommends: ii acpid 1.0.4-5Utilities for using ACPI power man -- debconf information: cpufreqd/no_pm: * cpufreqd/no_procfs_sysfs: signature.asc Description: Digital signature
Bug#412502: libcgicc1-dev: fails to compile most programs because constructors are implemented in #pragma interface headers
Package: libcgicc1-dev
Version: 3.2.3-3
Severity: grave
Justification: renders package unusable
Tag: patch
Almost all headers contain
#pragma interface
and at the same time implement constructors like
inline CgiInput() {}
which just doesn't fit together. Trying to compile things with g++ will
result in g++ ignoring these implementations which will result in a
linker failure. As cgicc::Cgicc also has such a case this will render
the package almost unusable.
A quick-fix to this problem is discarding all #pragma interface lines.
Helmut
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages libcgicc1-dev depends on:
ii libcgicc1 3.2.3-3A C++ class library for writing CG
Versions of interesting packages:
ii g++ 4.1.1-15 The GNU C++ compiler
libcgicc1-dev recommends no packages.
-- no debconf information
signature.asc
Description: Digital signature
Bug#382482: kde: Alt+Tab stops working after a while.
severity 382482 normal tags 382482 moreinfo thanks > I've started to use again KDE since two days (i.e. the problem was not > there some months ago, but I don't know exactly when it appeared), and > now I have the problem that Alt-Tab stops working after a while. > My .xsession-errors is full of cryptic (for me) messages, and I didn't yet > find a relation with an action taken. This behaviour was not observed by KDE team members. Could you provide precise information on how to quickly reproduce the described behaviour? This could include but is not limited to mentioning applications that need to be started or other things. You should also create a new user and verify if you can reproduce this behaviour with another user. Helmut Grohne signature.asc Description: Digital signature
Bug#352139: getopt optional arg does not work as documented
tag 352139 wontfix thanks > However, this does not seem to be the case. Actually it works quite similar. > When run: > [EMAIL PROTECTED]:/tmp$ a.out -a > a arg is: (null) Correct behaviour. $ ./a.out -afoo a arg is: foo > [EMAIL PROTECTED]:/tmp$ a.out -a hello > a arg is: (null) Now. This case is difficult. The string "hello" could also be just a normal filename argument. I think the glibc handles this case correctly and thus mark the bug as wontfix. Helmut signature.asc Description: Digital signature
Bug#160683: date: long timezone offset sighlently changed
tag 160683 moreinfo thanks On Thu, Sep 12, 2002 at 12:10:48PM -0700, Blars Blarson wrote: > Gnu date apperently siglently limits the timezone offset to 23, so the > above command will SOMETIMES show todays date instead with no error > message. (The SOMETIMES makes this even harder to debug.) This > breaks portable and older shell scripts. (I realize there are better > ways of doing this using Gnu date, but they don't work on solaris or > aix.) Could you be more precise on "SOMETIMES" and maybe include steps to reproduce? Does it only happen for specific dates? Which? Does it depend on the architecture? Which? Helmut signature.asc Description: Digital signature
Bug#415383: pcmcia-cs: firmwares not found by udev
Package: pcmcia-cs Version: 3.2.8-9 Severity: important Tag: patch The firmwares are located at /etc/pcmcia/cis. udev expects firmwares to be at /lib/firmware and others places, but not /etc/pcmcia/cis. So cards with firmwares cannot be used using current kernels and udev. Copying /etc/pcmcia/cis/tamarack.dat to /lib/firmware/tamarack.cis solved my problem. I'm not sure that this is a pcmcia-cs bug, so please forward the bug to the package it really applies to. There are basically some ways of fixing this bug: 1) Moving firmwares to a separate package as they are useful to both pcmcia-cs (older kernels) and pcmciautils (newer kernels) and place them correctly. [probably the clean way] 2) Include firmwares in pcmciautils instead of pcmcia-cs as it depends that way. [another clean way] 3) Tweak udev to load firmwares from /etc/pcmcia/cis. [a hack] 4) Use clever symlinking. [an ugly hack] This bug seems to be fixed in recent SuSE packages. So may be a fix could be inspired there. Please contact me if you need further information. Helmut Grohne -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-rc2 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages pcmcia-cs depends on: ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii lsb-base3.1-23.1 Linux Standard Base 3.1 init scrip ii module-init-tools 3.3-pre4-2 tools for managing Linux kernel mo ii modutils2.4.27.0-6 Linux module utilities ii pcmciautils 014-3PCMCIA utilities for Linux 2.6 ii psmisc 22.3-1 Utilities that use the proc filesy Versions of packages pcmcia-cs recommends: ii udev 0.105-3/dev/ and hotplug management daemo -- debconf information: * pcmcia-cs/run_probe: true * pcmcia-cs/start_pcmcia: true signature.asc Description: Digital signature
Bug#385911: more information
Package: xorg Version: 7.1.0-11 My Xorg.log of a similar segfault is attached and maybe it helps. An amd64 nvidia (proprietary) X segfaultet while running fluxbox, xterm and a wine with a broken google earth. Interaction with google earth was probably the cause of the segfault as it created windows with a width above 5000px and did other oddities. This happened without console switching. If further information on this crash or aid in debugging would be helpful, please contact me. I suggest marking this bug as wontfix. Helmut X Window System Version 7.1.1 Release Date: 12 May 2006 X Protocol Version 11, Revision 0, Release 7.1.1 Build Operating System: UNKNOWN Current Operating System: Linux alf 2.6.18 #1 SMP Sat Sep 30 20:23:38 CEST 2006 x86_64 Build Date: 09 January 2007 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.1.log", Time: Sun Jan 28 12:49:22 2007 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Default Layout" (**) |-->Screen "Primary Screen" (0) (**) | |-->Monitor "macom" (**) | |-->Device "Primary Device" (**) |-->Input Device "Generic Keyboard" (**) Option "XkbRules" "xorg" (**) XKB: rules: "xorg" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "de" (**) XKB: layout: "de" (**) Option "XkbVariant" "nodeadkeys" (**) XKB: variant: "nodeadkeys" (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "Configured Mouse" (WW) `fonts.dir' not found (or not valid) in "/usr/lib/X11/fonts/misc". Entry deleted from font path. (Run 'mkfontdir' on "/usr/lib/X11/fonts/misc"). (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. Entry deleted from font path. (WW) The directory "/usr/lib/X11/fonts/cyrillic" does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in "/usr/lib/X11/fonts/100dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/lib/X11/fonts/100dpi/"). (WW) `fonts.dir' not found (or not valid) in "/usr/lib/X11/fonts/75dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/lib/X11/fonts/75dpi/"). (WW) `fonts.dir' not found (or not valid) in "/usr/lib/X11/fonts/Type1". Entry deleted from font path. (Run 'mkfontdir' on "/usr/lib/X11/fonts/Type1"). (WW) The directory "/usr/share/fonts/X11/CID" does not exist. Entry deleted from font path. (WW) The directory "/usr/lib/X11/fonts/CID" does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in "/usr/lib/X11/fonts/100dpi". Entry deleted from font path. (Run 'mkfontdir' on "/usr/lib/X11/fonts/100dpi"). (WW) `fonts.dir' not found (or not valid) in "/usr/lib/X11/fonts/75dpi". Entry deleted from font path. (Run 'mkfontdir' on "/usr/lib/X11/fonts/75dpi"). (**) FontPath set to: unix/:7100, /usr/share/fonts/X11/misc, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi (==) RgbPath set to "/etc/X11/rgb" (==) ModulePath set to "/usr/lib/xorg/modules" (**) Extension "Composite" is enabled (II) Open ACPI successful (/var/run/acpid.socket) (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 1.0 X.Org XInput driver : 0.6 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/lib/xorg/modules/fonts/libbitmap.so (II) Module bitmap: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/lib/xorg/modules/libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.0 (--) using VT number 9 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,0238 card 1043,815d rev 00 class 06,00,00 hdr 80 (II) PCI: 00:00:1: chip 1106,1238 card , rev 00 class 06,00,00 hdr 00 (II) PCI: 00:00:2: chip 1106,2238 card , rev 00 class 06,00,00 hdr 00 (II) PCI: 00:00:3: chip 1106,3238 card , rev 00 class 06,00,00 hdr 00 (II) PCI: 00:00:4: chip 1106,4238 card , rev 00 class 06,00,00 hdr 00 (II) PCI: 00:00:5: chip 1106,5238 card , rev 00 class 08,00,20 hdr 80 (II) PCI: 00:00:7: chip 1106,7238 card , rev 00 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,b188 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:02:0: chip 1106,a238 card , re
Bug#419671: spelling mistake in /usr/share/doc/alex/html/introduction.html
Package: alex Version: 2.1.0~rc1-1 Severity: minor Tag: patch The html file contains the line: the action functions to be passed the appriate where "appropriate" is probably meant instead of "appriate". -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-rc2 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages alex depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libgmp3c2 2:4.2.1+dfsg-4 Multiprecision arithmetic library alex recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#420171: apt-listbugs: NameError: global name 'R_OK' is not defined
Package: apt-listbugs
Version: 0.0.75
Severity: important
Tags: patch
Traceback (most recent call last):
File "/usr/bin/apt-listchanges", line 226, in ?
main()
File "/usr/bin/apt-listchanges", line 58, in main
if os.access('/dev/tty', R_OK):
NameError: global name 'R_OK' is not defined
R_OK is an attribute of os, which is imported. Please use os.R_OK
instead of R_OK or use from os import R_OK.
Helmut
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.20.1 (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages apt-listbugs depends on:
ii apt 0.6.46.4-0.1 Advanced front-end for dpkg
ii libdpkg-ruby1.8 0.3.2modules/classes for dpkg on ruby 1
ii libhttp-access2-ruby1.8 2.0.6-3 HTTP accessing library for ruby
ii libintl-gettext-ruby1.8 0.11-9 Gettext wrapper for Ruby 1.8
ii libruby1.8 [libzlib-ruby1.8 1.8.6-1 Libraries necessary to run Ruby 1.
ii libxml-parser-ruby1.8 0.6.8-2 Interface of expat for the scripti
ii ruby1.8.2-1 An interpreter of object-oriented
apt-listbugs recommends no packages.
-- no debconf information
signature.asc
Description: Digital signature
Bug#418068: scons: manpage uses incorrect example env = Environment(ENV = os.environ['PATH'])
Package: scons Version: 0.96.93-2 Severity: minor Tag: patch The manpage of scons says: Or you may explicitly propagate the invoking user's complete external environment: import os env = Environment(ENV = os.environ['PATH']) This is wrong as os.environ['PATH'] will be a str (if existent) and not a dict. The line should probably look like: env = Environment(ENV = os.environ) Helmut -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-rc2 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages scons depends on: ii python2.4.4-2An interactive high-level object-o ii python-central0.5.12 register and build utility for Pyt scons recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#416618: cpufreqd: I'd like to see acpi lid support
tag 416618 patch
thanks
> yes, I'd like to have a patch :)
Attached.
> I'm sorry but I don't have much time to dedicat to cpufreqd right now
> (and a new release will be delayed by that anyway).
Doesn't really matter. It's only I already patched 2.0.0 and though
others might be interested as well. Maybe forwarding to upstream might
be a good idea too.
> By the way, you will need to add some lines to cpufreqd_acpi.c too.
Good point. I had to adapt it a bit.
Helmut Grohne
diff -ruN cpufreqd-2.2.1/configure cpufreqd-2.2.1.1/configure
--- cpufreqd-2.2.1/configure 2006-11-21 22:25:00.0 +0100
+++ cpufreqd-2.2.1.1/configure 2007-04-06 18:54:30.0 +0200
@@ -23473,9 +23473,9 @@
DISABLED_PLUGINS="$DISABLED_PLUGINS acpi_event"
fi
if test x"${acpi_enable}" = xyes; then
- ENABLED_PLUGINS="$ENABLED_PLUGINS acpi_battery acpi_ac acpi_temperature"
+ ENABLED_PLUGINS="$ENABLED_PLUGINS acpi_battery acpi_ac acpi_lid acpi_temperature"
else
- DISABLED_PLUGINS="$DISABLED_PLUGINS acpi_battery acpi_ac acpi_temperature"
+ DISABLED_PLUGINS="$DISABLED_PLUGINS acpi_battery acpi_ac acpi_lid acpi_temperature"
fi
###
diff -ruN cpufreqd-2.2.1/NEWS cpufreqd-2.2.1.1/NEWS
--- cpufreqd-2.2.1/NEWS 2006-11-03 20:47:55.0 +0100
+++ cpufreqd-2.2.1.1/NEWS 2007-04-06 18:55:24.0 +0200
@@ -18,6 +18,7 @@
* acpi_ac OK
* acpi_battery OK
+* acpi_lid OK
* acpi_temperature OK
* programs OK
* cpu OK
diff -ruN cpufreqd-2.2.1/README cpufreqd-2.2.1.1/README
--- cpufreqd-2.2.1/README 2006-11-03 20:47:55.0 +0100
+++ cpufreqd-2.2.1.1/README 2007-04-06 18:55:53.0 +0200
@@ -41,6 +41,7 @@
---+---+---+-
R | | acpi_ac | OK!
R | | acpi_battery | OK!
+ R | | acpi_lid | OK!
R | | acpi_temperature | OK!
R | | acpi_event| planned
R | | apm | OK!
diff -ruN cpufreqd-2.2.1/src/Makefile.am cpufreqd-2.2.1.1/src/Makefile.am
--- cpufreqd-2.2.1/src/Makefile.am 2006-11-03 20:47:55.0 +0100
+++ cpufreqd-2.2.1.1/src/Makefile.am 2007-04-06 19:34:55.0 +0200
@@ -99,6 +99,7 @@
cpufreqd_acpi_la_SOURCES = \
cpufreqd_acpi.c \
cpufreqd_acpi_ac.c \
+ cpufreqd_acpi_lid.c \
cpufreqd_acpi_battery.c \
cpufreqd_acpi_event.c \
cpufreqd_acpi_temperature.c
@@ -196,6 +197,7 @@
cpufreqd_log.h \
cpufreqd_acpi.h \
cpufreqd_acpi_ac.h \
+ cpufreqd_acpi_lid.h \
cpufreqd_acpi_battery.h \
cpufreqd_acpi_event.h \
cpufreqd_acpi_temperature.h \
diff -ruN cpufreqd-2.2.1/src/cpufreqd_acpi.c cpufreqd-2.2.1.1/src/cpufreqd_acpi.c
--- cpufreqd-2.2.1/src/cpufreqd_acpi.c 2006-11-03 20:47:55.0 +0100
+++ cpufreqd-2.2.1.1/src/cpufreqd_acpi.c 2007-04-06 19:29:49.0 +0200
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2006 Mattia Dongili <[EMAIL PROTECTED]>
+ * modified by Helmut Grohne <[EMAIL PROTECTED]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -22,11 +23,13 @@
#include "cpufreqd_plugin.h"
#include "cpufreqd_acpi.h"
#include "cpufreqd_acpi_ac.h"
+#include "cpufreqd_acpi_lid.h"
#include "cpufreqd_acpi_battery.h"
#include "cpufreqd_acpi_event.h"
#include "cpufreqd_acpi_temperature.h"
static short acpi_ac_failed;
+static short acpi_lid_failed;
static short acpi_batt_failed;
static short acpi_ev_failed;
static short acpi_temp_failed;
@@ -71,6 +74,8 @@
}
clog(LOG_DEBUG, "Initializing AC\n");
acpi_ac_failed = acpi_ac_init();
+ clog(LOG_DEBUG, "Initializing Lid\n");
+ acpi_lid_failed = acpi_lid_init();
clog(LOG_DEBUG, "Initializing BATTERY\n");
acpi_batt_failed = acpi_battery_init();
clog(LOG_DEBUG, "Initializing TEMPERATURE\n");
@@ -78,7 +83,7 @@
clog(LOG_DEBUG, "Initializing EVENT\n");
acpi_ev_failed = acpi_event_init();
/* return error _only_ if all components failed */
- return acpi_ev_failed && acpi_ac_failed && acpi_batt_failed && acpi_temp_failed;
+ return acpi_ev_failed && acpi_ac_failed && acpi_lid_failed && acpi_batt_failed && acpi_temp_failed;
}
static int acpi_exit (void) {
@@ -87,6 +92,10 @@
clog(LOG_DEBUG, "Closing AC\n");
ret |= acpi_ac_exit();
}
+ if (!acpi_lid_failed) {
+ clog(LOG_DEBUG, "Closing Lid\n");
+ ret |= acpi_lid_exit();
+ }
if (!acpi_batt_failed) {
clog(LOG_DEBUG, "Closing BATTERY\n");
ret |= acpi_battery_exit();
@@ -106,6 +115,8 @@
if (!acpi_ac_failed)
acpi_ac_update();
+ if (!acpi_lid_failed)
+ acpi_lid_update();
acpi_event_lock();
if (!acpi_batt_failed)
@@ -122,6 +133,7 @@
static struct cpufreqd_keyword kw[] = {
{ .word = "
Bug#390234: valgrind: Assertion 'cfsi->len > 0 && cfsi->len < 2000000' failed with any C++ program
Package: valgrind
Version: 1:3.2.0-2
Severity: important
$ cat test.c++
main(){}
$ g++ --version
g++ (GCC) 4.1.2 20060920 (prerelease) (Debian 4.1.1-14)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
$ g++ test.c++
$ valgrind --tool=none ./a.out
==30834== Nulgrind, a binary JIT-compiler.
==30834== Copyright (C) 2002-2006, and GNU GPL'd, by Nicholas Nethercote.
==30834== Using LibVEX rev 1606, a library for dynamic binary translation.
==30834== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==30834== Using valgrind-3.2.0-Debian, a dynamic binary instrumentation
framework.
==30834== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==30834==
--30834-- Command line
--30834--./a.out
--30834-- Startup, with flags:
--30834---v
--30834----tool=none
--30834-- Contents of /proc/version:
--30834-- Linux version 2.6.17-2-amd64 (Debian 2.6.17-9) ([EMAIL PROTECTED])
(gcc version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)) #1 SMP Wed Sep 13
17:49:33 CEST 2006
--30834-- Arch and hwcaps: AMD64, amd64-sse2
--30834-- Valgrind library directory: /usr/lib/valgrind
--30834-- Reading syms from /home/helmut/darcs/string/a.out (0x40)
--30834-- warning: DiCfSI 0x286100E00400509 .. 0x286100E0040050B outside
segment 0x40 .. 0x400FFF
--30834-- Reading syms from /lib/ld-2.3.6.so (0x400)
--30834-- Reading debug info from /lib/ld-2.3.6.so...
--30834-- ... CRC mismatch (computed 3777F8F4 wanted 4E780ECE)
--30834--object doesn't have a symbol table
--30834-- Reading syms from /usr/lib/valgrind/amd64-linux/none (0x3800)
--30834--object doesn't have a dynamic symbol table
--30834-- Reading syms from /usr/lib/valgrind/amd64-linux/vgpreload_core.so
(0x4918000)
--30834-- Reading syms from /usr/lib/libstdc++.so.6.0.8 (0x4A19000)
--30834--object doesn't have a symbol table
--30834-- DWARF2 CFI reader: unhandled CFI instruction 0:24
--30834-- DWARF2 CFI reader: unhandled CFI instruction 0:24
--30834-- DWARF2 CFI reader: unhandled CFI instruction 0:24
--30834-- warning: DiCfSI 0xE44100EFFF836FB .. 0xE44100EFFF8372A outside
segment 0x4A19000 .. 0x4C18FFF
--30834-- DWARF2 CFI reader: unhandled CFI instruction 0:24
--30834-- DWARF2 CFI reader: unhandled CFI instruction 0:24
--30834-- warning: DiCfSI 0x8F01900EFFF83E37 .. 0x8F01900EFFF83EC4 outside
segment 0x4A19000 .. 0x4C18FFF
--30834-- DWARF2 CFI reader: unhandled CFI instruction 0:24
[line is repeated 32 times]
valgrind: m_debuginfo/storage.c:311 (vgModuleLocal_addDiCfSI): Assertion
'cfsi->len > 0 && cfsi->len < 200' failed.
==30834==at 0x3803F38E: report_and_quit (m_libcassert.c:136)
==30834==by 0x3803F6F1: vgPlain_assert_fail (m_libcassert.c:200)
==30834==by 0x380442CC: vgModuleLocal_addDiCfSI (storage.c:311)
==30834==by 0x3804DD20: run_CF_instructions (readdwarf.c:2338)
==30834==by 0x3804E63A: vgModuleLocal_read_callframe_info_dwarf2
(readdwarf.c:2699)
==30834==by 0x380467E7: vgModuleLocal_read_elf_debug_info (readelf.c:1206)
==30834==by 0x3801952C: vgPlain_di_notify_mmap (debuginfo.c:177)
==30834==by 0x38028145: vgModuleLocal_generic_PRE_sys_mmap
(syswrap-generic.c:1874)
==30834==by 0x38038515: vgSysWrap_amd64_linux_sys_mmap_before
(syswrap-amd64-linux.c:944)
==30834==by 0x3802C713: vgPlain_client_syscall (syswrap-main.c:719)
==30834==by 0x3801BA3F: vgPlain_scheduler (scheduler.c:721)
==30834==by 0x380358A9: run_a_thread_NORETURN (syswrap-linux.c:87)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==30834==at 0x401073C: (within /lib/ld-2.3.6.so)
==30834==by 0x400505C: (within /lib/ld-2.3.6.so)
==30834==by 0x4006D6C: (within /lib/ld-2.3.6.so)
==30834==by 0x4009EFC: (within /lib/ld-2.3.6.so)
==30834==by 0x400B7E0: (within /lib/ld-2.3.6.so)
==30834==by 0x400A5D3: (within /lib/ld-2.3.6.so)
==30834==by 0x40028FB: (within /lib/ld-2.3.6.so)
==30834==by 0x400F7EF: (within /lib/ld-2.3.6.so)
==30834==by 0x400127C: (within /lib/ld-2.3.6.so)
==30834==by 0x4000A87: (within /lib/ld-2.3.6.so)
Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.
If that doesn't help, please report this bug to: www.valgrind.org
In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using. Thanks.
$
I hope that this is enough information.
Helmut Grohne
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-amd64
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages valgrind depends on:
ii libc62.3.6.ds1-4 GNU C L
Bug#391538: python-zopeinterface fails to install: raise PyCentralError, "package has no field Python-Version"
Package: python-zopeinterface Version: 3.3.0-2 Severity: grave Justification: renders package unusable Fails to configure with: Setting up python-zopeinterface (3.3.0-2) ... Traceback (most recent call last): File "/usr/bin/pycentral", line 1336, in ? main() File "/usr/bin/pycentral", line 1330, in main rv = action.run(global_options) File "/usr/bin/pycentral", line 865, in run pkg.read_version_info() File "/usr/bin/pycentral", line 535, in read_version_info raise PyCentralError, "package has no field Python-Version" __main__.PyCentralError: package has no field Python-Version dpkg: error processing python-zopeinterface (--configure): subprocess post-installation script returned error exit status 1 As other packages using python-central seem to work on my system I don't think this to be a python-central bug. It seems like the package just hasn't been tested with a recent python-central version. Helmut Grohne -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-amd64 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages python-zopeinterface depends on: ii python-central0.5.6 register and build utility for Pyt python-zopeinterface recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#391761: python-soappy: fails to bytecompile at postinst with python2.5 because of a SyntaxError with __future__
Package: python-soappy Version: 0.11.3-1.6 Severity: normal Let me just paste it. This should explain almost everything needed: ... Setting up python-soappy (0.11.3-1.6) ... Compiling /var/lib/python-support/python2.5/SOAPpy/Client.py ... File "/var/lib/python-support/python2.5/SOAPpy/Client.py", line 46 from __future__ import nested_scopes SyntaxError: from __future__ imports must occur at the beginning of the file Compiling /var/lib/python-support/python2.5/SOAPpy/GSIServer.py ... File "/var/lib/python-support/python2.5/SOAPpy/GSIServer.py", line 49 from __future__ import nested_scopes SyntaxError: from __future__ imports must occur at the beginning of the file Compiling /var/lib/python-support/python2.5/SOAPpy/Server.py ... File "/var/lib/python-support/python2.5/SOAPpy/Server.py", line 46 from __future__ import nested_scopes SyntaxError: from __future__ imports must occur at the beginning of the file Compiling /var/lib/python-support/python2.5/SOAPpy/Types.py ... File "/var/lib/python-support/python2.5/SOAPpy/Types.py", line 39 from __future__ import nested_scopes SyntaxError: from __future__ imports must occur at the beginning of the file ... This happens when compilation for python2.5 is enabled. Please disable py2.5 support or just fix this bug, by putting the from __future__ import nested_scopes line before the ident="..." line. Helmut Grohne -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages python-soappy depends on: ii python2.4.3-11 An interactive high-level object-o ii python-support0.5.3 automated rebuilding support for p ii python-xml0.8.4-5XML tools for Python python-soappy recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#392005: neon26: typing mistake in src/ne_auth.c: logical and used where bitwise expected
Package: neon26
Version: 0.26.1-1
Severity: minor
Tags: patch upstream
Debian: src/ne_auth.c:1358
Upstream tarball from http://www.webdav.org/neon/: src/ne_auth.c:1204:
else if (sess->protocol
&& sess->protocol->flags && AUTH_FLAG_VERIFY_NON40x
&& (status->klass == 2 || status->klass == 3)
&& auth_hdr) {
ret = sess->protocol->verify(areq, sess, auth_hdr);
}
flags && AUTH_FLAG_VERIFY_NON40x is typing mistake and should be
corrected to bitwise and, as it could lead to unexpected behaviour or a
security hole.
Helmut Grohne
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
signature.asc
Description: Digital signature
Bug#392006: python-simplejson: fails to bytecompile with python2.5, because of a SyntaxError concerning __future__ imports
Package: python-simplejson Version: 1.3-0.1 Severity: normal Some parts from postinst: Compiling /var/lib/python-support/python2.5/SOAPpy/GSIServer.py ... File "/var/lib/python-support/python2.5/SOAPpy/GSIServer.py", line 49 from __future__ import nested_scopes SyntaxError: from __future__ imports must occur at the beginning of the file Compiling /var/lib/python-support/python2.5/SOAPpy/Server.py ... File "/var/lib/python-support/python2.5/SOAPpy/Server.py", line 46 from __future__ import nested_scopes SyntaxError: from __future__ imports must occur at the beginning of the file Compiling /var/lib/python-support/python2.5/SOAPpy/Types.py ... File "/var/lib/python-support/python2.5/SOAPpy/Types.py", line 39 from __future__ import nested_scopes SyntaxError: from __future__ imports must occur at the beginning of the file Please move the corresponding lines up or mark your package as not beeing compatible with Python2.5. Helmut Grohne -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages python-simplejson depends on: ii python2.4.3-11 An interactive high-level object-o ii python-support0.5.3 automated rebuilding support for p python-simplejson recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#339770: darcs-server is a misleading package name
reopen 339770 severity 339770 whishlist thanks Hi, I beliebe that the bug was not fixed, so please tag it as wontfix or rename the package. Furthermore there exists another tool at http://www.equational.org/darcs-server/ which would actually be worth the name. Greetings Helmut Grohne signature.asc Description: Digital signature
Bug#389883: RM: slate -- RoM: upstream nearly dead
Package: ftp.debian.org Severity: normal Once there were two developers. One is left. The last release is one year old. There is barely no mailing list traffic anymore and I have no hope for slate to get a new release before etch is going to be stable. I therefore suggest removing the package entirely. Helmut Grohne signature.asc Description: Digital signature
Bug#294459: /usr/share/doc/darcs/manual/index.html is empty
Hi, I think something more is broken. $ ls -la /usr/share/doc/darcs/manual/index.html -rw-r--r-- 1 root root 0 2006-07-03 11:05 /usr/share/doc/darcs/manual/index.html $ dpkg -l darcs ... ii darcs 1.0.8-1an advanced revision control system $ uname -a Linux alf 2.6.17 #1 SMP Tue Jun 20 14:45:00 CEST 2006 x86_64 GNU/Linux $ Please try to make the file nonempty at least. It's completely unusable at the moment. Thanks. Helmut signature.asc Description: Digital signature
Bug#648021: fail2ban: Logfile in UTC, localtime UTC+1 -> no entrioes found
On Tue, Nov 08, 2011 at 01:01:23PM +0100, a...@old-forest.org wrote: > On this (hopefully quite generic) system a log line looks: > Nov 8 11:19:38 bar sshd[25427]: pam_unix(sshd:auth): authentication failure; > logname= uid=0 euid=0 tty=ssh ruser= rhost=fnord > > The time given is in UTC, localtime is UTC+1. Fail2ban seems to interpret the > time stamp as localtime and given the value of 'findtime' of 600 will never > find any logentry. > > My workaround is 'fail2ban-client set ssh findtime 4600', which is a bit ugly. > A nicer approach would be to make a time offset settable. I also ran into this issue. A different work around is echo "export TZ=UTC" >> /etc/default/fail2ban Since it took me quite some time to notice this issue, let me propose the following extension: In processLineAndAdd you already (debug) log when a line gets ignored due to the findtime setting. I propose adding a flag to processLineAndAdd that indicates whether it was called due to a poll or during program startup. Since all polling modes either immediately notice changes or take at most 1 second, this ignoring can (in theory) never happen during polling. So I suggest to emit a warning in this case. I believe that a warning is warranted when a poller takes more than findtime seconds to report new messages. The advantage is that now fail2ban spams my log when I have misconfigured it and chances are, that I'll notice. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604925: /usr/lib/libgssapi_krb5.so.2: cannot login to ssh after upgrade from lenny to squeeze
Package: libgssapi-krb5-2 Version: 1.8.3+dfsg-2 Severity: grave File: /usr/lib/libgssapi_krb5.so.2 My system uses kerberos to authenticate users to ssh. After upgrading a server to squeeze logging in is no longer possible (this could satisfy critical severity). Unfortunately debugging this turned out to be harder than expected, because gssapi is not very precise about what the problem really is. All I can do is post the logs. Logging in from a (lenny) client that could log in to the same system before the upgrade: $ ssh -vvv somemachine ... debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-keyex debug3: remaining preferred: gssapi-with-mic,gssapi,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-keyex debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug2: we did not send a packet, disable method debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: gssapi,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Delegating credentials debug1: Delegating credentials debug1: Unspecified GSS failure. Minor code may provide more information Generic error (see e-text) debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug2: we did not send a packet, disable method ... Of course I also turned on debugging on the server: ... Nov 25 13:43:46 someserver sshd[5661]: Set /proc/self/oom_adj to 0 Nov 25 13:43:46 someserver sshd[5661]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8 Nov 25 13:43:46 someserver sshd[5661]: debug1: inetd sockets after dupping: 3, 3 Nov 25 13:43:46 someserver sshd[5661]: Connection from 10.0.82.2 port 36317 Nov 25 13:43:46 someserver sshd[5661]: debug1: Client protocol version 2.0; client software version OpenSSH_5.1p1 Debian-5 Nov 25 13:43:46 someserver sshd[5661]: debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH* Nov 25 13:43:46 someserver sshd[5661]: debug1: Enabling compatibility mode for protocol 2.0 Nov 25 13:43:46 someserver sshd[5661]: debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-5+b1 Nov 25 13:43:46 someserver sshd[5661]: debug1: PAM: initializing for "root" Nov 25 13:43:46 someserver sshd[5661]: debug1: PAM: setting PAM_RHOST to "reverse.dns.of.somemachine" Nov 25 13:43:46 someserver sshd[5661]: debug1: PAM: setting PAM_TTY to "ssh" Nov 25 13:43:46 someserver sshd[5661]: Failed none for root from 10.0.82.2 port 36317 ssh2 Nov 25 13:43:46 someserver sshd[5661]: debug1: Unspecified GSS failure. Minor code may provide more information\nNo such file or directory\n Nov 25 13:43:46 someserver sshd[5661]: debug1: Got no client credentials ... The origin of the "Unspecified GSS failure." message is src/lib/gssapi/mechglue/g_dsp_status.c which is a generic error handler. The "Got no client credentials" message originates from sshd itself gss-serv.c in ssh_gssapi_accept_ctx after finding that an error occured. Any other information needed? Do you have any ideas for debugging? Helmut -- System Information: Debian Release: squeeze/sid APT prefers squeeze-volatile APT policy: (500, 'squeeze-volatile'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgssapi-krb5-2 depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libcomerr2 1.41.12-2common error description library ii libk5crypto31.8.3+dfsg-2 MIT Kerberos runtime libraries - C ii libkeyutils11.4-1Linux Key Management Utilities (li ii libkrb5-3 1.8.3+dfsg-2 MIT Kerberos runtime libraries ii libkrb5support0 1.8.3+dfsg-2 MIT Kerberos runtime libraries - S libgssapi-krb5-2 recommends no packages. Versions of packages libgssapi-krb5-2 suggests: pn krb5-doc (no description available) ii krb5-user 1.8.3+dfsg-2 Basic programs to authenticate usi -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604925: krb5.conf
I was asked to show a krb5.conf for the ssh server. See it below.
Helmut
$ cat /etc/krb.conf
[libdefaults]
default_realm = REALM.DOMAIN.EXAMPLE
dns_lookup_realm = false
dns_lookup_kdc = false
[realms]
REALM.DOMAIN.EXAMPLE = {
kdc = kdchost.domain.example:88
admin_server = kdchost.domain.example:749
default_domain = domain.example
}
[domain_realm]
.domain.example = REALM.DOMAIN.EXAMPLE
domain.example = REALM.DOMAIN.EXAMPLE
[login]
krb4_convert = true
krb4_get_tickets = false
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604925: "No such file or directory": /usr/lib/krb5/plugins/authdata
Running strace on ssh revealed the almost immediately before emiting the "Unspecified GSS failure. Minor code may provide more information\nNo such file or directory\n" it tries to open a directory /usr/lib/krb5/plugins/authdata which does not exist on my system (and is not contained in any package). Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604925: "No such file or directory": /usr/lib/krb5/plugins/authdata
On Thu, Nov 25, 2010 at 02:56:46PM +0100, Helmut Grohne wrote: > Running strace on ssh revealed the almost immediately before emiting the > "Unspecified GSS failure. Minor code may provide more information\nNo such > file or directory\n" > it tries to open a directory /usr/lib/krb5/plugins/authdata which does > not exist on my system (and is not contained in any package). Actually this seems unrelated. When I create the missing directory (as empty directory) the visible behaviour is not changed in any way. So the "No such file or directory" message does not seem to originate from some system call, but from some userspace deciding that this is the right message. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604925: /usr/lib/libgssapi_krb5.so.2: cannot login to ssh after upgrade from lenny to squeeze
> Is your server keyed with a DES key? Which server are you talking about? The kdc or the ssh server? Maybe you can find the answer in the details below: This is what my ticket (on the lenny client) looks like: $ klist -e Ticket cache: FILE:/tmp/krb5cc_1000_FQS33c Default principal: gro...@realm.domain.example Valid starting ExpiresService principal 11/25/10 17:11:23 11/26/10 03:11:23 krbtgt/realm.domain.exam...@realm.domain.example renew until 11/26/10 17:11:23, Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, Triple DES cbc mode with HMAC/sha1 Kerberos 4 ticket cache: /tmp/tkt1000 klist: You have no tickets cached $ In a network packet capture I can see that both des3-cbc-sha1 and some aes-256-something are in use at some point. The ssh server has four different keys, one them being des, and two being aes. The kdc runs mac osx 10 server with mit kerberos. If your question isn't answered by now, can you ask it more precisely? Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604925: /usr/lib/libgssapi_krb5.so.2: cannot login to ssh after upgrade from lenny to squeeze
On Thu, Nov 25, 2010 at 11:55:16AM -0500, Sam Hartman wrote: > Is the default realm on your ssh server set to the realm in which it has > its host keys? Yes. > Do things change if you add a domain_realm entry to your ssh server > mapping it into the realm where its key exists? Good catch! Yes. The error message changes slightly: It is now: Nov 25 18:18:48 someserver sshd[1960]: debug1: Unspecified GSS failure. Minor code may provide more information\nWrong principal in request\n Nov 25 18:18:48 someserver sshd[1960]: debug1: Got no client credentials One detail I probably forgot to add is that invoking kinit on the ssh server (after authenticating in a different manner) works fine. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604925: /usr/lib/libgssapi_krb5.so.2: cannot login to ssh after upgrade from lenny to squeeze
Hi Sam, thanks for bearing with us! On Thu, Nov 25, 2010 at 02:01:02PM -0500, Sam Hartman wrote: > OK. The way in which the principal is determined changed between krb5 > 1.8 and 1.6. In 1.8 the system searches through all the keys in the > keytab looking for a key that successfully decrypts a ticket. The > server name sent in the ticket over the network is ignored (at least by > sshd) and only the key in the keytab's name is used. > > So, if you had a key in your keytab with principal name host/a.com and > the same key as host/b.com, then 1.8 and 1.6 might have different ideas > about what the request was actually from. We verified that keys are not shared among hosts. Each host has its unique key. Looks like we are getting nowhere without a deeper look, unless you have more ideas I could quickly check. How would you use 1.9 on squeeze? Compile from source? Just use experimental packages? Rebuild or backport them? Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738855: initscripts: Skip killing process starting with @
Hi Dimitri, On Thu, Feb 13, 2014 at 01:58:23PM +, Dmitrijs Ledkovs wrote: > There is convention starting that processes whos name starts with '@' > shouldn't be killed. It is used to indicate that process is needed to > manage root device / cleanly unmount the root filesystem. > > At least mdadm supports it for it's 'mdmon' process which is daemon > needed to manage containers (aka fakeraid controllers - Intel Matrix > Raid and DDF). > > I've implemented a patch using pgrep, thus it's optional code in > sendsigs if pgrep is not available. Are you sure that the described behaviour is desirable at all? I argue that evading sendsigs should be a privileged operation. If it isn't, I can simply rename my process to start with an '@' and block umounting filesystems possibly causing data loss (due to failing umount). I am not sure that the drafted scenario can actually happen in practise, but from a first glance it seems to be the case. Thus applying your patch would open up the possibility for data loss. Do you concur with this reasoning? Yes -> Please close this bug. No -> Please explain in what way my argument is flawed. Maybe mdmon should use the existing mechanism and write its PID to /run/sendsigs.omit.d/mdmon instead? Thanks Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738855: initscripts: Skip killing root-owned process starting with @
Control: retitle -1 initscripts: Skip killing root-owned process starting with @ On Thu, Feb 13, 2014 at 08:58:33PM +, Dimitri John Ledkov wrote: > How about limiting it to processes running as root? > > E.g. pgrep -u root -f "^@" ? > > That way there is no loop-hole opened, since those processes could > have written to /run/sendsigs.omit.d/ already. I concur with this remedy. Can you update your patch or remove the patch tag? > Writing out a pidfile (and or otherwise copying them around is ok) but > it is debian [derivative] specific as far as I can tell. > Where is "@" convention is supported by a larger amount of > distributions and other initsystems (e.g. systemd). > ( http://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/ ) > Writing out a pid-file should be avoided, especially since that is > optional across all init systems and un-desirable for newer ones. > Also, processes could be started off-root (e.g. initramfs) and/or > otherwise not hold-up unmounting root. > Thus I find "@" convention useful and lightweight self-identification. Thanks for pointing out the rationale and documentation. Did you notice that the referenced documentation explicitly restricts the technique to root-owned processes? Thanks for not introducing a security issue. :) Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738855: initscripts: Skip killing root-owned process starting with @
On Fri, Feb 14, 2014 at 12:28:52AM +, Dimitri John Ledkov wrote: > Thanks a lot for the review! Hmm. Maybe you can hold this patch off for a little longer? Pulling in oss-sec, because I am no longer sure that the remedy addresses all relevant aspects. Summary of previous discussion follows for oss-sec: Dimitri Ledkov asked for the initscripts package to exempt root-owned processes whose process name starts with an '@' from being killed in the sendsigs script during shutdown. This support would make initscripts a little more compatible with systemd, which is a good thing! The relevant systemd documentation can be found at: http://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/ However, I doubt that the proposed restriction (effective UID of process equals 0) is sufficient. For example in a SELinux context being root may mean significantly less. Russel Coker runs a machine where you can log into as root remotely, see http://www.coker.com.au/selinux/play.html. In this context allowing user processes to not be killed merely by changing their name could cause data loss during shutdown by blocking umount. I do not understand the consequences of the above technique in other security extension contexts, so I am asking here for help. The alternative mechanism currently used by initscripts is to allow daemons to write their PID to /run/sendsigs.omit.d/$daemon. Being a file-based approach, it can be easily controlled in the SELinux context using restorecon. Another aspect of interest could be processes running as root with their capability bounding set cleared or reduced. So dear oss-sec readers, do you think that allowing processes whose effective UID is 0 to not being killed during shutdown is a good idea? If the answer is no, then please assign a CVE identifier for systemd (version 38+, src/core/killall.c). Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738855: initscripts: Skip killing root-owned process starting with @
On Fri, Feb 14, 2014 at 09:18:19AM +0100, Helmut Grohne wrote: > Hmm. Maybe you can hold this patch off for a little longer? Discussion on oss-sec is inconclusive. Specifically there is no strong opinion that the approach is considered to be a vulnerability or weakness. Please move forward with your patch (barring other reviews). For all participants in this bug, please do *not* Cc oss-sec unless you intend to discuss security aspects. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738855: [oss-security] Re: Bug#738855: initscripts: Skip killing root-owned process starting with @
On Sat, Feb 15, 2014 at 05:22:15PM +0100, Florian Weimer wrote: > * Helmut Grohne: > > > In this context allowing user processes to not be killed merely by > > changing their name could cause data loss during shutdown by > > blocking umount. > > Does that actually work? If so, it's a funcitonality bug that should > be fixed. Usually, user processes are killed by sendsigs and that is why they cannot block umount. For instance, if a processes ends up being unkillable (e.g. due to a kernel oops), you can experience data loss (been there, done that). What is new here is that systemd proposed a generic exemption mechanism for processes with effective UID 0. Judging from the responses received so far, I think that the consensus is that effective UID 0 should be considered fully privileged no matter how restricted such a process is. That is a perfectly fine choice (especially in the presence of user namespaces), but we'll have to keep it in mind when looking at other system components that may violate this assumption (e.g. SELinux, Linux capabilities). I conclude that the implementation in systemd is not considered vulnerable. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739347: lintian: raise file-name-is-not-valid-UTF-8 to error in accordance with policy 10.10
Package: lintian Version: 2.5.21 Severity: wishlist Dear lintian Maintainers, Please raise the file-name-is-not-valid-UTF-8 tag to error level, because the aspect it enforces has reached the Debian policy in section 10.10 in version 3.9.5 with a MUST clause. I suggest the following info text (based on the original info text): | The file name does not appear to be valid UTF-8. This violates Policy | section 10.10. | | Note that Lintian may be unable to display the filename accurately. | Unprintable characters may have been replaced. Note that the policy text has went further than the lintian tag in that it requires members of $PATH to be representable as ASCII. You may want to implement a tag enforcing this property as well. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739741: fontconfig-config: fails to upgrade from 2.11.0-2 overwriting files in fontconfig
Package: fontconfig-config Version: 2.11.0-2 Severity: serious Justification: fails to upgrade Hi Keith, I noticed the following apt output while upgrading fontconfig-config from 2.11.0-2 to 2.11.0-3 with fontconfig 2.11.0-3 already installed. Preparing to unpack .../libfontconfig1_2.11.0-3_amd64.deb ... Unpacking libfontconfig1:amd64 (2.11.0-3) over (2.11.0-2) ... Preparing to unpack .../fontconfig-config_2.11.0-3_all.deb ... Unpacking fontconfig-config (2.11.0-3) over (2.11.0-2) ... dpkg: error processing archive /var/cache/apt/archives/fontconfig-config_2.11.0-3_all.deb (--unpack): trying to overwrite '/usr/share/doc/fontconfig/fontconfig-user.html', which is also in package fontconfig 2.11.0-3 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/fontconfig-config_2.11.0-3_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: dpkg: dependency problems prevent configuration of libfontconfig1:amd64: libfontconfig1:amd64 depends on fontconfig-config (= 2.11.0-3); however: Version of fontconfig-config on system is 2.11.0-2. dpkg: error processing package libfontconfig1:amd64 (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: libfontconfig1:amd64 Maybe there is some Replaces header is missing here? Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735923: piuparts: maybe --pbuilder should also set --tmpdir?
Package: piuparts Version: 0.56 Severity: wishlist Tags: patch Hi, When using piuparts --pbuilder I noticed that it feels slow. Now that's not the fault of piuparts, but instead an artifact of my setup that made me ponder whether piuparts' defaults are good. It happens that I mounted /var/cache/pbuilder/build as an fs tuned for performance. I was kind of expecting piuparts to use pbuilders build directory. So maybe setting --pbuilder should also set --tmpdir? diff against /usr/sbin/pbuilder def set_basetgz_to_pbuilder(option, opt, value, parser, *args, **kwargs): parser.values.basetgz = "/var/cache/pbuilder/base.tgz" +parser.values.tmpdir = "/var/cache/pbuilder/build" def parse_command_line(): """Parse the command line, change global settings, return non-options.""" If you disagree, please just close this bug after tagging it wontfix. Thanks for considering. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736357: syncevolution: tmp file vulnerability
Package: syncevolution Version: 1.0+ds1~beta2a-2 Severity: important Tags: security Dear Maintainer, Your package contains a funny tmp file vulnerability. $ grep 'mktemp`\.' -r . ./src/syncevo/installcheck-local.sh:TMPFILE_CXX=`mktemp`.cxx ./src/syncevo/installcheck-local.sh:TMPFILE_O=`mktemp`.o $ Both of them are doing it wrong. They create a secure tempfile, but don't use it and instead generate a (now) predictable(!) name without opening it in a safe (O_CREAT) way. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736359: localepurge: tmp file vulnerability
Package: localepurge Version: 0.6.2+nmu1 Severity: important Tags: security Hi Niels, the maintainer scripts of localepurge contain a funny tmp file vulnerability: $ grep tempfile -r . ./debian/postrm:DEBREINSTALL="$(tempfile).$$" ./debian/localepurge.config:TEMPFILE=$(tempfile).$$ ./debian/localepurge.config:LOCALEGEN=$(tempfile).locale.gen $ All of them are doing it wrong. They create a secure tempfile, but don't use it and instead generate a (now) predictable(!) name without opening it in a safe (O_CREAT) way. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736358: axiom: tmp file vulnerability
Package: axiom Version: 20100701-1.1 Severity: important Tags: security Dear Maintainer, Your package contains a funny tmp file vulnerability. $ grep 'tempfile).' -r . ./debian/axiom-test.sh:k=$(tempfile).input $ This is wrong. It creates a secure tempfile, but doesn't use it and instead generates a (now) predictable(!) name without opening it in a safe (O_CREAT) way. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736360: lintian: do not warn about doxygen embedding jquery
Package: lintian Version: 2.5.2 Severity: normal Dear Maintainers, Please stop warning about jquery.js as embedded by Doxygen. I evaluated all options at fixing this issue in Doxygen and conclude that a fix is infeasible and its usefulness is limited. The issue and the problems about fixing it are documented in /usr/share/doc/doxygen/README.jquery (in the doxygen package >= jessie). Even if there were a security issue in jquery, it will likely not affect any user via Doxygen. For detection I suggest to look for doxygen.png and doxygen.css. If both are present, the jquery warning should be suppressed. Note that some maintainers have started replacing jquery.js in response to the lintian tag. Unfortunately what is named jquery.js does not only contain jquery. Thus some generated documentation is now broken. I would like lintian to error out if jquery.js of Doxygen-generated documentation is a symbolic link to the jquery package. Do you need a separate bug number for this? Thanks Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736357: syncevolution: tmp file vulnerability
On Wed, Jan 22, 2014 at 08:47:22PM +0100, Tino Mettler wrote: > On Wed, Jan 22, 2014 at 19:09:24 +0100, Helmut Grohne wrote: > > Package: syncevolution > > Version: 1.0+ds1~beta2a-2 > > Severity: important > > Tags: security > > > > Dear Maintainer, > > > > Your package contains a funny tmp file vulnerability. > > > > $ grep 'mktemp`\.' -r . > > ./src/syncevo/installcheck-local.sh:TMPFILE_CXX=`mktemp`.cxx > > ./src/syncevo/installcheck-local.sh:TMPFILE_O=`mktemp`.o > > $ > > > > Both of them are doing it wrong. They create a secure tempfile, but don't > > use it and instead generate a (now) predictable(!) name without opening > > it in a safe (O_CREAT) way. > > Hi, > > could you point out in more detail what is wrong here, and how it > should be done right? Sorry for having assumed this obvious. So what happens when you create a temporary file like is being done in syncevolution TMPFILE=`mktemp`.suffix is that a temporary file is securely made, but then you don't use it and instead base your temporary filename on the secure temporary file. You later write to it without using O_CREAT thus leading to the issue. Ideally you don't manipulate the filename after the fact, so you need to have the desired suffix incorporate into the creation process. Luckily mktemp provides a mechanism for that: --suffix. So the correct solution is: TMPFILE=`mktemp --suffix .suffix` Now the desired file is created by mktemp and when you write to it using other tools, it already is known to be owned by the relevant user. Hope this helps Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736357: syncevolution: tmp file vulnerability
On Wed, Jan 22, 2014 at 09:41:41PM +0100, Tino Mettler wrote: > Btw., don't expect me to fix this for oldstable, which is the version > you use. As far as I can see, the script is only used at build time. The issue is reported against oldstable, because it is the oldest relevant version applicable. I agree that fixing a build issue for stable or oldstable is probably not worth the effort. CVE-2014-1639 was assigned to this issue. Please mention the identifier in the changelog when fixing. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736432: [doxygen] Include header/footer/img as external ressource
Hi Bastien, On Thu, Jan 23, 2014 at 05:17:34PM +, bastien ROUCARIES wrote: > Could you please see a patch for including generated doc as external > ressource and not compiled inside doxygen. Thanks for working on the embedding problem for doxygen! While I see your patch, I am somewhat left in the dark as to what it tries to achieve and which part of the problem it tries to solve. Please elaborate. > It save a few byte, improve the jquery problem and so on. All of these claims appear to be wrong: * The patch tries to move the contents of header.html.in from the binary to /usr/share/doxygen. Data is moved, not saved. * Since the header you moved, does not contain jquery, it does not affect the embedding of jquery at all. * What do you mean with "and so on"? I suggest that before you invest additional time into polishing a patch, you explain precisely what you are trying to achieve. I'll be happy to help with the implementation, but as I have explained in README.jquery, I do not see how to substantially improve the situation. I refrain from tagging the bug - patch + moreinfo in the presumption that you'll provide the requested information in a timely manner. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736432: [doxygen] Include header/footer/img as external ressource
Hi Bastien, On Thu, Jan 23, 2014 at 07:31:43PM +0100, Bastien ROUCARIES wrote: > ressource and not compiled inside doxygen. >From my point of view it does not matter whether the doxygen package ships jquery inside a binary or in a separate file. Both are contained in the package and both are compiled (albeit differently). What you describe is not a worthwhile goal to me. > My goal is to move the data from c file compiles to run time. Thus 1. 2. 3 > or your readme.jquerry are not used for debian. If you intend to work on aspect 1. (embedding of jquery sources in the doxygen source package) then surely the first step would be *packaging* the missing libraries. Can you point me to the work you have done in that area? I also do not see any aspects of you addressing embedding 2. or 3. (minified jquery in doxygen source package). At no point do you add code that touches the build system. Your initial patch does not address any of your claimed goals! > And so on means I have done for one file but I will do for all file > including png if needed. As I have pointed out in my previous mail, I do not see moving the resources from one place to another as a worthwhile goal. > My goal is to automatically generate a data package. After I will use > compatibilty layer of jquerry in order to replace link in generated package. I have already investigated this option. When I asked Doxygen upstream about API stability of the bundled jquery libraries Dimitri explicitly denied any kind of forwards- or backwards-compatibility. That means that any documentation package depending on a doxygen-data package will need a versioned dependency. When a new version of doxygen gets uploaded, all reverse build-dependencies therefore need to be rebuilt. Unfortunately for us, most of them are Architecture:all and we currently only do Architecture:any binNMUs. While I agree that this would ultimately be the best outcome, it is not currently possible. If you intend to further this goal, please work on Architecture:all autobuilding. Unless you add substantial information to this bug report, I am inclined to close it. As is, this bug report is in no way actionable. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736432: Fwd: Re: Bug#736432: [doxygen] Include header/footer/img as external ressource
Hi Bastien, On Thu, Jan 23, 2014 at 08:51:20PM +0100, Bastien ROUCARIES wrote: > For me it is a worthwhile goal reduce archive size. When moving files within a package there is no reduction in size. That is precisely why the goal did not seem worthwhile to me. In any case it is not substantial. We are talking about a few kb if anything. Space is not a reasonable argument here, sorry. On the other hand the Debian policy discourages the use of embedded code copies. The main reason here is that the work to fix a bug in the code is amplified by the number of embedded copies. > No because with a few script line we could render jquery backward > compatible. We do not care about doxygen. > > We load recent jquery and we add some compatibility layer see > https://github.com/jquery/jquery-migrate/blob/master/README.md While it may be possible to make jquery backwards compatible, that's not the goal here. The goal for Doxygen would be to make the embedded file called jquery.js backwards compatible. These are two very different goals, because (I repeat) what is called jquery.js is not jquery, but happens to also contain jquery. None of your past mails show that you have understood the scope of the problem. Please take a bit more time and think things through before replying. I am not opposed to solving the embedding issue, but I do not yet see, how you intend to solve it. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736477: agda-mode: enable multiarch
Package: agda-mode Version: 2.3.2.2-1 Severity: wishlist Dear Maintainer, It would be awesome to install 32bit agda on an amd64 base system, because 32bit agda is significantly faster. Making this possible is a huge task and fixing this bug will not suffice to make it possible, but this package also has a small piece of the cake: The agda-mode package is arch:all and depends on libghc-agda-dev which is arch:any. Since arch:all packages are treated as native architecture (amd64 in my case), it currently requires libghc-agda-dev to be native as well. Would it be possible to loosen this dependency in a way where a libghc-agda-dev:i386 suffices for agda-mode when amd64 is the native architecture? This depends on several factors. When switching architectures, on has to pay attention to were architecture boundaries are. agda-mode essentially depends on three components: emacs, agda-bin and libghc-agda-dev. The important question here is whether agda-mode needs agda-bin and libghc-agda-dev to have the same architecture. If that is the case, then my request is not satisfiable with the current dpkg. In that case, please outright close this bug, because solving the relevant dpkg limitation would obsolete this bug. If that architecture matching is not required, then marking agda-bin and libghc-agda-dev as Multi-Arch: allowed or even marking agda-bin as Multi-Arch: foreign might be feasible. Once that has happened, agda-mode can annotate the relevant dependencies on M-A:allowed packages with :any to solve this bug. Thanks for considering Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724255: util-linux: FTBFS: m4 runs out of memory
Control: tags -1 + patch On Sun, Nov 10, 2013 at 08:56:36PM +, Wookey wrote: > Confirmed. I get exactly the same issue building this package in current > amd64 unstable chroot. > > Changing to previous m4 version (m4_1.4.16-5_amd64.deb) makes no difference: > > The commands being run are: > /usr/bin/sh autopoint --force > which runs: > /usr/bin/perl -w /usr/bin/autom4te --no-cache > --language=Autoconf-without-aclocal-m4 --trace=AM_GNU_GETTEXT_VERSION:$% - > configure.ac > which runs: > sh -c /usr/bin/m4 --nesting-limit=1024 --gnu --include=/usr/share/autoconf > --debug=aflq --fatal-warning --debugfile=/tmp/am4tDdyolT/traces Thanks for the initial work. I tracked it down to m4_shiftn(2, sequence of two elements) causing an infinite loop from _UTIL_CHECK_SYSCALL in configure.ac. For some reason the optimized version m4_shift2 introduced in autoconf 2.62 (very old version) does not suffer from this issue. Also note that the relevant configure.ac code got completely rewritten on the path to 2.24 and probably does not suffer this issue. I assume that a new upstream release would fix this FTBFS as well. In addition a new upstream release is kinda required to fix other RC bugs of util-linux. Should I NMU the attached patch to util-linux? Helmut diff -u util-linux-2.20.1/configure.ac util-linux-2.20.1/configure.ac --- util-linux-2.20.1/configure.ac +++ util-linux-2.20.1/configure.ac @@ -733,7 +733,7 @@ [m4_ifval([$1], [#( $1) syscall="$2" ;;dnl - _UTIL_CHECK_SYSCALL_FALLBACK(m4_shiftn(2, $@))])dnl + _UTIL_CHECK_SYSCALL_FALLBACK(m4_shift2($@))])dnl ]) diff -u util-linux-2.20.1/debian/changelog util-linux-2.20.1/debian/changelog --- util-linux-2.20.1/debian/changelog +++ util-linux-2.20.1/debian/changelog @@ -1,3 +1,11 @@ +util-linux (2.20.1-5.6) unstable; urgency=medium + + * Non-maintainer upload. + * Fix m4 looping in configure.ac's _UTIL_CHECK_SYSCALL. +m4_shiftn(2, sequence of two elements) infloops. (Closes: #724255) + + -- Helmut Grohne Sat, 25 Jan 2014 13:38:36 +0100 + util-linux (2.20.1-5.5) unstable; urgency=medium * Non-maintainer upload by the Security Team.
Bug#731574: Please package new upstream version (mount(8) bugfix included)
Control: unmerge 734813 Control: severity 731574 wishlist Control: tags 734813 + patch On Sat, Dec 07, 2013 at 12:06:06AM +0100, Michael Stapelberg wrote: > Can you please package the new upstream version so that this bugfix will > be available and the docker package can start depending on mount >= 2.24 > instead of adding ugly workarounds please? Thanks! While packaging a new upstream release is sufficient, there also is a 1-line fix available against the old code base. I am attaching a patch, which also happens to fix the FTBFS (cause without that fix you couldn't evaluate this fix anyway, right?). I intend to NMU util-linux. Please raise any objections soonish. Helmut diff -u util-linux-2.20.1/configure.ac util-linux-2.20.1/configure.ac --- util-linux-2.20.1/configure.ac +++ util-linux-2.20.1/configure.ac @@ -733,7 +733,7 @@ [m4_ifval([$1], [#( $1) syscall="$2" ;;dnl - _UTIL_CHECK_SYSCALL_FALLBACK(m4_shiftn(2, $@))])dnl + _UTIL_CHECK_SYSCALL_FALLBACK(m4_shift2($@))])dnl ]) diff -u util-linux-2.20.1/mount/mount.c util-linux-2.20.1/mount/mount.c --- util-linux-2.20.1/mount/mount.c +++ util-linux-2.20.1/mount/mount.c @@ -596,7 +596,7 @@ /* The propagation flags should not be used together with any other flags */ if (*flags & MS_PROPAGATION) - *flags &= MS_PROPAGATION; + *flags &= MS_PROPAGATION|MS_REC; } /* Try to build a canonical options string. */ diff -u util-linux-2.20.1/debian/changelog util-linux-2.20.1/debian/changelog --- util-linux-2.20.1/debian/changelog +++ util-linux-2.20.1/debian/changelog @@ -1,3 +1,12 @@ +util-linux (2.20.1-5.6) unstable; urgency=medium + + * Non-maintainer upload. + * Fix m4 looping in configure.ac's _UTIL_CHECK_SYSCALL. +m4_shiftn(2, sequence of two elements) infloops. (Closes: #724255) + * mount should not strip MS_REC for --make-r* options. (Closes: #731574) + + -- Helmut Grohne Sat, 25 Jan 2014 13:38:36 +0100 + util-linux (2.20.1-5.5) unstable; urgency=medium * Non-maintainer upload by the Security Team.
Bug#723168: libmount1-udeb: uninstallable, depends on libselinux1
On Tue, Sep 17, 2013 at 03:46:52AM +0200, Cyril Brulebois wrote: > running edos-debcheck on debian-installer Packages files, I noticed > libmount1-udeb is uninstallable, as it depends on libselinux1. For those interested in squashing this bug, I'll share my analysis. A dependency from a udeb on a non-udeb is outright wrong. The reason why it happened here is that when dpkg-shlibdeps is invoked with -tudeb, it disregards .symbols files and just looks at .shlibs files. It primarily looks for lines prefixed with "udeb: ", but failing to find those falls back to regular lines, which happened for libselinux1. The reason for why this happened is that there is no libselinux1-udeb. This leaves three ways of fixing this bug: 1) Remove libmount1-udeb. There is no user within d-i anyway (verify this claim, before actually doing so). 2) Build util-linux twice, once with selinux for .deb and once without selinux for .udeb. After choosing this option #581631 is easy to fix as well. 3) Teach libselinux to provide libselinux1-udeb and rebuild util-linux. None of these options look like they should be done via a NMU. Thanks to KiBi for helping me understand the issues beneath. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737048: udd: import CVE identifiers from secure-testing SVN
Package: qa.debian.org
Severity: wishlist
User: qa.debian@packages.debian.org
Usertags: udd
X-Debbugs-CC: debian-secur...@lists.debian.org
It would be nice to have UDD import parts of the secure-testing SVN
repository maintained by the Debian security team. The biggest benefit I
see is that it would help in analyzing and fixing the existing data
leading to more consistency. Let me briefly summarize the source data:
The relevant data is maintained in a SVN repository available at
svn+ssh://svn.debian.org/svn/secure-testing or
svn://anonscm.debian.org/secure-testing in the file data/CVE/list.
This file contains records for CVE-identifiers. Please find a few
selected entries and explanations below:
| CVE-2014-1670 (The Microsoft Bing application before 4.2.1 for Android allows
remote ...)
| NOT-FOR-US: Microsoft Bing application
Each entry starts with an unindented identifier with optional text in
braces. This particular entry does not apply to Debian (NOT-FOR-US,
NFU), because it applies to the named product which is not packaged for
Debian.
| CVE-2014-0412 (Unspecified vulnerability in the MySQL Server component in
Oracle ...)
| {DSA-2848-1 DSA-2845-1}
| - mariadb-5.5
| - mysql-5.5 5.5.35+dfsg-1
| - mysql-5.1
This identifier applies to multiple packages and two DSAs were issued.
It is fixed for mysql-5.5, we do not care about mysql-5.1, because it
got removed, and it is still present in mariadb-5.5.
| CVE-2013-7291 (memcached before 1.4.17, when running in verbose mode, allows
remote ...)
| - memcached (low; bug #735314)
| [squeeze] - memcached (Minor issue)
| [wheezy] - memcached (Minor issue)
This issue has a bug associated with it and is characterized as "low"
(or "medium" or "high"). No DSAs will be issued for squeeze or wheezy,
because of its low priority.
| CVE-2013-6885 (The microcode on AMD 16h 00h through 0Fh processors does not
properly ...)
| - amd64-microcode
| NOTE: http://www.openwall.com/lists/oss-security/2013/11/28/1
For this issue it is not yet clear whether it affects the
amd64-microcode package, but that is the only relevant package here.
Notes provide additional free-text information and may appear multiple
times. There can also be "TODO:" items. Other CVE identifiers may be
"RESERVED" (undisclosed) or "REJECTED" (e.g. duplicate).
| CVE-2013-7316 (Cross-site scripting (XSS) vulnerability in GitLab 6.0 allows
remote ...)
| - gitlab (bug #651606)
This vulnerability applies to a software which is not yet packaged, the
ITP bug is referenced here.
How can this data be mapped into an SQL schema suitable for UDD? I don't
think that it is useful to map every single aspect of the data file to
UDD. To be useful to me, the database should be able to answer at least
the following questions:
* Is a given CVE identifier an NFU? And why?
* Which packages are associated with a given CVE identifier?
* Which bugs are associated with a given CVE identifier?
(*) Which version of a given package was a given CVE identifier fixed
in?
I'd appreciate if some UDD maintainer could give advice with the
creation of the SQL schema. If you more information about the data
format is needed, please don't hesitate to ask. If desired, I can help
with writing import modules in Python.
Thanks to all the people that made UDD reality.
Helmut
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737048: udd: import CVE identifiers from secure-testing SVN
Control: merge 660170 -1 This is a duplicate. Sorry for the noise. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737259: util-linux block linux update
On Fri, Jan 31, 2014 at 10:51:44PM +0100, Marco Righi wrote: > After apt-get update and apt-get dist-upgrade I got this situation > > Debian E: "util-linux": il sottoprocesso installato script di > post-installation > ha restituito lo stato di errore 1 > > > PLEASE WRITE ME IF YOU NEED MORE INFORMATION Yes, more information is required. You need to include the full upgrade log. Specifically the version you upgraded from and the output of the post installation script (if any) is absolutely required to process this bug report at all. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736432: Fwd: Re: Bug#736432: [doxygen] Include header/footer/img as external ressource
Control: retitle -1 remove embedding of jquery Control: tags -1 - patch + upstream wontfix Control: severity -1 wishlist Control: outlook -1 /usr/share/doc/doxygen/README.jquery Given that this report has not received sufficient information to warrant the patch tag I am turning the issue into what I believe is at its core: the embedding of jquery. It is already well documented at /usr/share/doc/doxygen/README.jquery. The issue obviously results from upstream decisions and I am not the one fixing it in the current ecosystem. That means the tag wontfix will stay until at least one of the following conditions is met: * We can do Arch:all binNMUs. * All relevant jquery auxiliary libraries are packaged and there is commitment to packaging the future libraries Doxygen upstream will introduce. * There is a patch, that does not break legitimate use cases. Given that I am not doing the work, there are no tracker bugs for the former two issues. If they are created, I'd appreciate relevant block commands to the bts. Still hoping that I am wrong and things are easier than this. ;-) Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736360: lintian: do not warn about doxygen embedding jquery
On Mon, Feb 03, 2014 at 12:39:10PM +0100, Jakub Wilk wrote: > Security is not the only issue here. jquery.js created by Doxygen is > minified, so there's a risk that we ship it without source. Thanks for highlighting the issue. Fortunately we already have a tool to work around this issue. It is called Built-Using. Last time I checked whether (dh_)doxygen should be simplifying the process of adding the Built-Using headers, I achieved no consensus on the value of such a change and discussion on what Built-Using is supposed to mean was still ongoing. If there is consensus now, we can use that tool to address this particular issue. Do you think that this would adequately address the availability of source? Do you happen to have an alternative proposal in mind? Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737645: checksecurity: does not check file capabilities
Package: checksecurity Version: 2.0.15 Severity: wishlist Dear Maintainer, As packages (e.g. iputils) transition from setuid to file capabilities, so should checksecurity. Worse, not detecting capabilities means that they can be used as a stealth mechanism against checksecurity and some capabilities (e.g. CAP_SETUID) are realistically equivalent to setuid root. So checksecurity currently gives a false sense of security. Unfortunately GNU findutils (used to implement checksecurity) do not seem to support searching for capabilities. Is there any other tool, that could fill this gap? Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737957: munin: depends on transitional package ttf-dejavu
Package: munin Version: 2.0.19-3 Severity: minor Hi Holger, ssm, and crowd, The munin package depends on the ttf-dejavu package. The latter is being hit by the fonts transition from ttf-* package names to fonts-* package names. In order to make removal of ttf-dejavu possible (the ultimate goal), munin needs to stop depending on it. Since ttf-dejavu (and its dependencies) provide compatibility symlinks, simply swapping out the dependency from ttf-dejavu to fonts-dejavu may break things. It must be verified that the compatibility symlinks are not used by munin. How does munin use these fonts? Via rrdtool? Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737957: munin: depends on transitional package ttf-dejavu
Control: tag -1 + pending On Sat, Feb 08, 2014 at 12:18:57AM +0100, Matthias Schmitz wrote: > Munin doesn't use the font file directly but configures RRDs::graph to use it > by adding --font 'DejaVuSans' to the config options of RRDs. So it should > be safe to replace ttf-dejavu by fonts-dejavu in the Depends:. > > I updated the d/control in the branches 'debian' [1] and the > 'debian-experimental' [2] > so with the next release / upload this should be fixed. Thanks for clarification and verification of the suggested fix. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736360: lintian: do not warn about doxygen embedding jquery
On Sat, Feb 08, 2014 at 11:03:13PM +0100, Jakub Wilk wrote: > >Do you happen to have an alternative proposal in mind? > > Well, the simpler alternative is to make doxygen use unminified JS. I am not yet entirely convinced about the "simpler" yet. Thanks for the suggestion anyway. Upstream goes to great lengths to make using unminified JS hard. There is this jquery/split_jquery.pl script, that hacks jquery pieces of 1<<15 bytes. Of course the number of pieces is hard coded as 3 in various places. Even in the best case the file ending up in generated documentation as "jquery.js" is a compilation (concatenation) of various libraries. So it might not count as source either. To actually ship unminified JS, an alternative might be to replace the code that creates jquery.js with a file copy operation and shipping the JS outside the doxygen binary. There is a drafted patch for this variant at http://bugs.debian.org/736432#5. In any case simple is not an attribute of the process. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731326: haskell-mode: breaks agda-mode (<< 2.3.2)
Package: haskell-mode Version: 13.07-1 Severity: normal This version of the haskell-mode package removes haskell-ghci.el which is explicitly referenced by agda-mode 2.3.0.1-2 (stable). Without this file agda-mode will not work. Please add Breaks: agda-mode (<< 2.3.2) to the haskell-mode package. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732179: upstart should support systemd-style socket activation
X-Debbugs-CC: James Hunt Package: upstart Severity: normal Version: 0.1.1-1 Control: owner -1 james.h...@ubuntu.com On Sat, Dec 14, 2013 at 11:53:42PM +0100, Michael Stapelberg wrote: > Ian Jackson writes: > > I think it would be good, regardless of what the TC decides on the > > init system question for Debian, for systemd and upstart to converge > > on a single reasonable protocol. > Helmut Grohne has done some work in that direction², speaking to the > relevant people at DebConf 13 in person. I am not entirely sure about > the current status of these efforts, maybe Helmut can comment Thanks for the reminder. I talked to James Hunt about this during DebConf 13 and also asked at least Steve Langasek about the rationale behind the socket activation interface that upstart uses. At that point, we were unable to understand the technical reasons and agreed that I should attempt to contact Scott James Remnant to ask him for his thoughts on this. Sadly he never replied even though I included at least two of his email addresses. We further agreed that the condition of timeout would be met with upstart actually implementing systemd's interface and James Hunt doing the work. The missing piece currently seems to be a bug report for getting the process going. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727708: systemd socket activation protocol rationale
On Sat, Dec 14, 2013 at 11:53:42PM +0100, Michael Stapelberg wrote: > Ian Jackson writes: > > I think it would be good, regardless of what the TC decides on the > > init system question for Debian, for systemd and upstart to converge > > on a single reasonable protocol. > Helmut Grohne has done some work in that direction², speaking to the > relevant people at DebConf 13 in person. I am not entirely sure about > the current status of these efforts, maybe Helmut can comment See http://bugs.debian.org/732179. (Afaik you cannot create a new bug and CC another at the same time. That's why I split the messages.) Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732712: denyhosts should not be released with jessie
Package: denyhosts Version: 2.6-10 Severity: serious Tags: jessie sid security Dear Maintainer, We, the Debian security team, believe that denyhosts should not be released with Debian jessie and further releases for the following reasons: * There are unaddressed security issues (e.g. #692229). * The tool is dead upstream (last release 2008). * There is a viable alternative, fail2ban, that provides the same or increased feature set. For these reasons we deem denyhosts unsupportable during the jessie release cycle. If you agree with this reasoning, please send the following commands to the control interface of the bug tracking system to remove the package from Debian sid as well: retitle -1 RM: denyhosts -- RoM severity -1 normal reassign -1 ftp.debian.org Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726997: findbugs: reduce package size by 3.3M or 40%
Package: findbugs Version: 2.0.2-1 Severity: wishlist Dear Maintainer, The findbugs package contains an excellent opportunity to reduce space on the mirrors and installations. The findbugs.jar, which makes up almost half of the package, is shipped twice in the binary package[1]. Can you replace one copy with a symbolic link to the other? For details on shrinking packages see https://wiki.debian.org/dedup.debian.net. If you need assistance, please ask. Helmut [1] http://dedup.debian.net/compare/findbugs/findbugs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
TL;DR: Thoughts on using systemd .service files on non-Linux ports. On Tue, Oct 29, 2013 at 09:20:10AM +0100, Lucas Nussbaum wrote: > Note that there are two options that could be explored, to remove the > need to maintain init scripts: > - generating sysvinit scripts from systemd service files or upstart job > files at build time (this was explored, for systemd service files, > during a GSoC project in 2012, without much success) > - having a .service/job files runtime interpreter (that sounds quite > promising) > > Even if it cannot be used for all services, using such as interpreter > could maybe provide an easy support path for sysvinit on non-linux > platforms for a large number of "simple" services. > > There's a subthread about that starting at > https://lists.debian.org/debian-devel/2013/05/msg01309.html > Helmut Grohne (Cced) did most of the work on analyzing those possibilities. Thanks for inviting me to speak up here. Lucas asked me to summarize my analysis of systemd/sysv integration earlier and I'll be giving this summary (written for Lucas at that time) below. For better separation of facts and opinion, let me point out my motivation for working on this aspect. I believe that the declarative service configuration of systemd and upstart is superior to init shell scripts. Consequently, dropping the need for init shell scripts is the only way to improve the situation (imo). Lacking time, I mostly neglected upstart. On 23/08/13 at 22:32 +0200, Helmut Grohne wrote: > The existing converter (GSOC) can be found at > https://github.com/akhilvij/systemd-to-sysvinit-converter. > > My analysis of this project: > https://lists.debian.org/debian-devel/2013/05/msg01309.html > This includes a drafted idea on how to do runtime conversion. > > Implementation details on runtime conversion: (last pragraph) > https://lists.debian.org/debian-devel/2013/05/msg01337.html > > Random details about service file conversion issues: > https://lists.debian.org/debian-devel/2013/05/msg01334.html > Important point over here: In .service files important dependency > information has been elided by socket activation. Socket activation is > official part of the dependency tree and any conversion utility that > does not do socket activation will not produce correct boot ordering. > > Statistical analysis of existing .service files in Debian. > https://lists.debian.org/debian-devel/2013/07/msg00436.html > > .service file parser written in C, could be used as a starting point. > https://lists.debian.org/debian-devel/2013/07/msg00429.html > > I presume that you are preparing arguments for a discussion with the > CTTE about how to move forward with /sbin/init. The question of whether > or how to support systemd .service files on non-Linux platforms will be > asked over there. > > The biggest issue I see here is the socket activation. It is mandatory > for syslog, so no service will declare a dependency on syslog and just > assume it to be present. On a technical level implementing socket > activation on non-Linux platforms is possible. It would require a super > server (similar to inetd) to be started early on and it would start > .service files on request by other interpreted .service files when > executed as init scripts. This amounts to reimplementing a fair part of > systemd. The only alternative would be to annotate .service files with > the missing dependency information, but which would likely be wrong most > of the time. > > I guess that an implementation that allows socket activation would be > able to support around 50% of the currently existing .service files. > > Bear in mind that systemd is a rapidly moving target. When I talked to > Lennart about the idea of a portable .service file interpreter, he > summarized future extensions to systemd that would raise the bar. The > next issue will likely be the tight integration with dbus and later > kdbus (the kernel implementation of dbus). By the time we would have an > implementation featuring socket activation, we will likely need it to do > dbus activation as well. Having read the parts of the ctte bug, it feels odd to preclude the option of supporting multiple init systems from discussion or consideration. If Debian is to support only one init system and that one init system is systemd, then given my above analysis it will be very hard for non-Linux ports to catch up. I argue that in this case we should consider dropping support for non-Linux ports. So if we really are considering such an outcome, why not consider the outcome of supporting multiple init systems (but maybe only one per architecture)? This would become radically easier if gnome were to become Architecture: linux-any. In any case, feel free to ask me for answers or help w
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi Steve, On Tue, Oct 29, 2013 at 09:31:37AM -0700, Steve Langasek wrote: > On Tue, Oct 29, 2013 at 10:22:54AM +0100, Helmut Grohne wrote: > > Having read the parts of the ctte bug, it feels odd to preclude the > > option of supporting multiple init systems from discussion or > > consideration. If Debian is to support only one init system and that one > > init system is systemd, then given my above analysis it will be very > > hard for non-Linux ports to catch up. I argue that in this case we > > should consider dropping support for non-Linux ports. So if we really > > are considering such an outcome, why not consider the outcome of > > supporting multiple init systems (but maybe only one per architecture)? > > While other members of the TC may wish to consider this option, I've ruled > it out myself because we would lose most of the benefits of switching away > from sysvinit and instead accrue significant maintenance costs to individual > developers who would then have to support both init systems in their > packages. What makes switching init systems worth doing is being able to > *simplify* the interfaces between the init system and the services. > Continuing to support different init systems across different architectures > would add complexity instead. That's a pretty bleak outcome. I fully agree with your reasoning. Yet, I see that the options * drop support for non-Linux ports and * maintain some support for an alternate init system are similarly painful. I see neither of them a desirable, but if we really consider one of them, I'd ask for the other one to be considered and evaluated as well. Most participants in this thread appear to agree that the sysvinit *interface* for services (shell scripts) is suboptimal. We are currently mostly arguing about implementations, because each proposed interface has only one implementation. It might make sense to consider a subset of the interface that one implementation provides as our standard and provide a degraded experience to that interface on non-Linux ports. For example, if systemd were to be the init system of choice, it could be required to provide an init script for services with Type=notify. The interfaces of all init systems (except sysvinit, but are we really considering that one?) still are somewhat in flux, so this is the point where we can still influence and shape them. Imagine a world where upstart and systemd would use the same syntax (structure) but implement different and somewhat overlapping aspects. Maybe 50% of the daemons would work with either of them without needing changes. But now we call it "exec" here and "ExecStart" there, "export" here and "Environment" there, and "chdir" here and "WorkingDirectory" there. Bummer. Oh wait, I am talking to one of the guys who can actually fix this. :) > > This would become radically easier if gnome were to become Architecture: > > linux-any. > > GNOME may be the trigger for this being raised to the TC, but it's not the > core question that we need to address. Even though I did mention gnome over there, the argument is not restricted to gnome in any way. It can be applied to any other package not deemed worthy to support on non-Linux ports (and I should have made this explicit). Furthering this thought leads to turning non-Linux ports into derivatives as presented by others in this thread. I argue that a resolution of this bug needs to answer: What is going to happen with non-Linux ports? Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734329: denyhosts: regression in regex.py
Control: found -1 2.6-7+deb6u2
Control: found -1 2.6-10+deb7u2
On Mon, Jan 06, 2014 at 11:00:45AM +1100, Vincent McIntyre wrote:
> I have 2.6-10 running on a few squeeze hosts here and applied the patch that
> should fix #692229. I think there is a problem with one aspect of that
> change -
>
> - FAILED_ENTRY_REGEX = re.compile(r"""Failed (?P.*) for
> (?Pinvalid user |illegal user )?(?P.*?) .*from
> (:::)?(?P\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})""")
> + FAILED_ENTRY_REGEX = re.compile(r"""Failed (?P\S*) for
> (?Pinvalid user |illegal user )?(?P.*) from
> (:::)?(?P\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})$""")
>
> The issue is the $ after the IP address matching - this fails on my syslog
> files which have lines like:
> Jan 5 21:01:15 venice sshd[12491]: Failed password for root from
> 122.252.245.89 port 57845 ssh2
Thanks for reporting this regression.
> To make the regex match again, just drop the $. (Tested with 'kodos').
> What I am unclear about is whether making this change will allow
> IP address injections again. Can the wildcard for the match
> be made non-greedy?
As soon as you have two .* patterns, injections are technically
possible. Dropping the $ accounts as one trailing .*. Making the user
match non-greedy reintroduces the issue. It must be greedy.
> Otherwise, the following regex may be ok:
>
> Failed (?P\S*) for (?Pinvalid user |illegal user
> )?(?P.*) from (:::)?(?P\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})(
> port \d+)?
The trailing ( port \d+)? is useless, because it is always fulfilled
with the empty string and any garbage beyond is matched by the lack of a
$ pattern. This is no improvement over just dropping the $.
> This issue is also present in 2.6-7+deb6u2 (I checked regex.py)
> and (I infer) 2.6-10+deb7u.
Marked in the bts.
A real fix seems more involved. Suggestions welcome.
Helmut
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725653: --clip copies to CLIPBOARD, I'd prefer PRIMARY selection
Hi Thorsten, On Thu, Oct 17, 2013 at 08:18:47PM +, Thorsten Glaser wrote: > retitle 725653 --clip copies to CLIPBOARD, I'd prefer PRIMARY selection > tags 725653 + patch Thanks for this patch and thanks to Colin Watson for carrying it. It scratches my itch as well. > I???ve decided to just copy to both. The attached patch ??? > untested of course ;-) ??? does that; xsel(1) is able to > keep it in memory by forking a dæmon subprocess that???s > ended as soon as it???s no longer needed. I was wondering whether we could exploit the existence of the subprocess in a useful way. Reading the manual page, I presumed that passing the -t switch could terminate an xsel process after a specific amount of time, but this seems not to be the case. When wrapping xsel --nodetach in timeout or timelimit, we can ensure that the buffer is gone. This would also alleviate the need to launch a secondary xsel again forking to background, since - it seems - the behaviour of a dieing xsel process is to restore the previous clipboard contents, precisely what is desired here. So maybe all the hackery for restoration including the sleep 45 could be replaced by something akin to printf '%s' "$1" | timeout 45 xsel -n -i -b & printf '%s' "$1" | timeout 45 xsel -n -i -p & further simplifying the code at the cost of an additional dependency. What do you think? Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682045: libtool: please mark libtool multi-arch: allowed
On Thu, Jan 09, 2014 at 07:20:40PM +, Colin Watson wrote: > If you weren't one of the people in the "thinking extremely hard about > multiarch" BOF at DebConf, note that Multi-Arch: foreign denotes a point > in the dependency graph where you're allowed to switch architectures, > Multi-Arch: allowed denotes such a point if and only if the incoming > dependency is annotated with :any, and otherwise you may not switch > architectures; this holds even when you're going through an > Architecture: all package, so you're allowed to do this: While thinking of Arch:all packages as being somewhat "transparent" and something to go through is convenient, this way of thinking risks to bring in the wrong associations. From a dpkg point of view, there is a special architecture (called native architecture, it happens to be the architecture of the dpkg package). Now Arch:all is just an alias for native. So the situation you pictured > Package: a > Architecture: i386 > Depends: b > > Package: b > Architecture: all > Depends: c > > Package: c > Architecture: i386 may actually be disallowed if you happen to use dpkg:amd64. This elaboration does not change any of your arguments, but I figured I'd pick on it again, because I have seen it gotten wrong so many times to the point of wanting to change this particular behaviour. ;-) > Bearing that in mind, let's go back to Kurt's options in > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682045#22, elaborated a > bit: Excuse my ignorance to previous discussion, but why is there no /usr/bin/-libtool? To me it appears that libtools is similar in nature to a compiler in that it is executed on one architecture (build architecture in autoconf terms) and produces material useful on a (possibly) different architecture (host architecture). It is an established practise to prefix such tools with their host architecture. I recognize that libtool itself is a shell script that decides on most of the architecture specific stuff at runtime. But this aspect makes a transition to an architecture prefix easier, as the evaluation of $0 could be used to override the host* variables defined near its top. All that it needs would be clever symlinking. > Reasoning about multiarch can be hard work and I'm running low on > coffee. Would anyone like to pick holes in this analysis? Having a multiarch background, but no libtool background, I tried to understand it. I did not find any obvious flaws, but I do note that with option 2.1, having libtool depend on libtool-bin does not conceptually make sense to me, even though this alternative may be practically useful. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734329: denyhosts: regression in regex.py
Control: tags -1 + patch
Hi Vincent,
On Mon, Jan 06, 2014 at 06:32:13AM +0100, Helmut Grohne wrote:
> A real fix seems more involved. Suggestions welcome.
Personally I cannot reproduce this issue on any of my machines, but I
believe that I understand the cause.
Can you test one of the attached patches? I presume that you can build
the packages yourself, if not, please contact me.
Note that due to the very likely removal of denyhosts from sid, my patch
does not solve the regression for jessie or sid. It only works with
older openssh versions from squeeze or wheezy. The patches are also
available as branches from the collab-maint/denyhosts git repository.
Helmut
>From d534d03cae4541c74b66bde7e83e7f2a17e90bf7 Mon Sep 17 00:00:00 2001
From: Helmut Grohne
Date: Sun, 12 Jan 2014 19:21:40 +0100
Subject: [PATCH] propose fix for 734329
---
debian/changelog | 7 +++
debian/patches/13_CVE-2013-6890.patch | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index c7aa4b8..56b9c26 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+denyhosts (2.6-10+deb7u3) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload by the Security Team.
+ * Fix regression another regression. Closes: 734329.
+
+ -- Helmut Grohne Sun, 12 Jan 2014 19:19:14 +0100
+
denyhosts (2.6-10+deb7u2) wheezy-security; urgency=high
* Non-maintainer upload by the Security Team.
diff --git a/debian/patches/13_CVE-2013-6890.patch b/debian/patches/13_CVE-2013-6890.patch
index d55382b..ed02249 100644
--- a/debian/patches/13_CVE-2013-6890.patch
+++ b/debian/patches/13_CVE-2013-6890.patch
@@ -27,7 +27,7 @@ Index: denyhosts-2.6/DenyHosts/regex.py
#SSHD_FORMAT_REGEX = re.compile(r""".* sshd.*: (?P.*)""")
-FAILED_ENTRY_REGEX = re.compile(r"""Failed (?P.*) for (?Pinvalid user |illegal user )?(?P.*?) .*from (:::)?(?P\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})""")
-+FAILED_ENTRY_REGEX = re.compile(r"""Failed (?P\S*) for (?Pinvalid user |illegal user )?(?P.*) from (:::)?(?P\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})$""")
++FAILED_ENTRY_REGEX = re.compile(r"""Failed (?P\S*) for (?Pinvalid user |illegal user )?(?P.*) from (:::)?(?P\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})( port \d+)?( ssh2)?$""")
-FAILED_ENTRY_REGEX2 = re.compile(r"""(?P(Illegal|Invalid)) user (?P.*?) .*from (:::)?(?P\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})""")
+FAILED_ENTRY_REGEX2 = re.compile(r"""(?P(Illegal|Invalid)) user (?P.*) from (:::)?(?P\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})$""")
--
1.8.5.2
>From c5b2a7a84599c26038bbbc8616128118abc30f6e Mon Sep 17 00:00:00 2001
From: Helmut Grohne
Date: Sun, 12 Jan 2014 19:25:41 +0100
Subject: [PATCH] propose fix for 734329
---
debian/changelog | 7 +++
debian/patches/13_CVE-2013-6890.patch | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index 69aea93..27cccdc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+denyhosts (2.6-7+deb6u3) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload by the Security Team.
+ * Fix regression another regression. Closes: 734329.
+
+ -- Helmut Grohne Sun, 12 Jan 2014 19:19:14 +0100
+
denyhosts (2.6-7+deb6u2) squeeze-security; urgency=high
* Non-maintainer upload by the Security Team.
diff --git a/debian/patches/13_CVE-2013-6890.patch b/debian/patches/13_CVE-2013-6890.patch
index c947986..4272083 100644
--- a/debian/patches/13_CVE-2013-6890.patch
+++ b/debian/patches/13_CVE-2013-6890.patch
@@ -27,7 +27,7 @@ Index: denyhosts-2.6/DenyHosts/regex.py
#SSHD_FORMAT_REGEX = re.compile(r""".* sshd.*: (?P.*)""")
-FAILED_ENTRY_REGEX = re.compile(r"""Failed (?P.*) for (?Pinvalid user |illegal user )?(?P.*?) .*from (:::)?(?P\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})""")
-+FAILED_ENTRY_REGEX = re.compile(r"""Failed (?P\S*) for (?Pinvalid user |illegal user )?(?P.*) from (:::)?(?P\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})$""")
++FAILED_ENTRY_REGEX = re.compile(r"""Failed (?P\S*) for (?Pinvalid user |illegal user )?(?P.*) from (:::)?(?P\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})( port \d+)?( ssh2)?$""")
-FAILED_ENTRY_REGEX2 = re.compile(r"""(?P(Illegal|Invalid)) user (?P.*?) .*from (:::)?(?P\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})""")
+FAILED_ENTRY_REGEX2 = re.compile(r"""(?P(Illegal|Invalid)) user (?P.*) from (:::)?(?P\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})$""")
--
1.8.5.2
Bug#732712: Requesting removal of denyhosts from sid
Control: retitle -1 RM: denyhosts -- RoST; upstream dead; unmaintained; dysfunctional in sid Control: severity -1 normal Control: reassign -1 ftp.debian.org On Fri, Dec 20, 2013 at 04:10:21PM +0100, Helmut Grohne wrote: > We, the Debian security team, believe that denyhosts should not be > released with Debian jessie and further releases for the following > reasons: > > * There are unaddressed security issues (e.g. #692229). > * The tool is dead upstream (last release 2008). > * There is a viable alternative, fail2ban, that provides the same or >increased feature set. > > For these reasons we deem denyhosts unsupportable during the jessie > release cycle. It appears that at least none of the maintainers disagree with this reasoning. In other words, I didn't get a single reply since disclosing the issue. In the mean time I noticed that the security uploads introduced a(nother) regression #734329. While it appears to be fixable for squeeze and wheezy, it is more involved for jessie and sid. Thus I am accelerating the removal process in order to go with the simple fix for said regression. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734329: denyhosts: regression in regex.py
On Mon, Jan 13, 2014 at 09:49:07AM +1100, Vincent McIntyre wrote: > I've tried the patch and it works correctly. Thanks. Could you also mention which patch you tried? squeeze or wheezy? Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
