Debian Bug report logs - #273192
swapped colors with 2.6 kernel

version graph

Package: bogl-bterm; Maintainer for bogl-bterm is Samuel Thibault <sthibault@debian.org>; Source for bogl-bterm is src:bogl.

Reported by: Joey Hess <joeyh@debian.org>

Date: Fri, 24 Sep 2004 13:48:03 UTC

Severity: normal

Tags: d-i

Merged with 247095, 274659, 275913, 276433, 277954

Found in version 0.1.18-1.1

Done: Samuel Thibault <sthibault@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <dan@debian.org>:
Bug#273192; Package bogl-bterm. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
New Bug report received and forwarded. Copy sent to Daniel Jacobowitz <dan@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: swapped colors with 2.6 kernel
Date: Fri, 24 Sep 2004 00:06:39 +0200
[Message part 1 (text/plain, inline)]
Package: bogl-bterm
Version: 0.1.18-1.1
Severity: normal
Tags: d-i

Several people here are seeing bterm come up in d-i with the blue and
red colors swapped, so we get a red background normally and blue error
screens. I think the other reporters were running oldworld powerpc,
vmware, and I'm seeing it on my test laptop (i386). All of us using d-i
with the 2.6.8 kernel. If we switch to another VC and switch back, the
colors are corrected.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <dan@debian.org>:
Bug#273192; Package bogl-bterm. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Daniel Jacobowitz <dan@debian.org>. Full text and rfc822 format available.

Message #10 received at 273192@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: 273192@bugs.debian.org
Subject: Re: Bug#273192: swapped colors with 2.6 kernel
Date: Fri, 24 Sep 2004 19:53:29 +0200
[Message part 1 (text/plain, inline)]
Joey Hess wrote:
> Several people here are seeing bterm come up in d-i with the blue and
> red colors swapped, so we get a red background normally and blue error
> screens. I think the other reporters were running oldworld powerpc,
> vmware, and I'm seeing it on my test laptop (i386). All of us using d-i
> with the 2.6.8 kernel. If we switch to another VC and switch back, the
> colors are corrected.

The iso image that Konstantinos Margaritis <markos@debian.org> saw start
to a red screen in his vmware 4.x is archived at
http://kitenet.net/~joey/tmp/redder-sarge-i386-businesscard.iso
(I cannot reproduce it with vmware 3.x and this image.)

An initrd using the 2.6.8 kernel, which I see start to a red background
screen when booting it on my test laptop is at
http://kitenet.net/~joey/tmp/redder-initrd26.gz

That initrd is a hd-media initrd that I built locally, and it includes a
copy of gdb. Apparently this problem only occurs on some builds of the
d-i initrds, because when I removed gdb and rebuilt the initrd, the red
screen went away. Also, Konstantinos reports that today's daily build of
the image he had the problem with no longer has the red screen problem.
On the other hand, Sven Luther seems to see the red screen all the time
on his oldworld powerpc machine, and the problem seems to have existed
for months there.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Merged 273192 274659. Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Merged 273192 274659 275913. Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Merged 273192 274659 275913 276433. Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Merged 247095 273192 274659 275913 276433. Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <dan@debian.org>:
Bug#273192; Package bogl-bterm. Full text and rfc822 format available.

Acknowledgement sent to Kenshi Muto <kmuto@debian.org>:
Extra info received and forwarded to list. Copy sent to Daniel Jacobowitz <dan@debian.org>. Full text and rfc822 format available.

Message #23 received at 273192@bugs.debian.org (full text, mbox):

From: Kenshi Muto <kmuto@debian.org>
To: 273192@bugs.debian.org
Subject: swapped colors with 2.6 kernel
Date: Sun, 17 Oct 2004 10:53:52 +0900
Hi,
I don't certain whether it hits bogl or not, but linux 2.6.9.rc4 mm
patch has some interesting fix around framebuffer
(ttp://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/announce.txt).

Thanks,
-- 
Kenshi Muto
kmuto@debian.org



Merged 247095 273192 274659 275913 276433 277954. Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Tags removed: moreinfo Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <dan@debian.org>:
Bug#273192; Package bogl-bterm. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Daniel Jacobowitz <dan@debian.org>. Full text and rfc822 format available.

Message #32 received at 273192@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: Daniel Jacobowitz <dan@debian.org>
Cc: 273192@bugs.debian.org
Subject: Re: red screen problems with bterm
Date: Sat, 23 Oct 2004 17:54:00 -0400
[Message part 1 (text/plain, inline)]
Daniel Jacobowitz wrote:
> I guess "not that hard" isn't a good description.  The actual debugging
> is easy: you need either gdbserver, or gdb and ssh, on the target
> system.  It can be debugged easily as long as you don't try to do it
> from the same console bterm is drawing on.
> 
> What framebuffer is being used - is it vga16?

Yes, vga16fb.

> If so, and the problem
> wasn't seen earlier, then it must have been either a kernel bug
> (somewhat likely) or triggered by the changes in 0.1.18 to fix colors
> after VT switching.  My best guess would be, add a call to
> bogl_vga16_reinit just before the return at the bottom of
> bogl_vga16_init, since the former is a little more thorough.  Does that
> help?

Well, it's complicated by the way that modifying the initrd that
contains bterm seems to make the problem go away sometimes. This makes
it hard to tell conclusively if any given change has fixed it, but I did
this:

- reproduced the problem with a locally built bterm copied into the
  initrd
- added the bogl_vga16_reinit, still see the problem

At least I have access to an unstripped bterm, gdb, and can reproduce
the problem with them now though.

Which is strange, because the problem _does_ go away when I do a VT
switch.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Tags added: d-i Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#273192; Package bogl-bterm. Full text and rfc822 format available.

Acknowledgement sent to Daniel Jacobowitz <dan@debian.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #39 received at 273192@bugs.debian.org (full text, mbox):

From: Daniel Jacobowitz <dan@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: 273192@bugs.debian.org
Subject: Re: red screen problems with bterm
Date: Sat, 23 Oct 2004 18:07:03 -0400
On Sat, Oct 23, 2004 at 05:54:00PM -0400, Joey Hess wrote:
> Daniel Jacobowitz wrote:
> > I guess "not that hard" isn't a good description.  The actual debugging
> > is easy: you need either gdbserver, or gdb and ssh, on the target
> > system.  It can be debugged easily as long as you don't try to do it
> > from the same console bterm is drawing on.
> > 
> > What framebuffer is being used - is it vga16?
> 
> Yes, vga16fb.
> 
> > If so, and the problem
> > wasn't seen earlier, then it must have been either a kernel bug
> > (somewhat likely) or triggered by the changes in 0.1.18 to fix colors
> > after VT switching.  My best guess would be, add a call to
> > bogl_vga16_reinit just before the return at the bottom of
> > bogl_vga16_init, since the former is a little more thorough.  Does that
> > help?
> 
> Well, it's complicated by the way that modifying the initrd that
> contains bterm seems to make the problem go away sometimes. This makes
> it hard to tell conclusively if any given change has fixed it, but I did
> this:
> 
> - reproduced the problem with a locally built bterm copied into the
>   initrd
> - added the bogl_vga16_reinit, still see the problem
> 
> At least I have access to an unstripped bterm, gdb, and can reproduce
> the problem with them now though.
> 
> Which is strange, because the problem _does_ go away when I do a VT
> switch.

Grr!  It's got to be something that the kernel isn't initializing to a
sane value, that we do reinitialize on vt switch.  I thought reinit
would catch all of them.  We're already setting the palette shortly
after bogl_vga16_init anyway.

I'm not sure where to go next.  The palette initialization does happen,
right, and the same palette is used as after a VT switch?

-- 
Daniel Jacobowitz



Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <dan@debian.org>:
Bug#273192; Package bogl-bterm. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Daniel Jacobowitz <dan@debian.org>. Full text and rfc822 format available.

Message #44 received at 273192@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: Daniel Jacobowitz <dan@debian.org>
Cc: 273192@bugs.debian.org
Subject: Re: red screen problems with bterm
Date: Sat, 23 Oct 2004 19:52:53 -0400
[Message part 1 (text/plain, inline)]
Daniel Jacobowitz wrote:
> I'm not sure where to go next.  The palette initialization does happen,
> right, and the same palette is used as after a VT switch?

Well, I tried playing with the colors defined in palette[]. For example,
I made the whole first row be 0xaa, so all the colors have a nice lavender
tint to them:

-    {0x00, 0x00, 0x00},        /* 0: Black. */
+    {0xaa, 0x00, 0x00},        /* 0: Black. */
     {0xaa, 0x00, 0x00},        /* 1: Red. */
-    {0x00, 0xaa, 0x00},        /* 2: Green. */
+    {0xaa, 0xaa, 0x00},        /* 2: Green. */
     {0xaa, 0xaa, 0x00},        /* 3: Yellow. */
-    {0x00, 0x00, 0xaa},        /* 4: Blue. */
+    {0xaa, 0x00, 0xaa},        /* 4: Blue. */
     {0xaa, 0x00, 0xaa},        /* 5: Magenta. */
-    {0x00, 0xaa, 0xaa},        /* 6: Cyan. */
+    {0xaa, 0xaa, 0xaa},        /* 6: Cyan. */
     {0xaa, 0xaa, 0xaa},        /* 7: White. */
-    {0xff, 0x00, 0x00},        /* 8: Bright red (unused). */
-    {0x00, 0x00, 0xff},        /* 9: Bright blue (unused). */
-    {0xa9, 0x99, 0x75},        /* A: Tux #1. */
-    {0xec, 0xc9, 0x39},        /* B: Tux #2. */
-    {0x61, 0x52, 0x39},        /* C: Tux #3. */
-    {0xe4, 0xa8, 0x10},        /* D: Tux #4. */
-    {0xa0, 0x6d, 0x0c},        /* E: Tux #5. */

If I boot with this bterm, I do not see any purples, just standard d-i
colors with the wrong color for blue, yeilding the same red background.

If I do a vt switch and back, glourios purple! (I think d-i has a future
with this color scheme ;-). 

So, I guess this means the palete is not being initialised on startup
and is after switch? As far as I can see, bogl_set_palette is called in
main() at startup. But I have not verified this in gdb yet or anything.
I also don't see what else could be happening on a VT siwtch to force
the palette to be set.

What do you think should be my next step to find out why the palette set
is not working at first?

Hmm, I just noticed something else of interest that my partial
colorblindness and sitting too far from the screen hid from me before.
If I boot the standard, unmodified bterm, and get the red background, I
also see cyan (or something close) for the foreground color of the
selected menu item. That color is supposed to be non-bright white.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#273192; Package bogl-bterm. Full text and rfc822 format available.

Acknowledgement sent to Daniel Jacobowitz <dan@debian.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #49 received at 273192@bugs.debian.org (full text, mbox):

From: Daniel Jacobowitz <dan@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: 273192@bugs.debian.org
Subject: Re: red screen problems with bterm
Date: Sat, 23 Oct 2004 20:10:15 -0400
On Sat, Oct 23, 2004 at 07:52:53PM -0400, Joey Hess wrote:
> Daniel Jacobowitz wrote:
> > I'm not sure where to go next.  The palette initialization does happen,
> > right, and the same palette is used as after a VT switch?
> 
> Well, I tried playing with the colors defined in palette[]. For example,
> I made the whole first row be 0xaa, so all the colors have a nice lavender
> tint to them:
> 
> -    {0x00, 0x00, 0x00},        /* 0: Black. */
> +    {0xaa, 0x00, 0x00},        /* 0: Black. */
>      {0xaa, 0x00, 0x00},        /* 1: Red. */
> -    {0x00, 0xaa, 0x00},        /* 2: Green. */
> +    {0xaa, 0xaa, 0x00},        /* 2: Green. */
>      {0xaa, 0xaa, 0x00},        /* 3: Yellow. */
> -    {0x00, 0x00, 0xaa},        /* 4: Blue. */
> +    {0xaa, 0x00, 0xaa},        /* 4: Blue. */
>      {0xaa, 0x00, 0xaa},        /* 5: Magenta. */
> -    {0x00, 0xaa, 0xaa},        /* 6: Cyan. */
> +    {0xaa, 0xaa, 0xaa},        /* 6: Cyan. */
>      {0xaa, 0xaa, 0xaa},        /* 7: White. */
> -    {0xff, 0x00, 0x00},        /* 8: Bright red (unused). */
> -    {0x00, 0x00, 0xff},        /* 9: Bright blue (unused). */
> -    {0xa9, 0x99, 0x75},        /* A: Tux #1. */
> -    {0xec, 0xc9, 0x39},        /* B: Tux #2. */
> -    {0x61, 0x52, 0x39},        /* C: Tux #3. */
> -    {0xe4, 0xa8, 0x10},        /* D: Tux #4. */
> -    {0xa0, 0x6d, 0x0c},        /* E: Tux #5. */
> 
> If I boot with this bterm, I do not see any purples, just standard d-i
> colors with the wrong color for blue, yeilding the same red background.
> 
> If I do a vt switch and back, glourios purple! (I think d-i has a future
> with this color scheme ;-). 

:-)

> So, I guess this means the palete is not being initialised on startup
> and is after switch? As far as I can see, bogl_set_palette is called in
> main() at startup. But I have not verified this in gdb yet or anything.
> I also don't see what else could be happening on a VT siwtch to force
> the palette to be set.

Yes, I think you must be right.  I know that the initial red palette
people have been seeing is the Linux console's default palette, more or
less.  So we're getting stuck with that one.

> 
> What do you think should be my next step to find out why the palette set
> is not working at first?

Verifying in GDB that we do set it might be the next step.  I can't
imagine that we don't.  Maybe the ioctl() is returning some exciting
result code, possibly -EFAULT?  Maybe we're doing something else which
resets the cmap?

-- 
Daniel Jacobowitz



Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <dan@debian.org>:
Bug#273192; Package bogl-bterm. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Daniel Jacobowitz <dan@debian.org>. Full text and rfc822 format available.

Message #54 received at 273192@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: Daniel Jacobowitz <dan@debian.org>
Cc: 273192@bugs.debian.org
Subject: Re: red screen problems with bterm
Date: Sat, 23 Oct 2004 21:24:31 -0400
[Message part 1 (text/plain, inline)]
Daniel Jacobowitz wrote:
> > What do you think should be my next step to find out why the palette set
> > is not working at first?
> 
> Verifying in GDB that we do set it might be the next step.  I can't
> imagine that we don't.  Maybe the ioctl() is returning some exciting
> result code, possibly -EFAULT?

The ioctl is only called once, so if it didn't work, then the kernel
wouldn't be able to restore the (correct) cmap after a VT switch, would
it?

> Maybe we're doing something else which resets the cmap?

What else could reset the cmap?

I wonder if perhaps there's a bug in the kernel that makes it accept the
new cmap, but not always make it take effect until a VT switch. If so,
then it can't be fixed in bterm at all, really.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#273192; Package bogl-bterm. Full text and rfc822 format available.

Acknowledgement sent to Daniel Jacobowitz <dan@debian.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #59 received at 273192@bugs.debian.org (full text, mbox):

From: Daniel Jacobowitz <dan@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: 273192@bugs.debian.org
Subject: Re: red screen problems with bterm
Date: Sat, 23 Oct 2004 22:07:17 -0400
On Sat, Oct 23, 2004 at 09:24:31PM -0400, Joey Hess wrote:
> Daniel Jacobowitz wrote:
> > > What do you think should be my next step to find out why the palette set
> > > is not working at first?
> > 
> > Verifying in GDB that we do set it might be the next step.  I can't
> > imagine that we don't.  Maybe the ioctl() is returning some exciting
> > result code, possibly -EFAULT?
> 
> The ioctl is only called once, so if it didn't work, then the kernel
> wouldn't be able to restore the (correct) cmap after a VT switch, would
> it?

Hmm, I guess you're right.
> > Maybe we're doing something else which resets the cmap?
> 
> What else could reset the cmap?
> 
> I wonder if perhaps there's a bug in the kernel that makes it accept the
> new cmap, but not always make it take effect until a VT switch. If so,
> then it can't be fixed in bterm at all, really.

I have no idea.  That _shouldn't_ happen.  I don't see anything of the
sort in my current reading of the vga16 code, but I'm out of touch with
the framebuffer code.  It looks like the ioctl should feed directly
into a couple of outb's, in vga16_setpalette, so that doesn't seem
likely.  There haven't been any changes to this code in a while,
either.

The same code called by the ioctl to set the color map is called
by fbcon_switch after a VT switch, so that's not the problem either.

If that turns out to be the problem, either bterm or d-i could hack
around it by forcing a VT switch.  Yuck.

-- 
Daniel Jacobowitz



Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <dan@debian.org>:
Bug#273192; Package bogl-bterm. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Daniel Jacobowitz <dan@debian.org>. Full text and rfc822 format available.

Message #64 received at 273192@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: Daniel Jacobowitz <dan@debian.org>
Cc: 273192@bugs.debian.org
Subject: Re: red screen problems with bterm
Date: Sat, 23 Oct 2004 22:57:36 -0400
[Message part 1 (text/plain, inline)]
Daniel Jacobowitz wrote:
> > I wonder if perhaps there's a bug in the kernel that makes it accept the
> > new cmap, but not always make it take effect until a VT switch. If so,
> > then it can't be fixed in bterm at all, really.
> 
> I have no idea.  That _shouldn't_ happen.  I don't see anything of the
> sort in my current reading of the vga16 code, but I'm out of touch with
> the framebuffer code.  It looks like the ioctl should feed directly
> into a couple of outb's, in vga16_setpalette, so that doesn't seem
> likely.  There haven't been any changes to this code in a while,
> either.
> 
> The same code called by the ioctl to set the color map is called
> by fbcon_switch after a VT switch, so that's not the problem either.

Unless there's some difference in how it sets up things during a swtich
from text mode vs setting the color palette when already in graphics
mode as bterm starts up. Maybe a different ordering of actions or just a
different config of the video card. But I don't know what I'm talking
about really..

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Reply sent to Samuel Thibault <sthibault@debian.org>:
You have taken responsibility. (Sun, 20 Mar 2011 17:00:07 GMT) Full text and rfc822 format available.

Notification sent to Joey Hess <joeyh@debian.org>:
Bug acknowledged by developer. (Sun, 20 Mar 2011 17:00:07 GMT) Full text and rfc822 format available.

Message #69 received at 273192-done@bugs.debian.org (full text, mbox):

From: Samuel Thibault <sthibault@debian.org>
To: 273192-done@bugs.debian.org
Subject: Re: Bug#273192: swapped colors with 2.6 kernel
Date: Sun, 20 Mar 2011 17:56:56 +0100
We haven't had more reports recently (and some people have reported
it as fixed). I believe this bug has somehow been fixed in the kernel
itself.

Samuel




Reply sent to Samuel Thibault <sthibault@debian.org>:
You have taken responsibility. (Sun, 20 Mar 2011 17:00:08 GMT) Full text and rfc822 format available.

Notification sent to Jonathan Matthew <jonathan@kaolin.hn.org>:
Bug acknowledged by developer. (Sun, 20 Mar 2011 17:00:08 GMT) Full text and rfc822 format available.

Reply sent to Samuel Thibault <sthibault@debian.org>:
You have taken responsibility. (Sun, 20 Mar 2011 17:00:08 GMT) Full text and rfc822 format available.

Notification sent to "Herbert Kaminski" <herbert.kaminski@t-online.de>:
Bug acknowledged by developer. (Sun, 20 Mar 2011 17:00:08 GMT) Full text and rfc822 format available.

Reply sent to Samuel Thibault <sthibault@debian.org>:
You have taken responsibility. (Sun, 20 Mar 2011 17:00:08 GMT) Full text and rfc822 format available.

Notification sent to tapio.lehtonen@iki.fi:
Bug acknowledged by developer. (Sun, 20 Mar 2011 17:00:09 GMT) Full text and rfc822 format available.

Reply sent to Samuel Thibault <sthibault@debian.org>:
You have taken responsibility. (Sun, 20 Mar 2011 17:00:09 GMT) Full text and rfc822 format available.

Notification sent to "Mathias R. Huber" <mrhuber@sbox.tugraz.at>:
Bug acknowledged by developer. (Sun, 20 Mar 2011 17:00:09 GMT) Full text and rfc822 format available.

Reply sent to Samuel Thibault <sthibault@debian.org>:
You have taken responsibility. (Sun, 20 Mar 2011 17:00:09 GMT) Full text and rfc822 format available.

Notification sent to Martin Samuelsson <debianbts@cos.user.lysator.liu.se>:
Bug acknowledged by developer. (Sun, 20 Mar 2011 17:00:09 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Mon, 18 Apr 2011 07:32:19 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 07:07:10 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.