Simon Waters | 1 Oct 01:04 2008

Bug#500743: Segmentation fault in running bind9

Package: bind9
Version: 1:9.5.0.dfsg.P2-1
Severity: important

Sep 30 23:23:54 derek kernel: [791273.512364] named[2244]: segfault at dededef2 ip b7eaad0e sp b7549f90
error 7 in[b7e40000+141000]

I use bind9 running locally on my desktop box as the local recursive
resolver. Although this box has some unusual history (ran sid) as far as I can
ascertain it is running correct version of bind9 and libraries for
lenny. The bind9 config is relatively straight forward, and close to the
Debian default, with addition of some local authoritative zones.

Twice recently bind9 has stopped, dumping two core files in
/var/cache/bind. On both occasions problems were seen resolving some names
(reporting timeouts) immediately before the crash.

-rw------- 1 bind bind 58179584 2008-09-30 23:23 core.2243
-rw------- 1 bind bind 43302912 2008-09-22 19:58 core.2463

On one occasion I immediately ran "rndc dumpdb" when I encountered
issues with name resolution, and the crash took place a few seconds
after the database was written to /var/cache/bind/named_dump.db

-rw-r--r-- 1 bind bind    81933 2008-09-30 23:20 named_dump.db

Please advise if this information would be useful in diagnosing bind

(Continue reading)

Paolo | 1 Oct 01:14 2008

Bug#500534: cupsys: printing via lp (cupsys-client) on HP-DJ560C yields mirror image

On Tue, Sep 30, 2008 at 10:00:40PM +0100, Roger Leigh wrote:
> To see if it's an issue with PPD-aware job submission, could you please
> try to print with kprinter (package kdeprint).  Try "kprinter <>"

or gpr? iirc it does make use of PPDs as well.
Will try.

> The lp command is also capable of setting job options in the PPD.  It's
> possible a specific option is causing mirrored output.  There's an
> "-o mirror" option which might be getting set.  Does this have an

quick check: lp -o mirror ... -> no change



Asheesh Laroia | 1 Oct 01:17 2008

Bug#409151: Fixed upstream

This seems fixed upstream: 2005?  Can it be reproduced with current upstream and/or current 
Debian packaging?

-- Asheesh.


It's time to boot, do your boot ROMs know where your disk controllers are?

Damien Raude-Morvan | 1 Oct 01:13 2008

Bug#500744: no more popcon graph since move of

Severity: normal


Since move of p.d.o to a new machine [1], popcon graph are "404 Not Found" [2].

Those reports was hosted on Ian "igloo" Lynagh account on p.d.o for a long time and I would like
to thanks him for this service.
But, IMHO, thoses graphs should be directly hosted on machine to avoid
this kind of unavailability and to keep things related together.



-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (600, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.25-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Dag Wieers | 1 Oct 01:35 2008

Bug#467615: dstat: Aborts with ZeroDivisionError

On Sun, 23 Mar 2008, Dag Wieers wrote:

> Sam, could you please retry the version from subversion ?
> We made some changes to the scheduling code which triggered this bug on a 
> stopped terminal. The problem is that on 2 different positions in time it 
> returns exctly the same number of ticks, which normally should not happen. 
> This means that either the cpu did not do anything in between (like when you 
> hibernate or suspend your system) or the 2 positions in time are very close 
> to each other (which is again weird since we have at least 1 second 
> intervals).
> I noticed that also on VMware, where time and cpu ticks can be variable (they 
> synchronise time each minute and gradually correct time, which means that 
> when dstat thinks it is 1 second later, in fact it only is a fw milliseconds 
> later, alas the problem...)
> I can imagine that a variable cpu speed can impact this problem as well.
> But now it is fixed and dstat will show when it is loosing ticks and how 
> many. This is easy to trigger by stopping your terminal (ctrl-s) for about 15 
> seconds or by suspending your computer with dstat running.
> I am interested to hear how it works for you.
> BTW Thanks for reporting this bug !

Since the dstat 0.6.8 release this code was released. So again, I think 
this bug should be closed and reopened if some new information appears.

(Continue reading)

rolf | 1 Oct 01:54 2008

Bug#445987: OOPS in xen domU

I have managed in building the xen-vserver kernel a la Debian
with Göran's patch and now it works for me too.

Thank you very much to all of you!


A Person | 1 Oct 01:59 2008

Bug#500488: Further Info

I downloaded and installed (and uninstalled) the current Debian version, 

No problems.

Installed perfectly including updates.

Marc Mongenet | 1 Oct 02:42 2008

Bug#161539: fonts

I have -*-helvetica-medium-r-normal-*-*-120-*-*-*-iso8859-1
on my system. This command line opens NEdit with menus
in Helvetica:
/usr/bin/nedit -xrm '*fontList:


Marc Mongenet
Creator of the Web 2 Markup Language

Nelson A. de Oliveira | 1 Oct 02:52 2008

Bug#500745: zsh-beta: Tab completion looking for /etc/init.d/program

Package: zsh-beta
Version: 4.3.6-dev-0+20080929-1
Severity: important


With the new zsh-beta package, the Tab completion seems to be broken:

$ reportbug z[TAB]
$ reportbug z
_init_d:17: no such file or directory: /etc/init.d/reportbug

$ ls [TAB]
$ ls 
_init_d:17: no such file or directory: /etc/init.d/ls

$ cd [TAB]
$ cd 
_init_d:17: no such file or directory: /etc/init.d/cd

Thank you!

Best regards,

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
(Continue reading)

Kees Cook | 1 Oct 03:17 2008

Bug#500746: feature request: use pre-existing schroot or run early script hook

Package: sbuild
Version: 0.57.5-1
Severity: normal
Tags: patch

Hello!  I'd like to have the ability to run commands within the chroot
before building.  In a perfect world, I could specify a pre-existing
chroot snapshot (one already started with schroot -b -c ....), and then
I could open the chroot, run commands, run sbuild, and then destroy the
chroot myself.  I imagine this looking like so:

$ CMDS=$(mktemp -t cmds-XXXXXX)
$ echo "stuff to run...." > "$CMDS"
$ CHROOT=$(schroot -b -c unstable-i386)
$ schroot -u root -r -c "$CHROOT" "$CMDS"
$ rm -f "$CMDS"
$ sbuild -d unstable -c "$CHROOT" -A somepkg.dsc
$ schroot -e -c "$CHROOT"

However, sbuild doesn't know how to look up this schroot nor to skip
initialization, etc.

Without this, I thought perhaps I could just run a script before starting
the build.  However, the sbuild options aren't passed into the environment
anywhere, so in this example hack^Wpatch, I'm just passing the arguments
I happened to need for my script.



(Continue reading)