Bug#583917: My analysis of the bug
Matteo Frigo ath...@fftw.org writes: martin f krafft madd...@debian.org writes: also sprach Matteo Frigo ath...@fftw.org [2010.09.01.0139 +0200]: I have been hit by this bug. My analysis of the situation is the following. Nice analysis. I think that 3.1.4 now fixes this, as we reverted the mapfile change. Yes, I have installed 3.1.4 from sid and it fixes the bug. Thank you for taking care of this. I can confirm this also resolves my problem with mdadm spinning forever. Thank you all, Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593356: apt-cacher-ng: memory leak in Lenny backport of 0.5.1 with MaxStandbyConThreads: 2 enabled
Eduard Bloch e...@gmx.de writes: * Daniel Pittman [Thu, Aug 19 2010, 06:28:01PM]: Eduard Bloch e...@gmx.de writes: G'day Eduard. Sorry for the long delay in responding to this bug report, and your changes. I regret holding up so long on that. [...] I found a couple of issues which might cause the leak. I will send you a current development snapshot tonight. Thanks. As promised, have a look at the snapshot from http://www.unix-ag.uni-kl.de/~bloch/acng/download/unreleased/. The i386 version is built against stable, amd64 against unstable. The regular tasks should work stable there ATM, only the new features still need some polishing. OK. This appears to have resolved our problems, and not introduced any others, which is wonderful. I will continue to keep an eye on it, but for now it hopefully can close the issue. Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593356: apt-cacher-ng: memory leak in Lenny backport of 0.5.1 with MaxStandbyConThreads: 2 enabled
--- 131352 Unknown0 I attached the code for proc-maps, but it basically just sums memory allocations. On the same hunch /proc/.../maps and /proc/.../smaps are both attached, although I don't think they tell much more than the summary above. Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons proc-maps Description: Binary data maps Description: Binary data smaps Description: Binary data
Bug#549275: udev: no longer creates /dev/disk/by-id/md-uuid-* symlinks, breaking boot!
1:3.1.4-1 Linux PCI Utilities ii usbutils 0.86-2 Linux USB utilities udev suggests no packages. -- debconf information: udev/new_kernel_needed: false udev/reboot_needed: -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons Looking for work? Love Perl? In Melbourne, Australia? We are hiring. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546695: dovecot-imapd: dovecot epoll fails with -EPERM for dovecot --exec-mail imap at the shell
Timo Sirainen t...@iki.fi writes:
On Sep 15, 2009, at 9:10 AM, Daniel Pittman wrote:
Sep 15 16:03:31 krosp IMAP(daniel): : Fatal: io_loop_handle_add:
epoll_ctl(1, 0): Operation not permitted
Sorry to take so long to follow up on this.
Do you have rawlog enabled? IIRC that was the main cause of this.
Or anything else in mail_executable except the default imap binary?
No, rawlog is disabled, and the only occurrences of mail_executable are
commented out. Heck, the configuration is almost exclusively barren; the only
non-command and non-whitespace lines are:
,[ /etc/dovecot/dovecot.conf - clean ]
| protocols = imap
| log_timestamp = %Y-%m-%d %H:%M:%S
| mail_location = dbox:~/.dovecot-mail
| mail_privileged_group = mail
| protocol imap {
| }
| protocol pop3 {
| pop3_uidl_format = %08Xu%08Xv
| }
| protocol managesieve {
| }
| auth default {
| mechanisms = plain
| passdb pam {
| }
| userdb passwd {
| }
| user = root
| }
| dict {
| }
| plugin {
| }
`
Regards,
Daniel
--
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
Looking for work? Love Perl? In Melbourne, Australia? We are hiring.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546695: dovecot-imapd: dovecot epoll fails with -EPERM for dovecot --exec-mail imap at the shell
Package: dovecot-imapd
Version: 1:1.2.5-1
Severity: grave
I run dovecot directly, without passing through a TCP socket, on my laptop to
provide direct access to a mail spool in my home directory, with preauth:
/usr/sbin/dovecot --exec-mail imap
This previously worked just fine, but now fails as both a privileged and
unprivileged user due to epoll returning -EPERM:
epoll_ctl(6, EPOLL_CTL_ADD, 0, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP,
{u32=9753488, u64=9753488}}) = -1 EPERM (Operation not permitted)
Note that it tries the operation of FD 0, STDIN, which is attached to the
shell in the interactive test, or to a pipe otherwise.
mail.log contains:
Sep 15 16:03:31 krosp IMAP(daniel): : Fatal: io_loop_handle_add: epoll_ctl(1,
0): Operation not permitted
The only references to this I can find are historic, and suggest this was an
issue elsewhere but is now fixed.
I am running the stock Debian/unstable kernel, nothing special.
Please find attached a full strace of the Dovecot run that fails.
This is pretty serious for me, because it prevents this *documented* mode of
operation from working under, as far as I can tell, any circumstances.
Downgrading to the version from stable, 1.2.24-2, resolves the problem.
Regards,
Daniel
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dovecot-imapd depends on:
ii dovecot-common1:1.2.5-1 secure mail server that supports m
ii libc6 2.9-26 GNU C Library: Shared libraries
ii libssl0.9.8 0.9.8k-5 SSL shared libraries
dovecot-imapd recommends no packages.
dovecot-imapd suggests no packages.
-- no debconf information
--
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
Looking for work? Love Perl? In Melbourne, Australia? We are hiring.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546694: dovecot-imapd: dovecot epoll fails with -EPERM for dovecot --exec-mail imap at the shell
Package: dovecot-imapd
Version: 1:1.2.5-1
Severity: grave
I run dovecot directly, without passing through a TCP socket, on my laptop to
provide direct access to a mail spool in my home directory, with preauth:
/usr/sbin/dovecot --exec-mail imap
This previously worked just fine, but now fails as both a privileged and
unprivileged user due to epoll returning -EPERM:
epoll_ctl(6, EPOLL_CTL_ADD, 0, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP,
{u32=9753488, u64=9753488}}) = -1 EPERM (Operation not permitted)
Note that it tries the operation of FD 0, STDIN, which is attached to the
shell in the interactive test, or to a pipe otherwise.
mail.log contains:
Sep 15 16:03:31 krosp IMAP(daniel): : Fatal: io_loop_handle_add: epoll_ctl(1,
0): Operation not permitted
The only references to this I can find are historic, and suggest this was an
issue elsewhere but is now fixed.
I am running the stock Debian/unstable kernel, nothing special.
Please find attached a full strace of the Dovecot run that fails.
This is pretty serious for me, because it prevents this *documented* mode of
operation from working under, as far as I can tell, any circumstances.
Downgrading to the version from stable, 1.2.24-2, resolves the problem.
Regards,
Daniel
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dovecot-imapd depends on:
ii dovecot-common1:1.2.5-1 secure mail server that supports m
ii libc6 2.9-26 GNU C Library: Shared libraries
ii libssl0.9.8 0.9.8k-5 SSL shared libraries
dovecot-imapd recommends no packages.
dovecot-imapd suggests no packages.
-- no debconf information
--
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
Looking for work? Love Perl? In Melbourne, Australia? We are hiring.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542889: nvidia-kernel-source: kernel panic on amd64 with 185.18.31 drivers, Quadro card
Sven Joachim svenj...@gmx.de writes: On 2009-08-22 03:06 +0200, Daniel Pittman wrote: Package: nvidia-kernel-source Version: 185.18.31-1 Severity: grave After upgrading to the 185.18.31 packages from 185.18.14, X caused a kernel panic with a NULL pointer dereference. This seems to be the same problem discussed here: http://www.nvnews.net/vbulletin/showthread.php?t=136959 Downgrading to the earlier version is suggested as fixing the issue, and does for me, but I figure that others might want to know about this beforehand. Thanks for this warning. I figure that other people can probably live without a couple of hours of annoyance downgrading. ;) Thank you for your swift response. Probably the Debian package should be upgraded to 185.18.36, http://www.nvnews.net/vbulletin/showthread.php?p=2071410 mentions Fixed a bug that caused kernel panics when starting X on some mobile GPUs. I am quite happy to test an upgraded package, if that helps, and verify it resolves the issue at least for my 01:00.0 VGA compatible controller: nVidia Corporation Quadro FX 570M (rev a1) Regards, Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons Looking for work? Love Perl? In Melbourne, Australia? We are hiring. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542889: nvidia-kernel-source: kernel panic on amd64 with 185.18.31 drivers, Quadro card
Package: nvidia-kernel-source Version: 185.18.31-1 Severity: grave After upgrading to the 185.18.31 packages from 185.18.14, X caused a kernel panic with a NULL pointer dereference. This seems to be the same problem discussed here: http://www.nvnews.net/vbulletin/showthread.php?t=136959 Downgrading to the earlier version is suggested as fixing the issue, and does for me, but I figure that others might want to know about this beforehand. Regards, Daniel -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nvidia-kernel-source depends on: ii debhelper 7.3.14 helper programs for debian/rules ii dpatch2.0.31 patch maintenance system for Debia ii make 3.81-6 An utility for Directing compilati ii sed 4.2.1-3The GNU sed stream editor Versions of packages nvidia-kernel-source recommends: ii devscripts 2.10.53 scripts to make the life of a Debi ii kernel-package 12.019 A utility for building Linux kerne ii module-assistant 0.11.1 tool to make module package creati ii nvidia-glx 185.18.14-2 NVIDIA binary Xorg driver nvidia-kernel-source suggests no packages. -- no debconf information -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons Looking for work? Love Perl? In Melbourne, Australia? We are hiring. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531269: libplist-utils: ships a symbolic link to a versioned utility, but not the actual utility...
Package: libplist-utils Version: 0.12-1 Severity: grave Justification: renders package unusable libplist-utils ships /usr/bin/plist as a symbolic link, but not the actual binary: ] ls -l /usr/bin/plutil* lrwxrwxrwx 1 root root 11 2009-05-31 16:22 /usr/bin/plutil - plutil-0.12 It should probably install the binary, without version, under the unversioned name. Regards, Daniel -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517340: /usr/bin/pp: Resolution to #451600 incomplete: pp still expects /usr/bin/par.pl
Package: libpar-packer-perl Version: 0.982-2 Severity: grave File: /usr/bin/pp Justification: renders package unusable G'day. After y'all resolved #451600 by renaming /usr/bin/par.pl to /usr/bin/par-archive the pp process for generating stand-alone Perl scripts is broken: ] pp -P -e '1;' Can't open perl script /usr/bin/par.pl: No such file or directory The pp tool, and in fact a non-trivial amount of the libpar-packer-perl code, has not been fixed to handle this renaming, breaking the package in one scenario I tested and, at a guess, potentially in a non-trivial number of others. It certainly makes it impossible to generate a stand-alone Perl script, rather than a script with an embedded Perl binary, at this stage. For reference, the following files refer to par.pl: ] dpkg -L libpar-packer-perl | xargs grep -l 'par\.pl' /usr/share/perl5/pp.pm /usr/share/perl5/PAR/Packer.pm /usr/share/doc/libpar-packer-perl/copyright /usr/bin/parldyn /usr/bin/par-archive /usr/bin/parl Regards, Daniel -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpar-packer-perl depends on: ii libarchive-zip-perl 1.18-1 Module for manipulation of ZIP arc ii libc6 2.9-3 GNU C Library: Shared libraries ii libcompress-zlib-perl 2.015-1Perl module for creation and manip ii libgetopt-argvfile-perl 1.11-1 Perl module for reading script opt ii libmodule-scandeps-perl 0.89-1 Perl module to recursively scan Pe ii libpar-dist-perl 0.44-1 perl module to create and manipula ii libpar-perl 0.984-1Perl Archive Toolkit ii libperl5.10 5.10.0-19 Shared Perl library ii perl 5.10.0-19 Larry Wall's Practical Extraction ii perl-modules 5.10.0-19 Core Perl modules Versions of packages libpar-packer-perl recommends: ii perl-tk [libtk-perl] 1:804.028-3 Perl module providing the Tk graph libpar-packer-perl suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513310: [Debian] Re: Bug#513310: vzctl fails to set capabilities, and subsequently fails to start any VE
Kir Kolyshkin k...@openvz.org writes: This is caused by newer kernel headers (in this case on a build system that was used to build this vzctl package), and is fixed in vzctl-3.0.23. See the following git commit: vzctl 3.0.23-2 is available in experimental, so I have installed it and tested it on my machine; it addresses the problem and the VE will again start. So the solution is either to upgrade to vzctl-3.0.23 or to backport this simple fix. I can confirm that the newer package version resolves the problem. Ola Lundqvist wrote: Hi Daniel This is interesting as it works very well on my systems. On other hand that system is a 686 based one. You write that you have not significantly changed your system, but at the same time you write that you are not sure that it has ever worked with the 2.6.26 kernel. Sorry, I see I was unclear: I have upgraded to sid, which significantly changed the system, but the OpenVZ configuration remained stable. I thought that the VE had started successfully under 2.6.26 before, but could only confirm from my logs that I had used it under 2.6.24. Sorry for being so unclear, and thankfully Kir has saved me by identifying the problem despite my poor communication. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513310: [Debian] Re: Bug#513310: vzctl fails to set capabilities, and subsequently fails to start any VE
Ola Lundqvist o...@inguza.com writes: If you could try this fix out it would be really great. A built package for amd64 is available at: http://apt.inguza.org/vzctl/ Ah. I am on amd64, and that is an i386 package without source. Anyway, I grabbed the source, manually applied the patch and downgraded the vzctl package to 3.0.22-14 from sid. I then went to reproduce the problem and couldn't: 3.0.22-14 worked fine for me after downgrading, without any additional patches at all. Um, all of which leaves me a bit mystified, but the upgrade to 3.0.23, then back down to 3.0.22 did replace all the distribution configuration files, etc... In any case I can no longer reproduce the fault with 3.0.22-14 from sid, so I can only presume that there was something very strange went wrong on my local system, but that the issue is now resolved. Thank you both for your help, and I am sorry for the trouble. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513310: vzctl fails to set capabilities, and subsequently fails to start any VE
Package: vzctl
Version: 3.0.22-14
Severity: grave
Justification: renders package unusable
When trying to start a VE I get the following output:
] sudo vzctl start sd-dev
Starting VE ...
VE is mounted
Unable to set capability: Operation not permitted
Unable to set capability
VE start failed
VE is unmounted
When I strace the system I see the following call to set capabilities:
[pid 14391] capget(0x20071026, 0, NULL) = -1 EFAULT (Bad address)
[pid 14390] exit_group(0) = ?
Process 14390 detached
[pid 14391] capset(0x20071026, 0,
{CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_FSETID|CAP_KILL|CAP_SETGID|CAP_SETUID|CAP_LINUX_IMMUTABLE|CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_RAW|CAP_IPC_LOCK|CAP_IPC_OWNER|CAP_SYS_CHROOT|CAP_SYS_PTRACE|CAP_SYS_BOOT|CAP_SYS_NICE|CAP_SYS_RESOURCE|CAP_SYS_TTY_CONFIG|0x7800,
CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_FSETID|CAP_KILL|CAP_SETGID|CAP_SETUID|CAP_LINUX_IMMUTABLE|CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_RAW|CAP_IPC_LOCK|CAP_IPC_OWNER|CAP_SYS_CHROOT|CAP_SYS_PTRACE|CAP_SYS_BOOT|CAP_SYS_NICE|CAP_SYS_RESOURCE|CAP_SYS_TTY_CONFIG|0x7800,
CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_FSETID|CAP_KILL|CAP_SETGID|CAP_SETUID|CAP_LINUX_IMMUTABLE|CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_RAW|CAP_IPC_LOCK|CAP_IPC_OWNER|CAP_SYS_CHROOT|CAP_SYS_PTRACE|CAP_SYS_BOOT|CAP_SYS_NICE|CAP_SYS_RESOURCE|CAP_SYS_TTY_CONFIG|0x7800})
= -1 EPERM (Operation not permitted)
This fails to start the VE, reporting that the capset operation failed.
None of my configuration has been modified significantly, and certainly not
to change the capability set of the VE or anything like that.
This same configuration worked on a 2.6.24 VZ kernel, but I am not sure it ever
worked on the 2.6.26 kernel.
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-openvz-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages vzctl depends on:
ii iproute 20080725-2 networking and traffic control too
ii libc6 2.7-18 GNU C Library: Shared libraries
ii vzquota 3.0.11-1 server virtualization solution - q
Versions of packages vzctl recommends:
ii rsync 3.0.5-1fast remote file copy program (lik
Versions of packages vzctl suggests:
pn linux-patch-openvznone (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#336373: subversion: svn MKCOL ssl error
Package: subversion Version: 1.2.3dfsg1-3 Severity: grave G'day. I have run into a problem where I can't commit a change to my subversion repository via HTTP/SSL. The problem seems identical to the one described in this bug report, but my issues continue despite running the version that claims to have fixed the problem. The server is running an up-to-date version of unstable as well, and I have verified that the same version of subversion and all appropriate modules are installed and running on both sides. The error I see is: svn: Commit failed (details follow): svn: MKCOL of '/svn/general/!svn/wrk/6796d7ea-5b09-0410-9cde-b6775cbebef8/debian/perl/librose-html-objects-perl-0.32/lib/Rose': SSL negotiation failed: SSL error: decryption failed or bad record mac (https://digital-infrastructure.com.au) There are, annoyingly enough, no errors at all in the Apache logs on the server side, which makes tracking this down much more annoying. The commit in question is fairly large, as it adds 8.2MB of files, representing 662 individual files. Other commits seem to work just fine, but they are much smaller. I have run into this once before -- but it was a much smaller commit, a long time ago, and not at all reproducible. At the time I couldn't identify any particular cause... I wonder if perhaps this is some sort of SSL renegotiation bug that triggers when submitting a sufficiently large commit or something? Daniel -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages subversion depends on: ii db4.3-util 4.3.29-3 Berkeley v4.3 Database Utilities ii libapr02.0.55-3 the Apache Portable Runtime ii libc6 2.3.5-9 GNU C Library: Shared libraries an ii libneon24 0.24.7.dfsg-3 An HTTP and WebDAV client library ii libsvn01.2.3dfsg1-3 shared libraries used by Subversio ii patch 2.5.9-2 Apply a diff file to an original subversion recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305617: squid: assertion failure causes squid to abort: assertion failed: store_swapout.c:232: mem-inmem_lo == 0
Package: squid Version: 2.5.9-4 Severity: serious This applies to 2.5.9-5 - I downgraded to be able to check for duplicate bug reports. I get this assertion failure, and abort: assertion failed: store_swapout.c:232: mem-inmem_lo == 0 Regards, Daniel -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.12-rc1-enki Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages squid depends on: ii adduser 3.63 Add and remove users and groups ii coreutils 5.2.1-2 The GNU core utilities ii debconf 1.4.48 Debian configuration management sy ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libldap22.1.30-6 OpenLDAP libraries ii libpam0g0.76-22 Pluggable Authentication Modules l ii logrotate 3.7-2Log rotation utility ii netbase 4.21 Basic TCP/IP networking system ii squid-common2.5.9-4 Internet Object Cache (WWW proxy c -- debconf information: squid/fix_cachedir_perms: false * squid/largefiles_warning: squid/anonymize_headers: squid-cgi/cachemgr: squid/old_version: false squid/http_anonymizer: squid/authenticate_program: squid/fix_lines: true -- Artists are people driven by a conflict between the desire to communicate and the even stronger desire to hide. -- D. W. Winnicott -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302634: squid: assertion failure in stmem.c results in unclean restart of squid
Package: squid Version: 2.5.9-2 Severity: grave After upgrading to 2.5.9-3, squid would routinely fail with this assertion: 2005/04/02 12:01:48| assertion failed: stmem.c:93: current_offset == target_offset The process seemed to restart automatically, and perform an DIRTY cache rebuild. I have, as you will note, downgraded to the previous version, which resolves the problem. I use diskd as the storage mechanism for my cache directory. Daniel -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.12-rc1-enki Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages squid depends on: ii adduser 3.63 Add and remove users and groups ii coreutils 5.2.1-2 The GNU core utilities ii debconf 1.4.47 Debian configuration management sy ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libldap22.1.30-3 OpenLDAP libraries ii libpam0g0.76-22 Pluggable Authentication Modules l ii logrotate 3.7-2Log rotation utility ii netbase 4.21 Basic TCP/IP networking system ii squid-common2.5.9-2 Internet Object Cache (WWW proxy c -- debconf information: squid/fix_cachedir_perms: false * squid/largefiles_warning: squid/anonymize_headers: squid-cgi/cachemgr: squid/old_version: false squid/http_anonymizer: squid/authenticate_program: squid/fix_lines: true -- I have no life, and I must scream. And in response, thus spake the Oracle: } And there we have it, modern music summed up in one tidy sentence. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
