Bug#257096: Bug still current
Hi, Answered my own question, two years later. Yes, this bug is still current; I just did a new Postfix 2.7 install (Debian squeeze) and had DNS resolution issues. Googled for the problem and found my own bug report. Heh. :) No worries, just thought I'd mention it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#611036: clive: YouTube formats are outdated, and config validation prevents using new names
Package: clive
Version: 2.2.13-5
Severity: normal
The YouTube module appears to have evolved to use new names for many of
the formats. From YouTube.pm:
# flv
flv_240p => '5',
flv_360p => '34',
flv_480p => '35',
# mp4
mp4_360p => '18',
mp4_720p => '22',
mp4_1080p => '37',
mp4_3072p => '38',
# webm
webm_480p => '43',
webm_720p => '45',
# 3gp
'3gp_144p'=> '17',
Yet rather than consult this table of formats, the Config.pm appears
to be using a local simple validation:
# Check format.
my @youtube = qw(fmt18 fmt34 fmt35 fmt22 fmt17 hq 3gp);
my @google = qw(mp4);
my @vimeo = qw(hd);
[... other providers ...]
my @formats
= ( qw(flv best), @youtube, @google, @vimeo, @spiegel, @golem );
#unless (@formats ~~ $config{format}) { # Perl 5.10.0+
unless ( grep( /^$config{format}$/, @formats ) ) {
It looks like we're using this simple validation scheme that a) lets you
use any format from any host (e.g. Vimeo "hd" with YouTube) and b) is
prone to falling out of date with the actual host files.
This has rather frustrating consequences, since (at least) the
YouTube provider seems to ignore unknown formats and just use the
default one.
The manpage and the Config.pm validation specify all these "fmt??"
formats that the YouTube module doesn't appear to support.
For example, these commands will _all_ get me the 2.6 meg FLV version
of this video:
clive 'http://www.youtube.com/watch?v=f0PbjqwJTZs'
clive --format=fmt22 'http://www.youtube.com/watch?v=f0PbjqwJTZs'
(should be MP4)
clive --format=fmt18 'http://www.youtube.com/watch?v=f0PbjqwJTZs'
(should be MP4)
clive --format=fmt35 'http://www.youtube.com/watch?v=f0PbjqwJTZs'
(should be different size)
These commands get me the 17.8 meg 720p MP4 version (format 22):
clive --format=best 'http://www.youtube.com/watch?v=f0PbjqwJTZs'
clive --format=hd 'http://www.youtube.com/watch?v=f0PbjqwJTZs'
(note that 'hd' is listed under Vimeo validations, not YouTube)
clive --format=mp4_720p 'http://www.youtube.com/watch?v=f0PbjqwJTZs'
(this format is specified in YouTube.pm, but only works if I
add mp4_720p to the Config.pm list)
I would think we should be consulting the provider modules to
determine the list of usable formats. At the very least, the
Config.pm validation badly needs updating, and the docs need updating
either way because the "fmt??" formats are all invalid now.
-- System Information:
Debian Release: squeeze/sid
APT prefers stable
APT policy: (990, 'stable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages clive depends on:
ii libclass-singleton-perl1.4-1 implementation of a "Singleton" cl
ii libconfig-tiny-perl2.12-1Read/Write .ini style files with a
ii libexpect-perl 1.20-1Expect.pm - Perl Expect interface
ii libgetopt-argvfile-perl1.11-1Perl module for reading script opt
ii libhtml-parser-perl3.56-1+lenny1 A collection of modules that parse
ii liburi-perl1.54-2module to manipulate and access UR
ii libwww-curl-perl 4.05-1Perl bindings to libcurl
ii perl 5.10.1-16 Larry Wall's Practical Extraction
Versions of packages clive recommends:
pn clive-utils(no description available)
ii libberkeleydb-perl0.34-1+b1 use Berkeley DB 4 databases from P
ii libterm-readkey-perl 2.30-4 A perl module for simple terminal
Versions of packages clive suggests:
ii ffmpeg 5:0.6~svn20100726-0.1 audio/video encoder, streaming ser
-- debconf-show failed
signature.asc
Description: Digital signature
Bug#603153: xpdf: Crashes on all PDFs: Assertion `mutex->__data.__owner == 0' failed
Package: xpdf Version: 3.02-11 Severity: important Once upgraded to 3.02-11, xpdf fails to open all PDF files: % xpdf /tmp/specs.pdf xpdf: pthread_mutex_lock.c:62: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. zsh: abort xpdf /tmp/specs.pdf The lenny version works fine. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xpdf depends on: ii lesstif21:0.95.0-2.1 OSF/Motif 2.1 implementation relea ii libc6 2.11.2-5 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.3-5GCC support library ii libpoppler5 0.12.4-1.1 PDF rendering library ii libstdc++6 4.4.3-5 The GNU Standard C++ Library v3 ii libx11-62:1.2.2-1X11 client-side library ii libxt6 1:1.0.5-3X11 toolkit intrinsics library Versions of packages xpdf recommends: ii gsfonts-x11 0.21 Make Ghostscript fonts available t pn poppler-data (no description available) ii poppler-utils 0.12.4-1.1 PDF utilitites (based on libpopple xpdf suggests no packages. -- debconf-show failed signature.asc Description: Digital signature
Bug#576245: clive: failures with newer youtube videos
FYI, you can still get the video_id from the JSON parameters by changing this (in YouTube.pm) id => qr|"video_id": "(.*?)"|, into this id => qr|'VIDEO_ID': '(.*?)'|, or, if you want backwards compatibility, this id => qr|['"]video_id['"]: ['"](.*?)['"]|i, The problem is then the "t" parameter. I'm not even sure what it referred to, and I can't find anything that sounds similar. signature.asc Description: Digital signature
Bug#572261: New patch
tags 572261 + patch thanks Okay, this one doesn't leak *or* crash, so I think it's at least vaguely correct. :) Valgrind was getting confused by the memory buffers and blaming slirp_input(), since that's where the original malloc() (via m_get) occurs. (Is that buffering really necessary? Last I heard, GNU libc takes steps to prevent memory fragmentation by doing its own internal overallocation and handing out pieces of that to malloc() calls.) The real source of the leak were in places like tcp_output() and others, which prepare buffers for if_output(). They get queued for sending, and eventually dequeued, but never m_free()d. I'm not sure if the VDE developers intended for the m_free() to go in if_output() or if_encap(), but it's not in either, and that's the actual source of the leak. diff --git a/src/slirpvde/if.c b/src/slirpvde/if.c index 7c7ca21..5b9f70e 100644 --- a/src/slirpvde/if.c +++ b/src/slirpvde/if.c @@ -318,6 +318,7 @@ again: /* Encapsulate the packet for sending */ if_encap(ifm->m_data, ifm->m_len); +m_freem(ifm); if (if_queued) goto again; signature.asc Description: Digital signature
Bug#572261: Acknowledgement (slirpvde: Massive memory leak)
tags 572261 - patch thanks Okay, turns out my patch was a bit naive -- it's been a while since I did any serious C coding. The patch is bad but the problem is real. I can trigger it via pings, via regular TCP traffic, etc. I'll see if I can come up with another patch soon, since this is a rather critical bug for me. signature.asc Description: Digital signature
Bug#572261: slirpvde: Massive memory leak
Package: vde2 Version: 2.2.3-3 Severity: important Tags: patch slirpvde leaks over 1600 bytes per packet received, even tiny ones like pings. This makes it practically unusable for a production system in the current state. I've attached a patch to fix the leak. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vde2 depends on: ii adduser 3.110 add and remove users and groups ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib ii libpcap0.81.0.0-6system interface for user-level pa ii libvde0 2.2.3-3Virtual Distributed Ethernet - sup ii libvdeplug2 2.2.2-3Virtual Distributed Ethernet - Plu vde2 recommends no packages. Versions of packages vde2 suggests: ii qemu 0.11.1-2 fast processor emulator ii qemu-kvm [kvm] 0.11.1+dfsg-1 Full virtualization on x86 hardwar pn vde2-cryptcab (no description available) -- no debconf information diff --git a/src/slirpvde/slirp.c b/src/slirpvde/slirp.c index e0d6807..b5c2084 100644 --- a/src/slirpvde/slirp.c +++ b/src/slirpvde/slirp.c @@ -601,6 +601,7 @@ void slirp_input(const uint8_t *pkt, int pkt_len) m->m_len -= ETH_HLEN; ip_input(m); +m_free(m); break; default: break; signature.asc Description: Digital signature
Bug#257096: postfix: noexec /var breaks postfix chroot
retitle 257096 postfix: noexec /var breaks postfix chroot thanks I've been going through my old reported bugs today and I'm wondering, is this bug still current? I notice I have a Postfix server (2.5.5-1.1 lenny) that has a noexec /var, and yet Postfix seems to be working fine with a relayhost specified by name rather than IP. Normally I would just mark this as done, but I notice there are still libraries in /var/spool/postfix/lib, so I'm curious if / how the chroot + noexec problem was solved. signature.asc Description: Digital signature
Bug#570308: redmine: Expects to write to plugin_assets in /usr
Package: redmine Version: 0.9.2-2 Severity: serious Justification: Policy 9.1.1 FHS chapter 4 The plugin_assets directory is expected to be writable by the user running Redmine. In the Debian redmine package, this is currently /usr/share/redmine/public/plugin_assets. The package scripts acknowledge this by making directory writable by www-data, but writing to /usr at runtime is not allowed per the FHS, and will cause problems on systems where /usr is mounted read-only (which is acceptable per Debian policy). I expect the solution would be to put plugin_assets somewhere in /var and create a symbolic link pointing to it. This may cause problems on Apache systems where symbolic links are disallowed, but this could be worked around using an "Alias" directive in the example Apache configurations. On a related note: This part isn't a policy violation (that I know of), but I figured I should mention that the package also creates "/usr/share/redmine/public/plugin_assets/README" and "/usr/share/redmine/db/schema.db" at config time, untracked by dpkg. These files get removed at "purge" time via "rm -rf /usr/share/redmine", but this seems a bit heavy-handed, since people might have installed plugins there. I wonder if it would be better to delete these files, perhaps as part of the "prerm" script (or even at the end of the "config" script), such that dpkg can clean up /usr/share/redmine on its own? (Just throwing this out there. It's minor and optional enough that I didn't want to bother you with a second "wishlist" bug.) -- System Information: Debian Release: 5.0.3 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages redmine depends on: ii dbconfig-common 1.8.39 common framework for packaging dat ii debconf [debconf-2.0]1.5.24 Debian configuration management sy ii libjs-prototype 1.6.1-1 JavaScript Framework for dynamic w ii libjs-scriptaculous 1.8.3-1 JavaScript library for dynamic web ii rails2.2.3-2 MVC ruby based framework geared fo ii rake 0.8.7-1 a ruby build program ii redmine-pgsql0.9.2-2 metapackage providing PostgreSQL d ii ruby 4.2 An interpreter of object-oriented ii ruby1.8 1.8.7.249-1 Interpreter of object-oriented scr Versions of packages redmine recommends: pn libapache2-mod-fcgid (no description available) ii libfcgi-ruby1.8 [libfcgi-ruby 0.8.7-4.1 FastCGI library for Ruby Versions of packages redmine suggests: pn libopenid-ruby (no description available) ii librmagick-ruby 2.5.2-1ImageMagick API for Ruby pn libsvn-ruby(no description available) ii thin 1.2.4-1fast and very simple Ruby web serv -- debconf information excluded signature.asc Description: Digital signature
Bug#570171: /usr/lib/ruby/1.8/active_support/test_case.rb: Depends on nonexistant "rails/backtrace_cleaner"
Package: libactivesupport-ruby1.8 Version: 2.3.3-1 Severity: normal File: /usr/lib/ruby/1.8/active_support/test_case.rb While attempting to configure Redmine (via the Debian package), errors were being masked by a second error: no such file to load -- rails/backtrace_cleaner /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require' /usr/share/redmine/vendor/rails/activesupport/lib/active_support/dependencies.rb:153:in `require' /usr/share/redmine/vendor/rails/activesupport/lib/active_support/dependencies.rb:521:in `new_constants_in' /usr/share/redmine/vendor/rails/activesupport/lib/active_support/dependencies.rb:153:in `require' /usr/lib/ruby/1.8/active_support/test_case.rb:24 [...] That last item (/usr/lib/ruby/1.8/active_support/test_case.rb line 24) is the problem here, as it requires 'rails/backtrace_cleaner', which does not exist. I believe it ought to be requiring 'active_support/backtrace_cleaner' instead? (Setting the environment variable "BACKTRACE=1" worked around this for now.) -- System Information: Debian Release: 5.0.3 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libactivesupport-ruby1.8 depends on: ii libbuilder-ruby1.8 2.1.2-1 Ruby library to facilitate program ii libi18n-ruby1.8 0.1.1~git20081120-3 I18n and localization solution (Ru ii libmemcache-client-r 1.5.0-2 Ruby client library for memcached ii libruby1.8 1.8.7.249-1 Libraries necessary to run Ruby 1. ii libtzinfo-ruby1.80.3.14-1Ruby library for transformations b ii libxml-simple-ruby 1.0.12-1Simple Ruby API for reading and wr libactivesupport-ruby1.8 recommends no packages. libactivesupport-ruby1.8 suggests no packages. -- no debconf information signature.asc Description: Digital signature
Bug#566032: qemu-kvm: Unstated dependency on libgssapi_krb5.so.2
Package: qemu-kvm Version: 0.11.1+dfsg-1 Severity: serious Justification: Policy 3.5 In Debian bug #566028, I reported that the latest version of qemu-system had an unstated dependency on libgssapi_krb5.so.2. It seems that qemu-kvm now has the same dependency now as well: % ldd /usr/bin/kvm | grep gss libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x7f7b648e) As in that bug, unless I have package "libgssapi-krb5-2" installed (which is not depended on by any package on my system), I cannot run qemu-kvm. -- Package-specific info: /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU5140 @ 2.33GHz stepping: 6 cpu MHz : 2327.497 cache size : 4096 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr dca lahf_lm bogomips: 4658.61 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU5140 @ 2.33GHz stepping: 6 cpu MHz : 2327.497 cache size : 4096 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr dca lahf_lm bogomips: 4655.03 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: -- System Information: Debian Release: 5.0.3 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages qemu-kvm depends on: ii adduser 3.110 add and remove users and groups ii bridge-utils 1.4-5 Utilities for configuring the Linu ii iproute 20080725-2 networking and traffic control too ii libasound21.0.21a-1 shared library for ALSA applicatio ii libbluetooth3 4.57-1 Library to use the BlueZ Linux Blu ii libbrlapi0.5 3.10~r3724-1+lenny1braille display access via BRLTTY ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib ii libcurl3-gnutls 7.18.2-8lenny3 Multi-protocol file transfer libra ii libgnutls26 2.8.5-2the GNU TLS library - runtime libr ii libncurses5 5.7+20081213-1 shared libraries for terminal hand ii libpci3 1:3.1.4-5 Linux PCI Utilities (shared librar ii libpulse0 0.9.21-1 PulseAudio client libraries ii libsasl2-22.1.22.dfsg1-23+lenny1 Cyrus SASL - authentication abstra ii libsdl1.2debian 1.2.13-2 Simple DirectMedia Layer ii libvdeplug2 2.2.2-3Virtual Distributed Ethernet - Plu ii libx11-6 2:1.1.5-2 X11 client-side library ii python2.5.4-5An interactive high-level object-o ii zlib1g1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages qemu-kvm recommends: ii linux-image-2.6.17 2.6.17-9 Linux 2.6.17 image on AMD64 ii linux-image-2.6.18 2.6.18.dfsg.1-13etch6 Linux 2.6.18 image on AMD64 ii linux-image-2.6.18 2.6.18.dfsg.1-26etch1 Linux 2.6.18 image on AMD64 ii linux-image-2.6.26 2.6.26-19lenny2 Linux 2.6.26 image on AMD64 Versions of packages qemu-kvm suggests: pn debootstrap(no description available) pn hal(no description available) pn samba (no description available) ii vde2 2.2.3-3Virtual Distributed Ethernet -- no debconf information -- System Information: Debian Release: 5.0.3 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versio
Bug#566028: qemu-system: Unstated dependency on libgssapi_krb5.so.2
Package: qemu-system Version: 0.11.1-2 Severity: serious Justification: Policy 3.5 After installing the latest qemu packages, I found qemu would no longer run due to a missing library dependency. % ldd /usr/bin/qemu-system-i386 | grep gss libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x7f126be38000) I had to install the "libgssapi-krb5-2" package to get it working again. Not sure why the Debian package build process didn't pick this up. Note that this problem also occurs in "qemu-kvm" as of the latest version. I'll be reporting it there as well. -- System Information: Debian Release: 5.0.3 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages qemu-system depends on: ii libasound21.0.21a-1 shared library for ALSA applicatio ii libbluetooth3 4.57-1 Library to use the BlueZ Linux Blu ii libbrlapi0.5 3.10~r3724-1+lenny1braille display access via BRLTTY ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib ii libcurl3-gnutls 7.18.2-8lenny3 Multi-protocol file transfer libra ii libesd0 0.2.36-3 Enlightened Sound Daemon - Shared ii libgnutls26 2.8.5-2the GNU TLS library - runtime libr ii libncurses5 5.7+20081213-1 shared libraries for terminal hand ii libpulse0 0.9.21-1 PulseAudio client libraries ii libsasl2-22.1.22.dfsg1-23+lenny1 Cyrus SASL - authentication abstra ii libsdl1.2debian 1.2.13-2 Simple DirectMedia Layer ii libvdeplug2 2.2.2-3Virtual Distributed Ethernet - Plu ii libx11-6 2:1.1.5-2 X11 client-side library ii zlib1g1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages qemu-system recommends: ii bochsbios 2.4.2-1 BIOS for the Bochs emulator ii openbios-ppc1.0+svn505-1 PowerPC Open Firmware ii openbios-sparc 1.0-1SPARC Open Firmware ii openhackware0.4.1-4 OpenFirmware emulator for PowerPC ii qemu-utils 0.11.1-2 QEMU utilities ii vde22.2.2-3 Virtual Distributed Ethernet ii vgabios 0.6c-2 VGA BIOS software for the Bochs an Versions of packages qemu-system suggests: pn kqemu-source (no description available) pn samba (no description available) -- no debconf information signature.asc Description: Digital signature
Bug#565485: bluez-utils: 'rfcomm listen' wastes a lot of CPU
Package: bluez-utils Version: 4.57-1 Severity: normal I use 'rfcomm listen' in combination with 'gpspipe' to relay GPS data from my eeePC to my Blackberry. I noticed, however, that the CPU overhead from 'rfcomm listen' is quite significant -- over 10% on my eeePC 901. Running 'strace' reveals that rfcomm is in a tight loop between 'waitpid' (with WNOHANG) and 'ppoll' (with a 200 nanosecond(!!) timeout). This is evidently the source of the extreme CPU usage. If it's critical that rfcomm know the child has died ASAP, I would expect it should be watching for the SIGCHLD signal rather than trying to use waitpid(). If it's not all that critical, it probably doesn't need to be watching for child death at a rate of five millions checks per second. :) -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (990, 'stable'), (500, 'oldstable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages bluez-utils depends on: ii bluetooth 3.36-3 Bluetooth stack utilities bluez-utils recommends no packages. bluez-utils suggests no packages. -- no debconf information signature.asc Description: Digital signature
Bug#564168: net/http.rb: Error on page fetch exception (regression)
Package: libruby1.8
Version: 1.8.7.248-1
Severity: normal
Tags: patch
I have some code that does web fetches and sometimes expects them to
fail, but interprets the failure and continues running.
That's how it used to work, but as of the latest libruby1.8 upgrade, it
breaks with the following exception:
/usr/lib/ruby/1.8/net/http.rb:1060:in `request': undefined method `closed?' for
nil:NilClass (NoMethodError)
The problem is evidently that @socket may sometimes be nil in this case.
I've attached a patch (against the live net/http.rb file) that seems
to fix the issue, though it ought to be scrutinised a bit more -- I
don't know if it's just masking an deeper underlying problem /
erroneous assumption.
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (990, 'stable'), (500, 'oldstable'), (500, 'unstable'), (500,
'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libruby1.8 depends on:
ii libc6 2.9-7 GNU C Library: Shared libraries
ii libncurses55.7+20081213-1shared libraries for terminal hand
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
libruby1.8 recommends no packages.
libruby1.8 suggests no packages.
-- no debconf information
--- /usr/lib/ruby/1.8/net/http.rb.orig 2010-01-07 23:53:20.0 -0500
+++ /usr/lib/ruby/1.8/net/http.rb 2010-01-07 23:52:54.0 -0500
@@ -1057,7 +1057,7 @@
res
rescue => exception
D "Conn close because of error #{exception}"
- @socket.close unless @socket.closed?
+ @socket.close unless @socket.nil? || @socket.closed?
raise exception
end
signature.asc
Description: Digital signature
Bug#504319: lighttpd: Unnecessary restarts to rotate logs
Package: lighttpd Version: 1.4.19-5 Severity: minor The /etc/logrotate.d/lighttpd postrotate script uses the lighttpd initscript with the 'reload' argument, which reloads the configuration via a "graceful" SIGINT shutdown and restart. (Note that the current SIGINT shutdown isn't actually particularly graceful; see the other bug, #504315, that I just filed.) The more correct approach would be to send a SIGHUP to lighttpd, which causes it to just close and reopen the log files. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lighttpd depends on: ii libattr1 1:2.4.43-1Extended attribute shared library ii libbz2-1.0 1.0.5-1 high-quality block-sorting file co ii libc6 2.7-14GNU C Library: Shared libraries ii libfam02.7.0-13.3Client library to control the FAM ii libldap-2.4-2 2.4.11-1 OpenLDAP libraries ii libpcre3 7.6-2.1 Perl 5 Compatible Regular Expressi ii libssl0.9.80.9.8g-13 SSL shared libraries ii libterm-readline-perl- 1.0302-1 Perl implementation of Readline li ii lsb-base 3.2-20Linux Standard Base 3.2 init scrip ii mime-support 3.44-1MIME files 'mime.types' & 'mailcap ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime lighttpd recommends no packages. Versions of packages lighttpd suggests: ii apache2-utils 2.2.9-10 utility programs for webservers ii openssl 0.9.8g-13 Secure Socket Layer (SSL) binary a pn rrdtool(no description available) -- no debconf information signature.asc Description: Digital signature
Bug#504315: lighttpd: Debian "graceful" restart isn't
Package: lighttpd Version: 1.4.19-5 Severity: normal When lightttpd receives a SIGINT, it immediately closes the listener socket for new connections. While it continues to serve old connections (including keepalive sessions), any new incoming connections will be refused. http://blog.lighttpd.net/articles/2005/09/02/graceful-restart The correct approach to graceful restart in lighttpd is to send a SIGINT to the existing lighttpd, and then very quickly launch a new one to resume listening for new connections. With the current Debian initscript behaviour, graceful restart on a busy server is arguably less graceful than a "hard" restart, since many clients are affected by refused connections, all for the sake of not interrupting the lucky few clients that had existing connections. (Many of those connections are just unused keepalives that will time out anyway.) In the upstream stock rc.lighttpd script, they start a new lighttpd immediately after sending the SIGINT to the old one. See line 120: http://redmine.lighttpd.net/repositories/entry/lighttpd/trunk/doc/rc.lighttpd (My understanding is that killproc is like killall and does not wait for the process to terminate.) I would tend to assume the time it takes to start lighttpd (to the point where it wants to bind on the listening port) far exceeds the time it takes for an existing one to respond to the SIGINT and free up the port. However, if the existing lighttpd is heavily swapped out or very busy, I could see this being a race condition. If the risk of a race condition is high enough to prevent this behaviour being adopted in Debian, then I guess this should be forwarded as an upstream bug. Ideally, to avoid a race condition, the new lighttpd would get to the point where it's ready to bind to the ports, then wait for some indication that it should proceed. Perhaps the best approach would be a special graceful-restart command-line parameter to lighttpd that triggers behaviour like so: 1. New: Start up, parse config files, get ready to bind. 2. New: Read the PID of the old lighttpd from the pidfile. 3. New: Update the pidfile with the new PID. 4. New: Issue a graceful-stop signal to the old PID. 5. Old: Read the PID of the new lighttpd from the pidfile. 6. Old: Unbind ports. 7. Old: Issue a graceful-start signal to the new PID. 8. New: Bind to listening ports and resume startup process. A less ideal approach is just to have the initscript not start the new lighttpd until it has some indication that the listeners have been closed. Downtime is increased but should still be fairly short, especially compared to the current behaviour. P.S.: Please also note related bug #419: http://redmine.lighttpd.net/issues/show/419 Bug #419 is currently suppressed by the existing Debian initscript behaviour, but may come up when this bug is fixed. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lighttpd depends on: ii libattr1 1:2.4.43-1Extended attribute shared library ii libbz2-1.0 1.0.5-1 high-quality block-sorting file co ii libc6 2.7-14GNU C Library: Shared libraries ii libfam02.7.0-13.3Client library to control the FAM ii libldap-2.4-2 2.4.11-1 OpenLDAP libraries ii libpcre3 7.6-2.1 Perl 5 Compatible Regular Expressi ii libssl0.9.80.9.8g-13 SSL shared libraries ii libterm-readline-perl- 1.0302-1 Perl implementation of Readline li ii lsb-base 3.2-20Linux Standard Base 3.2 init scrip ii mime-support 3.44-1MIME files 'mime.types' & 'mailcap ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime lighttpd recommends no packages. Versions of packages lighttpd suggests: ii apache2-utils 2.2.9-10 utility programs for webservers ii openssl 0.9.8g-13 Secure Socket Layer (SSL) binary a pn rrdtool(no description available) -- no debconf information signature.asc Description: Digital signature
Bug#503853: gnupg: Sometimes hangs on truncated binary input
Some additional info: When I say "only hangs sometimes", I mean for particular inputs, not each time I run "gpg --verify". That is, when I generate foo and truncate one byte, the result is sometimes just unparseable, and sometimes results in a hang. I've attached an example that works, but hangs when one byte is truncated. example.gpg Description: Binary data signature.asc Description: Digital signature
Bug#503853: gnupg: Sometimes hangs on truncated binary input
Package: gnupg Version: 1.4.9-3 Severity: normal Here's the sequence of events: % echo '1234' | gpg --sign > foo % ls -l foo -rw-r--r-- 1 wisq wisq 98 2008-10-28 15:19 foo % dd if=foo of=bar bs=1 count=97 97+0 records in 97+0 records out 97 bytes (97 B) copied, 0.000480021 s, 202 kB/s % gpg --verify bar Note that this only hangs sometimes. Other times, it correctly detects the error: % gpg --verify bar gpg: fatal: zlib inflate problem: invalid distance code secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 When it hangs, the output of --debug-all shows gpg: DBG: enter inflate: avail_in=1, avail_out=8071 gpg: DBG: leave inflate: avail_in=0, avail_out=8070, zrc=0 gpg: DBG: iobuf-1.0: underflow: eof (no filter) gpg: DBG: enter inflate: avail_in=1, avail_out=8070 gpg: DBG: leave inflate: avail_in=0, avail_out=8069, zrc=0 gpg: DBG: iobuf-1.0: underflow: eof (no filter) gpg: DBG: enter inflate: avail_in=1, avail_out=8069 gpg: DBG: leave inflate: avail_in=0, avail_out=8068, zrc=0 gpg: DBG: iobuf-1.0: underflow: eof (no filter) etc., looping forever. The main problem is that this renders GnuPG much less useful for unattended operation on arbitrary binary data supplied by untrusted peers -- e.g. for a service that verifies incoming data and takes action on the data if it trusts the signature, like the one I'm designing (to handle dynamic DNS updates). For such a service, this would constitute a local denial-of-service if the process limits its GnuPG workers, or a system-wide denial-of- service if it doesn't. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnupg depends on: ii gpgv 1.4.9-3 GNU privacy guard - signature veri ii libbz2-1.0 1.0.5-1 high-quality block-sorting file co ii libc6 2.7-14GNU C Library: Shared libraries ii libreadline5 5.2-3 GNU readline and history libraries ii libusb-0.1-4 2:0.1.12-12 userspace USB programming library ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages gnupg recommends: ii libldap-2.4-2 2.4.11-1 OpenLDAP libraries Versions of packages gnupg suggests: pn gnupg-doc (no description available) ii imagemagick 7:6.3.7.9.dfsg1-2+b2 image manipulation programs pn libpcsclite1 (no description available) ii xloadimage 4.1-16 Graphics file viewer under X11 -- no debconf information signature.asc Description: Digital signature
Bug#483439: zsh-beta: Large file support missing
Package: zsh-beta Version: 4.3.6-dev-0+20080516-1 Severity: normal zsh can write to oversize files, but zsh-beta can't: --- [EMAIL PROTECTED]:~% rm testfile [EMAIL PROTECTED]:~% dd of=testfile bs=1 seek=2147483645 count=1 if=/dev/zero 1+0 records in 1+0 records out 1 byte (1 B) copied, 9.2614e-05 s, 10.8 kB/s [EMAIL PROTECTED]:~% zsh-beta -c 'echo foo >> testfile' zsh:echo:1: write error: file too large zsh: exit 1 zsh-beta -c 'echo foo >> testfile' [EMAIL PROTECTED]:~% zsh -c 'echo foo >> testfile' [EMAIL PROTECTED]:~% zsh-beta -c 'echo foo >> testfile' zsh:1: value too large for defined data type: testfile zsh: exit 1 zsh-beta -c 'echo foo >> testfile' [EMAIL PROTECTED]:~% zsh -c 'echo foo >> testfile' --- -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages zsh-beta depends on: ii libc6 2.7-10 GNU C Library: Shared libraries ii libcap2 2.09-1 support for getting/setting POSIX. ii libncursesw5 5.6+20080308-1 Shared libraries for terminal hand ii passwd1:4.1.1-1 change and administer password and Versions of packages zsh-beta recommends: ii libpcre37.4-1+lenny1 Perl 5 Compatible Regular Expressi -- no debconf information signature.asc Description: Digital signature
Bug#468654: zsh: rsync completion fails to complete remote paths with spaces
On Fri, Feb 29, 2008 at 07:57:55PM -0500, Clint Adams wrote: > Adrian, does this do the trick? Indeed, it works fine. signature.asc Description: Digital signature
Bug#468654: zsh: rsync completion fails to complete remote paths with spaces
Package: zsh
Version: 4.3.5-4
Severity: normal
Tags: patch
If I have the following on host 'alpha':
/tmp/foo bar baz/foo
/tmp/foo bar baz/bar
/tmp/foo bar baz/baz
I can do this:
% rsync alpha:/tmp/foo
--> % rsync alpha:/tmp/foo\\\ bar\\\ baz/
But I can't continue:
% rsync alpha:/tmp/foo\\\ bar\\\ baz/
--> no response
Tracing this, I found that it ran a failing 'ls' via ssh, something akin
to this:
ssh -a -x alpha ls -d1FL "/tmp/foo bar baz/*"
This fails because the quoting only makes the argument appear as a
single argument to 'ssh'; when ssh passes the command to the remote
host, it comes out as trying to list three different files.
The solution is to double-quote the parameter, akin to this:
ssh -a -x alpha ls -d1FL "\"/tmp/foo bar baz/\"*"
I've attached a patch. I'm no zsh expert, so it needs review -- I
don't know if I've fixed one thing and broken another. But it does
seem to work for this situation.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (900, 'unstable'), (400, 'testing'), (300, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages zsh depends on:
ii libc6 2.7-5 GNU C Library: Shared libraries
ii libcap1 1:1.10-14 support for getting/setting POSIX.
ii libncursesw5 5.6+20080119-1 Shared libraries for terminal hand
Versions of packages zsh recommends:
ii libpcre3 7.4-1 Perl 5 Compatible Regular Expressi
-- debconf information:
zsh/rcmove:
--- /usr/share/zsh/functions/Completion/Unix/_rsync 2008-02-28 00:39:09.0 -0500
+++ /usr/share/zsh-beta/functions/Completion/Unix/_rsync 2008-02-29 14:46:52.0 -0500
@@ -58,7 +58,7 @@
elif compset -P 1 '*:'; then
if zstyle -T ":completion:${curcontext}:files" remote-access; then
-remfiles=(${(M)${(f)"$(_call_program files ssh -a -x ${IPREFIX%:} ls -d1FL "${(Q)PREFIX%%[^./][^/]#}\*" 2>/dev/null)"}%%[^/]#(|/)})
+remfiles=(${(M)${(f)"$(_call_program files ssh -a -x ${IPREFIX%:} ls -d1FL "\"${(Q)PREFIX%%[^./][^/]#}\"\*" 2>/dev/null)"}%%[^/]#(|/)})
compset -P '*/'
compset -S '/*' || suf='remote file'
signature.asc
Description: Digital signature
Bug#432890: graphviz: 'dot' creates corrupted output for certain input (regression)
On Thu, Jul 12, 2007 at 11:25:53PM +0200, Cyril Brulebois wrote: > Thanks for the different output formats you tried, it shows it is > not only an output plugin problem. Yeah. Also, after I sent the report, I checked the SVG file, and it looks like it tries to declare an SVG image 23.91 inches wide by 14913089.86 inches tall, which would explain the too-much-memory / file-too-big errors. > > This file worked previously, and downgrading to version 2.8-2.6 made > > it work fine again, so this is apparently a regression issue. > > Thanks for testing this too. No problem -- it was mostly a question of finding a version that worked, since I needed those diagrams rebuilt ASAP. :) > If you have more files that fail, feel free to link to them, or send > them to me by private mail. I ran a test and it looks like item #3008's reverse map (the one I posted in my original report) was the only file that fails. This is from a set of 653 'dot' diagrams in total. I noted from your report that shortening both 'Catapulse Battery' and 'Strange Particles' made it work normally. I've confirmed this on my end; the SVG dimensions reduce to a much more reasonable 9.64 inches tall. Note that both 'Catapulse Battery' and 'Strange Particles' (and even longer names) are featured in the many other similar diagrams I made for my site (http://www.wisq.net/games/seed/items/), so this is definitely some sort of internal error rather than just a generic case of labels being too large. signature.asc Description: Digital signature
Bug#432890: graphviz: 'dot' creates corrupted output for certain input (regression)
Package: graphviz
Version: 2.12-3
Severity: normal
While attempting to regenerate some old graphs, I found that 'dot' was
producing corrupted PostScript output for a certain .dot file.
The offending file is available at the following URL (2700 bytes):
http://kochi.wisq.net/misc/demo/i3008_reverse.dot
PostScript creation (-Tps2) raises no errors, but 'convert'
(ImageMagick), 'gv', and 'kghostscript' are all unable to parse
the result.
Attempting to create a PNG (-Tpng) raises errors but does not exit with
a non-zero status:
gd warning: product of memory allocation multiplication would
exceed INT_MAX, failing operation gracefully
Error: gdImageCreate returned NULL. Malloc problem?
Creating an SVG file (-Tsvg) works, but the file cannot be opened with
the Gimp ('unknown reason') nor converted with 'convert':
pwrite64(4, "\0", 1, 14791876266719) = -1 EFBIG (File too large)
--- SIGXFSZ (File size limit exceeded) @ 0 (0) ---
Creating an imagemap file (-Tcmapx) results in an empty element.
This file worked previously, and downgrading to version 2.8-2.6 made
it work fine again, so this is apparently a regression issue.
Oversized allocation seems to be the overall error theme.
I have not verified if this is the only file that fails with 2.12-3;
'make' simply stopped at the first error. If it helps, I can
catalogue the .dot files that fail.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (400, 'testing'), (300, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.16-2-686
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages graphviz depends on:
ii libgraphviz3 2.12-3 rich set of graph drawing tools
graphviz recommends no packages.
-- no debconf information
signature.asc
Description: Digital signature
Bug#308110: Launching on 'about:blank' loads no page; denies functionality.
On Mon, Jun 11, 2007 at 11:35:33AM +0200, David MartÃnez Moreno wrote: > Hello, Adrian. I do not understand completely your comment. > > If I run "konqueror about:blank" from konsole, I get a blank > konqueror with the cursor ready in the location bar. Isn't it what > you want? This behaviour is fine -- indeed, perfect -- and is precisely the reason I still use "konqueror about:blank" as my launch shortcut. The bug in this case is that a large portion of Konqueror functionality is disabled in this initial state. It is as if Konqueror is only half leaded. Examples: * I cannot open new tabs. Since this condition is not remedied until after I successfully access a webpage, if the website I try to access is slow or down, I cannot open a new tab to initiate a second request while waiting for the first. * I cannot stop a request from loading. In this case, the menu actually shows the 'stop' option, but neither the menu option nor the keyboard command (escape) has any effect. This is particularly annoying when combined with the 'cannot open new tabs' issue. A common scenario: I enter a URL, but it is taking a long time to load. Since I cannot open a second tab, I instead hit escape and type in a different URL. However, in the middle of entering the second URL, the first URL loads, erasing the second URL I was typing. * The entire 'Tools' menu is nonfunctional. Most options are missing; the only two available options are disabled. I cannot, for example, disable or enable the use of the HTTP proxy/cache, nor access the list of crashes in case my last session crashed. * I cannot show or hide the menubar. If I am unfortunate enough to have exited a prior session with both the location bar and menu bar disabled (which I occasionally do for demonstrations), I am not aware of any way to proceed; I have to exit and launch on a different URL. There are likely other issues, but these are the ones that come up the most often. I still use Konqueror in this state simply because the majority of launches don't invoke any of the above issues. However, I reported this bug because they do occur (under my own personal usage pattern), and I was hoping the underlying issue could be dealt with. Regardless of the cause, it still seems odd to me that I can launch "konqueror about:blank" and end up in state A, then type "about:blank" into the location bar and end up in (drastically different) state B. signature.asc Description: Digital signature
Bug#308110: Launching on 'about:blank' loads no page; denies functionality.
I understand this is a low priority issue, but it should not be mistaken for a mere corner case that will never be used. I encounter this bug every single day; I have simply grown accustomed to it and now routinely work around it, when it affects me at all. I always launch Konqueror via 'konqueror about:blank' because I prefer to begin browsing from a blank page rather than a big blue introduction to Konqueror (the about:konqueror page), which I find distracting. I could make my own blank HTML file and launch on that instead, but then I would need to clear the location bar to type in a URL. What I find strange is why Konqueror is willing to launch in a "half-loaded" state, rather than actually loading the real about:blank page (which exhibits none of these issues). In any case, this bug is minor (and apparently esoteric) enough that I don't really see the need to reopen it. Just thought I would comment. signature.asc Description: Digital signature
Bug#425937: libhtml-mason-perl: 'exec' on CGI-based request does not return a value.
Package: libhtml-mason-perl
Version: 1:1.35-3
Severity: normal
Tags: patch
HTML::Mason::Request::CGI subclasses HTML::Mason::Request to add
additional CGI functionality. Among other things, it overrides the
'exec' method, performing CGI-related actions based on the return
value of the underlying standard 'exec' call.
What it then fails to do is to eventually pass on the return value
of the underlying 'exec' call. This causes problems for anything
that relies on the return value of a Mason template -- code that
works in mod_perl or in a standalone manner will mysteriously fail
in a CGI context.
I've included a patch to resolve this omission.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (400, 'testing'), (300, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.16-2-686
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libhtml-mason-perl depends on:
ii libcache-cache-perl 1.05-2 Managed caches of persistent infor
ii libclass-container-perl 0.12-2 Glues object frameworks together t
ii libexception-class-perl 1.23-1 a module that allows you to declar
ii libparams-validate-perl 0.77-1 validate parameters to Perl method
ii perl 5.8.8-7Larry Wall's Practical Extraction
ii perl-base [libscalar-list-uti 5.8.8-7The Pathologically Eclectic Rubbis
Versions of packages libhtml-mason-perl recommends:
ii libapache-mod-perl 1.29.0.4-4.1 integration of perl with the Apach
ii libapache-request-perl 1.33-1 Generic Apache Request Library
ii libapache2-mod-perl22.0.2-2.4Integration of perl with the Apach
-- no debconf information
Thu May 24 19:14:03 EDT 2007 Adrian Irving-Beer <[EMAIL PROTECTED]>
* Return SUPER::exec return value in CGI 'exec' method.
diff -rN -u old-libhtml-mason-perl-1.35/lib/HTML/Mason/CGIHandler.pm new-libhtml-mason-perl-1.35/lib/HTML/Mason/CGIHandler.pm
--- old-libhtml-mason-perl-1.35/lib/HTML/Mason/CGIHandler.pm 2007-05-24 19:18:55.098774801 -0400
+++ new-libhtml-mason-perl-1.35/lib/HTML/Mason/CGIHandler.pm 2007-05-24 19:18:55.130775815 -0400
@@ -207,6 +207,8 @@
and (!$retval or $retval==200)) {
$r->send_http_header();
}
+
+return $retval;
}
sub redirect {
signature.asc
Description: Digital signature
Bug#424688: libmasonx-request-withapachesession-perl: Wrong request object passed to Apache::Session::Wrapper under CGI
Package: libmasonx-request-withapachesession-perl
Version: 0.30-2
Severity: normal
Tags: patch
I recently attempted to get this module working under FastCGI using
the HTML::Mason::CGIHandler module -- which this module is apparently
designed to support, as noted by its reference to the CGIHandler's
presence in deciding how to operate.
The CGIHandler exposes the CGI object (CGI::Fast in this case) as
$m->cgi_object. This provides methods such as 'param' to query the
submitted URL parameters, as needed to get the session ID from such a
parameter.
CGIHandler also offers a fake Apache object (HTML::Mason::FakeApache)
as $m->cgi_request. This contains methods such as 'headers_in' and
'headers_out' to set and read HTTP headers, as needed to get and set
the session ID via cookies.
Apache::Session::Wrapper requires both of these capabilities.
MasonX::Request::WithApacheSession is correctly passing the former,
but is also passing the former in lieu of the latter. This prevents
the module from working whatsoever in a CGI environment.
The attached patch sends the correct objects when initialising
Apache::Session::Wrapper. I believe this is the correct approach,
and I now have session tracking set up identically to when I was
using mod_perl.
Note that I have not tested what effect this may have on
MasonX::Request::WithMultiSession. However, given that it
subclasses MasonX::Request::WithApacheSession, I believe this patch
will fix both.
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable'), (400, 'testing'), (300, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.16-2-686
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Versions of packages libmasonx-request-withapachesession-perl depends on:
ii libapache-request-perl1.33-1 Generic Apache Request Library
ii libapache-session-perl1.81-1 Perl modules for keeping persisten
ii libapache-session-wrapper-per 0.33-1 A simple wrapper around Apache::Se
ii libhtml-mason-perl1:1.35-1 HTML::Mason Perl module
ii perl [perl5] 5.8.8-7Larry Wall's Practical Extraction
libmasonx-request-withapachesession-perl recommends no packages.
-- no debconf information
--- /usr/share/perl5/MasonX/Request/WithApacheSession.pm2005-11-18
10:47:31.0 -0500
+++ lib/MasonX/Request/WithApacheSession.pm 2007-05-16 15:00:50.0
-0400
@@ -87,9 +87,9 @@
param_object => $self->apache_req,
);
}
-elsif ( $self->can('cgi_object') )
+elsif ( $self->can('cgi_request') && $self->can('cgi_object') )
{
-%extra = ( header_object => $self->cgi_object,
+%extra = ( header_object => $self->cgi_request,
param_object => $self->cgi_object,
);
}
signature.asc
Description: Digital signature
Bug#418923: Manpage: copy-dirlinks is -k, not -K
Package: rsync Version: 2.6.9-3 Severity: minor "--copy-dirlinks" is incorrectly labelled as shortcut "-K" in the "OPTIONS" section of the manpage. The "OPTIONS SUMMARY" section appears to have it right. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (400, 'testing'), (300, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages rsync depends on: ii libacl1 2.2.41-1 Access control list shared library ii libc6 2.3.6.ds1-11 GNU C Library: Shared libraries ii libpopt01.10-3 lib for parsing cmdline parameters ii lsb-base3.1-22 Linux Standard Base 3.1 init scrip rsync recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#396461: offlineimap: Dies trying to upload messages with invalid dates
Package: offlineimap Version: 4.0.14 Severity: normal I received a spam with a "Date:" header of "Tue, 31 Nov 2006". It downloaded fine, but when I moved it to my "spam" folder, it would crash whenever it tried to upload the message (back to the IMAP server). Obviously, there is no thirty-first of November, but offlineimap doesn't recognise that; instead, it tries to send that date to the IMAP server (Cyrus), which rejects it, causing a crash. Thread 'New msg sync from spam' terminated with exception: Traceback (most recent call last): [...] error: APPEND command error: BAD ['Invalid date-time in Append command'] Last 11 debug messages logged for New msg sync from spam prior to exception: imap: savemessage: called imap: savemessage: using date "31-Nov-2006 18:42:06 -0500" [...] Editing the mail and changing the "Date:" header to the 30th of November made everything work fine again. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (400, 'testing'), (300, 'stable'), (200, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages offlineimap depends on: ii python2.4.3-11 An interactive high-level object-o ii python-support0.4.3 automated rebuilding support for p offlineimap recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#387173: xvnc4viewer: Terminal password entry broken when 0 to 7 characters in length
Package: xvnc4viewer Version: 4.1.1+X4.3.0-17 Severity: normal This is similar to bug #386404, but whereas that bug seems to have been solved, this one is still open for me as of package version 17. When connecting from my Debian laptop (xvnc4viewer) to a Windows 2000 Server (RealVNC, latest version), terminal entry of passwords fails for any password of length 0 to 7. Lengths 8 and 9 (and presumably longer) appear to work fine. GUI password entry always works fine. Note that my laptop runs Dvorak as a keyboard layout, if that makes a difference. However, the passwords I used to test (every length from 1 to 9) were simply sequences of the letter 'a', which is the same on both layouts. I also generally work inside 'screen' in a urxvt, but I tested from a plain urxvt and had the same issue. Also note that '0' is not a typo. Length 0 passwords suffer the same issue; they work in the GUI but not in the terminal. (This is not to be confused with 'no authentication', which does not prompt for a password at all.) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (400, 'testing'), (300, 'stable'), (200, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages xvnc4viewer depends on: ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries ii libgcc1 1:4.2-20060709-1 GCC support library ii libice6 1:1.0.1-1X11 Inter-Client Exchange library ii libsm6 6.9.0.dfsg.1-6 X Window System Session Management ii libstdc++6 4.2-20060709-1 The GNU Standard C++ Library v3 ii libx11-66.9.0.dfsg.1-6 X Window System protocol client li ii libxext66.9.0.dfsg.1-6 X Window System miscellaneous exte ii zlib1g 1:1.2.3-13 compression library - runtime xvnc4viewer recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#386649: sysvinit: Dangerous instructions in NEWS.Debian, removes packages
Package: sysvinit Version: 2.86.ds1-18 Severity: critical Justification: breaks unrelated software The NEWS.Debian has these instructions on how to fix the broken init.d links caused by bug #386500: for p in `dpkg -S /etc/init.d/*|cut -d: -f1|sort -u`; do apt-get --reinstall install -y $p done This fails to check if a package has been removed but not purged -- hence its init.d script exists, but the package is no longer on the system. In my case, it attempted to reinstall "xfs-xtt", which (due to conflicting with the current version of X) effectively attempted to remove every single X-based package on my system (270 packages). Because of the "-y", no prompt is issued; many packages were removed before I realised what was going on and aborted it. (Please let me know if this is the correct severity, BTW. The instructions may break unrelated packages, but the software / package itself does not, and only some users will experience this. I was hesitant to report it at "critical", but deemed it better to risk crying wolf than to understate the issue.) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages sysvinit depends on: ii initscripts 2.86.ds1-18 Scripts for initializing and shutt ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libselinux1 1.30.27-2 SELinux shared libraries ii libsepol11.12.26-1 Security Enhanced Linux policy lib ii sysv-rc 2.86.ds1-18 System-V-like runlevel change mech sysvinit recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#380656: dosbox: 0.63 to 0.65 fatal regression running "Game Wizard" tool
Package: dosbox Version: 0.65-1 Severity: normal "Game Wizard" tool is a DOS Terminate and Stay Resident (TSR) program that searches and edits memory, and can "lock" memory bytes to a specific value. Secondary functions include altering execution speed, taking screenshots, boss screen, saving and loading of program state, intentionally "crashing" a program to the command prompt, and swapping out a program to open a DOS shell. These are all operated via a menu that is triggered by a hotkey during the execution of a program. It suspends execution (properly handling a configured sound card to avoid glitches) and may swap DOS memory around for some operations. (To avoid issues with XMS and EMS, I have it swapping to disk.) In 0.63, it would run, albeit only with the "normal" or "simple" cores. I have used it often in this configuration without issue. Running with the "dynamic" core exits with "Illegal option", and the "full" core appears to freeze (but could just be extremely slow). In 0.65, it fails to run with any core. CPU cores "normal" and "simple" exit dosbox with "CPU:GRP5:Illegal Call 7". The "full" core continues to freeze. The "dynamic" core simply exits as if the command was a no-op, neither loading the program nor crashing dosbox. As far as I can tell, the program can no longer run whatsoever under dosbox version 0.65. In the likely event that a developer needs the program for debugging purposes, please contact me directly at the address on this e-mail. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (400, 'testing'), (300, 'stable'), (200, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages dosbox depends on: ii libasound21.0.11-7 ALSA library ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libgcc1 1:4.2-20060709-1 GCC support library ii libpng12-01.2.8rel-5.1 PNG library - runtime ii libsdl-net1.2 1.2.5-7network library for Simple DirectM ii libsdl-sound1.2 1.0.1-9+b1 Decoder of several sound file form ii libsdl1.2debian 1.2.10-3 Simple DirectMedia Layer ii libstdc++64.2-20060709-1 The GNU Standard C++ Library v3 ii xlibmesa-gl [libgl1] 6.9.0.dfsg.1-5bpo2 Mesa 3D graphics library [X.Org] ii zlib1g1:1.2.3-13 compression library - runtime dosbox recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#378052: kxmleditor: "Find" fails silently when "Create items on demand" is set
Package: kxmleditor Version: 1.1.4-3 Severity: normal Using "Find" to search for elements I know exist in my document (but are several layers deep and unexpanded), I get a silent failure, marked only by an error on the console: kxmleditor: ERROR: KXE_TreeView::selectNode can't find an item to the given node. I would tend to assume this is because the node is created on demand, and hence does not exist yet, so the tree view widget cannot select it. Turning off "Create items on demand" in the settings, I find I can search as normal. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (400, 'testing'), (300, 'stable'), (200, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.16-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages kxmleditor depends on: ii kdelibs4c2a 4:3.5.3-1 core libraries and binaries for al ii libacl1 2.2.37-1 Access control list shared library ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libattr1 2.4.32-1 Extended attribute shared library ii libaudio2 1.7-9 The Network Audio System (NAS). (s ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libfam0 2.7.0-10 Client library to control the FAM ii libfontconfig12.3.2-7generic font configuration library ii libfreetype6 2.2.1-2FreeType 2 font engine, shared lib ii libgcc1 1:4.1.1-8 GCC support library ii libice6 6.9.0.dfsg.1-6 Inter-Client Exchange library ii libidn11 0.5.18-2 GNU libidn library, implementation ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libpng12-01.2.8rel-5.1 PNG library - runtime ii libqt3-mt 3:3.3.6-2 Qt GUI Library (Threaded runtime v ii libsm66.9.0.dfsg.1-6 X Window System Session Management ii libstdc++64.1.1-8The GNU Standard C++ Library v3 ii libx11-6 6.9.0.dfsg.1-6 X Window System protocol client li ii libxcursor1 1.1.5.2-5 X cursor management library ii libxext6 6.9.0.dfsg.1-6 X Window System miscellaneous exte ii libxft2 2.1.8.2-5.1FreeType-based font drawing librar ii libxi66.9.0.dfsg.1-6 X Window System Input extension li ii libxinerama1 1:1.0.1-4 X11 Xinerama extension library ii libxrandr22:1.1.0.2-4X11 RandR extension library ii libxrender1 1:0.9.0.2-4X Rendering Extension client libra ii libxt66.9.0.dfsg.1-6 X Toolkit Intrinsics ii zlib1g1:1.2.3-13 compression library - runtime kxmleditor recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#371038: tla 1.3.3-3.3 can no longer write to WebDAV archives
Package: tla Version: 1.3.3-3.3 Severity: important An attempted import with tla 1.3.3-3.3. Note that 'wisq' is censored with '' to avoid spamming webcrawlers: % tla import -S -s"Import clean build tree." * creating category [EMAIL PROTECTED]/dboxfe * creating branch [EMAIL PROTECTED]/dboxfe--debian * creating version [EMAIL PROTECTED]/dboxfe--debian--0.1.1 i/o error modifying archive (internal error in archive-pfs.c(pfs_lock_revision)) archive: [EMAIL PROTECTED] path: dboxfe/dboxfe--debian/dboxfe--debian--0.1.1/[EMAIL PROTECTED]/+contents/++revision-lock/+contents The version is left in a locked, non-unlockable (ususable) state and must be manually fixed. Once the archive is cleaned up (remove category 'dboxfe'), I can downgrade to tla 1.3.3-3 and commit. Looks exactly the same up to the GPG prompt, after which I get the standard * imported [EMAIL PROTECTED]/dboxfe--debian--0.1.1 This is 100% reproduceable: If I upgrade back to tla 1.3.3-3.3, again clean the archive, and again try to import (a pre-import copy of) my tree (i.e. replicating the above steps), it continues to fail. I have experienced this with 'commit', too, but at the time, I thought it was a locking error in my archive. This could possibly be an error in libneon25, but I have no way to test that hypothesis. Either way, it's tla that cacks in the end. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (400, 'testing'), (300, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.16-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages tla depends on: ii diff 2.8.1-11 File comparison utilities ii gawk 1:3.1.5.dfsg-4 GNU awk, a pattern scanning and pr ii libc6 2.3.6-13 GNU C Library: Shared libraries ii libneon25 0.25.5.dfsg-5 An HTTP and WebDAV client library ii patch 2.5.9-4Apply a diff file to an original tla recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#296811: SSH hanging issues
I ran into this exact problem today with 1:3.4p1-1.woody.3. It's undoubtedly a server-side MTU issue. I was able to do ssh [EMAIL PROTECTED] /sbin/ifconfig eth0 mtu 1000 and after a brief pause, everything works again. The pause is presumably because it sent me an oversized packet before the command actually executed, but then the MTU took effect, and the retransmission hit the new local MTU limit and was forced to fragment. I do not know why these MTU issues only began affecting me today, since I have SSHed to this machine several times before. However, it bears all the symptoms of an MTU issue, and I have experienced no further trouble since I lowered the server's MTU. signature.asc Description: Digital signature
Bug#355662: Installation report
On Tue, Mar 07, 2006 at 11:36:45AM -0500, Lennart Sorensen wrote: > The ability to add to logical volumes without worrying about where > they start and end makes it much more flexible than partitions > ever were. Right, and that's what I meant -- my dividing it up into multiple partitions was just a leftover habit from the old way of managing disk space. It didn't really make much sense. > Hmm, I have never used the ssh option myself. It's pretty handy. Aside from letting you wander off-site and continue the install, it also lets you do it from a fully-operational system -- multiple terminal windows, copy and paste, etc. > > It did try to load the 'floppy' driver three times, once as part > > of the CD detection process and twice by prompt later. All failed > > due to lack of a floppy drive. Also not a big deal. > > Yeah I know. Not sure what can be done about that. Perhaps just maintain a list of modules that failed to load. The followup prompts (checklists of modules to load) could offer these modules (like floppy) as an option, but unchecked, meaning you can just dismiss the window in its default state without trying to load it again. (Presumably, failing to check anything will also skip the "specify parameters for modules?" dialog.) > The sarge installer uses devfs. Newer installers use udev and hence > a different device naming system. Ah. I did notice that at the installer shell, 'fdisk -l' on some of my installs reported things in /dev/hd* style, some in /dev/ide/* style. That was probably due to trying out various 2.6 and 2.4 install options until I settled on one. > > Deleting it and recreating the volume group (wanted a different > > name) reported 230.09 GB, which I guess is GiB? All the LVM stuff > > seems to be in GiB, while the partitioner seems to be GB. > > Ehm, yeah probably in GiB. Yeah. "df -H" reports e.g. my "200 GB" /home as 212G, and everything else as being similarly larger than I specified. (I used the 'G' suffix for all my installer input, which seemed to be interpreted as gigabytes by the partitioner, but gibibytes by LVM setup.) > Personally I like swap inside LVM. That allows me to resize it > later too if I decide to. Don't even need an extended partition if > all you have is / and LVM partitions. I was under the impression there were certain issues installing swap in LVM, but I've since looked these up, and they were specific situations (like suspend-to-disk) that aren't applicable in my case. I picked the conservative option at the time. But if there are no issues, then sure, that makes sense. > I also run /tmp as tmpfs so I don't bother with a partition for > that either. Ah, excellent idea. This also very much justifies swap in LVM, since you now have to take the amount of tmpfs space allocated into account when considering how much swap to allocate. > > LVVGAttr LSize Origin Snap% Move Copy% [various lines snipped] > > usr wisq_root -wi-ao 5.00G > > var wisq_root -wi-ao 10.00G > > Looks fairly reasonble. I think /usr is too small given that is > where all debian packages install to, unless you don't intend to > install a lot. I might also think of a larger /var unless you > aren't planning to run databases, proxys, etc. Good points all. I did leave about 9 GiB free in unallocated LVM space to extend these if needed, but I may as well put that to use and resize later as needed. I'm thinking I'll double each of the above. (This system will be the root node of a cluster, so there will be plenty of other disks, but this disk is the newest, largest, and quietest, and resides on the fastest machine with the most RAM. So I realise now that I may as well sacrifice mass /home storage for system operations space, and leave the slower disks & machines for all the data hoarding.) Thanks very much for all your suggestions; they certainly made the entire installation report process worthwhile. :) I'll do another install later to take them into account, but I don't forsee running into any additional issues. One last thing: I'll also be testing out the OpenSSI software and seeing how it fares on the 2.6 kernel, but I may need to also change to a 2.4 on my next install. I recall that (experimentally) booting a 2.6 install with a Debian 2.4 kernel resulted in a "udev requires 2.6" message. What will I end up with for /dev if I do a 2.4 install? Old-style static, or devfs? Just wondering what to expect. signature.asc Description: Digital signature
Bug#355662: Installation report
On Tue, Mar 07, 2006 at 09:05:20AM -0500, Lennart Sorensen wrote: > It is correct behaviour. If cfdisk doesn't do the same thing if you > use it to add a partition to an existing partition table, then > cfdisk is broken. I suspect it only rearanged partitions made > within one session, which is reasonable I suppose, and not unheard > of in other fdisk implementations. That appears to be what cfdisk does, yes; any logical partitions created in the current session will be in order based on position on the disk. Neither seems unreasonable, and it was simply the difference that confused me. So no real problem here. > You allocate a partition as LVM physical volume, then you go pick > LVM setup at the top of the partition menu, and it will let you > creat a volume group, and then logical volumes within it. Yeah, I missed that option, I guess. Even in my subsequent meddling with the expert install. Guess being an "expert" means you make assumptions and don't read things carefully. Sorry. ;) > (You don't want root on LVM at this time. Too messy.) My thoughts exactly. Also, subsequent readings of the LVM docs indicated I should also create a single physical LVM volume per physical disk (for simplicity, striping, etc.), unlike my inclination to divide it into chunks -- a throwback to standard partitioning, I suppose, where having a 247-gig partition was a recipe for inflexibility (unless you bought an even bigger disk to move stuff onto). So, my follow-up install: Same system and image. Used 'expert'. I liked all the prompts, and the defaults were usually fine. Liked how it confirmed the CD identity. Very much liked the SSH-based installer, and that it asked me to confirm the SSH host key. It'd be nice if the SSH installer terminated connections more kindly at the end, because it dropped in the middle of the screen and left my terminal reversed and without a cursor. Not a big deal. It did try to load the 'floppy' driver three times, once as part of the CD detection process and twice by prompt later. All failed due to lack of a floppy drive. Also not a big deal. When it came time to set up the volume group, it misreported my 247.1-gig partition as a 43.82-gig partition, and used the /dev/ide/... notation. (I'm guessing this is a udev-style thing I'm just going to have to get used to, eh?) I had to double check the partition table to make sure it wasn't wiping the wrong one (even though the bus, disk, and partition all matched up). Deleting it and recreating the volume group (wanted a different name) reported 230.09 GB, which I guess is GiB? All the LVM stuff seems to be in GiB, while the partitioner seems to be GB. Back in the partition manager after the LVM setup, the fact that each volume occupied two lines (and were all numbered #1) made things a bit cramped and easier to lose track of things. A *very* minor wishlist item would be to condense the information to one line, if possible, perhaps as a numbered list under the LVM volume group heading. Still worked, though, and was a fairly painless process. I liked that I could finally set up the noexec, etc. properties at install time. Final partition table: Device Boot Start End Blocks Id System /dev/hdc1 * 1 122 979933+ 83 Linux /dev/hdc2 123 30401 243216067+ 5 Extended /dev/hdc5 123 365 1951866 82 Linux swap / Solaris /dev/hdc6 366 30401 241264138+ 8e Linux LVM lvs: LVVGAttr LSize Origin Snap% Move Copy% home wisq_root -wi-ao 200.00G tmp wisq_root -wi-ao 1.00G usr wisq_root -wi-ao 5.00G usr_local wisq_root -wi-ao 3.00G var wisq_root -wi-ao 10.00G var_exec wisq_root -wi-ao 1.00G var_tmp wisq_root -wi-ao 1.00G Thanks for another great install. :) signature.asc Description: Digital signature
Bug#355662: Installation report
Package: installation-reports Boot method: netinst CD image booted from CD-R Image version: netinst i386 downloaded at 2006-03-06 21:56 Date: 2006-03-06 22:30 (approx) Machine: Generic tower system Processor: Pentium 4 at 1.8 GHz Memory: 512M. Once had a bad RAM sector, but memtest86+ reports it gone... Partitions: Disk /dev/hdc: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdc1 * 1 122 979933+ 83 Linux /dev/hdc2 123 30401 243216067+ 5 Extended /dev/hdc5 123 244 979933+ 82 Linux swap / Solaris /dev/hdc6 245608046877638+ 8e Linux LVM /dev/hdc76081 1215948829536 8e Linux LVM /dev/hdc8 12160 1823848829536 8e Linux LVM /dev/hdc9 18239 2431748829536 8e Linux LVM /dev/hdc10 24318 3040148869698+ 8e Linux LVM Output of lspci and lspci -n: lspci: :00:00.0 Host bridge: Intel Corporation 82845 845 (Brookdale) Chipset Host Bridge (rev 04) :00:01.0 PCI bridge: Intel Corporation 82845 845 (Brookdale) Chipset AGP Bridge (rev 04) :00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 05) :00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 05) :00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 (rev 05) :00:1f.2 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #1) (rev 05) :00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus (rev 05) :00:1f.4 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #2) (rev 05) :01:00.0 VGA compatible controller: nVidia Corporation NV20 [GeForce3 Ti 200] (rev a3) :02:0c.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 08) :02:0c.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 08) :02:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) lspci -n: :00:00.0 0600: 8086:1a30 (rev 04) :00:01.0 0604: 8086:1a31 (rev 04) :00:1e.0 0604: 8086:244e (rev 05) :00:1f.0 0601: 8086:2440 (rev 05) :00:1f.1 0101: 8086:244b (rev 05) :00:1f.2 0c03: 8086:2442 (rev 05) :00:1f.3 0c05: 8086:2443 (rev 05) :00:1f.4 0c03: 8086:2444 (rev 05) :01:00.0 0300: 10de:0201 (rev a3) :02:0c.0 0401: 1102:0002 (rev 08) :02:0c.1 0980: 1102:7002 (rev 08) :02:0d.0 0200: 10ec:8139 (rev 10) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] (DHCP) Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] (but see issues #1, #2 below) Create file systems:[O] Mount partitions: [O] (but see issue #2 below) Install base system:[O] Install boot loader:[O] Reboot: [O] Comments/Problems: Very well done overall. I like how aptitude is installed by default. I also like how it skipped many of the (usually redundant) steps in the old install, like loading modules (assuming autodetect works). It was interesting how it refrained from bugging me, since things were moving along fine without my input. The number of prompts was kept to a minimum, which is probably ideal for a non-expert install. Only two real issues, neither particularly problematic, and both possibly intentional behaviour. One, as I recall, the partitioner seemed to number partitions "backwards" if I placed them at the end of the partitioned space, i.e. numbering them by the order they were created rather than their position on the disk. I don't know how it would have actually written this to disk, or if writing logical partitions out of order is even possible, but it was the opposite behaviour from the old Debian install partitioning tool (cfdisk) and hence confused me. Two, I noticed mention of LVM in the install process. I chose not to use those options because I didn't want my root on LVM. I was pleased to note that the partitioner offered LVM physical volume allocation. However, I couldn't seem to locate the ability to allocate LVM logical volumes. Furthermore, unlike my previous Debian installs, there was no big gap between the last mounting of a filesystem and the installing of the base system -- a gap where I could use a terminal to perhaps set up the appropriate mounts. So I'm left building my LVM setup after the initial install, and moving parts of the existing system (/usr, etc.) into it. Not a big deal. Overall, an exc
Bug#354901: konqueror: JavaScript loading of external XML always uses cache
Package: konqueror
Version: 4:3.5.0-4
Severity: normal
(Hope this is the correct place to send Konqueror JavaScript issues.)
When using e.g. "doc = document.implementation.createDocument" to
create a DOM document, then "doc.load('some-file.xml')" to load an XML
document (either locally or from the net), the result is cached
(good). But no matter how much you reload the page, turn off caching,
clear the disk cache, etc., it refuses to load the XML document again
until the next browser session.
Evidently, it's not using the same cache as Konqueror itself, because
even if I load the XML file by typing the URL in directly (and get the
current version), it has no impact on the rendered HTML result.
I've attached a demo HTML and XML. (Because I've used no delays to
allow the document time to load, you may need to refresh to see the
text the first time.) Subsequent edits to the XML file have no effect
on the final rendered result, again no matter how much I try to force a
non-cached refresh.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (300, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.12-1-686
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Versions of packages konqueror depends on:
ii kcontrol 4:3.5.0-4 control center for KDE
ii kdebase-kio-plugins 4:3.5.0-4 core I/O slaves for KDE
ii kdelibs4c2a 4:3.5.0-3 core libraries for all KDE applica
ii kdesktop 4:3.5.0-4 miscellaneous binaries and files f
ii kfind 4:3.5.0-4 file-find utility for KDE
ii libacl1 2.2.34-1 Access control list shared library
ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi
ii libattr1 2.4.25-1 Extended attribute shared library
ii libaudio2 1.7-3 The Network Audio System (NAS). (s
ii libc6 2.3.5-12 GNU C Library: Shared libraries an
ii libfam0c102 [libfam0] 2.7.0-6sarge1 client library to control the FAM
ii libfontconfig12.3.2-1.1 generic font configuration library
ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib
ii libgcc1 1:4.0.2-7 GCC support library
ii libice6 6.9.0.dfsg.1-4 Inter-Client Exchange library
ii libidn11 0.5.18-1 GNU libidn library, implementation
ii libjpeg62 6b-11 The Independent JPEG Group's JPEG
ii libkonq4 4:3.5.0-4 core libraries for Konqueror
ii libpng12-01.2.8rel-5 PNG library - runtime
ii libqt3-mt 3:3.3.5-3 Qt GUI Library (Threaded runtime v
ii libsm66.9.0.dfsg.1-4 X Window System Session Management
ii libstdc++64.0.2-7The GNU Standard C++ Library v3
ii libx11-6 6.9.0.dfsg.1-4 X Window System protocol client li
ii libxcursor1 1.1.3-1X cursor management library
ii libxext6 6.9.0.dfsg.1-4 X Window System miscellaneous exte
ii libxft2 2.1.7-1FreeType-based font drawing librar
ii libxi66.9.0.dfsg.1-4 X Window System Input extension li
ii libxinerama1 6.9.0.dfsg.1-4 X Window System multi-head display
ii libxrandr26.9.0.dfsg.1-4 X Window System Resize, Rotate and
ii libxrender1 1:0.9.0.2-1X Rendering Extension client libra
ii libxt66.9.0.dfsg.1-4 X Toolkit Intrinsics
ii zlib1g1:1.2.3-9 compression library - runtime
konqueror recommends no packages.
-- no debconf information
Text from XML document:
test.xml
Description: application/xml
signature.asc
Description: Digital signature
Bug#348584: eclipse-jdt: Won't start without 'eclipse' package
Package: eclipse-jdt Version: 3.1.1-8 Severity: normal With only the 'eclipse-jdt' package installed, I cannot run 'eclipse'; I get the attached logfile. It appears to be an issue with the initial configurator. Since 'eclipse-jdt' is described as "JDT provides a whole Java IDE," I incorrectly assumed this was the package I wanted rather than the entire Eclipse framework. The fact that /usr/bin/eclipse existed made me think I had a complete (but broken) installation. Given that I now find that /usr/bin/eclipse is provided by 'eclipse-platform-common', I find it somewhat odd that it appears unusable unless the top-level 'eclipse' package is installed. (For that matter, I though 'eclipse' was just a metapackage, too.) Is this a real error, or just an error in my assumptions? -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (300, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages eclipse-jdt depends on: ii ant-optional 1.6.5-3Java based build tool like make - ii eclipse-jdt-common3.1.1-8Java Development Tools plug-ins fo ii eclipse-platform 3.1.1-8Eclipse platform without plug-ins ii junit 3.8.1.1-6 Automated testing framework for Ja Versions of packages eclipse-jdt recommends: ii eclipse-jdt-gcj 3.1.1-8Java Development Tools plug-ins fo -- no debconf information !SESSION 2006-01-17 14:48:59.701 --- eclipse.buildId=M20050929-0840 java.version=1.4.2 java.vendor=Kaffe.org project BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_CA Command-line arguments: -os linux -ws gtk -arch x86 !ENTRY org.eclipse.update.configurator 2006-01-17 14:49:03.586 !MESSAGE Unable to find feature.xml in directory: /usr/lib/eclipse/features/org.eclipse.sdk_3.1.1 !ENTRY org.eclipse.update.configurator 2006-01-17 14:49:03.615 !MESSAGE Unable to find feature.xml in directory: /usr/lib/eclipse/features/org.eclipse.pde_3.1.1 !ENTRY org.eclipse.update.configurator 2006-01-17 14:49:03.631 !MESSAGE Unable to find feature.xml in directory: /usr/lib/eclipse/features/org.eclipse.sdk_3.1.1 !ENTRY org.eclipse.update.configurator 2006-01-17 14:49:03.647 !MESSAGE Unable to find feature.xml in directory: /usr/lib/eclipse/features/org.eclipse.pde_3.1.1 !ENTRY org.eclipse.core.runtime 2006-01-17 14:49:19.773 !MESSAGE Product org.eclipse.sdk.ide could not be found. !ENTRY org.eclipse.osgi 2006-01-17 14:49:20.547 !MESSAGE Application error !STACK 1 java.lang.RuntimeException: No application id has been found. at org.eclipse.core.internal.runtime.PlatformActivator$1.run (PlatformActivator.java:204) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:376) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:163) at java.lang.reflect.Method.invoke0 (Method.java) at java.lang.reflect.Method.invoke (Method.java:255) at org.eclipse.core.launcher.Main.invokeFramework (Main.java:334) at org.eclipse.core.launcher.Main.basicRun (Main.java:278) at org.eclipse.core.launcher.Main.run (Main.java:973) at org.eclipse.core.launcher.Main.main (Main.java:948) at java.lang.reflect.Method.invoke0 (Method.java) at java.lang.reflect.Method.invoke (Method.java:255) at org.kaffe.jar.ExecJarName.main (ExecJarName.java:64) at org.kaffe.jar.ExecJar.main (ExecJar.java:57) signature.asc Description: Digital signature
Bug#330248: quagga: Unexpected ospfd "horizon" & segfaults after 0.99 upgrade
On Tue, Sep 27, 2005 at 01:05:37AM +0200, Christian Hammers wrote: > please report this to the Quagga mailing list, I do not know enough > about routing to help you here. I unfortunately lacked the time to report this problem until this weekend. However, 0.99.2 was released on Friday. This appears to have eliminated the "horizon" effect. A fix committed hours before the release perfectly described the other router I mentioned, where ospfd merely crashed rather than behaving improperly. Again, installing 0.99.2 eliminated the crashes I was getting with 0.99.1. I would consider this bug closed when 0.99.2 is released. signature.asc Description: Digital signature
Bug#330248: quagga: Unexpected ospfd "horizon" & segfaults after 0.99 upgrade
Package: quagga Version: 0.99.1-3 Severity: normal I have a laptop, connected via VPN over wireless to a desktop, connected via Ethernet to a local Internet gateway, who is then connected via VPNs to two other Internet gateways. All gateways, plus the desktop and laptop, are a part of an area-0 OSPF network. The three gateways all broadcast a 0.0.0.0 default route, as well as their own internal networks. On my laptop, after upgrading to 0.99, I am no longer able to see any routers beyond the local Internet gateway. Their routes do not show up in my routing table, nor do the routers themselves show up in the "OSPF router routing table" section of "show ip ospf route". As far as my OSPF daemon is concerned, the OSPF network ends there. (All other routers can see each other fine.) The exact same effect occurs if I upgrade Quagga on the desktop (that connects my laptop to the local Internet gateway). I was unable to determine if the broadcasting default (0.0.0.0) routes was part of the problem or not, because by the time I had disabled this, the desktop's ospfd had begun to segfault less than a minute after startup: OSPF: Received signal 11 at 1127774329 (si_addr 0x200a, PC 0xb7f40cf7); aborting ... Program counter: /usr/lib/libzebra.so.0(listnode_lookup+0x35)[0xb7f40cf7] Backtrace for 11 stack frames: /usr/lib/libzebra.so.0(zlog_backtrace_sigsafe+0x29)[0xb7f5430a] /usr/lib/libzebra.so.0(zlog_signal+0x210)[0xb7f547ab] /usr/lib/libzebra.so.0[0xb7f5bd5d] [0xe440] /usr/lib/libospf.so.0(ospf_vertex_add_parent+0x66)[0xb7f9f433] /usr/lib/libospf.so.0(ospf_spf_calculate+0xe2)[0xb7fa04b7] /usr/lib/libospf.so.0(ospf_spf_calculate_timer+0x90)[0xb7fa05d0] /usr/lib/libzebra.so.0(thread_call+0x70)[0xb7f4aa66] /usr/lib/quagga/ospfd(main+0x29d)[0x80493d7] /lib/tls/libc.so.6(__libc_start_main+0xd0)[0xb7d46ec0] /usr/lib/quagga/ospfd[0x8049031] I've had to downgrade to 0.98.3 for now. Should I be taking this to the Quagga mailing list? Figured I'd post here first in case there had been a Debian-specific change. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (400, 'stable'), (300, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.10-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages quagga depends on: ii debconf 1.4.58 Debian configuration management sy ii iproute 20041019-3 Professional tools to control the ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libcap1 1:1.10-14 support for getting/setting POSIX. ii libncurses5 5.4-9 Shared libraries for terminal hand ii libpam0g 0.76-23Pluggable Authentication Modules l ii libreadline4 4.3-15 GNU readline and history libraries ii logrotate 3.7.1-2Log rotation utility quagga recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328399: libmasonx-request-withapachesession-perl: Fails to properly handle subrequests.
Package: libmasonx-request-withapachesession-perl
Version: 0.30-1
Severity: normal
Tags: patch
Due to a mistaken 'return' statement, the "new" subroutine on
MasonX::Request::WithApacheSession returns an undefined value if a
subrequest is created, rather than returning itself.
$m->make_subrequest would simply return null, and $m->subexec
would thusly complain about being unable to run 'exec' on an
undefined object.
A patch is attached.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing'), (400, 'stable'), (300, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.10-1-686
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Versions of packages libmasonx-request-withapachesession-perl depends on:
ii libapache-request-perl1.1-0.1Generic Apache Request Library
ii libapache-session-perl1.60-2 Perl modules for keeping persisten
ii libapache-session-wrapper-per 0.21-1 A simple wrapper around Apache::Se
ii libhtml-mason-perl1:1.30-1 HTML::Mason Perl module
ii perl [perl5] 5.8.7-3Larry Wall's Practical Extraction
libmasonx-request-withapachesession-perl recommends no packages.
-- no debconf information
--- /tmp/WithApacheSession.pm.old 2005-09-14 23:27:49.648664936 -0400
+++ /usr/share/perl5/MasonX/Request/WithApacheSession.pm2005-09-14
23:03:09.795603823 -0400
@@ -74,7 +74,7 @@
my $self = $class->SUPER::new(@_);
-return if $self->is_subrequest;
+return $self if $self->is_subrequest;
# backwards compatibility
$self->{session_param_name} =
signature.asc
Description: Digital signature
Bug#320953: Debian bug #320953
Are you using GCC 4.0, now the default for sid? I had this problem with GCC 4.0, but GCC 3.3 seems to compile generic_serial.c okay, albeit with lots of warnings. signature.asc Description: Digital signature
Bug#313623: atc: Cannot specify direction of circling as per atc(6)
Package: bsdgames
Version: 2.17-1
Severity: normal
According to the manpage, I should be able to circle left
(counter-clockwise) as well as right (clockwise, the default), but the
game does not accept 'l' or 'r' arguments after 'c'.
In the game, pressing 'c' and then '?' for help gets me
a: circle @a
indicating that the only available follow-up key is the standard delay
command ('a't or '@'), with no 'l'eft or 'r'ight option available.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing'), (300, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.10-1-686
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Versions of packages bsdgames depends on:
ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an
ii libgcc1 1:3.4.3-6GCC support library
ii libncurses5 5.4-4Shared libraries for terminal hand
ii libstdc++5 1:3.3.5-8The GNU Standard C++ Library v3
ii wcanadian-large [wordlist] 5-4 Canadian English dictionary words
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308258: vim: 'set secure' isn't for own files; docs misleading.
Package: vim Version: 1:6.3-058+1 Severity: normal Taken from the help docs for the 'secure' option: [. . .] On Unix this option is only used if the ".vimrc" or ".exrc" is not owned by you. This can be dangerous if the systems allows users to do a "chown". You better set 'secure' at the end of your ~/.vimrc then. The last sentence doesn't make any sense; no matter where or when you set it, it has no effect on the execution of one's own .vimrc or .exrc files. Unpacking a tarball, checking out files via CVS or any other SCM, etc., all create files owned only by the current user. These can contain .vimrc's or .exrc's with malicious instructions that will be executed without restriction. The docs are misleading in this regard; I thought I was "secure" (so to speak) for years, and only just discovered I was an accident waiting to happen. Wishlist item: There's currently no way to distinguish a 'benign' .vimrc (e.g. official project indent settings) from a 'hostile' .vimrc (shell and write commands). The 'secure' option would be ideal for this, if only it or a new sister option would enforce 'secure' rules on *all* .vimrc and .exrc files. (If the doc bug is fixed without a true self-included 'secure' mode, we can rename this report and reclassify it as a wishlist item, or I can just submit a new one.) -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages vim depends on: ii dpkg1.10.27 Package maintenance system for Deb ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libgpmg11.19.6-19General Purpose Mouse - shared lib ii libncurses5 5.4-4Shared libraries for terminal hand ii vim-common 1:6.3-058+1 Vi IMproved - Common files -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308110: Launching on 'about:blank' loads no page; denies functionality.
Package: konqueror Version: 4:3.3.2-1 Severity: normal Within Konqueror, accessing the URL 'about:blank' (like with most browsers) accesses a blank page. White background, 'page loaded' status message, URL in the location bar. All is good. Launching konqueror as 'konqueror about:blank' does not actually load about:blank, but rather, doesn't load any page at all. Gray background, no messages, no URL. This would be perfectly fine if having 'no page' didn't prevent many useful options. For example, I cannot middle-click on the page body to drop in a URL from the X selection. I cannot do 'new tab' at all (silently ignores it). Many menu options are grayed out, including those that seemingly have nothing to do with having a page or not, like 'hide menubar'. Note that actually typing 'about:blank' into the location bar (directly after launch) will take you from a gray screen to a white, fully-functional page. This bug could be interpreted one of two ways -- either launching on 'about:blank' should be the equivalent of typing that URL into the location bar, or Konqueror should not deny so much functionality to a no-page situation. If the chosen solution is to provide the real 'about:blank' page, I recommend it be done *without* putting anything in the location bar (as per current behaviour). This allows typing a URL in directly, rather than having to delete 'about:blank'. (This is the sole benefit of the current situation.) -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages konqueror depends on: ii kcontrol 4:3.3.2-1 KDE Control Center ii kdebase-kio-plugins 4:3.3.2-1 KDE I/O Slaves ii kdelibs4 4:3.3.2-4.0.2 KDE core libraries ii kdesktop 4:3.3.2-1 KDE Desktop ii kfind4:3.3.2-1 KDE File Find Utility ii libart-2.0-2 2.3.17-1Library of functions for 2D graphi ii libc62.3.2.ds1-21GNU C Library: Shared libraries an ii libfam0c102 2.7.0-6 client library to control the FAM ii libgcc1 1:3.4.3-6 GCC support library ii libice6 4.3.0.dfsg.1-12.0.1 Inter-Client Exchange library ii libidn11 0.5.13-1.0 GNU libidn library, implementation ii libjpeg626b-9The Independent JPEG Group's JPEG ii libkonq4 4:3.3.2-1 Core libraries for KDE's file mana ii libpcre3 4.5-1.1 Perl 5 Compatible Regular Expressi ii libpng12-0 1.2.8rel-1 PNG library - runtime ii libqt3c102-mt3:3.3.4-3 Qt GUI Library (Threaded runtime v ii libsm6 4.3.0.dfsg.1-12.0.1 X Window System Session Management ii libstdc++5 1:3.3.5-8 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-12.0.1 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-12.0.1 X Window System miscellaneous exte ii libxrender1 0.8.3-7 X Rendering Extension client libra ii xlibs4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-3 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#307830: hylafax-server: Post-removal script fails silently on purge; prevents removal.
Package: hylafax-server Version: 4.2.1-5 Severity: normal The postrm script has -e set, so if purging the package, the line [ -e "$i" ] && rm "$i" (near the end) causes the script to fail if the file doesn't exist, rather than ignoring it. Also, subsequent purges (after the first is prevented) were also failing on the 'userdel' line above, since the user no longer existed due to the first purge. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages hylafax-server depends on: ii debconf 1.4.46 Debian configuration management sy ii gawk [awk] 1:3.1.4-2 GNU awk, a pattern scanning and pr ii gs 8.01-5 Transitional package ii gs-gpl [gs] 8.01-5 The GPL Ghostscript PostScript int pn hylafax-client Not found. ii libc62.3.2.ds1-21GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-6 GCC support library ii libpam0g 0.76-22 Pluggable Authentication Modules l ii libstdc++5 1:3.3.5-8 The GNU Standard C++ Library v3 ii libtiff-tools3.7.2-2 TIFF manipulation and conversion t ii libtiff4 3.7.1-4 Tag Image File Format (TIFF) libra ii mailx1:8.1.2-0.20040524cvs-4 A simple mail user agent ii mawk [awk] 1.3.3-11a pattern scanning and text proces pn mime-codecs Not found. ii psmisc 21.5-1 Utilities that use the proc filesy ii sed 4.1.2-8 The GNU sed stream editor ii zlib1g 1:1.2.2-3 compression library - runtime -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306813: konqueror: Right-click bookmark in menu; 'copy link address' only half works.
On Fri, Apr 29, 2005 at 06:24:27PM +0200, Kevin Krammer wrote: > > Okay, but this is in contrast to other Konqueror behaviour, then. If > > I right-click on a link and select 'copy link address', it puts it on > > both the clipboard and the selection. If I do the same to a bookmark, > > it only does the clipboard (but it does *clear* the selection, so it's > > still overwriting it). > > Oh, very strange. > I have Konqueror 3.3.2-1 from unstable and it does the same on copy link > address from bookmark or in-page links. Hm, okay. I wonder if there's something messed up just in my case, then. I started using 'xclip' to specifically dump each buffer, and when I go to www.google.ca and 'copy link address' on "Advertising Programs", I get primary:http://www.google.ca/ads/ secondary: clipboard:http://www.google.ca/ads/ buffer-cut: which (technical correctness aside) does match the behaviour I (have come to) expect. On the other hand, oddly, when I do the same on a bookmark, I get primary: secondary: clipboard: buffer-cut: which would seem to imply that it's not filling *any* of the buffers (yikes). But this is impossible, because I can middle-click in Konqueror and paste the URL, or even in X-Chat (non-KDE). Hence, I seem to have a lot of conflicting reports: * According to Konqueror, X-Chat, and Konsole, everything is fine. * According to urxvt, it's clearing and not filling the primary (clipboard unknown). * According to xclip, it's clearing *both* primary and clipboard. Hard to figure out what on earth is going on. signature.asc Description: Digital signature
Bug#306813: konqueror: Right-click bookmark in menu; 'copy link address' only half works.
On Fri, Apr 29, 2005 at 04:52:54PM +0200, Kevin Krammer wrote: > > Using Edit -> Paste works in Konsole, as does shift-insert. In my > > normal console (urxvt), I use middle-click to paste, and it works > > for everything (except the subject of this bug). > > Middle click pastes a different clipboard, the SELECTION as opposed > to the standard clipboard, i.e. something that got selected with > the mouse. > > Recommended behaviour[1] for X applications is to never overwrite > clipboard on selection and never overwrite selection on clipboard > copy or cut. Okay, but this is in contrast to other Konqueror behaviour, then. If I right-click on a link and select 'copy link address', it puts it on both the clipboard and the selection. If I do the same to a bookmark, it only does the clipboard (but it does *clear* the selection, so it's still overwriting it). signature.asc Description: Digital signature
Bug#306813: konqueror: Right-click bookmark in menu; 'copy link address' only half works.
On Fri, Apr 29, 2005 at 12:16:43PM +0200, Kevin Krammer wrote: > Can you try to paste into a different application which uses the > standard paste shortcut, e.g. not a terminal window as those tend to > have different copy&paste shortcuts due to the need to have CTRL+C > for sending the interrupt signal. > > Or, if you use Konsole as the terminal, use Edit->paste or Konsole's > shortcut SHIFT+INS Using Edit -> Paste works in Konsole, as does shift-insert. In my normal console (urxvt), I use middle-click to paste, and it works for everything (except the subject of this bug). Similarly, 'xclip' is a program that performs direct access to the X clipboard, and in most situations, I can do 'xclip -o' to see the contents of the X clipboard. But in this case, 'xclip -o' returns nothing. Is there some sort of special KDE paste buffer? signature.asc Description: Digital signature
Bug#306813: konqueror: Right-click bookmark in menu; 'copy link address' only half works.
Package: konqueror Version: 4:3.3.2-1 Severity: normal If I right-click on a bookmark and select 'copy link address', I can paste it into Konqueror. However, the X clipboard is not updated; in fact, it's blanked. So I cannot paste the address into another application, e.g. a shell. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages konqueror depends on: ii kcontrol 4:3.3.2-1 KDE Control Center ii kdebase-kio-plugins 4:3.3.2-1 KDE I/O Slaves ii kdelibs4 4:3.3.2-4.0.2 KDE core libraries ii kdesktop 4:3.3.2-1 KDE Desktop ii kfind4:3.3.2-1 KDE File Find Utility ii libart-2.0-2 2.3.17-1Library of functions for 2D graphi ii libc62.3.2.ds1-21GNU C Library: Shared libraries an ii libfam0c102 2.7.0-6 client library to control the FAM ii libgcc1 1:3.4.3-6 GCC support library ii libice6 4.3.0.dfsg.1-12.0.1 Inter-Client Exchange library ii libidn11 0.5.13-1.0 GNU libidn library, implementation ii libjpeg626b-9The Independent JPEG Group's JPEG ii libkonq4 4:3.3.2-1 Core libraries for KDE's file mana ii libpcre3 4.5-1.1 Perl 5 Compatible Regular Expressi ii libpng12-0 1.2.8rel-1 PNG library - runtime ii libqt3c102-mt3:3.3.3-8 Qt GUI Library (Threaded runtime v ii libsm6 4.3.0.dfsg.1-12.0.1 X Window System Session Management ii libstdc++5 1:3.3.5-8 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-12.0.1 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-12.0.1 X Window System miscellaneous exte ii libxrender1 0.8.3-7 X Rendering Extension client libra ii xlibs4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-3 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306478: Doc bug
I posted the same issue to the mailing list, and was informed by the author that in the new IMMS, you turn on XMMS 'shuffle' mode, which IMMS detects and supersedes. Hence, this is actually a documentation bug -- albeit an important one, because the package is useless unless the user knows this. I suggest a standard upgrade notification of changed behaviour (via debconf or whatever is the proper way to do this these days). signature.asc Description: Digital signature
Bug#305716: hotkeys: Control volumes other than master
Package: hotkeys Version: 0.5.7.3 Severity: wishlist My laptop has two separate 'master' volumes, one for speakers and one for headphones. It'd be nice to be able to control another channel (e.g. PCM) without having to patch the source myself -- as I've done in the past and have to do (again) now. (Controlling multiple channels at once would be ideal, but that is much trickier and beyond the scope of this wishlist item.) -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages hotkeys depends on: ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libdb3 3.2.9-22Berkeley v3 Database Libraries [ru ii libglib2.0-0 2.6.3-1 The GLib library of C routines ii libgtk2.0-0 2.6.2-4 The GTK+ graphical user interface ii libpango1.0-01.8.1-1 Layout and rendering of internatio ii libx11-6 4.3.0.dfsg.1-10 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-10 X Window System miscellaneous exte ii libxml2 2.6.16-3GNOME XML library ii libxmu6 4.3.0.dfsg.1-10 X Window System miscellaneous util ii libxosd2 2.2.14-1X On-Screen Display library - runt ii xlibs4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-3 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304703: kismet: Client list sorting is reversed
Package: kismet Version: 2005.04.R1-1 Severity: minor Most factors I am able to sort by appear to be reversed. Sorting by 'packets descending' puts higher packets on top for the main screen, but puts them on the bottom for the clients screen. Sorting by MAC puts 00:* below 90:*. Sorting by 'latest seen' causes most recently seen items to move to the top, while you need to sort by 'latest seen descending' on the main screen to get that effect, and vice versa. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages kismet depends on: ii ethereal-common 0.10.10-1 network traffic analyser (common f ii libbz2-1.0 1.0.2-5 high-quality block-sorting file co ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libdps1 4.3.0.dfsg.1-10 Display PostScript (DPS) client li ii libexpat11.95.8-1XML parsing C library - runtime li ii libfreetype6 2.1.7-2.3 FreeType 2 font engine, shared lib ii libgcc1 1:3.4.3-6 GCC support library ii libglib1.2 1.2.10-9The GLib library of C routines ii libgmp3 4.1.4-5 Multiprecision arithmetic library ii libice6 4.3.0.dfsg.1-10 Inter-Client Exchange library ii libjasper-1.701-11.701.0-2 The JasPer JPEG-2000 runtime libra ii libjpeg626b-9The Independent JPEG Group's JPEG ii liblcms1 1.13-1 Color management library ii libmagick6 6:6.0.6.2-2.2 Image manipulation library ii libncurses5 5.4-4 Shared libraries for terminal hand ii libpng12-0 1.2.8rel-1 PNG library - runtime ii libsm6 4.3.0.dfsg.1-10 X Window System Session Management ii libstdc++5 1:3.3.5-8 The GNU Standard C++ Library v3 ii libtiff4 3.7.1-4 Tag Image File Format (TIFF) libra ii libx11-6 4.3.0.dfsg.1-10 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-10 X Window System miscellaneous exte ii libxml2 2.6.16-3GNOME XML library ii libxt6 4.3.0.dfsg.1-10 X Toolkit Intrinsics ii wireless-tools 27-2Tools for manipulating Linux Wirel ii xlibs4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-3 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304223: konqueror: Changing focus to/from large modified textarea causes dramatic downwards scrolling
Package: konqueror Version: 4:3.3.2-1 Severity: normal This bug may be related to bug #290040, but I do not know for certain, so I'm filing it as a new report. The best way to explain this is probably by example: * I pull up the Wikipedia article on the Cold War and begin editing. * I scroll the textarea to the middle. * I enter the text area. (Note that entering and exiting does not do anything at this point.) * I remove a single letter, in this case, the "t" in "the". * I click on "Edit Summary". Suddenly, the text area scrolls to the very bottom. This appears to be cumulative. If I scroll down a single line, make an edit, and exit the box, my text area only scrolls down one line. As I enter and exit, it scrolls down in larger and larger increments until I reach the bottom. If you're having trouble reproducing this, I've provided a URL, http://kochi.wisq.net/misc/demo/konq-scroll.html which provides a sample web page. Press the down arrow on the textarea once, then delete the period after "user base". Click on the text box below, and the textarea should scroll down one line. Click back and forth between the two until the document scrolls to the bottom. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages konqueror depends on: ii kcontrol 4:3.3.2-1 KDE Control Center ii kdebase-kio-plugins 4:3.3.2-1 KDE I/O Slaves ii kdelibs4 4:3.3.2-4.0.2 KDE core libraries ii kdesktop 4:3.3.2-1 KDE Desktop ii kfind4:3.3.2-1 KDE File Find Utility ii libart-2.0-2 2.3.17-1Library of functions for 2D graphi ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libfam0c102 2.7.0-6 client library to control the FAM ii libgcc1 1:3.4.3-6 GCC support library ii libice6 4.3.0.dfsg.1-10 Inter-Client Exchange library ii libidn11 0.5.13-1.0 GNU libidn library, implementation ii libjpeg626b-9The Independent JPEG Group's JPEG ii libkonq4 4:3.3.2-1 Core libraries for KDE's file mana ii libpcre3 4.5-1.1 Perl 5 Compatible Regular Expressi ii libpng12-0 1.2.8rel-1 PNG library - runtime ii libqt3c102-mt3:3.3.3-8 Qt GUI Library (Threaded runtime v ii libsm6 4.3.0.dfsg.1-10 X Window System Session Management ii libstdc++5 1:3.3.5-8 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-10 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-10 X Window System miscellaneous exte ii libxrender1 0.8.3-7 X Rendering Extension client libra ii xlibs4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-3 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#119836: Wishlist item appears to be done
I've had this item in my Konqueror for a long time now (currently 3.3.2). Should we close this report? signature.asc Description: Digital signature
Bug#257096: Bug #257096, re: shared libs in /var
Another solution is to move /var/spool/postfix/lib to another partition, then mount (potentially via fstab) that directory using 'bind' mounting. Unlike a symbolic link, a bind mount does work for chroot. I am not a dynamic-linking-in-C expert, but do we really actually need the .so's in /var? Can't Postfix load the appropriate libraries before chrooting? That seems to work for other chrooted daemons, as far as I've seen. signature.asc Description: Digital signature
Bug#301249: tcptraceroute: Locks up network device unless tcpdump is running
Package: tcptraceroute Version: 1.5beta6-1 Severity: important When used on my laptop (via Ethernet), tcptraceroute fails to function, and (IIRC) has done so for as long as I've tried it. Further, while active, the system cannot receive packets on the Ethernet interface, for *any* application. tcpdump on other machines shows that packets are being sent properly, including the tcptraceroute packets, but the machine now silently ignores the replies and other incoming packets. Pings freeze with no error messages (but continue to transmit ICMP echo-requests) until tcptraceroute is aborted, and incoming pings from other machines are ignored. Running tcpdump on the same system while tcptraceroute is active prevents the network 'freeze', but does not allow tcptraceroute to receive its own packets. This occurs both with standard firewalling rules and with all tables flushed. Ethernet is a BroadCom, b44 driver. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages tcptraceroute depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libnet1 1.1.2.1-2library for the construction and h ii libpcap0.7 0.7.2-7 System interface for user-level pa -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#279091: hotplug: Spurious shutting down of TUN devices on Ethernet state change
On Sun, Mar 20, 2005 at 02:37:15PM +0100, Marco d'Itri wrote: > Still waiting for an answer from the submitter: Thanks for the reminder. The issue seemed to go away on its own, and I had forgotten about this bug. So I pulled up some backups from back when I filed the report and determined what was different. Turns out the entire affair was my own fault. A convoluted path of scripts meant that the VPN daemons were getting restarted every time the interface went up or down, and then scripts called from those daemons' up-down scripts section were resetting the TUN-based interfaces in question. So that's good for you guys, hopelessly embarassing for me. Very sorry about all this. Obviously, it should be marked as closed, and not a bug, or whatever the appropriate PEBKAC-style tag is. signature.asc Description: Digital signature
Bug#300327: mutt: Fails to thread properly without an @ symbol in Message-ID field
Package: mutt
Version: 1.5.6-20040907+3
Severity: normal
If a message lacks an @ ('at') symbol in the Message-ID field, Mutt
refuses to connect messages to it, even if they correctly specify the
In-Reply-To header.
Further, connecting a thread manually using the '&' key (link-threads)
lasts only while that mailbox index is open. Reopening the mailbox
loses the linkage.
Specifying a Message-ID without a domain is highly unusual, and goes
against a 'RECOMMENDED' clause in RFC 2822, but the only 'MUST' clause
relating to Message-ID is that it be unique.
Also, some MTAs do specify a domain, but use the word "at" or some
other text as their delimiter, and these are in full compliance even
with the 'RECOMMENDED' clause.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing'), (300, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1-686
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Versions of packages mutt depends on:
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libdb4.24.2.52-18Berkeley v4.2 Database Libraries [
ii libgnutls11 1.0.16-9 GNU TLS library - runtime library
ii libidn110.5.2-3 GNU libidn library, implementation
ii libncursesw55.4-4Shared libraries for terminal hand
ii libsasl22.1.19-1.5 Authentication abstraction library
ii postfix [mail-transport-age 2.1.5-6 A high-performance mail transport
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299082: openvpn: Nested configs do not respect late --cd
Package: openvpn Version: 1.99+2.rc16-1 Severity: normal Ordinarily, one can use 'config' inside a config file to source other config files (for a modular configuration). Unfortunately, in the default setup, this produces errors: Options error: In /etc/openvpn/main.conf:26: Error opening configuration file: tls/tls-client.conf Key settings using relative paths work fine, but nested configs do not. However, if one specifies cd /etc/openvpn in the sourcing config, or places --cd before --config in the initscript (a good temporary fix, FYI), they work fine. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages openvpn depends on: ii debconf 1.4.45 Debian configuration management sy ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii liblzo1 1.08-1.2 A real-time data compression libra ii libssl0.9.7 0.9.7e-2 SSL shared libraries -- debconf information: openvpn/change_init: true * openvpn/create_tun: true * openvpn/stop2upgrade: false * openvpn/default_port: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294030: chrony: Freezes and modutils
On Thu, Feb 24, 2005 at 12:03:24PM -0500, Adrian Irving-Beer wrote: > I believe this is actually a bug in modutils. Note how > /etc/modutils/arch/i386 has that exact alias at the end. But > /etc/modprobe.d/arch/i386 does not. Though all my statements remain, I should note that /etc/modprobe.d is the domain of 'module-init-tools', and not 'modutils'. All other mentions of 'modutils' in my previous e-mail should be replaced by 'module-init-tools'. The former has the 'rtc' alias, while the latter does not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294030: chrony: Freezes and modutils
Package: chrony Version: 1.20-6 Followup-For: Bug #294030 Note that I came to the same rtc vs. genrtc conclusion independently, so it seems chrony+genrtc is indeed the culprit here. You can solve your problem by creating /etc/modprobe.d/local (for example) and putting alias char-major-10-135 rtc as a line in that file. I believe this is actually a bug in modutils. Note how /etc/modutils/arch/i386 has that exact alias at the end. But /etc/modprobe.d/arch/i386 does not. Hence, when modutils moved to the new system -- where instead of generating /etc/modules.conf, it actually directly reads files in /etc/modprobe.d -- it had no explicit alias for that device. Instead, it falls back on the contents of /lib/modules/`uname -r`/modules.alias which contains *both* aliases for rtc and genrtc. Somehow, the genrtc one takes precedence, unless you have your own entry in modprobe.d. To the maintainer: This would appear to warrant bugs in both modutils and possibly the kernel itself. Unless chrony's usage of the RTC is considered atypical or improper, genrtc causing freezes seems like a bug in itself. Even without the bug in genrtc, though, using a software RTC instead of hardware RTC, when a hardware RTC is generally universal to i386 system and was the default before, is (IMO) a bug in modutils too. Note that I have also seen the occasional console message about 'genrtc: lost 3 jiffies' which helped alert me to the issue. HTH. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages chrony depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libncurses5 5.4-4Shared libraries for terminal hand ii libreadline44.3-15 GNU readline and history libraries -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#233068: offlineimap: Confirmation (4.0.7)
Package: offlineimap Version: 4.0.7 Followup-For: Bug #233068 Just an FYI from a third party -- I can confirm this behaviour in 4.0.7, though I typically get a "2" instead. :) Since I didn't think to look at the filename, I just turn expunge off, delete the message, sync, undelete whatever got marked on the server, turn on expunge, and sync again. When I get a chance, I'll look into turning on debug long-term, but it can take weeks or months to manifest. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages offlineimap depends on: ii python2.3 2.3.4-18 An interactive high-level object-o -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291450: perl: index() on two tainted constants breaks subsequent open(FH, "-|")
Package: perl Version: 5.8.4-5 Severity: normal Tags: sarge The following script causes a strange taint error when supplied with two command-line parameters: #!/usr/bin/perl -T use constant C_A => $ARGV[0]; use constant C_B => $ARGV[1]; index(C_A, C_B); open(FOO, "-|"); Result: $ ./taint.pl aaa bbb Insecure dependency in piped open while running with -T switch at ./taint.pl line 5. Commenting out the index() makes the error disappear, as does refraining from supplying one or both of the args. An index() shouldn't impact an open(), and the open() shouldn't ever cause a taint error anyway (it just opens a pipe and forks). The problem does not seem reproducable using variables, subroutines, or direct reference to @ARGV -- only the 'constant' module. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Versions of packages perl depends on: ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an ii libdb4.24.2.52-17Berkeley v4.2 Database Libraries [ ii libgdbm31.8.3-2 GNU dbm database routines (runtime ii perl-base 5.8.4-5 The Pathologically Eclectic Rubbis ii perl-modules5.8.4-5 Core Perl modules -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
