Bug#641867: screen version bump (4.1.0 20101110git066b098)
Hi Axel, hi Brian, Since the current maintainer of screen in Debian is quite busy in real life at the moment, I'm thinking about doing an Non-Maintainer Upload (NMU) for screen. Your packaging work comes in quite handy there, thanks! :-) thanks to both of you for your work on getting the screen package back into shape. I'm indeed quite busy (yay, at work on Saturdays) and unsure when I will be able to invest enough time into Debian again to wipe the dust off my packages myself. I'm afraid this won't happen in the forseeable future. Due to this, if someone wants to take over, I'm all for it. Thanks again and best wishes, Jan signature.asc Description: Digital signature
Bug#600228: byte order bug in afsconf_LookupServer()
Package: openafs-krb5
Severity: normal
Hi,
found while using aklog, so reporting against -krb5...
= src/auth/cellconfig.c:
] int
] afsconf_GetAfsdbInfo(char *acellName, char *aservice,
] struct afsconf_cell *acellInfo)
] {
] [...]
] code = afsconf_LookupServer((const char *)service, udp,
] (const char *)acellName, afsdbport,
] cellHostAddrs, cellHostNames,
] ports, ipRanks, numServers, ttl,
] realCellName);
] [...]
] acellInfo-hostAddr[i].sin_port = ports[i];
] int
] afsconf_LookupServer(const char *service, const char *protocol,
] const char *cellName, unsigned short afsdbPort,
] int *cellHostAddrs, char cellHostNames[][MAXHOSTCHARS],
] unsigned short ports[], unsigned short ipRanks[],
] int *numServers, int *ttl, char **arealCellName)
] {
] [...]
/* p[] is a byte pointer into the DNS answer to a type SRV query
and points into the contents of the SRV RR right at the priority,
so the dest port is at (p+4) */
] ports[server_num] = (p[4] 8) | p[5];
So ports[] is manually extracted from the DNS answer and thus implicitely
converted from network to host byte order, but not converted back when
assigning the (struct sin_addr).sin_port member.
Suggestion: Wrap either assignment with htons().
Regards,
Jan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600228: byte order bug in afsconf_LookupServer()
Hi, found while using aklog, so reporting against -krb5... This code doesn't exist in the current version of openafs in unstable or testing, so I assume you're using the version from experimental? oh right, forgot the tag (and the Version: header, sorry). It's the current experimental (1.5.77-2), yes. Best regards, Jan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591075: glib2.0 segv
Hi,
probably an optimization problem? Given the test program
extern void g_type_init(void);
int main(int an, char **ac) {
(void)g_type_init();
return 0;
}
I get this backtrace:
#0 g_bsearch_array_create ()
at
/build/buildd-glib2.0_2.25.12-1-i386-5iccNM/glib2.0-2.25.12/glib/gbsearcharray.h:137
#1 g_signal_init ()
at
/build/buildd-glib2.0_2.25.12-1-i386-5iccNM/glib2.0-2.25.12/gobject/gsignal.c:775
#2 0xb7fafaef in g_type_init_with_debug_flags (debug_flags=G_TYPE_DEBUG_NONE)
at
/build/buildd-glib2.0_2.25.12-1-i386-5iccNM/glib2.0-2.25.12/gobject/gtype.c:4349
#3 0xb7fafc2e in g_type_init ()
at
/build/buildd-glib2.0_2.25.12-1-i386-5iccNM/glib2.0-2.25.12/gobject/gtype.c:4367
#4 0x080484bf in main (an=1, ac=0xb614) at x.c:4
Now a close look at g_signal_init():
#1 C Source
g_signal_init()
[...]
g_handler_list_bsa_ht = g_hash_table_new (g_direct_hash, NULL);
g_signal_key_bsa = g_bsearch_array_create (g_signal_key_bconfig);
[...]
[inline] g_bsearch_array_create()
static inline GBSearchArray*
g_bsearch_array_create (const GBSearchConfig *bconfig)
{
GBSearchArray *barray;
guint size;
g_return_val_if_fail (bconfig != NULL, NULL);
size = sizeof (GBSearchArray) + bconfig-sizeof_node;
if (bconfig-flags G_BSEARCH_ARRAY_ALIGN_POWER2)
size = G_BSEARCH_UPPER_POWER2 (size);
barray = (GBSearchArray *) g_malloc (size);
memset (barray, 0, sizeof (GBSearchArray));
return barray;
}
#2 Assembler
g_signal_init
[...]
0xb7fa5297 +167: moveax,DWORD PTR [ebx-0x30]
0xb7fa529d +173: movDWORD PTR [esp+0x4],0x0
0xb7fa52a5 +181: movDWORD PTR [esp],eax
0xb7fa52a8 +184: call 0xb7f8c714 g_hash_table_...@plt
0xb7fa52ad +189: movDWORD PTR [esp],0x0
0xb7fa52b4 +196: movDWORD PTR [ebx+0x504],eax
0xb7fa52ba +202: call 0xb7f8c614 g_mal...@plt
= 0xb7fa52bf +207: movDWORD PTR [eax],0x0
0xb7fa52c5 +213: movDWORD PTR [eax+0x4],0x0
[...]
This is effectively *(GBSearchArray *)g_malloc(0) = {0, 0} and MUST fail.
(Where the rest of the inlined function has gone is beyond my comprehension.)
Recompiling the package without optimization makes g_bsearch_array_create() a
proper function (no inlining), the generated assembler looks good, and the
bug disappears.
Regards,
Jan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543024: pam-shield: FTBFS
tags 543024 + patch kthxbye Hi Mateusz, I've prepared the adjustments to make the package build with automake 1.11 and eliminated a few very inviting lintian warnings. I'll upload this as an NMU in a few days if you don't want to prepare an upload yourself - the NMU patch is attached. Regards, Jan diff -u pam-shield-0.9.2/debian/rules pam-shield-0.9.2/debian/rules --- pam-shield-0.9.2/debian/rules +++ pam-shield-0.9.2/debian/rules @@ -53,7 +53,8 @@ clean: _clean unpatch rm -fr aclocal.m4 build-stamp config* missing \ -Makefile* stamp* .depend .deps/ .pc/ ltmain.sh libtool depcomp + Makefile* stamp* .depend .deps/ .pc/ ltmain.sh \ + libtool depcomp install-sh - rm -fr $(CURDIR)/debian/libpam-shield install: build diff -u pam-shield-0.9.2/debian/postrm pam-shield-0.9.2/debian/postrm --- pam-shield-0.9.2/debian/postrm +++ pam-shield-0.9.2/debian/postrm @@ -7,7 +7,7 @@ purge|remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear) if [ -d /var/lib/pam_shield ]; then -/bin/rm -fr /var/lib/pam_shield +rm -fr /var/lib/pam_shield fi ;; @@ -23,2 +22,0 @@ - - diff -u pam-shield-0.9.2/debian/control pam-shield-0.9.2/debian/control --- pam-shield-0.9.2/debian/control +++ pam-shield-0.9.2/debian/control @@ -2,7 +2,7 @@ Section: admin Priority: optional Maintainer: Mateusz Kaduk mate...@kaduk.net -Build-Depends: debhelper (= 5), libgdbm-dev, libpam0g-dev, quilt, autoconf, automake (= 1.10), libtool +Build-Depends: debhelper (= 5), libgdbm-dev, libpam0g-dev, quilt, autoconf, automake (= 1.11), libtool Standards-Version: 3.7.3 Package: libpam-shield diff -u pam-shield-0.9.2/debian/postinst pam-shield-0.9.2/debian/postinst --- pam-shield-0.9.2/debian/postinst +++ pam-shield-0.9.2/debian/postinst @@ -5,14 +5,14 @@ case $1 in configure) if [ ! -d /var/lib/pam_shield ]; then -/bin/mkdir /var/lib/pam_shield +mkdir /var/lib/pam_shield fi -/bin/touch /var/lib/pam_shield/db +touch /var/lib/pam_shield/db ;; abort-upgrade|abort-remove|abort-deconfigure) if [ -d /var/lib/pam_shield ]; then -/bin/rm -fr /var/lib/pam_shield +rm -fr /var/lib/pam_shield fi ;; @@ -28 +27,0 @@ - diff -u pam-shield-0.9.2/debian/changelog pam-shield-0.9.2/debian/changelog --- pam-shield-0.9.2/debian/changelog +++ pam-shield-0.9.2/debian/changelog @@ -1,3 +1,13 @@ +pam-shield (0.9.2-3.2) unstable; urgency=low + + * NMU. + * Migrate to automake 1.11. Closes: #543024. + * Minor improvements to debian/rules (purge install-sh, too) and the +maintainer scripts (don't call binaries with full path), but don't +bump Standards version. + + -- Jan Christoph Nordholz he...@pool.math.tu-berlin.de Mon, 07 Sep 2009 23:01:50 +0200 + pam-shield (0.9.2-3.1) unstable; urgency=low * Non-maintainer upload. diff -u pam-shield-0.9.2/debian/patches/automake.patch pam-shield-0.9.2/debian/patches/automake.patch --- pam-shield-0.9.2/debian/patches/automake.patch +++ pam-shield-0.9.2/debian/patches/automake.patch @@ -42,8 +42,8 @@ @@ -0,0 +1,6 @@ +#!/bin/sh + -+export AUTOMAKE=/usr/bin/automake-1.10 -+export ACLOCAL=/usr/bin/aclocal-1.10 ++export AUTOMAKE=/usr/bin/automake-1.11 ++export ACLOCAL=/usr/bin/aclocal-1.11 + +exec autoreconf -fi; Index: pam-shield-0.9.2/configure.ac signature.asc Description: Digital signature
Bug#540059: udev segfaults
Hi Marco, it seems the kernel is at fault and not udev. Have a look at this commit, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8442edc18843491978f7820f87dbdf293461290e especially the third blob - the unfixed version rounded even a -name_len == 0 up to sizeof(struct inotify_event) and copied more into the userspace buffer than it was asked for, which is nicely visible in a udev strace log... read(13, \4\0\0\0\0\200\0\0\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0, 16) = 32 (( Received inotify_event for watch #4, IN_DELETE, len has been rounded up to 16, but the -name is just , which itself is fine because #4 was in this case a watch on '/dev/sdb' and not a directory )) I'm just compiling 2.6.31-rc9 which contains the fix (the mentioned commit was made 8 days ago). If I don't report back, at least this specific segfault instance is fixed. ;) Regards, Jan signature.asc Description: Digital signature
Bug#540059: udev segfaults
Hi Marco, I've seen this, too. I couldn't reproduce the hang-on-boot yet after experiencing it once, but the segfaults are pretty reliable. Here's an exemplary crash and the accompanying debug log (attached). I'm away over the weekend, but I'll gladly help when I get back if you need core dumps or more test runs. Regards, Jan r...@apocatequil:/mnt# udevd --debug 2 /root/udev_heap_corruption.log *** glibc detected *** udevd: free(): invalid next size (fast): 0x097814f8 *** === Backtrace: = /lib/i686/cmov/libc.so.6[0xb7e188f4] /lib/i686/cmov/libc.so.6(cfree+0x96)[0xb7e1a896] udevd[0x8055690] /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7dc07a5] udevd[0x804a071] === Memory map: 08048000-08065000 r-xp 08:02 2330236/sbin/udevd 08065000-08066000 rw-p 0001d000 08:02 2330236/sbin/udevd 0976f000-097c7000 rw-p 00:00 0 [heap] b7c0-b7c21000 rw-p 00:00 0 b7c21000-b7d0 ---p 00:00 0 b7d3e000-b7d68000 r-xp 08:02 523601 /lib/libgcc_s.so.1 b7d68000-b7d69000 rw-p 00029000 08:02 523601 /lib/libgcc_s.so.1 b7d69000-b7d73000 r-xp 08:02 533647 /lib/i686/cmov/libnss_files-2.9.so b7d73000-b7d74000 r--p 9000 08:02 533647 /lib/i686/cmov/libnss_files-2.9.so b7d74000-b7d75000 rw-p a000 08:02 533647 /lib/i686/cmov/libnss_files-2.9.so b7d75000-b7d8a000 r-xp 08:02 533649 /lib/i686/cmov/libnsl-2.9.so b7d8a000-b7d8b000 r--p 00014000 08:02 533649 /lib/i686/cmov/libnsl-2.9.so b7d8b000-b7d8c000 rw-p 00015000 08:02 533649 /lib/i686/cmov/libnsl-2.9.so b7d8c000-b7d8e000 rw-p 00:00 0 b7da4000-b7da5000 rw-p 00:00 0 b7da5000-b7da7000 r-xp 08:02 533657 /lib/i686/cmov/libdl-2.9.so b7da7000-b7da8000 r--p 1000 08:02 533657 /lib/i686/cmov/libdl-2.9.so b7da8000-b7da9000 rw-p 2000 08:02 533657 /lib/i686/cmov/libdl-2.9.so b7da9000-b7daa000 rw-p 00:00 0 b7daa000-b7f02000 r-xp 08:02 533393 /lib/i686/cmov/libc-2.9.so b7f02000-b7f03000 ---p 00158000 08:02 533393 /lib/i686/cmov/libc-2.9.so b7f03000-b7f05000 r--p 00158000 08:02 533393 /lib/i686/cmov/libc-2.9.so b7f05000-b7f06000 rw-p 0015a000 08:02 533393 /lib/i686/cmov/libc-2.9.so b7f06000-b7f09000 rw-p 00:00 0 b7f09000-b7f22000 r-xp 08:02 655868 /lib/libselinux.so.1 b7f22000-b7f23000 r--p 00018000 08:02 655868 /lib/libselinux.so.1 b7f23000-b7f24000 rw-p 00019000 08:02 655868 /lib/libselinux.so.1 b7f25000-b7f2e000 r-xp 08:02 533653 /lib/i686/cmov/libnss_nis-2.9.so b7f2e000-b7f2f000 r--p 8000 08:02 533653 /lib/i686/cmov/libnss_nis-2.9.so b7f2f000-b7f3 rw-p 9000 08:02 533653 /lib/i686/cmov/libnss_nis-2.9.so b7f3-b7f37000 r-xp 08:02 533399 /lib/i686/cmov/libnss_compat-2.9.so b7f37000-b7f38000 r--p 6000 08:02 533399 /lib/i686/cmov/libnss_compat-2.9.so b7f38000-b7f39000 rw-p 7000 08:02 533399 /lib/i686/cmov/libnss_compat-2.9.so b7f39000-b7f3c000 rw-p 00:00 0 b7f3c000-b7f3d000 r-xp 00:00 0 [vdso] b7f3d000-b7f59000 r-xp 08:02 524277 /lib/ld-2.9.so b7f59000-b7f5a000 r--p 0001b000 08:02 524277 /lib/ld-2.9.so b7f5a000-b7f5b000 rw-p 0001c000 08:02 524277 /lib/ld-2.9.so bfea3000-bfeb8000 rw-p 00:00 0 [stack] Aborted (core dumped) 1252111429.509218 [19694] udev_device_new_from_syspath: device 0x97702c0 has devpath '/devices/pci:00/:00:1a.7/usb1/1-3/1-3:1.0/host5/target5:0:0/5:0:0:0/block/sdb' 1252111429.540598 [19694] udev_device_read_db: device 0x97702c0 filled with db file data 1252111429.540620 [19694] udev_watch_restore: restoring old watch on '/dev/sdb' 1252111429.540635 [19694] udev_watch_begin: adding watch on '/dev/sdb' 1252111429.541322 [19694] parse_file: reading '/etc/udev/rules.d/025_libgphoto2.rules' as rules file 1252111429.552345 [19694] parse_file: reading '/etc/udev/rules.d/035_kino.rules' as rules file 1252111429.552444 [19694] parse_file: reading '/lib/udev/rules.d/45-libmtp8.rules' as rules file 1252111429.558203 [19694] parse_file: reading '/lib/udev/rules.d/50-udev-default.rules' as rules file 1252111429.558750 [19694] parse_file: reading '/lib/udev/rules.d/55-dm.rules' as rules file 1252111429.558829 [19694] add_rule: name empty, node creation suppressed 1252111429.558948 [19694] parse_file: reading '/lib/udev/rules.d/60-libsane-extras.rules' as rules file 1252111429.559075 [19694] parse_file: reading '/lib/udev/rules.d/60-libsane.rules' as rules file 1252111429.564638 [19694] parse_file: reading '/lib/udev/rules.d/60-persistent-alsa.rules' as rules file 1252111429.564778 [19694] parse_file: reading '/lib/udev/rules.d/60-persistent-input.rules' as rules file 1252111429.565093 [19694] parse_file: reading '/lib/udev/rules.d/60-persistent-serial.rules' as rules file 1252111429.565259 [19694] parse_file: reading '/lib/udev/rules.d/60-persistent-storage-dm.rules' as
Bug#541349: autofs: Incorrect init.d dependency info make script start to early
tags 541349 + pending clone 541349 -1 reassign -1 autofs5 kthxbye Hi Petter, Here is an updated patch. It occured to me that for systems using LDAP (libnss-ldapd) instead of NIS, autofs should probably start after the nslcd daemon too. This patch make sure it does. thanks for collecting all the information. I'll apply this to both autofs versions in the archive during the next days. Regards, Jan signature.asc Description: Digital signature
Bug#541160: #541160 xterm: heap corruption when changing window size
Hi Thomas, This one is hard to reproduce (here). valgrind is not showing me any problems as I resize the screen in various ways. There are several special cases in the resizing logic, depending on resource-settings, as well as the amount of text that has been scrolled off onto the saved-lines buffer. More details would be helpful... while Julien has uploaded a new xterm package with fifo-lines disabled, I can still help debugging the actual problem if this is desired. I can reliably reproduce the problem with an empty (i.e. freshly started) xterm with a bare prompt - once the buffer is full I can no longer make it crash. My .Xresources only contains modifications to the font settings. I'll do a few valgrind runs myself and report back. Regards, Jan signature.asc Description: Digital signature
Bug#541160: #541160 xterm: heap corruption when changing window size
Hi Thomas, Here's a fix for the positioning problem that I've been seeing (attached). thank you very much, the malloc corruption is gone now, too. Regards, Jan signature.asc Description: Digital signature
Bug#541160: xterm: heap corruption when changing window size
Package: xterm Version: 244-1 Severity: normal Hi, I just noticed that xterm doesn't like it very much to be resized: when I grab a window edge and make a circular motion (i.e. enlarge and shrink again in both dimensions), I usually get it to segfault within fractions of a second. Here are a few backtrace samples... = (gdb) bt #0 0xb7e333fc in ?? () from /lib/i686/cmov/libc.so.6 #1 0xb7e349ff in calloc () from /lib/i686/cmov/libc.so.6 #2 0x0807d31e in allocScrnData (screen=0x80ca6b4, nrow=1, ncol=121) at ../screen.c:287 #3 0x0807cfcd in addScrollback (screen=0x80ca6b4) at ../scrollback.c:90 #4 0x0807d3d3 in saveEditBufLines (screen=0x80ca6b4, sb=0x80e2378, n=1) at ../screen.c:340 #5 0x080806fd in ScreenResize (xw=0x80ca5b0, width=730, height=496, flags=0x80cd984) at ../screen.c:1791 #6 0x0805d3a1 in VTResize (w=0x80ca5b0) at ../charproc.c:5021 #7 0xb7c485d9 in XtConfigureWidget () from /usr/lib/libXt.so.6 #8 0xb7c4877a in XtResizeWidget () from /usr/lib/libXt.so.6 #9 0xb7fa5c5a in XawVendorShellExtResize () from /usr/lib/libXaw.so.7 #10 0xb7c612a2 in ?? () from /usr/lib/libXt.so.6 #11 0xb7c450f4 in XtDispatchEventToWidget () from /usr/lib/libXt.so.6 #12 0xb7c45aaf in ?? () from /usr/lib/libXt.so.6 #13 0xb7c44a67 in XtDispatchEvent () from /usr/lib/libXt.so.6 #14 0x08076319 in xevents () at ../misc.c:459 #15 0x08059edb in in_put (xw=0x80ca5b0) at ../charproc.c:3437 #16 0x08059f14 in doinput () at ../charproc.c:3452 #17 0x0805962d in VTparse (xw=0x80ca5b0) at ../charproc.c:3023 #18 0x0805d200 in VTRun (xw=0x80ca5b0) at ../charproc.c:4957 #19 0x0806f416 in main (argc=0, argv=0xb4f8) at ../main.c:2414 = Program received signal SIGSEGV, Segmentation fault. 0xb7e322a8 in ?? () from /lib/i686/cmov/libc.so.6 (gdb) bt #0 0xb7e322a8 in ?? () from /lib/i686/cmov/libc.so.6 #1 0xb7e32896 in free () from /lib/i686/cmov/libc.so.6 #2 0x0807d831 in Reallocate (xw=0x80ca5b0, sbuf=0x80cc7b8, sbufaddr=0x80cc7c0, nrow=24, ncol=123, oldrow=25, oldcol=123) at ../screen.c:499 #3 0x08080777 in ScreenResize (xw=0x80ca5b0, width=742, height=292, flags=0x80cd984) at ../screen.c:1837 #4 0x0805d3a1 in VTResize (w=0x80ca5b0) at ../charproc.c:5021 #5 0xb7c485d9 in XtConfigureWidget () from /usr/lib/libXt.so.6 #6 0xb7c4877a in XtResizeWidget () from /usr/lib/libXt.so.6 #7 0xb7fa5c5a in XawVendorShellExtResize () from /usr/lib/libXaw.so.7 #8 0xb7c612a2 in ?? () from /usr/lib/libXt.so.6 #9 0xb7c450f4 in XtDispatchEventToWidget () from /usr/lib/libXt.so.6 #10 0xb7c45aaf in ?? () from /usr/lib/libXt.so.6 #11 0xb7c44a67 in XtDispatchEvent () from /usr/lib/libXt.so.6 #12 0x08076319 in xevents () at ../misc.c:459 #13 0x08059edb in in_put (xw=0x80ca5b0) at ../charproc.c:3437 #14 0x08059f14 in doinput () at ../charproc.c:3452 #15 0x0805962d in VTparse (xw=0x80ca5b0) at ../charproc.c:3023 #16 0x0805d200 in VTRun (xw=0x80ca5b0) at ../charproc.c:4957 #17 0x0806f416 in main (argc=0, argv=0xb4f8) at ../main.c:2414 = *** glibc detected *** ./xterm: free(): invalid pointer: 0x080d6b78 *** Program received signal SIGABRT, Aborted. 0xb7fe1424 in __kernel_vsyscall () (gdb) bt #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb7ded3d0 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb7df0a85 in abort () from /lib/i686/cmov/libc.so.6 #3 0xb7e262ed in ?? () from /lib/i686/cmov/libc.so.6 #4 0xb7e308f4 in ?? () from /lib/i686/cmov/libc.so.6 #5 0xb7e32835 in free () from /lib/i686/cmov/libc.so.6 #6 0x0807d06d in deleteScrollback (screen=0x80caa74, row=-1) at ../scrollback.c:115 #7 0x08080993 in ScreenResize (xw=0x80ca970, width=472, height=556, flags=0x80cdd44) at ../screen.c:1909 #8 0x0805d3a1 in VTResize (w=0x80ca970) at ../charproc.c:5021 #9 0xb7c485d9 in XtConfigureWidget () from /usr/lib/libXt.so.6 #10 0xb7c4877a in XtResizeWidget () from /usr/lib/libXt.so.6 #11 0xb7fa5c5a in XawVendorShellExtResize () from /usr/lib/libXaw.so.7 #12 0xb7c612a2 in ?? () from /usr/lib/libXt.so.6 #13 0xb7c450f4 in XtDispatchEventToWidget () from /usr/lib/libXt.so.6 #14 0xb7c45aaf in ?? () from /usr/lib/libXt.so.6 #15 0xb7c44a67 in XtDispatchEvent () from /usr/lib/libXt.so.6 #16 0x08076319 in xevents () at ../misc.c:459 #17 0x08059edb in in_put (xw=0x80ca970) at ../charproc.c:3437 #18 0x08059f14 in doinput () at ../charproc.c:3452 #19 0x0805962d in VTparse (xw=0x80ca970) at ../charproc.c:3023 #20 0x0805d200 in VTRun (xw=0x80ca970) at ../charproc.c:4957 #21 0x0806f416 in main (argc=0, argv=0xb508) at ../main.c:2414 = Regards, Jan signature.asc Description: Digital signature
Bug#520095: removes the toplevel mountpoint directories and fails to start the next time
Hi Michael,
No idea. If I were knew, I'd attach a patch for this issue.
The code is quite.. funny and fragile, I tried to understand
it right before submitting a bugreport but that wasn't quite
successful.
I ran it under strace - pure automountd, without any startu
scripts but with the same args. It never ever tried to mkdir
or rename. It created two random dirs in /tmp, mounted a
tmpfs over one of them (running mount(8)), bind-mounted it
on second dir, next did stat(/misc) (which returned ENOENT)
and immediately gave up returning it can't mount /misc.
this is the strace log on my system after the spawned umount
process has terminated:
] 30451 --- SIGCHLD (Child exited) @ 0 (0) ---
] 30451 rmdir(/tmp/autoa1Aqlv) = 0
] 30451 rmdir(/tmp/autohY6Rkm) = 0
] 30451 rt_sigaction(SIGTERM, {0xb801dd70, [HUP USR1 USR2 ALRM TERM],
SA_RESTART}, NULL, 8) = 0
] 30451 rt_sigaction( several more )
] 30451 open(/etc/mtab, O_RDONLY) = 8
] 30451 fstat64(8, {st_mode=S_IFREG|0644, st_size=701, ...}) = 0
] 30451 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fe7000
] 30451 read(8, /dev/sda2 / ext3 rw,errors=remou..., 4096) = 701
] 30451 read(8, , 4096) = 0
] 30451 close(8) = 0
] 30451 munmap(0xb7fe7000, 4096) = 0
] 30451 stat64(/misc, 0xbfbca894) = -1 ENOENT (No such file or
directory)
] 30451 open(/etc/mtab, O_RDONLY) = 8
] 30451 fstat64(8, {st_mode=S_IFREG|0644, st_size=701, ...}) = 0
] 30451 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fe7000
] 30451 read(8, /dev/sda2 / ext3 rw,errors=remou..., 4096) = 701
] 30451 read(8, , 4096) = 0
] 30451 close(8) = 0
] 30451 munmap(0xb7fe7000, 4096) = 0
] 30451 statfs(/, {f_type=EXT2_SUPER_MAGIC, f_bsize=4096, f_blocks=9612195,
f_bfree=5459645, f_bavail=4971364, f_files=2444624, f_ffree=2142
] 30451 mkdir(/misc, 0555) = 0
] 30451 pipe([8, 11]) = 0
] 30451 pipe([12, 13])= 0
] 30451 rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
] 30451 pipe([14, 15])= 0
] 30451 clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7e7fb48)
= 30454
] [...] which calls:
] 30454 execve(/bin/mount, [/bin/mount, -t, autofs, -o,
fd=11,pgrp=30451,minproto=2,maxp..., automount(pid30451), /misc], [/* 44
vars */]) = 0
Maybe you can spot the difference that's causing your automountd to
give up - but I'd suggest switching to v5 anyway because upstream
development on v4 has ceased, and I'd like to drop v4 before Squeeze
is released.
Regards,
Jan
signature.asc
Description: Digital signature
Bug#539453: [P-a-s] Please exclude autofs{,5} from kfreebsd-*
Package: buildd.debian.org Severity: wishlist Tags: patch Hi, please mark the source packages autofs and autofs5 as Linux-specific. Both could theoretically be adjusted to build on other architectures, but the daemons are useless without the Linux autofs kernel module anyway. Best regards, Jan --- Packages-arch-specific.txt 2009-08-01 03:43:47.0 +0200 +++ Packages-arch-specific.txt_NEW 2009-08-01 04:02:41.0 +0200 @@ -37,6 +37,8 @@ atari-bootstrap: m68k # m68k specific atitvout: i386 # i386 specific %athcool: i386 kfreebsd-i386 # Athlon powersave util +%autofs: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 # Linux-specific +%autofs5: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 # Linux-specific autorun4linuxcd: i386 amd64 # MS Windows specific %avifile: i386 amd64 # i386 Win32 DLLs needed/executed %avrprog: amd64 i386 kfreebsd-amd64 kfreebsd-i386 hurd-i386 # inb/outb (ab)use signature.asc Description: Digital signature
Bug#527545: autofs5-ldap: kerberos update causes automount with GSSAPI authetication to segfault
Hi, Package: autofs5-ldap Version: 5.0.4-1 Severity: normal restarting automount gave a segfault (/var/log/syslog): sorry that it took a while until I had time to prepare a new version of the Debian package. Could you please confirm that the segfault problem persists with 5.0.4-2? I cannot reproduce it on my box. Regards, Jan signature.asc Description: Digital signature
Bug#471763: screen diverted by screen-profiles
Hi Stephane, in screen-profiles preinst : aah, thanks for the hint, I did not know that screen-profiles had entered Debian and was diverting the screen binary. I'll check back how soon the package will be replaced by byobu (cf. #531791) and whether it still makes sense to change the screen init script. Thanks! Jan signature.asc Description: Digital signature
Bug#531791: screen-profiles - byobu migration?
Hi Dustin, I had seen quite some time ago that the screen-profiles package had entered Ubuntu, but I had no idea that it had made it to Debian in the meantime and that it was diverting the binary. A notification would have been great, as I've responded to the increasing number of reports of permission problems with the same firm response check /usr/bin/screen, check /var/run/screen. That said, how far are your plans regarding dropping the diversion and moving to byobu? I don't want to make my initscript accommodate your diversion if it's gone three days later or so. ;) Regards, Jan signature.asc Description: Digital signature
Bug#496180: screen: hardstatus causes trouble after window resize
Hi Christoph, sorry this has been lying around for so long - I'm just catching up on all bug reports... Maximize the terminal. The size of screen does not change, only the area avaible before is used. Sadly it does change here and always did. Do you still see that behaviour with your terminal emulator/window manager combination(s)? Is there a certain one that looks especially promising to provoke the bug? Apparently a few SIGWINCH are lost on the way from the terminal down to the session... Regards, Jan signature.asc Description: Digital signature
Bug#471763: /var/run/screen permission weirdness
Hi, Sorry, I don't have an upgrade path. I only do the sporadic apt-get upgrade and an apt-get dist-upgrade once in a blue moon. Sometimes things don't work out and when I report that they just say upgrading from xxx to yyy is not supported even though I have no intention to nor would I have know that my apt-get upgrade would have resulted in something unsupported. well, as long as you don't do upgrades between versions that are more than a whole release apart (i.e. something pre-etch to something post-lenny), there should be no problem. Could you email me (without CCing the BTS, if you want) those lines of your /var/log/dpkg.log that pertain to screen package upgrades? Then I can try to reproduce that sequence and see whether the problem appears... Regards, Jan signature.asc Description: Digital signature
Bug#533866: I get similar message
Hi, but I gat a similar message: I've seen this happen for a couple of times now, yet there has never been a single reproducible test case. But because I still hope I might see one someday I don't want to swap those lines. I've already documented screen's requirements regarding the permissions of that directory to the top of README.Debian's QA section - there's nothing more I can do right now. Thanks for your report, Jan signature.asc Description: Digital signature
Bug#317450: Not to be picky but..
Hi, Not to be picky, but the label is unchanged on the 4.0.3-11 screen package (the latest in current Debian testing). have you tried to start screen in a small terminal (i.e. with 10 rows)? The bottom line reads Press Space for next page or Return to end then, and in this context it is clear that end means the end of the copyright preamble. I don't think this is too confusing. Regards, Jan signature.asc Description: Digital signature
Bug#471763: /var/run/screen permission weirdness
Hi. I'm still looking for an upgrade path that reproduces this bug. Up to 4.0.3-0.3 /var/run/screen was part of the package tarball (and mode 0775 root:utmp), then it got moved out of it and its creation postponed to the initscript (for volatile /var/run mounts) or postinst - also root:utmp and with permissions in accordance to the setid bits on the binary. It would be great if you could show me a way to see this happen myself. Until then I don't want to change the lines in the initscript and probably cover the bug. Regards, Jan signature.asc Description: Digital signature
Bug#520095: removes the toplevel mountpoint directories and fails to start the next time
Hi Michael, (the following holds for both autofs v4 and v5) usually the daemon creates these directories on startup and removes them on exit. If you do not want that to happen, it suffices to mark the directory as u-w: ] r...@apocatequil:/etc# grep ^/misc /etc/auto.master ] /misc /etc/auto.misc ] r...@apocatequil:/etc# ls -ld /misc ] ls: cannot access /misc: No such file or directory ] r...@apocatequil:/etc# /etc/init.d/autofs start ] Starting automount: done. ] r...@apocatequil:/etc# ls -ld /misc ] drwxr-xr-x 2 root root 0 2009-07-25 16:08 /misc ] r...@apocatequil:/etc# /etc/init.d/autofs stop ] Stopping automount: done. ] r...@apocatequil:/etc# ls -ld /misc ] ls: cannot access /misc: No such file or directory ] r...@apocatequil:/etc# mkdir /misc; chmod 0555 /misc ] r...@apocatequil:/etc# ls -ld /misc ] dr-xr-xr-x 2 root root 4096 2009-07-25 16:08 /misc ] r...@apocatequil:/etc# /etc/init.d/autofs start ] Starting automount: done. ] r...@apocatequil:/etc# ls -ld /misc ] drwxr-xr-x 2 root root 0 2009-07-25 16:08 /misc ] r...@apocatequil:/etc# /etc/init.d/autofs stop ] Stopping automount: done. ] r...@apocatequil:/etc# ls -ld /misc ] dr-xr-xr-x 2 root root 4096 2009-07-25 16:08 /misc ] r...@apocatequil:/etc# So I presume the real problem here is that autofs cannot create the /net mountpoint upon startup. This is not a very usual case, because the only possibility I can think of is a NFS root with root squashing enabled (but how can it remove that directory then when it's going down?)... I'm not sure if this justifies grave. But I admit that it's not in the documentation (at least nowhere I know of) and that the initscript startup exit code is not helpful. Regards, Jan signature.asc Description: Digital signature
Bug#520095: removes the toplevel mountpoint directories and fails to start the next time
Hi, As I mentioned before, the ONLY way to stop it from removing the top-level dir is to chattr+i it. ah, autofs4 indeed removes the directory even without write permission (v5 doesn't), I thought I'd checked that, too. But this behaviour has been around for ages, and I still don't understand why it fails for you (i.e. why is root unable to create /net, but perfectly able to remove it later?). Could you please explain what's going on there? Regards, Jan signature.asc Description: Digital signature
Bug#506499: autofs: bad key parseing (oh the horrors of our past have come back and bitten us)
Hi, automount[18849]: cache_ghost: entry in file:/etc/auto.direct not valid map format, key /... It appears that someone was trying sanity tests (disallow /. and /..), but didn't contemplate their being anything after /.. (like another ., or any other character)... Clearly, the length of the key must also be taken into consideration ! no, this is in fact a safety measure: from the README.direct of autofs v4: ] NOTE: Due to current design limitations, direct maps will take over an ] entire directory hierarchy. What this means is, if your direct map key ] is /usr/share/bilbo, then /usr will become an automount mount point, ] mounting over the existing /usr. And adding a direct autofs mountpoint '/...' would obscure everything else below '/', which is quite fatal. (The check that emits the above warning simply checks that there is a slash later on in the path.) I suggest moving on to autofs v5 which can handle direct mounts without obscuring the rest of the filesystem. Regards, Jan signature.asc Description: Digital signature
Bug#534732: nvi: expansion of numbered backups is incorrect
tags 534732 = confirmed thankyou Hi again, I can't reproduce that here with 1.81.6-7... ok, I take that back, it does indeed produce strange expansions sometimes. Will investigate. Regards, Jan signature.asc Description: Digital signature
Bug#534732: nvi: expansion of numbered backups is incorrect
Hi Jeffrey, The expansion of numbered backups is incorrect. The actual expansion that nvi produces is somewhat random. I get the weirdest results when editing from the linux console, logged in as root. The expansion of numbered backups used to work correctly with nvi 1.79 version. I can't reproduce that here with 1.81.6-7... ] j...@apocatequil:/tmp$ grep backup ~/.exrc ] set backup=N%..~ ] j...@apocatequil:/tmp$ echo abc x ] j...@apocatequil:/tmp$ ls -l x* ] -rw-r--r-- 1 jcn jcn 4 2009-06-26 21:41 x ] j...@apocatequil:/tmp$ nvi x +:wq ] x: 1 lines, 4 characters ] j...@apocatequil:/tmp$ ls -l x* ] -rw-r--r-- 1 jcn jcn 4 2009-06-26 21:41 x ] -rw--- 1 jcn jcn 4 2009-06-26 21:41 x..~1 ] j...@apocatequil:/tmp$ Could you tell me if the problem persists with the latest version and whether there's anything special with your system? Regards, Jan signature.asc Description: Digital signature
Bug#453348: SSL client certificate support
Hi Emmanuel, It would be nice if you could attach your patch to this bug report even if it is not fully functionnal. It could help upstream developers to add this feature more quickly. ah, I see there has been another 0.2.6 release. I thought that branch would die soon now that 0.3 development is underway... if you think it's still worthwhile to create that functionality for 0.2.*, I'll dig it up again and shape it up. Regards, Jan signature.asc Description: Digital signature
Bug#453348: SSL client certificate support
Hi,
i think that the code you produced for 0.2.x branch could helped to
add this feature in one of the next release.
ah ok, I believed 0.3 was written (almost) from scratch, so I wasn't sure
whether there would be any benefit. I've attached my patch, but there are
a few remarks:
* The gnutls init code is in weechat_init_vars(), where the config dir has
probably not even been created. The certificate and key files ('x509.crt'
and 'x509.key') are therefore opened in the current directory (just like
the 'ca.pem' file already is).
* There is no support for passphrase-protected key files.
* I've already created the patch to use the certificate callback function
so weechat could react to the offered algorithms and list of trusted
CAs; it currently doesn't use that list, though, only one certificate
is loaded and offered to all servers alike.
Regards,
Jan
SSL client certificate support for weechat. Very rudimentary and
currently not configurable, just a proof of concept. Nevertheless
it plays together nicely with OFTC Nickserv.
--- weechat-0.2.6.3.orig/src/irc/irc-server.c 2009-05-12 18:22:25.0
+0200
+++ weechat-0.2.6.3/src/irc/irc-server.c2009-06-15 01:52:18.486255908
+0200
@@ -39,7 +39,8 @@
#include netdb.h
#ifdef HAVE_GNUTLS
#include gnutls/gnutls.h
+#include gnutls/x509.h
#endif
#include ../common/weechat.h
@@ -1881,6 +1882,18 @@
#ifdef HAVE_GNUTLS
if (server-ssl)
{
+if (gnutls_xcred_cert_retr_st.ncerts == 1)
+{
+char certdn[1024];
+size_t certlen = 1024;
+
(void)gnutls_x509_crt_get_dn(gnutls_xcred_cert_retr_st.cert.x509[0], certdn,
certlen);
+gui_printf (NULL, Using SSL client certificate %s%.*s%s.\n,
+GUI_COLOR(GUI_COLOR_WIN_CHAT_NICK),
+(1024certlen)?1024:certlen, certdn,
+GUI_COLOR(GUI_COLOR_WIN_CHAT_SERVER)
+ );
+}
+
if (gnutls_init (server-gnutls_sess, GNUTLS_CLIENT) != 0)
{
irc_display_prefix (server, server-buffer, GUI_PREFIX_ERROR);
only in patch2:
unchanged:
--- weechat-0.2.6.3.orig/src/common/weechat.c
+++ weechat-0.2.6.3/src/common/weechat.c
@@ -42,12 +42,15 @@
#include stdlib.h
#include stdio.h
#include string.h
+#include unistd.h
+#include fcntl.h
#include sys/stat.h
#include time.h
#include signal.h
#ifdef HAVE_GNUTLS
#include gnutls/gnutls.h
+#include gnutls/x509.h
#endif
#ifdef HAVE_LANGINFO_CODESET
@@ -87,7 +90,13 @@
int auto_load_plugins;/* enabled by default (cmd option to disable) */
#ifdef HAVE_GNUTLS
-gnutls_certificate_credentials gnutls_xcred; /* gnutls client credentials */
+gnutls_certificate_credentials gnutls_xcred; /* gnutls client credentials */
+
+gnutls_retr_st gnutls_xcred_cert_retr_st; /** structure
and callback prototype */
+gnutls_x509_crt_t gnutls_xcred_certificate; /* for client
certificate support **/
+gnutls_x509_privkey_t gnutls_xcred_certificate_key;
+
+int weechat_provide_gnutls_certificates(gnutls_session_t, const gnutls_datum_t
*, int, const gnutls_pk_algorithm_t *, int, gnutls_retr_st *);
#endif
@@ -573,9 +582,90 @@
gnutls_global_init ();
gnutls_certificate_allocate_credentials (gnutls_xcred);
gnutls_certificate_set_x509_trust_file (gnutls_xcred, ca.pem,
GNUTLS_X509_FMT_PEM);
+gnutls_xcred_cert_retr_st.ncerts = 0;
+
+do {
+ gnutls_datum_t filedatum;
+ struct stat filestat;
+ char *filebuffer;
+ off_t fileread;
+ int filefd;
+
+ filefd = open(x509.crt, O_RDONLY);
+ if (filefd 0) break;
+ if (fstat(filefd, filestat) 0 || ((filebuffer =
malloc(filestat.st_size)) == NULL) ) {
+close(filefd);
+break;
+ }
+ fileread = 0;
+ while (fileread filestat.st_size) {
+ssize_t R = read(filefd, filebuffer+fileread,
filestat.st_size-fileread);
+if (R 0) {
+ free(filebuffer); close(filefd);
+ break;
+}
+fileread += R;
+ }
+ close(filefd);
+ filedatum.data = (unsigned char *)filebuffer;
+ filedatum.size = filestat.st_size;
+ gnutls_x509_crt_init(gnutls_xcred_certificate);
+ gnutls_x509_crt_import(gnutls_xcred_certificate, filedatum,
GNUTLS_X509_FMT_PEM);
+ free(filebuffer);
+
+ filefd = open(x509.key, O_RDONLY);
+ if (filefd 0) break;
+ if (fstat(filefd, filestat) 0 || ((filebuffer =
malloc(filestat.st_size)) == NULL) ) {
+close(filefd);
+break;
+ }
+ fileread = 0;
+ while (fileread filestat.st_size) {
+ssize_t R = read(filefd, filebuffer+fileread,
filestat.st_size-fileread);
+if (R 0) {
+ free(filebuffer); close(filefd);
+ break;
+}
+fileread += R;
+ }
+ close(filefd);
+ filedatum.data = (unsigned char *)filebuffer;
+ filedatum.size = filestat.st_size;
Bug#527952: system-tools-backends: CVE-2008-6792 limiting effective password length to 8 characters
Hi,
NMU is about to hit unstable and s-p-u. I've added the attached
patch to the quilt series.
Regards,
Jan
Add fix for CVE 2008-6792 and another related bug in do_get_use_md5().
-- James Westby james.wes...@canonical.com
-- Jan Christoph Nordholz he...@pool.math.tu-berlin.de
--- system-tools-backends-2.6.0.orig/Users/Users.pm 2008-03-09 13:21:45.0 +
+++ system-tools-backends-2.6.0/Users/Users.pm 2009-05-18 15:41:15.246049271 +
@@ -286,13 +286,14 @@
if ($line[0] eq \...@include)
{
- $use_md5 = do_get_use_md5 ($line[1]);
+ $use_md5 |= do_get_use_md5 ($line[1]);
}
elsif ($line[0] eq password)
{
foreach $i (@line)
{
$use_md5 = 1 if ($i eq md5);
+$use_md5 = 1 if ($i =~ /^sha\d+/);
}
}
}
signature.asc
Description: Digital signature
Bug#527997: nmap: links against embedded copy of liblua
Hi, Thanks Jan. Our current svn does not have an nselibs-bin directory anyway. I've applied your patch to our configure.ac and regenerated configure in our latest SVN. All the better. SVN checkout works great here, too, system lua5.1 is detected and linked into nmap instead of the internal copy. Thanks for including this upstream! Jan signature.asc Description: Digital signature
Bug#527997: nmap: links against embedded copy of liblua
Hi, Thanks Jan. But if you get a chance, I'd love to see a patch which checks for both the plain lua and lua5.1 versions. That way it would still work on platforms which just use plain lua and so it would be appropriate for upstream integration. If we add it to an Nmap release, Debian doesn't have to worry about maintaining their own custom patch. Would you write a patch in which configure checks for lua first and then falls back on lua5.1 if that fails? Or, I suppose, the other order would probably be fine too. the patch to the configure.ac files is no problem - I'm having trouble however to get the autotools to cooperate. Rerunning autoconf alone in nselib-bin/ fails (read as: produces lots of scary warnings), and if I run aclocal autoconf, the generated libtool fails at the build stage. Bugs like #527503 suggest that I'm not alone with this problem; I'm afraid I can't do more than to give you my .ac patch. The configure scripts run fine (including the lua5.1/lua fallback), it just doesn't build until someone figures out what's wrong with libtool. Regards, Jan --- nmap-4.68.orig/configure.ac 2008-06-15 09:05:12.0 +0200 +++ nmap-4.68/configure.ac 2009-05-15 17:48:25.986698422 +0200 @@ -538,8 +538,10 @@ # If they didn't specify it, we try to find it if test $have_lua != yes; then -AC_CHECK_HEADERS(lua.h lua/lua.h, - AC_CHECK_LIB(lua, lua_call, [have_lua=yes; break],, [-lm])) +AC_CHECK_HEADERS([lua.h lua/lua.h lua5.1/lua.h], + AC_CHECK_LIB(lua, lua_call, [have_lua=yes; LIBLUA_LIBS=-llua; CPPFLAGS=-I/usr/include/lua $CPPFLAGS; break],, [-lm]) + AC_CHECK_LIB(lua5.1, lua_call, [have_lua=yes; LIBLUA_LIBS=-llua5.1; CPPFLAGS=-I/usr/include/lua5.1 $CPPFLAGS; break],, [-lm]) +) AC_LANG_PUSH(C++) AC_MSG_CHECKING([for lua version = 501]) @@ -549,7 +551,6 @@ have_lua=yes, have_lua=no) AC_LANG_POP(C++) -LIBLUA_LIBS=-llua LUA_DEPENDS= LUA_BUILD= LUA_CLEAN= --- nmap-4.68.orig/nselib-bin/configure.ac 2009-05-15 17:55:47.834731766 +0200 +++ nmap-4.68/nselib-bin/configure.ac 2009-05-15 17:57:13.034698515 +0200 @@ -15,7 +15,16 @@ AC_CANONICAL_HOST # needed for lua-includes -AC_CHECK_HEADER([lua.h],,[AC_MSG_NOTICE(using lua-includefiles provided with nmap);[LUAINCLUDE=-I../liblua/]],) +have_lua_headers=no +AC_CHECK_HEADERS([lua.h lua/lua.h lua5.1/lua.h],[have_lua_headers=yes],,) + +if test $have_lua_headers = no; then + AC_MSG_NOTICE(using lua-includefiles provided with nmap) + LUAINCLUDE=-I../liblua/ +else + LUAINCLUDE=-I/usr/include/lua -I/usr/include/lua5.1 +fi + AC_SUBST(LUAINCLUDE) AC_CONFIG_FILES([Makefile]) signature.asc Description: Digital signature
Bug#528639: wpasupplicant: buffer overflow in _wpa_hexdump
Package: wpasupplicant Version: 0.6.9-2 Severity: important Tags: security Hi, your syslog patch changes _wpa_hexdump() to create the debug string in a local buffer on the stack before emitting it - however you boldly assume that 2048B should be enough for everyone. When connecting to a WPA-EAP network here, my network card receives a 1028B packet during the handshake, which *easily* exceeds the 2048B for the hexdump string and smashes the stack. Maybe you should take the input length into account? Regards, Jan signature.asc Description: Digital signature
Bug#527997: nmap: links against embedded copy of liblua
tags 527997 = patch thankyou I might as well attach the appropriate patch... (autoconf is called from the upstream Makefile, which makes the build process a bit cumbersome now that we're patching configure.ac - you might choose to patch configure itself instead, or call autoconf early in the build process yourself) Regards, Jan diff -Naur nmap-4.68/configure.ac nmap-4.68_MOD/configure.ac --- nmap-4.68/configure.ac 2008-06-15 09:05:12.0 +0200 +++ nmap-4.68_MOD/configure.ac 2009-05-12 07:46:33.0 +0200 @@ -549,7 +549,7 @@ have_lua=yes, have_lua=no) AC_LANG_POP(C++) -LIBLUA_LIBS=-llua +LIBLUA_LIBS=-llua5.1 LUA_DEPENDS= LUA_BUILD= LUA_CLEAN= diff -Naur nmap-4.68/debian/rules nmap-4.68_MOD/debian/rules --- nmap-4.68/debian/rules 2009-05-12 07:50:58.0 +0200 +++ nmap-4.68_MOD/debian/rules 2009-05-12 07:41:04.0 +0200 @@ -31,7 +31,7 @@ cd libpcap ln -sf ../config.sub ../config.guess . cd nbase ln -sf ../config.sub ../config.guess . cd nsock/src ln -sf ../../config.sub ../../config.guess . - CXXFLAGS=$(CXXFLAGS) CFLAGS=$(CFLAGS) ./configure $(CONFIGURE_FLAGS) + CXXFLAGS=$(CXXFLAGS) CFLAGS=$(CFLAGS) CPPFLAGS=-I/usr/include/lua5.1 ./configure $(CONFIGURE_FLAGS) touch configure-stamp build: configure build-stamp diff -Naur nmap-4.68/nselib-bin/Makefile.in nmap-4.68_MOD/nselib-bin/Makefile.in --- nmap-4.68/nselib-bin/Makefile.in 2007-11-28 00:13:53.0 +0100 +++ nmap-4.68_MOD/nselib-bin/Makefile.in 2009-05-12 07:54:08.0 +0200 @@ -2,6 +2,8 @@ CC = @CC@ CXX = @CXX@ +CPPFLAGS = @CPPFLAGS@ +CFLAGS = @CFLAGS@ CCOPT = DBGFLAGS = @@ -15,7 +17,7 @@ all: bit.so bit.so: bit.c @LIBTOOL_DEPS@ - $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) @LUAINCLUDE@ $(CFLAGS) -c bit.c + $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) @LUAINCLUDE@ $(CFLAGS) $(CPPFLAGS) -c bit.c $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) -avoid-version -module -rpath /usr/local/lib -o bit.la bit.lo mv .libs/bit.so bit.so signature.asc Description: Digital signature
Bug#527997: nmap: links against embedded copy of liblua
Package: nmap Severity: important Hi, nmap has an internal copy of liblua and uses it instead of the system library because the configure script fails to detect the header files: } (package build log) ] checking lua.h usability... no ] checking lua.h presence... no ] checking for lua.h... no ] checking lua/lua.h usability... no ] checking lua/lua.h presence... no ] checking for lua/lua.h... no ] checking for lua version = 501... no } dpkg -L liblua5.1-0-dev | grep include.lua ] /usr/include/lua5.1 ] /usr/include/lua5.1/luaconf.h ] /usr/include/lua5.1/lua.h ] /usr/include/lua5.1/lauxlib.h ] /usr/include/lua5.1/lualib.h ] /usr/include/lua5.1/lua.hpp Regards, Jan signature.asc Description: Digital signature
Bug#527952: system-tools-backends: CVE-2008-6792
Hi, while you're at it, there is another bug in that small perl function: do_get_use_md5() recurses when it encounters an '@include' line and overwrites its $use_md5 variable with the result. Therefore the following /etc/pam.d/passwd would make the function return 0: requiredpam_unix.so md5 @includeempty_file Regards, Jan signature.asc Description: Digital signature
Bug#526160: ksh: FTBFS on kfreebsd-i386
tags 526160 + patch
thankyou
Hi,
ksh is failing because libc0.1-dev does not provide TAB{0,1,2,3}, but
only TAB{0,3} (= bits/termios.h). As this seems to be intentional (see
http://www.freshports.org/sysutils/coreutils/ for the corresponding
changes to the BSD coreutils), ksh should probably just play along
and make the two lines in src/lib/libcmd/stty.c dependent on the
presence of those two macros. I'd suggest applying the attached patch.
With it ksh builds fine again.
Regards,
Jan
--- ksh-93s+20080202/src/lib/libcmd/stty.c.orig 2007-11-27 22:54:41.0 +0100
+++ ksh-93s+20080202/src/lib/libcmd/stty.c 2009-04-29 19:11:16.0 +0200
@@ -315,8 +315,12 @@
#ifdef TABDLY
{ tabs, TABS, O_FLAG, IG, TABDLY, TAB3, C(Preserve (expand to spaces) tabs) },
{ tab0, BITS, O_FLAG, IG|SS, TABDLY, TAB0 },
+# ifdef TAB1
{ tab1, BITS, O_FLAG, US, TABDLY, TAB1 },
+# endif
+# ifdef TAB2
{ tab2, BITS, O_FLAG, US, TABDLY, TAB2 },
+# endif
{ tab3, BITS, O_FLAG, US, TABDLY, TAB3 },
#endif
#ifdef BSDLY
signature.asc
Description: Digital signature
Bug#522693: ksh: job control broken on kfreebsd
Hi, this was a bug in libc0.1-dev, not in ksh itself, cf. #522686. ksh simply needs to be rebuilt on kfreebsd-*. Regards, Jan signature.asc Description: Digital signature
Bug#524211: gkrellweather: build cleanup
tags 524211 + patch thankyou Hi, attached is a patch that fixes the /usr/local problem and also adjusts the build dependencies (libxaw7 is not necessary at all, and libglib1.2-dev should be replaced by libglib2.0-dev). A debhelper upgrade might be in order, too, but I didn't want to be too invasive. ;) Regards, Jan diff -u gkrellweather-2.0.8/debian/control gkrellweather-2.0.8/debian/control --- gkrellweather-2.0.8/debian/control +++ gkrellweather-2.0.8/debian/control @@ -1,7 +1,7 @@ Source: gkrellweather Section: x11 Priority: optional -Build-Depends: debhelper (= 4), gkrellm (= 2.1.4), libglib1.2-dev, libgtk2.0-dev, libxaw7-dev, libxaw7-dev +Build-Depends: debhelper (= 4), gkrellm (= 2.1.4), libglib2.0-dev, libgtk2.0-dev Maintainer: Norbert Veber nve...@debian.org Standards-Version: 3.8.0 diff -u gkrellweather-2.0.8/debian/rules gkrellweather-2.0.8/debian/rules --- gkrellweather-2.0.8/debian/rules +++ gkrellweather-2.0.8/debian/rules @@ -7,7 +7,7 @@ build-stamp: dh_testdir - $(MAKE) + $(MAKE) PREFIX= touch build-stamp clean: signature.asc Description: Digital signature
Bug#522686: bash: job control broken on kfreebsd-i386 and kfreebsd-amd64
reassign 522686 libc0.1-dev retitle 522686 [kfreebsd-*] bits/waitstatus.h __WIFCONTINUED userland definition doesn't match kernel kthxbye Hi, job control in bash is broken because jobs.c:waitchld() expects the Linux __WIFCONTINUED response (status == 0x) and erroneously assumes the job to be dead when BSD reports status == 0x13, i.e. BSD SIGCONT. Cf. FreeBSD kernel 7.1, sys/wait.h: ] #define _WSTATUS(x) (_W_INT(x) 0177) ] #define _WSTOPPED 0177/* _WSTATUS if process is stopped */ ] #define WIFSTOPPED(x) (_WSTATUS(x) == _WSTOPPED) ] #define WSTOPSIG(x) (_W_INT(x) 8) ] #define WIFSIGNALED(x) (_WSTATUS(x) != _WSTOPPED _WSTATUS(x) != 0) ] #define WTERMSIG(x) (_WSTATUS(x)) ] #define WIFEXITED(x)(_WSTATUS(x) == 0) ] #define WEXITSTATUS(x) (_W_INT(x) 8) ] #define WIFCONTINUED(x) (x == 0x13) /* 0x13 == SIGCONT */ ^^^ This should be fixed in libc0.1-dev's bits/waitstatus.h. To get a working bash in the meantime, you can apply the attached patch to the current bash4 source package. (Will probably work with minor modifications for bash3, too.) Regards, Jan diff -u bash-4.0/debian/rules bash-4.0/debian/rules --- bash-4.0/debian/rules +++ bash-4.0/debian/rules @@ -566,6 +566,7 @@ exec-redirections-man \ bash-aliases-repeat \ CVE-2008-5374 \ + jobcontrol ifeq ($(with_gfdl),yes) debian_patches += \ only in patch2: unchanged: --- bash-4.0.orig/debian/patches/jobcontrol.dpatch +++ bash-4.0/debian/patches/jobcontrol.dpatch @@ -0,0 +1,33 @@ +#! /bin/sh -e + +if [ $# -eq 3 -a $2 = '-d' ]; then +pdir=-d $3 +elif [ $# -ne 1 ]; then +echo 2 `basename $0`: script expects -patch|-unpatch as argument +exit 1 +fi +case $1 in +-patch) patch $pdir -f --no-backup-if-mismatch -p0 $0;; +-unpatch) patch $pdir -f --no-backup-if-mismatch -R -p0 $0;; +*) + echo 2 `basename $0`: script expects -patch|-unpatch as argument + exit 1 +esac +exit 0 + +# DP: fix jobcontrol until the WIFCONTINUED macro is fixed in libc0.1-dev +# DP: Jan Christoph Nordholz he...@pool.math.tu-berlin.de 2009-04-13 + +--- jobs.c.orig2009-01-29 23:09:49.0 +0100 jobs.c 2009-04-13 01:55:54.019583928 +0200 +@@ -134,6 +134,10 @@ + #if !defined (WIFCONTINUED) + # define WIFCONTINUED(s) (0) + #endif ++#if defined(__FreeBSD_kernel__) ++# undef WIFCONTINUED ++# define WIFCONTINUED(status) (WTERMSIG(status) == SIGCONT) ++#endif + + /* The number of additional slots to allocate when we run out. */ + #define JOB_SLOTS 8 signature.asc Description: Digital signature
Bug#522689: screen: doesn't pass signals to programs running inside screen on kfreebsd
Hi Axel, screen on kfreebsd-i386 and kfreebsd-amd64 doesn't seem to pass any signals (at least STOP, INT and WINCH) to text applications or shells running inside that screen. thanks for bringing the kfreebsd port to my attention. The buildd log looks a bit suspicious, too. I'll debug this, but I don't have any leftover hardware for it so I'll have to install and configure a kfreebsd VM, which might take me a few days. Regards, Jan signature.asc Description: Digital signature
Bug#522689: screen: doesn't pass signals to programs running inside screen on kfreebsd
Hi Axel, There are DD accessible kfreebsd machines: I'm well aware of that. But I don't have that status (yet). ;) If you happen to know of other kfreebsd machines where I could get temporary access, that would be great - otherwise I'll just get that VM running, might come in handy to have one anyway. Regards, Jan signature.asc Description: Digital signature
Bug#474128: O: libdumbnet -- A dumb, portable networking library
retitle 474128 ITA: libdumbnet -- A dumb, portable networking library owner 474128 ! kthxbye Hi, I'll take this one. Upstream's build system is quite straightforward (once you've updated all those ancient autotools files), and getting C networking code into shape is one of my favourite tasks anyway. Package is already finished and waiting to be uploaded. Jan signature.asc Description: Digital signature
Bug#516222: RFS: libnet - orphaning libnet
Hi Stefanos, if you need help, I could lend a hand now and then. I don't have the time to maintain the package on my own, but I have a faible for old and/or undocumented C code and some experience in delving through networking code in particular, so I could e.g. help hunting bugs. Regards, Jan signature.asc Description: Digital signature
Bug#407667: dhclient not requesting ntp-servers by default
unarchive 407667 reopen 407667 ! found 407667 3.0.5-2 kthxbye Hi, when you brought the request list back in 3.0.5-2's debian/dhclient.conf, the 'ntp-servers' parameter was again missing in it and still is. Would you please add it to the list? Thanks, Jan signature.asc Description: Digital signature
Bug#398752: nvi and the virtual package editor
tags 398752 + wontfix close 399913 kthxbye Hi, as there's been no activity at all and as I'm on final consideration joining Steve's opinion, I'm tagging my bug wontfix and closing the corresponding policy bug again. Sorry for the noise, guys. Regards, Jan signature.asc Description: Digital signature
Bug#319268: insecure
Hi Kevin, For anybody who falls on this bug, PHP MUST BE disabled where hypermail outputs its files, or i guess someone can hack you by sending php files to the list and you will host those backdoors..! how is this going to work? The first line that hypermail writes contains ?xml, and if 'short_tags = On', the PHP interpreter will already die here. If 'short_tags = Off', PHP will simply copy this line to its output and continue. But as all special characters in the mail are escaped, how could an attacker insert a string like '?php' to execute code? Regards, Jan signature.asc Description: Digital signature
Bug#520317: /var/run/screen requires mode 777
Hi, ls -las /usr/bin/screen 328 -rwxr-sr-x 1 root utmp 328448 Mar 6 16:36 /usr/bin/screen ok, then there are a couple of other reasons why this could be the case. I've just added a new QA pair to the upcoming version because there's often confusion about this: Q: screen always complains about the permissions of /var/run/screen. What's wrong? A: Simplified, the binary ensures that $SCREENDIR has just enough permission bits enabled so that each user can create and access his socket directory. This means: /usr/bin/screen setuid root - /var/run/screen 0755 /usr/bin/screen setgid utmp - /var/run/screen 0775 /usr/bin/screen without setid bits - /var/run/screen 0777 These cases are all handled by the init script. However, the actual test is a bit more complicated. And as the variable names are all quite self- explanatory, just have a look at the C code itself: ] n = (eff_uid == 0 (real_uid || (st.st_mode 0775) != 0775)) ? 0755 : ] (eff_gid == (int)st.st_gid eff_gid != real_gid) ? 0775 : ] 0777; ] if (((int)st.st_mode 0777) != n) ] Panic(0, Directory '%s' must have mode %03o., SockDir, n); If the invoking user has primary group utmp, the above assumption will fail. The same holds if the underlying file system is mounted 'nosuid'. In these cases you have to adapt the init script yourself. Regards, Jan signature.asc Description: Digital signature
Bug#520317: /var/run/screen requires mode 777
Hi Brian, when I first start screen after the system boots, it refuses to start, with a message that /var/run/screen must have permissoins 777. I chmod it, and it runs. I guess you removed all setid bits from /usr/bin/screen? The expected mode of /var/run/screen depends on the setid bits of the binary. I admit that the screen-cleanup init script doesn't handle this case yet - I'll add a stanza in the next version. Regards, Jan signature.asc Description: Digital signature
Bug#520359: screen: fixes from ubuntu: file-not-found-warning, invoke-with-command, winmsg-color-limit
Hi Dustin,
thanks for the patches. I'm not satisfied with the fix for #323756 though:
It would suppress all errors of the 'source' command, even if a user expli-
citly does {^A:source nonexistent} - and I'd expect that to display a flashy
warning message if the file isn't there.
Regards,
Jan
signature.asc
Description: Digital signature
Bug#518245: please remove /etc/modprobe.d/mt-st
severity 518245 minor tags 518245 + pending thankyou Hi Marco, /etc/modprobe.d/mt-st should be removed because it duplicates the functionality of the udev rules but at an higher cost. I'm not very fond of this idea for several reasons: * We're talking about 36 files in /etc/modprobe.d/ installed by 28 packages, according to apt-file. After the first request their contents are cached by the kernel anyway, so the performance impact should be negligible even if modprobe is called a hundred times during bootup. I've read #517954, and I'm getting these warnings myself, but the delay is way below one second here. And did anyone notice a considerable delay at all before the warnings appeared? * Not installing udev (or installing, but disabling it) is still a viable way to run a Debian system. Last time I checked, X ran fine with a static /dev even though it depends on hal (and thus udev) nowadays. * As from my personal experience mt-st is mostly installed on headless servers somewhere in a rack, the use cases of udev and mt-st couldn't be more contrary. Or is there a plan to make udev strictly mandatory in the future? Please also read http://blog.bofh.it/debian/id_236 for a detailed rationale about this request. Thanks, done. Suffix added, upload on the way. Regards, Jan signature.asc Description: Digital signature
Bug#496305: nvi cannot handle characters with the top bit set
tags 496305 + pending thanks Hi, When I edit /var/lib/dpkg/status using nvi and then search for a string (or page down a few times), I get: Conversion error on line 428 I then can't 428G, but 427G reveals: nvi with USE_WIDECHAR enabled is just being strict: US-ASCII is a 7-bit charset, so any characters with the 8th bit set cannot be meaningfully interpreted. I've written a small patch that restores the old, pre-WIDECHAR nvi behaviour of displaying those characters as hex codes, because (even if it's technically speaking not nvi's fault) writing truncated files is bad. Regards, Jan signature.asc Description: Digital signature
Bug#518289: Using bash-completion makes shell crash
tag 518289 + patch kthxbye Hi, I guess this has already been fixed upstream, but for the impatient: gen_shell_function_matches() is trying to restore a parser state that has never been saved. My fix is simple and pragmatic as I don't have any in-depth knowledge regarding whether it's necessary to save the parser state in that place at all... but bash4 works with it, so here goes. Regards, Jan diff -u bash-4.0/debian/rules bash-4.0/debian/rules --- bash-4.0/debian/rules +++ bash-4.0/debian/rules @@ -555,6 +555,7 @@ input-err \ exec-redirections-man \ bash-aliases-repeat \ + tentative-4.0parserstate ifeq ($(with_gfdl),yes) debian_patches += \ only in patch2: unchanged: --- bash-4.0.orig/debian/patches/tentative-4.0parserstate.dpatch +++ bash-4.0/debian/patches/tentative-4.0parserstate.dpatch @@ -0,0 +1,29 @@ +#! /bin/sh -e + +if [ $# -eq 3 -a $2 = '-d' ]; then +pdir=-d $3 +elif [ $# -ne 1 ]; then +echo 2 `basename $0`: script expects -patch|-unpatch as argument +exit 1 +fi +case $1 in +-patch) patch $pdir -f --no-backup-if-mismatch -p1 $0;; +-unpatch) patch $pdir -f --no-backup-if-mismatch -R -p1 $0;; +*) + echo 2 `basename $0`: script expects -patch|-unpatch as argument + exit 1 +esac +exit 0 + +# DP: Save the parser state so it can later be restored. Heh. + +--- bash-4.0/pcomplete.c 2009-02-01 23:12:31.0 +0100 bash-4.0/pcomplete.cM 2009-03-09 23:04:33.295242137 +0100 +@@ -1032,6 +1032,7 @@ + cmdlist = build_arg_list (funcname, text, lwords, cw); + + pps = ps; ++ save_parser_state(pps); + begin_unwind_frame (gen-shell-function-matches); + add_unwind_protect (restore_parser_state, (char *)pps); + add_unwind_protect (dispose_words, (char *)cmdlist); signature.asc Description: Digital signature
Bug#518397: Broken ^A (search word) handling
tags 518397 + pending thanks Hi Al, ^A handling is broken; it doesn't generate [[::]] in the end of resulting pattern, so e.g. after thanks for your detailed report! I've simplified your patch a little (there's a widechar-aware STRLEN macro available, and re_compile null-terminates its expressions on its own), but apart from that I've applied it as-is. Regards, Jan signature.asc Description: Digital signature
Bug#491812: Can not use terminfo-entry screen-256color-bce-s
Hi Steve, The following patch makes this use permissible: I'm reluctant to apply this patch as-is because the value 20 is hardcoded for $TERM-related buffers all over the place, and I'd rather double-check these things than simply inflate it at one single spot. I'll hurry to get things done, thanks for the patch suggestion nevertheless. Regards, Jan signature.asc Description: Digital signature
Bug#502490: No ncurses (?) support in screen sessions
Hi, I fail to start aptitude and also Midnight Commander (mc) from inside a screen session. Whenever I start screen -U and in it mc or aptitude I just get a blank screen, no color, no text, nothing (but the cursor is repositioned). I cannot even interrupt mc via Ctrl+C (works with aptitude). I cannot reproduce this bug (neither Lenny nor sid/experimental, neither with 'altscreen on' nor without). Is one of you still able to reproduce this behaviour? Without a reliable testcase I'm afraid I can't do much. It doesn't sound like a ncurses problem to me, the altscreen suggestion seems more likely. What terminal emulators are you running screen in (resp. have you been running when you encountered the bug)? Regards, Jan signature.asc Description: Digital signature
Bug#471763: /var/run/screens permissions inconsistency causes screen to refuse to start up
Hi, Changing the group to utmp is what the screen-cleanup script does indeed, but only when there was no /var/run/screen before (line 25 of /etc/init.d/screen-cleanup). Maybe it should be inforced generally by swapping lines 25 and 26? Reproduced on the freshly stable lenny. this puzzles me. Could you please check that * dpkg -S reports no owner for /var/run/screen and * /var/run/screen is correctly removed upon dpkg -P and reinstated with the correct (group) ownership after dpkg -i? Freshly stable means installed Lenny from scratch? That would mean that the directory was created before the screen package was even touched. - I've just verified that debootstrapping a Lenny and chrooting into it to install screen yields the correct ownership. Regards, Jan signature.asc Description: Digital signature
Bug#502293: Bugreport Package: Screen
Hi Rene, package: screen version: 4.00.03 (FAU) 23-Oct-06 which Debian version are you reporting this bug against? command: screen $pid -X hardcopy $filename Hm, doesn't fail here: ] j...@apocatequil:~$ screen -dmS test ] j...@apocatequil:~$ screen -ls ] There is a screen on: ] 8342.test (02/26/2009 01:27:32 AM)(Detached) ] 1 Socket in /var/run/screen/S-jcn. ] ] j...@apocatequil:~$ screen -X hardcopy /tmp/x1 ] j...@apocatequil:~$ screen -ls ] There is a screen on: ] 8342.test (02/26/2009 01:27:31 AM)(Detached) ] 1 Socket in /var/run/screen/S-jcn. ] ] j...@apocatequil:~$ ll /tmp/ ] -rw-r--r-- 1 jcn jcn 0 2009-02-26 01:27 x1 Did I make any mistakes? Regards, Jan signature.asc Description: Digital signature
Bug#509361: invalid SHELL variable in screen sessions
Hi, Some things fails to run in a screen session: $ sg floppy Cannot execute bash: No such file or directory $ echo $SHELL bash I don't believe this is a bug in screen. Are you sure all your startup files behave as they are meant to (both for login- and non-login shells: .profile, .bashrc, global /etc/bash.bashrc, /etc/profile, additional settings from your .screenrc)? I cannot reproduce this, $SHELL is set correctly here. Could you verify the bug is still there with a newly-created user? Regards, Jan signature.asc Description: Digital signature
Bug#507817: screen -r still sometimes fails with WriteMessage: Bad file descriptor
Hi, sorry it took me so long to get back to you. I still sometimes get the error WriteMessage: Bad file descriptor when running screen -r with 4.0.3-11. This is obviously related to #477739, however the conditions seem somewhat different so I decided to open a different bug. Hm. I haven't seen this bug for quite some time now, so any further material (gdb dumps, strace logs) is highly appreciated. I'll have a look at the code and check whether I've missed another race condition (or failed to properly fix the one from #477739). Thanks! Jan signature.asc Description: Digital signature
Bug#515803: screen: Add debian/control::Homepage header
tags 515803 + pending thankyou Hi, I've already done so, but the upload is still pending. Freshmeat is not the real homepage, though, I'd rather list www.gnu.org. Regards, Jan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497349: nvi Increment Command (#) Erases to End of Line
tags 497349 + pending upstream thankyou Hi, Withing nvi, placing the cursor over a number and pressing the # plus #, +, or - should increment or decrement that number, but now it erases everything from the cursor to the end of the line. yep, you're right - the v_increment command is not widechar-capable and messes up the line. This is an upstream bug, but I've created a fix myself in the meantime. Thanks for reporting! Jan signature.asc Description: Digital signature
Bug#497342: nvi No Longer Opens Files with O_NONBLOCK, Causing XTXTBSY Errors
Hi David, Performing the following steps on the Debian nvi packages 1.79-26 and 1.81.6-3 produces different results. that's strange - I can reproduce it with both versions here. Note however that the behaviour is different if the file in question was not executable when the editor opened it (e.g. if it didn't exist yet). I'm not quite sure why that is, but I'd call it a stdlib glitch, because the documentation is quite clear on this topic... From open(2): ] ETXTBSY ] pathname refers to an executable image which is currently ] being executed and write access was requested. And this works the other way round, too - from execve(2): ] ETXTBSY ] Executable was open for writing by one or more processes. I.e., as long as nvi has the file itself open for writing (no matter whether that access is exclusive or not) instead of a backup file, execve() cannot succeed. The only way around this would be to make a full copy of the original file, work on that and atomically copy the changes back on :w... but I don't remember a nvi version that did that. Regards, Jan signature.asc Description: Digital signature
Bug#496462: nvi: security vulnerability in creation of shared directory in postinst
Hi Raphael, your report is correct, but if /var/tmp/vi.recover was really a symlink to some existing directory (like /), mkdir -p won't fail at all - in fact, it won't even be executed because the [ -d ] test will already succeed. I'll fix it properly - thanks for catching it. Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495806: Locked screen accepts any password to unlock
tags 495806 + unreproducible thankyou Hi Troy, I can't reproduce the problem, no matter which PAM version I have installed (0.99.7 or 1.0.1). You are referring to the password prompt that screen shows upon resumption of a screen session that has been locked with the 'lockscreen' command, right? I can't come up with any good guesses how this could happen to you... just to make sure that we're talking about the same thing, could you give me a detailed list of actions to reproduce that behaviour and tell me if you made any substantial changes to relevant files (/etc/pam.d/*, any personal or system-wide screenrc settings etc.)? Regards, Jan signature.asc Description: Digital signature
Bug#490361: Please let nvi depend on newer DB.
Hi, 1.81.6-3 depends on libdb4.2, but the latest libdb in Debian is libdb4.7. The default libdb-dev depends on libdb4.6 currently. I build a nvi for libdb4.6, and it works fine. (I did not test it for libdb4.7.) I did indeed try a build against libdb4.6, and the results didn't satisfy me. There were spurious warnings about a missing DB_CREATE parameter and some strange open() calls which made me move back to a older version of libdb just to be on the safe side. (Note that these are runtime issues - the build itself does indeed run without problems.) Another factor was time - I wanted to get this into Lenny (and even now it is questionable whether it will make it). Now that 1.81.6 is in the archive, I'll test more libdb versions and upgrade the dependency when I am sure that it will work. Regards, Jan signature.asc Description: Digital signature
Bug#489037: audacious: Illegal instruction at start on i386 systems
Hi,
I've done a bit of backtracking:
* Offending instruction(s):
] [EMAIL PROTECTED]:~$ gdb /usr/bin/audacious core.11650
] GNU gdb 6.8-debian
] (gdb) disass $eip $eip+32
] Dump of assembler code from 0x80a4122 to 0x80a4142:
] 0x080a4122 [EMAIL PROTECTED]:movsd -0x18(%ebp),%xmm0
] 0x080a4127 [EMAIL PROTECTED]:cvttsd2si %xmm0,%eax
] [...]
(These are SSE2 instructions.)
* Problem:
The configure script tests for SSE2 by compiling a program similar to
] #include emmintrin.h
] void X()
] {
] _mm_setzero_pd();
] }
and checking whether it runs without getting SIGILL. This is a bad SSE test,
however, because on non-SSE hosts the instructions are simply left out, i.e.
the above compiles on older CPUs (e.g. my Athlon Thunderbird) to
] X:
]0: 55 push %ebp
]1: 89 e5 mov%esp,%ebp
]3: 5d pop%ebp
]4: c3 ret
whereas more recent systems yield
] X:
]0: 55 push %ebp
]1: 89 e5 mov%esp,%ebp
]3: 83 ec 18sub$0x18,%esp
]6: 66 0f 57 c0 xorpd %xmm0,%xmm0
]a: 66 0f 29 45 e8 movapd %xmm0,-0x18(%ebp)
]f: c9 leave
] 10: c3 ret
both without warning. Thus '-msse2' is enabled regardless of this test, and
the resulting binary fails on non-SSE2 hosts.
Regards,
Jan
signature.asc
Description: Digital signature
Bug#485996: ITA: ircii -- Internet Relay Chat client (update)
Hi Bernd, I'm currently working with upstream to re-enable UTF support for ircii - they have reverted the old UTF patch in 2006 for performance reasons. As IMHO it doesn't make sense to upload a new Debian package that lacks UTF support, I won't change this package in the near future (read: at least two weeks - I'm still waiting for upstream to provide me with the current state of the UTF patch). If you want to get out of the Maintainer: field, feel free to upload an otherwise-unchanged upgrade and change it to me. I'll update this report when news arrive. Jan signature.asc Description: Digital signature
Bug#488296: ^a ^\ kills all screens without actually asking
Hi, If the user accidentally pressed ^a ^\, screen will ask Do you really want to kill all screens and exit? (y/n). but it will go on and kill everything without actually waiting for the user to press n. I cannot reproduce this - screen waits at the prompt and properly accepts a 'n'o answer. (I've tested both -7 and -11). Can you tell me a bit more, e.g. since when you experience this bug and whether you have made any special settings? Regards, Jan signature.asc Description: Digital signature
Bug#330782: nvi: segfault when trailing tab hits end of line
severity 330782 grave
tags 330782 + help
thankyou
(bumping the severity up to grave because of possible data loss)
Ok, this one has been lying around for far too long. If anyone feels like
diving into ancient sourcecode, I'd highly appreciate that. Here's a
little teaser:
=
Core was generated by `./vi_O0g3'.
Program terminated with signal 11, Segmentation fault.
[New process 16692]
(gdb) bt 5
#0 0xb7e588e8 in vfprintf () from /lib/libc.so.6
#1 0xb7e7eab4 in vsnprintf () from /lib/libc.so.6
#2 0xb7e621e2 in snprintf () from /lib/libc.so.6
#3 0x080a4e4d in vs_line (sp=0x80bead8, smp=0x81726b8, yp=0xbf6b2b34,
xp=0x80bf698) at ../dist/../vi/vs_line.c:141
#4 0x08072665 in vs_paint (sp=0x80bead8, flags=3)
at ../dist/../vi/vs_refresh.c:641
(More stack frames follow...)
(gdb) bt -10
#27558 0x08072759 in vs_paint (sp=0x80bead8, flags=3)
at ../dist/../vi/vs_refresh.c:673
#27559 0x08072759 in vs_paint (sp=0x80bead8, flags=3)
at ../dist/../vi/vs_refresh.c:673
#27560 0x08072759 in vs_paint (sp=0x80bead8, flags=3)
at ../dist/../vi/vs_refresh.c:673
#27561 0x08072759 in vs_paint (sp=0x80bead8, flags=3)
at ../dist/../vi/vs_refresh.c:673
#27562 0x08070eda in vs_refresh (sp=0x80bead8, forcepaint=0)
at ../dist/../vi/vs_refresh.c:95
#27563 0x0809fd39 in v_txt (sp=0x80bead8, vp=0xbfeb026c, tm=0x0, lp=0x814ad28,
len=8, prompt=0, ai_line=0, rcount=1, flags=75793408)
at ../dist/../vi/v_txt.c:1427
#27564 0x080975ed in v_ii (sp=0x80bead8, vp=0xbfeb026c)
at ../dist/../vi/v_itxt.c:164
#27565 0x0806ccde in vi (spp=0xbfeb0498) at ../dist/../vi/vi.c:232
#27566 0x08060776 in editor (wp=0x80bd820, argc=0, argv=0xbfeb0618)
at ../dist/../common/main.c:410
#27567 0x0804c354 in main (argc=1, argv=0xbfeb0614)
at ../dist/../cl/cl_main.c:122
(gdb) list ../dist/../vi/vs_refresh.c:660,680
660 * Sanity checking. When the repainting code messes up, the
usual
661 * result is we don't repaint the cursor and so sc_smap will be
662 * NULL. If we're debugging, die, otherwise restart from
scratch.
663 */
664 #ifdef DEBUG
665 if (vip-sc_smap == NULL) {
666 fprintf(stderr, smap error\n);
667 sleep(100);
668 abort();
669 }
670 #else
671 if (vip-sc_smap == NULL) {
672 F_SET(sp, SC_SCR_REFORMAT);
673 return (vs_paint(sp, flags));
674 }
675 #endif
676
677 /*
678 * 9: Set the remembered cursor values.
679 */
680 OCNO = CNO;
=
[i.e. the code already *knows* that is has messed up big time. I'm just
having problems figuring out that tiny side-effect of having the
'set number' setting activated which triggers the bug.]
If the new (development branch) package has not yet entered the archive,
it would be best if you used this[1] package for debugging, although I
guess the bug hasn't changed between 1.79 and 1.81.
I'll still try my best, too, but Lenny is drawing near.
Thanks,
Jan
[1]: http://www-pool.math.tu-berlin.de/~hesso/deb/nvi_1.81.6+debian-1.dsc
signature.asc
Description: Digital signature
Bug#330782: nvi: segfault when trailing tab hits end of line
tags 330782 = pending thankyou Heh, tagging such a bug 'help' sometimes adds that bit of extra motivation that helps you find the problem yourself in the end. ;) A patched (a one-liner in a very innocent-looking part of the code) version is ready and will be uploaded in the next days. Regards, Jan signature.asc Description: Digital signature
Bug#484336: inform: Upgrade to Inform 6.31N
Hi, In the meantime, I noticed the bug report requesting the upgrade to 6.31. Actually, I think the latest version is 6.31N. Ah, that link is alive again? It has been dead for some time... According to the site, it contains a set of patches for bug fixes known not to cause problems and is the version being used underneath Inform 7. Yeah, I know - but I didn't want to wait for that download to be revived. AFAIK the patchset wasn't that large, so it shouldn't take long to review and apply. Can't wait for this to arrive in Testing AMD64 repository! Non-free is only autobuilt on special request, but I'm aiming at getting inform into Lenny. Thanks for notifying me! Jan signature.asc Description: Digital signature
Bug#471763: /var/run/screens permissions inconsistency causes screen to refuse to start up
Hi, I checked /var/run/screen and it is owned by user root group root, so it is not group utmp. Since this used to work, maybe the pre- install script should enforce the group? so changing the group to utmp fixed the problem? I'm at a loss how that directory has ended up with group root on your system - the initscript creates it with the correct group if it doesn't exist. Maybe you could extract your screen upgrade path from /var/log/dpkg.log? Regards, Jan signature.asc Description: Digital signature
Bug#471763: /var/run/screens permissions inconsistency causes screen to refuse to start up
Hi, any news on this? Regards, Jan signature.asc Description: Digital signature
Bug#474469: screen: fails to connect in multiusermode
Hi Andreas, did you check the suid bits on the screen binary? What is the status of this bugreport? Regards, Jan signature.asc Description: Digital signature
Bug#478884: screen: 40cjk_eastasian.dpatch breaks terminal layout
Hi, is the interval structure and the bisearch function necessary? I can't find a code path that calls it. Besides that the patch looks good and I'll include it in the next upload. Thanks! Jan signature.asc Description: Digital signature
Bug#468427: strange lockups of aptitude and m-a in screen
Hi, When I start aptitude in screen, the cursor goes to the top left position and just stays there, aptitude UI is now drawn until I resize the terminal that holds the screen. After that aptitude works OK. I can't reproduce this one either (using a standard xterm and a ISO8859 locale). What do you mean by is now drawn until...? Aptitude hangs? What terminal emulator do you use (or could you even try a few and report whether that changes anything)? Thanks! Jan signature.asc Description: Digital signature
Bug#399913: status of virtual package 'editor'
Hi, what's the current public opinion on this? The responses I got in November 2006[1] indicated that this metapackage is not desired and should not be re-added to the list - however it's still in widespread use... ] [EMAIL PROTECTED]:~$ for DEP in Provides Depends Recommends Suggests; do \ ] echo -n $DEP: ; grep-available -sPackage -F$DEP editor | wc -l; done ] Provides: 29 ] Depends: 8 ] Recommends: 2 ] Suggests: 8 Shall this be unified before Lenny, or may I safely tag #398752 wontfix for now? Regards, Jan [1] http://lists.debian.org/debian-devel/2006/11/msg00637.html based on a thread shortly before: http://lists.debian.org/debian-devel/2006/11/msg00483.html signature.asc Description: Digital signature
Bug#478332: screen: new window shows strange message at prompt line
Hi, [EMAIL PROTECTED]:~$ PS1=$ 134$ 134 is still there... (my terminal is in Tranditional-Chinese UTF-8 charset. Does that matter?) ok, we'll have to dig a bit deeper. Could you please install strace (if you haven't already) and do the following: * start a screen session as usual * do a 'screen -ls' inside it and note the PID of this session (it should say something like there's a session on PID.ttyX.host) * open up another terminal, become root there and do (using the PID you just looked up): strace -pPID -o /tmp/screen.strace * press enter in your screen session (so a new prompt is displayed) * interrupt the strace (Ctrl-C) and attach the file it wrote strace records all system calls of a given process and thus also records all data flowing from and to the screen session. Maybe this can tell us where the '134' is coming from, or whether screen is sending some control sequences that don't make it through... Regards, Jan signature.asc Description: Digital signature
Bug#478332: screen: new window shows strange message at prompt line
Hi, hmm, that's interesting. Here's what it should look like (or what it looks like when I just press Return in screen)... # screen forwards the keypress to the shell... read(3, \r, 4096) = 1 write(6, \r, 1) = 1 # ... and the shell moves the cursor to the next line... read(6, \0\r\n, 4096) = 3 write(3, \r\n, 2) = 2 # ... and redraws the prompt. read(6, [EMAIL PROTECTED]:~$ , 4096)= 14 write(3, [EMAIL PROTECTED]:~$ , 13) = 13 ... now yours (I've deleted the select() and gettimeofday() lines, they are irrelevant for our problem)... # read keypress... read(3, \r, 4096) = 1 write(6, \r, 1) = 1 # ... move cursor to beginning of next line... read(6, \0\r\n, 4096) = 3 write(3, \r\n, 2) = 2 # ... the shell echoes several strange characters (???)... read(6, \0\33k\33\\134, 4096) = 8 write(3, 134, 3) = 3 # ... draw prompt as usual. read(6, \0\33[01;[EMAIL PROTECTED]:\33[01;..., 4096) = 43 write(3, [EMAIL PROTECTED]:\33[1m\33[..., 42) = 42 I can't make any sense of that extra data. Could you please: * strace a regular bash session (i.e. one without screen in between) * provide me with 'echo $TERMCAP' (called from inside screen) I've tried to reproduce the problem under a zh_TW.utf8 locale, but failed. Oh, and just for the sake of completeness, could you test whether calling screen with and without '-U' makes any difference? Regards, Jan signature.asc Description: Digital signature
Bug#478332: screen: new window shows strange message at prompt line
Hi, and yes, the prompt colour is correct.. any suggestion to fix it? you keep forgetting to answer *all* my questions. ;) I'll make a list... * Is the 134 coloured, too? * If you do 'echo -e $PS1', does it result in some strange extra characters, too? (Besides printing \u for your username etc.) * What happens if you set 'PS1=$'? * What is the effect if you start screen with 'screen -- /bin/bash --norc'? Regards, Jan signature.asc Description: Digital signature
Bug#478332: screen: new window shows strange message at prompt line
Hi, please respond to [EMAIL PROTECTED] (Sending your answers to submit@ will result in every message generating a new report.) [EMAIL PROTECTED]:~$ -something like this Yes, that's what I suspected it to look like - but this doesn't answer my questions. Did you try any of my suggestions? Change (in no particular order, but one at a time) - shell (csh instead of bash, for example) - terminal emulator (xterm / eterm / one of the *xvt series) - user account - host you're testing on Could you report whether your bug survives all those changes? Regards, Jan signature.asc Description: Digital signature
Bug#478332: screen: new window shows strange message at prompt line
Hi, 1.shell (csh instead of bash, for example) this does workbut I could'nt change my shell...plz I mean for daily use, I need bash... 2.terminal emulator (xterm / eterm / one of the *xvt series) this does'nt help the 134 is still there ok, these two suggest that there's something wrong with your bash startup files... but you say it doesn't happen outside screen, right? 3.user account [EMAIL PROTECTED]:~$ su root password??? [EMAIL PROTECTED]:/home/aguai# Hm, just to make sure, could you give me the output of 'echo $PS1'? 4.host you're testing on well... I could'nt do this testI got only one Notebook here with me (you mean change another machine? do you?) Yes, that's what I meant. Nevermind, I think we'll get this resolved without that test. Regards, Jan signature.asc Description: Digital signature
Bug#478332: screen: new window shows strange message at prompt line
Hi, (should I reply to the bug reply system? sorry if I reply to the wrong address) just respond to [EMAIL PROTECTED], so your mail gets automatically appended to the bug report log. here is my $PS1 Ah ok, you are using the coloured prompt. Does the colour work (i.e. is the prompt inside screen still green and blue like it should be)? And is the initial '134' coloured, too? Regards, Jan signature.asc Description: Digital signature
Bug#477739: Screen -r fails with WriteMessage: bad file descriptor
tag 477739 + confirmed thankyou Hi Aaron and Jason, I am also experiencing this bug on my dual-cpu (quad-core) Intel Xeon 5140 system with 4gb RAM. However, on my laptop (single-core AMD Athlon64 CPU, 1.8ghz, 1gb RAM) with exactly the same kernel and screen 4.0.3-8, I can't reproduce it. I guess there is some kind of race condition in -8. I've finally found an amd64 box where I can reproduce the problem and am now digging into it. If fixing the issue takes longer than a week I'll bump this bug up to prevent it from reaching Lenny - but I doubt that this will be necessary. Thanks for reporting! Regards, Jan signature.asc Description: Digital signature
Bug#477739: #477739: resuming the only session may lead to race condition
tags 477739 = patch pending thankyou Hi, could you try this updated package[1] and report back whether it fixes the race? If it does, I'll add a few more fixes and arrange for having it uploaded during the next days. Regards, Jan [1]: http://www-pool.math.tu-berlin.de/~hesso/deb/screen_4.0.3-9.dsc http://www-pool.math.tu-berlin.de/~hesso/deb/screen_4.0.3-9_i386.deb http://www-pool.math.tu-berlin.de/~hesso/deb/screen_4.0.3-9_amd64.deb signature.asc Description: Digital signature
Bug#447210: screen: chdir command doesn't expand tilde
Hi, I'm not the maintainer, so I'm not sure if there is any chance of changing screen/screen upstream to have a new build dependency. If there is then that is obviously preferred. I don't like the idea of introducing additional build dependencies, and I don't think upstream would be very fond either. Besides I had already wrapped up some simple tilde expansion code to fix #308818, which is now going to satisfy both ':source' and ':chdir'. Thanks for your patch! Jan signature.asc Description: Digital signature
Bug#477455: screen: backspace key viewed as nul character with some terminals (e.g. xfce4-terminal)
reassign 477455 vte
retitle 477455 vte: backspace-autodetect mode uses c_cc[VERASE] even when
ICANON|ECHOE unset
thankyou
Hi,
With some terminals, such as xfce4-terminal (Debian package) and
osso-xterm (not in Debian), screen views the Backspace key as the
nul character (^@), so that it is not possible to erase characters
with it.
this is not screen's fault. screen disables most control code translations
on its outer fd (the one inherited from the invoking shell, which is
directly fed by the X terminal emulator) by calling tcsetattr():
] ioctl(3, TCGETS, {c_iflags=0x500, c_oflags=0x5, c_cflags=0xbf,
c_lflags=0x8a3b, c_line=0, c_cc...})
] ioctl(3, TCSETSW, {c_iflags=0x400, c_oflags=0x1, c_cflags=0xbf,
c_lflags=0xa30, c_line=0, c_cc...})
] ioctl(3, TCGETS, {c_iflags=0x400, c_oflags=0x1, c_cflags=0xbf,
c_lflags=0xa30, c_line=0, c_cc...})
The new c_lflags value expands to {ECHOE|ECHOK|ECHOCTL|ECHOKE}.
ECHOE,ECHOK and ECHOPRT depend on ICANON (which is unset), ECHOCTL depends on
ECHO
(which is also unset), so these bits (ought to) have no effect. Yet libvte
unconditionally uses c_cc[VERASE] for backspace:
] vte:src/vte.c:4330 ff.
] case VTE_ERASE_AUTO:
] default:
] if (terminal-pvt-pty_master != -1) {
] if (tcgetattr(terminal-pvt-pty_master,
]tio) != -1) {
] normal = g_strdup_printf(%c,
] tio.c_cc[VERASE]);
] normal_length = 1;
] }
] }
] suppress_meta_esc = FALSE;
] break;
] }
] handled = TRUE;
But screen sets that member to ascii NUL (because it shouldn't be used
anyway).
Regards,
Jan
signature.asc
Description: Digital signature
Bug#477728: screen: strange number display after C-a C-c creating new window
Hi, a number like 134 shows before my bash prompt after I create a new window in screen... have you followed the usual procedure to make sure this is screen-related? (Some commands in your shell rc files might run haywire, probably depending on $TERM or similar...) - Is it a part of the prompt (i.e. shown before every line) or only before the first? Is it always the same? Does the problem remain if you try as a different user / on a different system? Regards, Jan signature.asc Description: Digital signature
Bug#477739: screen: resuming fails with WriteMessage: Bad file descriptor
Hi Aaron, As of version 4.0.3-8, resuming a detached screen session (with screen -r) fails with the cryptic error WriteMessage: Bad file descriptor 4.0.3-7 has no such trouble, and can even resume sessions started with 4.0.3-8. can you spot a pattern? (Happens only when several sessions are alive / happens only as non-root / ...) Otherwise I guess the easiest way would be if you could provide me with a 'screen -ls' (so I know what I have to expect) and the output of strace -u $user -o ... -- screen -r further args... I have no problems here de- and attaching to screen sessions... but albeit somewhat cryptic that error message is quite characteristic. Regards, Jan signature.asc Description: Digital signature
Bug#445360: rxvt+mutt crash - solved?
Hi,
It's fixed. Thanks! (What was it? There is no description.)
thanks for verifying. I wanted to be sure that I'd found the right
place before elaborating what the problem was. The bug could be triggered
by making rxvt execute the following escape sequence:
'\e[1;19r\e[10S'
This reduces the scrolling region to lines 1-19 and then scrolls 10
lines forward. If the scroll buffer is empty, rotating it will move null
pointers into the visible area (because memory for each line is only
allocated when necessary) - but the allocation code didn't take the reduced
scrolling region into account, so some null pointers remained. (E.g. with a
80x24 terminal, the code would verify that after rotation the memory pointers
for display lines 14-23 were non-null instead of lines 9-18.)
The regular rxvt termcap is slightly different, and mutt uses a different
control sequence to accomplish the same result there - that's why it only
surfaced with your custom Xresource (which caused it to use xterm's termcap).
If you want to see something really annoying, have a look at my patch
(note the comment line):
] --- rxvt-2.6.4/src/screen.c
] +++ rxvt-2.6.4/src/screen.c
] @@ -853,8 +853,8 @@
] count = scroll_text(screen.tscroll, screen.bscroll, count, 0);
] /* XXX: Ummm, no? care needed with [bt]scroll, yes? */
] if (count 0) {
] - row = TermWin.nrow - count + TermWin.saveLines;
] - erow = TermWin.nrow + TermWin.saveLines;
] + row = TermWin.saveLines + screen.bscroll - count;
] + erow = TermWin.saveLines + screen.bscroll + 1;
] } else {
] row = TermWin.saveLines;
] erow = TermWin.saveLines - count;
Yes, care needed.
Regards,
Jan
signature.asc
Description: Digital signature
Bug#206572: screen: -ls should list sessons sorted chronologically
Hi Ben, Doesn't the ctime value from fstat(2) give the time the session was created? That seems like a more useful criterion. all three timestamps are modified by detach/attach. Writing messages to the fifo changes mtime and ctime (the latter being quite strange), receiving changes atime, and toggling the u+x mode bit (to record the Session Attached/Detached state) changes ctime as well. screen even calls utimes() to prevent the socket files from deletion by tempreaper tools, but it doesn't help disabling it due to the above reasons. Regards, Jan signature.asc Description: Digital signature
Bug#206572: screen: -ls should list sessons sorted chronologically
Hi, all three timestamps are modified by detach/attach. Writing messages to the fifo changes mtime and ctime (the latter being quite strange), That is strange. Perhaps it warrants another bug report? This bug could then depend on that one. no, that observation wasn't even related to screen - I made it when experimenting manually with two bash instances and a fifo. Disabling the utimes() call results in minimal differences (for instance, while screen asks for a password, a/mtime differ from ctime), but nothing useful. Regards, Jan signature.asc Description: Digital signature
Bug#445360: rxvt+mutt crash - solved?
Hi Josip, Okay, I would be happy to try and narrow it down some more - just give me more hints where to look... what would be next - terminfo? locales? good news: I think I've found it. Could you please verify that this update[1] fixes the bug? Thanks! Jan [1]: http://www-pool.math.tu-berlin.de/~hesso/deb/rxvt_2.6.4-14.dsc (That directory is my staging area - I don't use mentors.d.n because I have a constant pool of sponsors. There's also a ready-made .deb, the interdiff against -13 etc.) signature.asc Description: Digital signature
Bug#206572: screen: -ls should list sessons sorted chronologically
Hi, Further investigation shows this is defined behaviour for Unix (and correctly implemented in Linux). yes, I suspected that, but couldn't find anything myself - bad google-fu tonight. Thanks for looking it up. So it seem that there is currently no useful file-status time field to order by for the session FIFOs. Should one be created as an attribute of screen's session data? Indeed, the fifo is useless. Assuming the session is local, one could use the pid part of the $STY/fifo name to get the initial session creation time through /proc/$pid/stat... a bit hackish, but it should work. I'll prepare a patch and see if it works out. Regards, Jan signature.asc Description: Digital signature
Bug#206572: screen: -ls should list sessons sorted chronologically
Hi, the only timestamp we have is the time of last attachment/detachment (and we can't even tell them apart), and I don't think that sorting by that criterion is incredibly useful... so I'd like to tag this bug 'wontfix' if no-one objects. Regards, Jan signature.asc Description: Digital signature
Bug#468427: vim stock on initialiaing in screen for no reson recently
Hi, I've report it to vim maintainer and I don't know if this is a vim bug or a screen bug. However vim got an update yesterday and this situation got even worse. So I report this to screen maintainer as well. thanks if you can find the conflict part. It will be great if anyone'd like to teach me how to do a trace when it happen. All I can do now is open another terminal and ps -A|grep vim then kill the pid I cannot find any vim/screen-related bugs at the moment - does the problem still exist or was it fixed in a later vim upload? If it still exists, could you try varying your environment (Terminal emulator, locale etc.) and report the results? Thanks! Jan signature.asc Description: Digital signature
Bug#471763: /var/run/screens permissions inconsistency causes screen to refuse to start up
Hi, The current permissions of /var/run/screen would be useless, because I have changed it manually to the correct permissions already; otherwise I can't run screen at all, and I use it every day and I only reboot this machine for equipment upgrades or kernel upgrades. The current permissions of /usr/bin/screen is as follows: -rwxr-sr-x 1 root utmp 303808 2007-09-26 17:57 /usr/bin/screen this is the code in question: [screen.c:1014] n = (eff_uid == 0 (real_uid || (st.st_mode 0775) != 0775)) ? 0755 : (eff_gid == (int)st.st_gid eff_gid != real_gid) ? 0775 : 0777; if (((int)st.st_mode 0777) != n) Panic(0, Directory '%s' must have mode %03o., SockDir, n); If screen insists on mode 0777 for the fifo socket directory, we only have two possibilities: 1) eff_gid != st.st_gid Could mean that either /var/run/screen is not group utmp, or the setgid bit of the binary is being ignored (is the underlying filesystem mounted 'nosuid'?). 2) eff_gid == real_gid Again setgid not working, or the calling user actually has utmp as his primary group. Could you check these? If all looks ok, could you send me an strace of a screen invocation? The last 100 lines before the error message should be enough if you don't want to append the whole thing. (Note that you'll have to do that as root using 'strace -u', otherwise setgid won't work.) Regards, Jan signature.asc Description: Digital signature
Bug#187811: ^G or bell emits about 5 blank lines.
Hi, I cannot reproduce this bug (with and without vbell, using gnome-terminal, xterm and other terminal emulators) - could you please affirm that the problem still exists? Otherwise I'm going to close this bug in a few weeks, given that the report is five years old... Regards, Jan signature.asc Description: Digital signature
Bug#466437: Weird output when using any shortcuts in Vim in screen session
Hi, When i try to use any of commands in vim (i to insert mod, : to write :q and so on), I got strange message, but vim is still running, no crash, only this text: :*** debug [lib/liblow.c(212)]: VC: 0 I cannot reproduce this bug with the current versions of vim (1:7.1.293-1) and screen (4.0.3-7). Is there anything special about your system? I've already tried with a UTF and a ISO8859 locale... Which terminal emulator did you use when the bug appeared? Can you repeat it with others? Regards, Jan signature.asc Description: Digital signature
Bug#471763: /var/run/screens permissions inconsistency causes screen to refuse to start up
Hi, The /etc/init.d/screen-cleanup script, provided by package screen, chmod's /var/run/screen to a mode that will cause the screen command itself, also provided by the same package, to refuse to start up. would you please show me the current permissions of both /usr/bin/screen and /var/run/screen? screen wants the access bits on its fifo directory to be as permissive as necessary and as restrictive as possible. Deviations in either direction will evoke that warning. ++--+ | Permission Bits| Expected permissions | | on /usr/bin/screen | of /var/run/screen | ++--+ | 0755 |0777 | | 2755 |0775 | - package default | 4755 |0755 | ++--+ (both owned by user root, group utmp) Regards, Jan signature.asc Description: Digital signature
