Debian Bug report logs - #241717
xterm: various colour problems (mouse cursor color, text colours)

version graph

Package: xterm; Maintainer for xterm is Debian X Strike Force <debian-x@lists.debian.org>; Source for xterm is src:xterm.

Reported by: Marc Lehmann <debian-reportbug@plan9.de>

Date: Fri, 2 Apr 2004 16:03:09 UTC

Severity: minor

Tags: fixed-upstream, upstream

Found in version 4.3.0-7

Fixed in version xfree86/4.3.0.dfsg.1-2

Done: fabbione@fabbione.net (Fabio M. Di Nitto)

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, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#241717; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to Marc Lehmann <debian-reportbug@plan9.de>:
New Bug report received and forwarded. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. Full text and rfc822 format available.

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

From: Marc Lehmann <debian-reportbug@plan9.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: xterm: various colour problems (mouse cursor color, text colours)
Date: Fri, 02 Apr 2004 17:25:41 +0200
Package: xterm
Version: 4.3.0-7
Severity: minor

The xterm mouse cursor is a thin line, under debians xterm, it's much
thicker.

Specifying -rv restores the original cursor (but does not do reverse
video, see bug #239510, which is probably related).

It seems that debians xterm does not set mouse cursor colours correctly
and defaults to white background and black foreground, while the default
config specifies black background on white foreground, which is probably
why -rv fixes this as it correctly swaps background and foreground for all
items.

Another colour problem: debian also changed default colours of
xterm, which makes coloured text very hard to read, especially for
colour-impaired people like me (it's very difficult for me to decipher
e.g. the alsamixer labels in xterm, other shells work fine). The original
xterm colours are much easier on my eyes, due to the much increased
contrast.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (700, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.4
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8

Versions of packages xterm depends on:
hi  libc6                       2.3.2.ds1-11 GNU C Library: Shared libraries an
hi  libexpat1                   1.95.6-4     XML parsing C library - runtime li
ii  libfontconfig1              2.2.1-8      generic font configuration library
hi  libfreetype6                2.1.5-2      FreeType 2 font engine, shared lib
ii  libice6                     4.3.0-7      Inter-Client Exchange library
ii  libncurses5                 5.4-2        Shared libraries for terminal hand
ii  libsm6                      4.3.0-7      X Window System Session Management
ii  libxaw7                     4.3.0-7      X Athena widget set library
ii  libxext6                    4.3.0-7      X Window System miscellaneous exte
ii  libxft2                     2.1.2-6      FreeType-based font drawing librar
ii  libxmu6                     4.3.0-7      X Window System miscellaneous util
ii  libxpm4                     4.3.0-7      X pixmap library
ii  libxrender1                 0.8.3-7      X Rendering Extension client libra
ii  libxt6                      4.3.0-7      X Toolkit Intrinsics
ii  xlibs                       4.3.0-7      X Window System client libraries m
ii  xlibs-data                  4.3.0-7      X Window System client data

-- no debconf information



Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#241717; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to dickey@radix.net:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. Full text and rfc822 format available.

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

From: dickey@radix.net
To: 241717@bugs.debian.org
Cc: dickey@saltmine.radix.net
Subject: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241717
Date: Mon, 5 Apr 2004 06:26:09 -0400 (EDT)
                       Debian Bug report logs - #241717
>       xterm: various colour problems (mouse cursor color, text colours)
I don't see this behavior when I'm running xterm - it probably depends on
resource and environment settings.

The description is a little confused - I'm not entirely certain whether the
complaint is about the rectangular text-cursor, or the mouse pointer.  For the
former, xterm tries to determine if the colors coincide with the foreground or
background colors.  For the latter - that's set outside xterm.



Tags added: unreproducible, moreinfo Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#241717. Full text and rfc822 format available.

Message #15 received at 241717-submitter@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: 241717-submitter@bugs.debian.org, control@bugs.debian.org
Subject: Re: Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Date: Tue, 6 Apr 2004 02:21:11 -0500
[Message part 1 (text/plain, inline)]
tag 241717 + unreproducible moreinfo
thanks

On Fri, Apr 02, 2004 at 05:25:41PM +0200, Marc Lehmann wrote:
> Package: xterm
> Version: 4.3.0-7
> Severity: minor
> 
> The xterm mouse cursor is a thin line, under debians xterm, it's much
> thicker.

The *mouse* cursor is not controlled by xterm, but by another program,
probably your window manager.

> Specifying -rv restores the original cursor (but does not do reverse
> video, see bug #239510, which is probably related).
> 
> It seems that debians xterm does not set mouse cursor colours correctly
> and defaults to white background and black foreground, while the default
> config specifies black background on white foreground, which is probably
> why -rv fixes this as it correctly swaps background and foreground for all
> items.

To be precise, the Debian default is "gray90" on "black".  You can see
this in /etc/X11/app-defaults/XTerm-color.

> Another colour problem: debian also changed default colours of
> xterm, which makes coloured text very hard to read, especially for
> colour-impaired people like me (it's very difficult for me to decipher
> e.g. the alsamixer labels in xterm, other shells work fine). The original
> xterm colours are much easier on my eyes, due to the much increased
> contrast.

Perhaps you could put a window dump of xterm up on the web somewhere so
we could have a look at this?

What you're describing doesn't sound like Debian's defaults at all.

It's also worth noting that Debian's default xterm configuration hasn't
changed recently.  Perhaps something else on your system is playing
around with X resources?

-- 
G. Branden Robinson                |    Damnit, we're all going to die;
Debian GNU/Linux                   |    let's die doing something *useful*!
branden@debian.org                 |    -- Hal Clement, on comments that
http://people.debian.org/~branden/ |       space exploration is dangerous
[signature.asc (application/pgp-signature, inline)]

Information stored:
Bug#241717; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to Marc Lehmann <pcg@schmorp.de>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #20 received at 241717-quiet@bugs.debian.org (full text, mbox):

From: Marc Lehmann <pcg@schmorp.de>
To: Branden Robinson <branden@debian.org>, 241717-quiet@bugs.debian.org
Cc: 241717-submitter@bugs.debian.org, control@bugs.debian.org
Subject: Re: Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Date: Tue, 6 Apr 2004 16:10:52 +0200
On Tue, Apr 06, 2004 at 02:21:11AM -0500, Branden Robinson <branden@debian.org> wrote:
> tag 241717 + unreproducible moreinfo

Just BTW: there is no reason to tag this as unreproducible, as you haven't
tried to reproduce it but dismissed it because you assumed the mouse
cursor is wm-controlled. You might have tagged it as solved or notabug or
something similar (wich would have been wrong, but at least consistent
with your response :)

> thanks
> 
> > The xterm mouse cursor is a thin line, under debians xterm, it's much
> > thicker.
> 
> The *mouse* cursor is not controlled by xterm, but by another program,
> probably your window manager.

This is wrong. If you don't believe me please ask somebody who knows more
about X. The mouse cursor is application controllable and apps usually
make ample use of that. xterm sets it to the insert cursor (or whatever is
configured for xterm), sets the colours etc. and even has escape codes to
control this appearance.

> > It seems that debians xterm does not set mouse cursor colours correctly
> > and defaults to white background and black foreground, while the default
> > config specifies black background on white foreground, which is probably
> > why -rv fixes this as it correctly swaps background and foreground for all
> > items.
> 
> To be precise, the Debian default is "gray90" on "black".  You can see
> this in /etc/X11/app-defaults/XTerm-color.

I was very imprecise with my use of "black" vs. "white" indeed, the
point being more of dark-on-light bg vs. light on dark bg, or more
precisely, using the same fg/bg colours for the mouse cursor as for
the text.

Nevertheless, the mousecursor is normally black-on-white (or
black-on-gray90 if you like). Debian reverses the default colours for the
text but leaves the mouse cursor colours black-on-white (or gray90) while
correct colours are white-on-black (or gray90).

You can see the correct behaviour and correct appearance by starting xterm
without te debian colours (white bg), or another terminal emulator such as
rxvt-xpm or Eterm or pterm or just about anything else (I haven't found
any emulator that does it wrong with the exception of rxvt-unicode, which
is an old version which has been corrected upstream).

> Perhaps you could put a window dump of xterm up on the web somewhere so
> we could have a look at this?
> 
> What you're describing doesn't sound like Debian's defaults at all.

Here is an example:

http://data.plan9.de/x.png

The lower right terminal contains a much lighter blue (blue is often used
as a background colour). The other terminals show more-or-less standard
vt100 colours, the xterm shows a much more difficult-to-read combination
(for me). The program used is alsamixer, but many other programs use this
bg colour by default (mutt, irssi, epic4 I think etc..)

> It's also worth noting that Debian's default xterm configuration hasn't
> changed recently.  Perhaps something else on your system is playing
> around with X resources?

I am not using xterm normally, and am using my own .Xdefaults for
10years+, which is why I didn't notice the problem so far. While working
on rxvt-unicode I had a bug that kept the terminal from settting mouse
colours, which I fixed (in version 2.7 btw). My own rxvt* config also
defaults to white-on-black (gray80, actually ;), while both rxvt and
rxvt-unicode default to black-on-white just like xterm.

However, the mouse cursor in rxvt-unicode wasn't adjusted properly (that
code was broken and commented out). After fixing this I tried xterm with
the debian default config for the first time (thus the HOME=/tmp/empty
to ensure my .Xdefaults aren't picked up (they are not loaded into the
x-server, either)).

I then noticed both the hard-to-read colours (which are from
/etc/X11/app-defaults/XTerm-color) as well as the same "bug" regarding
the mouse cursor (unlike rxvt-unicode, it's not neccessarily a code bug
but a config bug, although it could be assumed that xterm should use the
configured fg/bg colours for the mouse cursor by default, as rxvt-unicode
does. xterm does not do this and needs manual configuration to match the
configured colours. The default black-on-white config is consistent,
while debian reversed only part of the colours and left others unchanged,
resulting in a white background colou for the mousecursor and black for
the text, creating an outline version of whatever cursor used).

As for a visual description of how the cursor in most terminal looks like,
it should (by default, this is usualy configurable, and no colour cursors
used) be a thin vertical line with thick endpoints (as you can see in most
terminals), the same is true with xterm in it's default configuration.

In debian, the insert cursor becomes very heavyweight because what's
actually displayed is the outline of this cursor. It does not resemble
the originally intended apearance.

I assume that this is a just an oversight or a omission on part of the
debian maintainer, nothing more, and not intended behaviour.

The changed colours, OTOH, are obviously intended behaviour, but most
combinations are much harder to read to me (I have a very common form of
red-green blindness).

The standard (vt100) colours are more-or-less standard among all terminal
emulators (some might use not-quite-white for white, but the general
brightness and look is extremely similar).

Debians xterm (and only debains xterm AFAICS) changed at least one of
these colours (maybe more). The problem is that programs assume the vt100
colour set and due to the drastically changed brightness (apart from
appearance) of the changed colour(s), programs often output hard-to-read
text on xterm while the same tetx looks readable everywhere else.

In addition, this colour change *is* a bug as the manpage documents the
colours clearly, but the displayed colours are not in according to the
manpage.

To resolve this, either the manpage needs to be updated to conform to
the debian "standard", or (preferably as this is a usability issue), the
colours should be set to the same set of colours that every other terminal
displays, otherwise programs have no chance to use colours portably.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |



Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#241717. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#241717; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to dickey@his.com (Thomas Dickey):
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. Full text and rfc822 format available.

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

From: dickey@his.com (Thomas Dickey)
To: 241717@bugs.debian.org
Cc: dickey@his.com (Thomas Dickey)
Subject: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241717
Date: Wed, 7 Apr 2004 06:43:30 -0400
>                       Debian Bug report logs - #241717
>       xterm: various colour problems (mouse cursor color, text colours)
...
>Date: Tue, 6 Apr 2004 16:10:52 +0200
>From: Marc Lehmann <pcg@schmorp.de>
...
>This is wrong. If you don't believe me please ask somebody who knows more
>about X. The mouse cursor is application controllable and apps usually
>make ample use of that. xterm sets it to the insert cursor (or whatever is
>configured for xterm), sets the colours etc. and even has escape codes to
>control this appearance.

hmm - no: you're confusing the mouse pointer and the text cursor.
Let's settle on using the terminology in the xterm manpage.

>Nevertheless, the mousecursor is normally black-on-white (or
>black-on-gray90 if you like). Debian reverses the default colours for the
>text but leaves the mouse cursor colours black-on-white (or gray90) while
>correct colours are white-on-black (or gray90).

still confused.

>You can see the correct behaviour and correct appearance by starting xterm
>without te debian colours (white bg), or another terminal emulator such as
>rxvt-xpm or Eterm or pterm or just about anything else (I haven't found
>any emulator that does it wrong with the exception of rxvt-unicode, which
>is an old version which has been corrected upstream).

There aren't any old versions of rxvt-unicode.

>> Perhaps you could put a window dump of xterm up on the web somewhere so
>> we could have a look at this?
>>
>> What you're describing doesn't sound like Debian's defaults at all.
>
>Here is an example:
>
>http://data.plan9.de/x.png

The given picture only shows an outline for the text cursor,
corresponding to when focus is lost.

>The lower right terminal contains a much lighter blue (blue is often used
>as a background colour). The other terminals show more-or-less standard
>vt100 colours, the xterm shows a much more difficult-to-read combination
>(for me). The program used is alsamixer, but many other programs use this
>bg colour by default (mutt, irssi, epic4 I think etc..)

vt100's don't do colors.  There are no standard vt100 colors.
See
	http://invisible-island.net/xterm/xterm.log.html
for relevant discussion of Dodger blue.

>In addition, this colour change *is* a bug as the manpage documents the
>colours clearly, but the displayed colours are not in according to the
>manpage.

I already updated the manpage (see changelog)
-- 
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net



Tags removed: unreproducible Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#241717. Full text and rfc822 format available.

Message #33 received at 241717-submitter@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: 241717-submitter@bugs.debian.org, control@bugs.debian.org
Subject: Re: Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Date: Thu, 8 Apr 2004 01:19:07 -0500
[Message part 1 (text/plain, inline)]
tag 241717 - unreproducible
thanks

On Tue, Apr 06, 2004 at 04:10:52PM +0200, Marc Lehmann wrote:
> On Tue, Apr 06, 2004 at 02:21:11AM -0500, Branden Robinson <branden@debian.org> wrote:
> > tag 241717 + unreproducible moreinfo
> 
> Just BTW: there is no reason to tag this as unreproducible, as you haven't
> tried to reproduce it but dismissed it because you assumed the mouse
> cursor is wm-controlled. You might have tagged it as solved or notabug or
> something similar (wich would have been wrong, but at least consistent
> with your response :)
> 
> > thanks
> > 
> > > The xterm mouse cursor is a thin line, under debians xterm, it's much
> > > thicker.
> > 
> > The *mouse* cursor is not controlled by xterm, but by another program,
> > probably your window manager.
> 
> This is wrong. If you don't believe me please ask somebody who knows more
> about X. The mouse cursor is application controllable and apps usually
> make ample use of that. xterm sets it to the insert cursor (or whatever is
> configured for xterm), sets the colours etc. and even has escape codes to
> control this appearance.

Sorry, you're right, and I had a brainfart here. I apologize.

However, the appearance of the X cursor when inside an xterm window has
not changed in my experience in the 6 years I've been maintaining this
package for Debian.

> > To be precise, the Debian default is "gray90" on "black".  You can see
> > this in /etc/X11/app-defaults/XTerm-color.
> 
> I was very imprecise with my use of "black" vs. "white" indeed, the
> point being more of dark-on-light bg vs. light on dark bg, or more
> precisely, using the same fg/bg colours for the mouse cursor as for
> the text.
> 
> Nevertheless, the mousecursor is normally black-on-white (or
> black-on-gray90 if you like). Debian reverses the default colours for the
> text but leaves the mouse cursor colours black-on-white (or gray90) while
> correct colours are white-on-black (or gray90).

Oh, I see what you mean.  The way old X documentation talks about this
is that the "background" of the X cursor is a "mask", and the foreground
is an inset image.  The mask completely surrounds the cursor.

Okay, so you're bothered by the fact that the mask is visible by default
in Debian, but not on good old white-background xterms.

Huh.  I can't remember anyone complaining about this before, and this
change has been in place for *years*.  However, I use "unclutter", so
the large, prominent text-insertion-looking cursor never really gets in
my way.

> You can see the correct behaviour and correct appearance by starting xterm
> without te debian colours (white bg), or another terminal emulator such as
> rxvt-xpm or Eterm or pterm or just about anything else (I haven't found
> any emulator that does it wrong with the exception of rxvt-unicode, which
> is an old version which has been corrected upstream).

Yeah, I know what you're talking about now.

> > Perhaps you could put a window dump of xterm up on the web somewhere so
> > we could have a look at this?
> > 
> > What you're describing doesn't sound like Debian's defaults at all.
> 
> Here is an example:
> 
> http://data.plan9.de/x.png
> 
> The lower right terminal contains a much lighter blue (blue is often used
> as a background colour). The other terminals show more-or-less standard
> vt100 colours, the xterm shows a much more difficult-to-read combination
> (for me). The program used is alsamixer, but many other programs use this
> bg colour by default (mutt, irssi, epic4 I think etc..)

xterm refers to it as "color4", a resource of the VT100 widget.

I find this color, "DodgerBlue1", much easer to read on a
black-background xterm when using terminal fonts of very low weight.

Like the default "fixed" font, which is xterm's default.

In fact, the upstream XTerm maintainer, Thomas Dickey, appears to have
agreed with my reasoning (as have many users), and changed the upstream
defaults to look like Debian's.

     * use  color  resource  setting  from Debian package for xterm VT100
       widget, since the choice of blues provides better contrast.

http://cvsweb.xfree86.org/cvsweb/xc/programs/xterm/XTerm-col.ad

(See the commit message for revision 3.2.)

I do agree that the contrast is better in the left window on your
screenshot, however you're using a heavily-weighted, thick font.

You might be able to win me over on the mouse cursor issue, but I'm not
persuaded on this one.

(Of course, if anyone reading this on debian-x would like to offer their
opinions, please do.)

> I am not using xterm normally, and am using my own .Xdefaults for
> 10years+, which is why I didn't notice the problem so far. While working
> on rxvt-unicode I had a bug that kept the terminal from settting mouse
> colours, which I fixed (in version 2.7 btw). My own rxvt* config also
> defaults to white-on-black (gray80, actually ;), while both rxvt and
> rxvt-unicode default to black-on-white just like xterm.
> 
> However, the mouse cursor in rxvt-unicode wasn't adjusted properly (that
> code was broken and commented out). After fixing this I tried xterm with
> the debian default config for the first time (thus the HOME=/tmp/empty
> to ensure my .Xdefaults aren't picked up (they are not loaded into the
> x-server, either)).
> 
> I then noticed both the hard-to-read colours (which are from
> /etc/X11/app-defaults/XTerm-color) as well as the same "bug" regarding
> the mouse cursor (unlike rxvt-unicode, it's not neccessarily a code bug
> but a config bug, although it could be assumed that xterm should use the
> configured fg/bg colours for the mouse cursor by default, as rxvt-unicode
> does. xterm does not do this and needs manual configuration to match the
> configured colours. The default black-on-white config is consistent,
> while debian reversed only part of the colours and left others unchanged,
> resulting in a white background colou for the mousecursor and black for
> the text, creating an outline version of whatever cursor used).

Reviewing the xterm manpage, I see that the pointer cursor is
configurable by escape sequences (as you noted), by a command-line
option ("-ms"), and by the X resources pointerColor and
pointerColorBackground.

With respect to the latter:

       pointerColor (class PointerColor)
	       Specifies the foreground color of the pointer.  The default is
	       ##XtDefaultForeground.##

       pointerColorBackground (class PointerColorBackground)
	       Specifies the background color of the pointer.  The default is
	       ##XtDefaultBackground.##

I wonder if it shouldn't default to the VT100 widget's text foreground and
background colors instead.

What do you think?

> I assume that this is a just an oversight or a omission on part of the
> debian maintainer, nothing more, and not intended behaviour.

Yup.

> The changed colours, OTOH, are obviously intended behaviour, but most
> combinations are much harder to read to me (I have a very common form of
> red-green blindness).

Hmm.  This is the first I've heard of the changed colors being an
accessibility impediment.

> The standard (vt100) colours are more-or-less standard among all terminal
> emulators (some might use not-quite-white for white, but the general
> brightness and look is extremely similar).

Well, the Linux framebuffer console driver uses a shade of blue very
similar to the one I made color4 use for the corresponding color, and
*that's* a VT100 (technically VT220) emulator.

It is this behavior of fbcon that inspiried me to change xterm's
default, as I found that brighter blue much easier to read against the
black background, and wanted xterm to be easy to read too.

> Debians xterm (and only debains xterm AFAICS) changed at least one of
> these colours (maybe more). The problem is that programs assume the vt100
> colour set and due to the drastically changed brightness (apart from
> appearance) of the changed colour(s), programs often output hard-to-read
> text on xterm while the same tetx looks readable everywhere else.

Well, as I said above, this has precedent in fbcon, and is now the
default upstream.

> In addition, this colour change *is* a bug as the manpage documents the
> colours clearly, but the displayed colours are not in according to the
> manpage.

I agree that the manpage should be patched for Debian.

> To resolve this, either the manpage needs to be updated to conform to
> the debian "standard", or (preferably as this is a usability issue), the
> colours should be set to the same set of colours that every other terminal
> displays, otherwise programs have no chance to use colours portably.

I think you are overstating your case.  Please adjust it in light of the
facts I have now brought to your attention.

-- 
G. Branden Robinson                |    People are equally horrified at
Debian GNU/Linux                   |    hearing the Christian religion
branden@debian.org                 |    doubted, and at seeing it
http://people.debian.org/~branden/ |    practiced.         -- Samuel Butler
[signature.asc (application/pgp-signature, inline)]

Information stored:
Bug#241717; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to Marc Lehmann <pcg@schmorp.de>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #38 received at 241717-quiet@bugs.debian.org (full text, mbox):

From: Marc Lehmann <pcg@schmorp.de>
To: Branden Robinson <branden@debian.org>, 241717-quiet@bugs.debian.org
Cc: 241717-submitter@bugs.debian.org, control@bugs.debian.org
Subject: Re: Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Date: Thu, 8 Apr 2004 17:14:13 +0200
On Thu, Apr 08, 2004 at 01:19:07AM -0500, Branden Robinson <branden@debian.org> wrote:
> However, the appearance of the X cursor when inside an xterm window has
> not changed in my experience in the 6 years I've been maintaining this
> package for Debian.

Well, it's not really a major bug but a minor issue. I think it should
be fixed, but it's obviously somethig if a correctness issue (how it was
meant to be, or how other terminals handle it) not a usability thing.

> Huh.  I can't remember anyone complaining about this before, and this
> change has been in place for *years*.

(Is that an argument? For what? :)

Fact is, it's incorrect, both from the standpoint of xterm (only some
of fg/bg was reversed) as well as from the standpoint of other apps,
terminals or not. They all use the same cursor, except xterm in default
config.

Wther there are masses of people complaining or not should certainly
influence the priority that this bug gets. One might even argue that the
new look is _better_ (I don't) and keep it, but it should receive some
thought at one point in time.

> I find this color, "DodgerBlue1", much easer to read on a
> black-background xterm when using terminal fonts of very low weight.

Well, this colour (a reatively dark blue on vt100 and everywhere else) is
often used as background colour because it's dark.

If you want a light blue as foreground, then you can always have a light
blue as foreground, as xterm offers high intensity blue.

The only "app" I know that uses the darker blue as fg is ls, however,
there are a multitude of apps that use it as bg (very old ones as well as
new ones, such as alsamixer).

Most combinations become unreadable to colour-blind people (it seems, at
least this is true to me, although I am not completely colour blind but
have a colour weakness).

> Like the default "fixed" font, which is xterm's default.

Thinner fonts only make this problem worse for me, as the area
decreases.

> In fact, the upstream XTerm maintainer, Thomas Dickey, appears to have
> agreed with my reasoning (as have many users), and changed the upstream
> defaults to look like Debian's.

I do not think it is fair to take a majority to decide for visually
impaired. After all, the majority of users doesn't suffer from this
problem. In contrast, it is rather easy to read the default dark blue on
black (for me), as opposed to almost anything on the new light blue.

So this change brings a small improvement for non-colour-blind and a
vast problem for others.

I still think that the majority of applications use blue as background
for blue being perceived as darker as other colours.

If an app uses it as fg and this is bad, then I think that app has a
problem, not the terminal emulator, which, after all, just offers a fairly
standardized colour set.

> I do agree that the contrast is better in the left window on your
> screenshot, however you're using a heavily-weighted, thick font.

Well, a thinner font makes it much worse for me.

> You might be able to win me over on the mouse cursor issue, but I'm not
> persuaded on this one.
> 
> (Of course, if anyone reading this on debian-x would like to offer their
> opinions, please do.)

I am not personally insulted if you fix neither of these problems. I
stated my opinion, that it is a bug, but I am not terribly affected by it
(most occasions where i have to use xterm I don't need colour, and when I
need colour I am usually in front of one of my machines).

It's not of any priority either...

>        pointerColor (class PointerColor)
> 	       ##XtDefaultForeground.##
> 
>        pointerColorBackground (class PointerColorBackground)
> 	       ##XtDefaultBackground.##
> 
> I wonder if it shouldn't default to the VT100 widget's text foreground and
> background colors instead.
> 
> What do you think?
> 

I tend to agree. That is (I think) how rxvt does it and (definitely) how
rxvt-unicode does it. I have no idea how other terminals like pterm, Eterm
etc. do it. They are (on debian at least) gray-on-black, but the mouse
cursor colours _are_ "correct", wether their maintainers, their authors ir
the binaries themselves do it, I am not sure.

> > combinations are much harder to read to me (I have a very common form of
> > red-green blindness).
> 
> Hmm.  This is the first I've heard of the changed colors being an
> accessibility impediment.

Most people won't bother to report it, I'd guess, because for most
people it is a non-issue (not having problems because they don't depend
on the contrast) and for the rest it's a minor issue (it _is_ a minor
issue: I can change colours, and people who can't can just use another
terminal. As a matter of fact, xterm is probably not the most-used shell,
as it is in a somewhat detrimental state and the (much worse) konsole and
gnome-terminals come "standard" on most dekstops).

> Well, the Linux framebuffer console driver uses a shade of blue very
> similar to the one I made color4 use for the corresponding color, and
> *that's* a VT100 (technically VT220) emulator.

I can't reproduce that at all.

I just booted a knoppix, which uses fb, and looked at the 2.4.25
source. The shade of blue used for the framebuffer looks identical and (by
code) seems to be even darker than colours the majority of terminals use
(i.e. "dark" blue, although it's quite a light blue in fact).

   framebuffer:  #0000aa (standard vga actually, and real vt100 AFAICR)
   gnome-terminal#0000aa
   Eterm:        #0000cc
   rxvt:         #0000cd
   mlterm:       #0000e6
   pterm:        #0000eb
   konsole:      #1818b2 (quite different, but still mostly the same blue)
   xterm-debian: #1e90ff (drastically different colour, especially
                          with regards to contrast)

That clearly disagrees with what you claim. As you can see, they vary
considerably in the exact colour used, but it's always a real blue. The
only exception is xterm on debian that drastically changed at least that
colour to something not really blue either, but _much_ lighter and
giving a much lower contrast.

Maybe the kernel you used was especially patched to use another colour?
Or you use some user-space program that resets the colours after boot?

> It is this behavior of fbcon that inspiried me to change xterm's
> default, as I found that brighter blue much easier to read against the
> black background, and wanted xterm to be easy to read too.

Whatever inspired you, it's not the standard fbcon that is part of the
linux kernel (2.4.25 at least).
   
Please note that I don't say that change is inherently bad (if somehting
is broken for 20 years it should still be fixed), but that change brings
more bad than good, as all the other terminals mostly agree on the
shade of blue used and programs wil need to make exceptions to look
good/readable/as expected on xterm only (which they might well do and look
bad on most other terminals).

I think one mustn't change too lightly something that is such a widely
used de-facto standard. It took me only a minute or so to find out that
something is bad about xterm: I couldn't use alsamixer. And later some
other apps, but then I stopped trying.

Alsamixer is a good example. It assumes (not without good indication)
that blue contrasts good with red. However, xterm replaced that blue with
something resembling a light cyan (you can disagree with that description,
after all, my colour vision is not _that_ good and describing colours is
not the easiest thing for me :).

As a result, alsamixer is readable _everywhere_ except on debians xterm.

I think what needs to be changed is programs using bad colour
combinations, not the standard vt100 colour palette. Consider a similar
change in the TCP/IP protocol suite: some web-server is misbehaving and
breaking the http protocol.

The "xterm solution" would be to use another port number for the working
servers, while I would propose to leave working servers as they are and
instead fix the one web server that is causing the trouble.

The obvious (to me) reason is that changing the colour palette affects all
the "good" applications, while fixing the few apps that use bad colours
(colour-ls for example I would put into that group, at least with a thin
font. I sit in front of an LCD screen and don't have problems, but I guess
on CRTs the dark blue for directories might be annoying).

> > text on xterm while the same tetx looks readable everywhere else.
> 
> Well, as I said above, this has precedent in fbcon, and is now the
> default upstream.

Well, as I said above, there seems to be no precedent and it makes it very
hard to use for visually impaired users, and disagrees with the _whole_
rest of the world.

> I agree that the manpage should be patched for Debian.

That solution is fine with me, if you ask me.

> > colours should be set to the same set of colours that every other terminal
> > displays, otherwise programs have no chance to use colours portably.
> 
> I think you are overstating your case.  Please adjust it in light of the
> facts I have now brought to your attention.

I honestly have no idea what you mean by that. I am not making fun of
you or anything, I just brought that to your attention, and you can fix
it in any way or like, either compatible with the rest of the world or
not.

Regarding the facts, the only verifiable fact I see is that debians xterm
uses a vastly different colour than everybody else seems to. I
completely agree wiht that, but that's what I am talking about, too.

I think I have now clearly and in every possible detail explained what
I wanted to explain. How you proceed is entirely at your discretion. My
"mission" is merely to bring this to your attention, and you agree that
_something_ should be done about this anyway.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |



Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#241717. Full text and rfc822 format available.

Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#241717. Full text and rfc822 format available.

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

From: Thomas Dickey <dickey@radix.net>
To: 241717-submitter@bugs.debian.org
Subject: Re: Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Date: Fri, 9 Apr 2004 05:58:00 -0400
[Message part 1 (text/plain, inline)]
On Thu, Apr 08, 2004 at 05:31:09PM +0200, Marc Lehmann wrote:
> On Thu, Apr 08, 2004 at 01:19:07AM -0500, Branden Robinson <branden@debian.org> wrote:
> > However, the appearance of the X cursor when inside an xterm window has
> > not changed in my experience in the 6 years I've been maintaining this
> > package for Debian.
> 
> Well, it's not really a major bug but a minor issue. I think it should
> be fixed, but it's obviously somethig if a correctness issue (how it was
> meant to be, or how other terminals handle it) not a usability thing.
> 
> > Huh.  I can't remember anyone complaining about this before, and this
> > change has been in place for *years*.
> 
> (Is that an argument? For what? :)

It sounds like an expression of surprise.  But I do see occasional reports
of longstanding bugs.  However, in the discussion so far, it is not clear
whether you are referring to the text cursor or the mouse pointer.
 
> Well, this colour (a reatively dark blue on vt100 and everywhere else) is
> often used as background colour because it's dark.

and it's still more readable for most people.  This is the 3rd comment in
6 months.  One pointed out a contrast problem with cyan.
 
Being a resource value, it is of course configurable.

> If you want a light blue as foreground, then you can always have a light
> blue as foreground, as xterm offers high intensity blue.

...which is still readily distinguishable from the default blue.
 
> The only "app" I know that uses the darker blue as fg is ls, however,
> there are a multitude of apps that use it as bg (very old ones as well as
> new ones, such as alsamixer).
> 
> Most combinations become unreadable to colour-blind people (it seems, at
> least this is true to me, although I am not completely colour blind but
> have a colour weakness).

I'm told that I am also, and that in fact people who have trouble
distinguishing the older blue from black are also defective.
 
> So this change brings a small improvement for non-colour-blind and a
> vast problem for others.

Perhaps the reverse of that comment is more correct.
 
> I still think that the majority of applications use blue as background
> for blue being perceived as darker as other colours.

Actually, the only workable blue background schemes I've seen use white
for text.  The other colors all are harder to read than using black or white
backgrounds.
 
> If an app uses it as fg and this is bad, then I think that app has a
> problem, not the terminal emulator, which, after all, just offers a fairly
> standardized colour set.

But it's not standardized.
 
> It's not of any priority either...
> 
> >        pointerColor (class PointerColor)
> > 	       ##XtDefaultForeground.##
> > 
> >        pointerColorBackground (class PointerColorBackground)
> > 	       ##XtDefaultBackground.##
> > 
> > I wonder if it shouldn't default to the VT100 widget's text foreground and
> > background colors instead.
> > 
> > What do you think?
> > 
> 
> I tend to agree. That is (I think) how rxvt does it and (definitely) how

I could revisit this issue.  When I first looked at it (probably 1997),
xterm was using Xt to lookup resource values automatically.  Now it delays
some of those til they're needed (so it would be possible to detect cases
where a resource value was not set, and modify its default value dynamically).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
[Message part 2 (application/pgp-signature, inline)]

Information stored:
Bug#241717; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to <pcg( Marc)@goof(A.).(Lehmann )com>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

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

From: <pcg( Marc)@goof(A.).(Lehmann )com>
To: Thomas Dickey <dickey@radix.net>, 241717-quiet@bugs.debian.org
Cc: 241717-submitter@bugs.debian.org
Subject: Re: Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Date: Sat, 10 Apr 2004 02:28:34 +0200
On Fri, Apr 09, 2004 at 05:58:00AM -0400, Thomas Dickey <dickey@radix.net> wrote:
> of longstanding bugs.  However, in the discussion so far, it is not clear
> whether you are referring to the text cursor or the mouse pointer.

Yes. I was refering to the mouse-cursor.

You have probably missed the remaining dialogue in the debian bug-report.
The maintainer kept replies off-list, and so I did the same.

The mails in the bug report detail the two problems quite thoroughly, so
if you ae interested in theese arguments you might want to read them.

> > If an app uses it as fg and this is bad, then I think that app has a
> > problem, not the terminal emulator, which, after all, just offers a fairly
> > standardized colour set.
> 
> But it's not standardized.

Depends. It's standardized in some local standards, used in about all
existing implementations (see the bug report for a comparison between
terminal emulators on unix) and was documented for many years.

I would call that pretty much standardized. What you mean is probably
that there is no real standard the mandates that with force.

That is of course true. Neither the w3c nor the ietf nor... will care a
bit which exact colour is used in xterm or elsewhere :)

> > > I wonder if it shouldn't default to the VT100 widget's text foreground and
> > > background colors instead.
> > > 
> > > What do you think?
> > > 
> > 
> > I tend to agree. That is (I think) how rxvt does it and (definitely) how
> 
> I could revisit this issue.  When I first looked at it (probably 1997),
> xterm was using Xt to lookup resource values automatically.  Now it delays
> some of those til they're needed (so it would be possible to detect cases
> where a resource value was not set, and modify its default value dynamically).

Well, I would be fine with whoever changing the text fg/bg would also
need to adjust the mouse cursor colours, too, to get standard behaviour.

So the defaults in the binary and the debain appdefaults would need to
be corrected.

It's probably more user-friendly to make this automatically when unset,
but I am mainly concerned about default settings.

Changing the defaults is certainly the easiest fix for this very minor
problem.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |



Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#241717. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#241717; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. Full text and rfc822 format available.

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

From: Branden Robinson <branden@debian.org>
To: Thomas Dickey <dickey@his.com>, 241717@bugs.debian.org
Subject: Re: Bug#241717: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241717
Date: Sat, 10 Apr 2004 13:10:37 -0500
[Message part 1 (text/plain, inline)]
On Wed, Apr 07, 2004 at 06:43:30AM -0400, Thomas Dickey wrote:
> hmm - no: you're confusing the mouse pointer and the text cursor.
> Let's settle on using the terminology in the xterm manpage.

Just a minor point here...

In the submitter's defense, the xterm manpage does sometimes use
"pointer", and sometimes uses "mouse".

I suggest changing "mouse" to "pointer" everywhere.

% MANWIDTH=75 man -Tascii xterm | egrep -1 'mouse'

       Xterm allows character-based applications to receive mouse events (cur-
       rently button-press and release events, and  button-motion  events)  as
--
               ors:  the vt100 foreground and background colors, the text cur-
               sor color, the mouse cursor foreground and  background  colors,
               the  Tektronix  emulator  foreground and background colors, and
--
       highlightSelection (class HighlightSelection)
               If ``false'', selecting with the mouse highlights all positions
               on  the  screen  between the beginning of the selection and the
--
CHARACTER CLASSES
       Clicking  the  middle mouse button twice in rapid succession will cause
       all characters of the same class (e.g., letters, white space,  punctua-
--
               the  third parameter mouse is given, the action is ignored when
               mouse reporting is enabled.

The second case is probably the most potentially confusing in this context.

-- 
G. Branden Robinson                |       Yesterday upon the stair,
Debian GNU/Linux                   |       I met a man who wasn't there.
branden@debian.org                 |       He wasn't there again today,
http://people.debian.org/~branden/ |       I think he's from the CIA.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#241717; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to dickey@his.com:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. Full text and rfc822 format available.

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

From: Thomas Dickey <dickey@his.com>
To: Branden Robinson <branden@debian.org>
Cc: Thomas Dickey <dickey@his.com>, 241717@bugs.debian.org
Subject: Re: Bug#241717: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241717
Date: Sat, 10 Apr 2004 15:07:36 -0400
[Message part 1 (text/plain, inline)]
On Sat, Apr 10, 2004 at 01:10:37PM -0500, Branden Robinson wrote:
> On Wed, Apr 07, 2004 at 06:43:30AM -0400, Thomas Dickey wrote:
> > hmm - no: you're confusing the mouse pointer and the text cursor.
> > Let's settle on using the terminology in the xterm manpage.
> 
> Just a minor point here...
> 
> In the submitter's defense, the xterm manpage does sometimes use
> "pointer", and sometimes uses "mouse".
> 
> I suggest changing "mouse" to "pointer" everywhere.

"mouse cursor" to "mouse pointer", yes.  The mouse is what you hold and
click, the pointer is what appears on the screen.

I overlooked that.  The one dealing with escape sequences is my wording from
~1996.  About a third of the features weren't documented, and this was one that
I added.
 
>                ors:  the vt100 foreground and background colors, the text cur-
>                sor color, the mouse cursor foreground and  background  colors,
>                the  Tektronix  emulator  foreground and background colors, and

-- 
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net
[signature.asc (application/pgp-signature, inline)]

Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#241717. Full text and rfc822 format available.

Message #65 received at 241717-submitter@bugs.debian.org (full text, mbox):

From: Thomas Dickey <dickey@radix.net>
To: 241717-submitter@bugs.debian.org
Subject: Re: Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Date: Mon, 12 Apr 2004 19:33:58 -0400
[Message part 1 (text/plain, inline)]
On Thu, Apr 08, 2004 at 05:31:09PM +0200, Marc Lehmann wrote:
 
>    framebuffer:  #0000aa (standard vga actually, and real vt100 AFAICR)

vt100's do not, never have done color.

>    gnome-terminal#0000aa
>    Eterm:        #0000cc
>    rxvt:         #0000cd
>    mlterm:       #0000e6
>    pterm:        #0000eb
>    konsole:      #1818b2 (quite different, but still mostly the same blue)
>    xterm-debian: #1e90ff (drastically different colour, especially
>                           with regards to contrast)

The original choice of color for xterm was done using the color names
from rgb.txt in 1995.  I recall looking (when I started working on it
in 1996) to see if there was a better choice, but also preferred using
the names (which happened to be different on some platforms).  rxvt
used numbers rather than names from the outset.  konsole and gnome-terminal
came around a few years later, and took for granted the improved display
hardware.

The so-called "pure" colors for blue in this host's rgb.txt are:

  0   0   0		black
  0   0 128		navy
  0   0 139		blue4
  0   0 205		blue3
  0   0 238		blue2
  0   0 255		blue1

A reasonable alternate choice (still improving contrast for blue/black) might
for instance be blue2, which is a little brighter (0xee) than the value used by
pterm.  On the other hand, it might not display well with a blue/white
combination on a low-quality display (I recall some issues about that).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
[Message part 2 (application/pgp-signature, inline)]

Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#241717. Full text and rfc822 format available.

Message #68 received at 241717-submitter@bugs.debian.org (full text, mbox):

From: Thomas Dickey <dickey@radix.net>
To: 241717-submitter@bugs.debian.org
Subject: Re: Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Date: Tue, 13 Apr 2004 05:41:04 -0400
[Message part 1 (text/plain, inline)]
On Tue, Apr 13, 2004 at 02:00:13AM +0200, Thomas Dickey wrote:
> A reasonable alternate choice (still improving contrast for blue/black) might
> for instance be blue2, which is a little brighter (0xee) than the value used by
> pterm.  On the other hand, it might not display well with a blue/white
> combination on a low-quality display (I recall some issues about that).

I note also:
black text on blue2 background is unreadable.
Dodger blue is readable.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
[Message part 2 (application/pgp-signature, inline)]

Information stored:
Bug#241717; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to <pcg( Marc)@goof(A.).(Lehmann )com>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #73 received at 241717-quiet@bugs.debian.org (full text, mbox):

From: <pcg( Marc)@goof(A.).(Lehmann )com>
To: Thomas Dickey <dickey@radix.net>, 241717-quiet@bugs.debian.org
Cc: 241717-submitter@bugs.debian.org
Subject: Re: Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Date: Tue, 13 Apr 2004 15:44:03 +0200
On Tue, Apr 13, 2004 at 05:41:04AM -0400, Thomas Dickey <dickey@radix.net> wrote:
> On Tue, Apr 13, 2004 at 02:00:13AM +0200, Thomas Dickey wrote:
> > A reasonable alternate choice (still improving contrast for blue/black) might
> > for instance be blue2, which is a little brighter (0xee) than the value used by
> > pterm.  On the other hand, it might not display well with a blue/white
> > combination on a low-quality display (I recall some issues about that).
> 
> I note also:
> black text on blue2 background is unreadable.
> Dodger blue is readable.

That is a very uncommon combination (I have not seen that used, and
after all, xterm has high-intensity colours, so it would be asking for
unreadable colours when you use two low-intensity colours together).

You will always find colour combimations that are unreadable. The point
of changing (or better: not canging colours) with respect to other
terminals is not to introduce more or different combinations that are
hard to read.

The vt100 colours look very similar everywhere, so programs had ample time
to find combinations that work, as opposed to ones that do not work.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |



Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#241717. Full text and rfc822 format available.

Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#241717. Full text and rfc822 format available.

Message #79 received at 241717-submitter@bugs.debian.org (full text, mbox):

From: Thomas Dickey <dickey@radix.net>
To: 241717-submitter@bugs.debian.org
Subject: Re: Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Date: Tue, 13 Apr 2004 10:15:51 -0400
[Message part 1 (text/plain, inline)]
> The vt100 colours look very similar everywhere, so programs had ample time
> to find combinations that work, as opposed to ones that do not work.

but as long as you insist on referring to vt100 colours, I'm regarding the
report only as an attempt to annoy people.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#241717; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. Full text and rfc822 format available.

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

From: Branden Robinson <branden@debian.org>
To: Thomas Dickey <dickey@his.com>
Cc: 241717@bugs.debian.org
Subject: Re: Bug#241717: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241717
Date: Tue, 13 Apr 2004 11:08:37 -0500
[Message part 1 (text/plain, inline)]
On Sat, Apr 10, 2004 at 03:07:36PM -0400, Thomas Dickey wrote:
> On Sat, Apr 10, 2004 at 01:10:37PM -0500, Branden Robinson wrote:
> > On Wed, Apr 07, 2004 at 06:43:30AM -0400, Thomas Dickey wrote:
> > > hmm - no: you're confusing the mouse pointer and the text cursor.
> > > Let's settle on using the terminology in the xterm manpage.
> > 
> > Just a minor point here...
> > 
> > In the submitter's defense, the xterm manpage does sometimes use
> > "pointer", and sometimes uses "mouse".
> > 
> > I suggest changing "mouse" to "pointer" everywhere.
> 
> "mouse cursor" to "mouse pointer", yes.  The mouse is what you hold and
> click, the pointer is what appears on the screen.

Well, I'm a pedantic guy, so I call the "pointer" what you hold and
click, and the "pointer cursor" what appears on the screen.

Because, you see, I don't use a "mouse".  Touchpads and trackballs, yes.

:)

> I overlooked that.  The one dealing with escape sequences is my wording from
> ~1996.  About a third of the features weren't documented, and this was one that
> I added.
>  
> >                ors:  the vt100 foreground and background colors, the text cur-
> >                sor color, the mouse cursor foreground and  background  colors,
> >                the  Tektronix  emulator  foreground and background colors, and

As long as the manpage is internally consistent, that's good enough, I
think.

-- 
G. Branden Robinson                |       Psychology is really biology.
Debian GNU/Linux                   |       Biology is really chemistry.
branden@debian.org                 |       Chemistry is really physics.
http://people.debian.org/~branden/ |       Physics is really math.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#241717; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to Thomas Dickey <dickey@his.com>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. Full text and rfc822 format available.

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

From: Thomas Dickey <dickey@his.com>
To: Branden Robinson <branden@debian.org>
Cc: 241717@bugs.debian.org
Subject: Re: Bug#241717: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241717
Date: Tue, 13 Apr 2004 13:37:27 -0400 (EDT)
On Tue, 13 Apr 2004, Branden Robinson wrote:

> On Sat, Apr 10, 2004 at 03:07:36PM -0400, Thomas Dickey wrote:
> As long as the manpage is internally consistent, that's good enough, I
> think.

yes (generally I use my comments in these threads to remind me of what I
intend fixing).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#241717. Full text and rfc822 format available.

Message #92 received at 241717-submitter@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: 241717-submitter@bugs.debian.org
Subject: Re: Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Date: Tue, 13 Apr 2004 15:04:43 -0500
[Message part 1 (text/plain, inline)]
On Sat, Apr 10, 2004 at 02:28:34AM +0200,  Marc A. Lehmann  wrote:
> On Fri, Apr 09, 2004 at 05:58:00AM -0400, Thomas Dickey <dickey@radix.net> wrote:
> > > If an app uses it as fg and this is bad, then I think that app has a
> > > problem, not the terminal emulator, which, after all, just offers a fairly
> > > standardized colour set.
> > 
> > But it's not standardized.
> 
> Depends. It's standardized in some local standards, used in about all
> existing implementations (see the bug report for a comparison between
> terminal emulators on unix) and was documented for many years.
> 
> I would call that pretty much standardized. What you mean is probably
> that there is no real standard the mandates that with force.
> 
> That is of course true. Neither the w3c nor the ietf nor... will care a
> bit which exact colour is used in xterm or elsewhere :)

That's common practice, not standardization.

With proper standardization comes expert advice.  I don't think the
xterm color defaults, or the defaults used by other terminal emulators,
were selected with the aid of expert advice.  They were picked because
they were color values close to some ANSI terminal standard (I don't
know which one) -- and which could be easily encoded in a 4-bit
colormap.

I think the colors in common practice were the product initially of
technological constraints, and subsequently due to laziness, inertia,
and code reuse.

That's not standardization.

-- 
G. Branden Robinson                |     One doesn't have a sense of humor.
Debian GNU/Linux                   |     It has you.
branden@debian.org                 |     -- Larry Gelbart
http://people.debian.org/~branden/ |
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#241717; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to <pcg( Marc)@goof(A.).(Lehmann )com>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. Full text and rfc822 format available.

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

From: <pcg( Marc)@goof(A.).(Lehmann )com>
To: Thomas Dickey <dickey@radix.net>, 241717@bugs.debian.org, Branden Robinson <branden@debian.org>
Cc: 241717-submitter@bugs.debian.org
Subject: Re: Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Date: Wed, 14 Apr 2004 20:18:58 +0200
On Mon, Apr 12, 2004 at 07:33:58PM -0400, Thomas Dickey <dickey@radix.net> wrote:
> On Thu, Apr 08, 2004 at 05:31:09PM +0200, Marc Lehmann wrote:
>  
> >    framebuffer:  #0000aa (standard vga actually, and real vt100 AFAICR)
> 
> vt100's do not, never have done color.

The ones with the advanced video option had. Call them vt102, or
whatever you like, I do not care.

> A reasonable alternate choice (still improving contrast for blue/black) might
> for instance be blue2, which is a little brighter (0xee) than the value used by
> pterm.  On the other hand, it might not display well with a blue/white
> combination on a low-quality display (I recall some issues about that).

On low quality displays people will not use blue/white, as it is very
straining for the eyes to have white backgrounds anyways.

On Tue, Apr 13, 2004 at 10:15:51AM -0400, Thomas Dickey <dickey@radix.net> wrote:
> > The vt100 colours look very similar everywhere, so programs had ample time
> > to find combinations that work, as opposed to ones that do not work.
> 
> but as long as you insist on referring to vt100 colours, I'm regarding the
> report only as an attempt to annoy people.

Well, you can research this easily yourself. I don't care how you regard
my report, as you can check everything I said for yourself, and I hope
you did.

Disregarding a perfectly fine bugreport just because I am not 100% precise
in my naming conventions is rather idiotic, but it's you to chose. I am
absolutely sure that you understood my points, and you understood all
the problems I am talking about. The solution, or the way to proceed, is
entirely up to your decision (or the debian X maintainers).

If you are looking for reasons to disregard my report, there are easier
ways than being a hipocrite :(

On Tue, Apr 13, 2004 at 03:04:43PM -0500, Branden Robinson <branden@debian.org> wrote:
> > > > problem, not the terminal emulator, which, after all, just offers a fairly
> > > > standardized colour set.
> > > 
> > > But it's not standardized.
> > 
> > I would call that pretty much standardized. What you mean is probably
> > that there is no real standard the mandates that with force.
> > 
> > That is of course true. Neither the w3c nor the ietf nor... will care a
> > bit which exact colour is used in xterm or elsewhere :)
> 
> That's common practice, not standardization.

It is common practise, and also standardization. Please do not think
that only "official" standard bodies can create standards, that's not
what the word "standard" means (see, for example, "de-factor standards"
or "industry standards" which might or might not be standardized by a
standards body like iso, but are beverteheles standards, as long as they
are documented).

I think that arguing about words (as this is the level both of you are
approaching here) is not useful, and I have nothing more to day about this
issue.

I would be glad if you would discuss or decide according to the technical
issues and problems I brought up. Arguing about words or word usage is
secondary to the problem, and will neither help you nor me.

> With proper standardization comes expert advice.  I don't think the
> xterm color defaults, or the defaults used by other terminal emulators,
> were selected with the aid of expert advice.

True. And neither was expert advice sought when changing these. The
problem is that a large body of software has inherent knowledge of these
colours (by using them in certain combinations to get certain effects,
e.g. use red for warnings). Obviously it would be bad to give some
colour codes (former red) completey new colours.

It's much less bad to change them subtly, and I think the xterm colour
change is somewhere in the middle: It's not terribly problematic, but
certainly a drawback for common existing applications, while improving
the situation for some others.

My point is that this is unexpected, and it's not a very intelligent
idea to make colours incompatible in xterm compared to other terminals
or terminal emulators by changing readable combinations.

Existing terminals have lots of combinations that are marginally readable,
not readable, or well readable. The xterm change does not improve the
situation, it just changes it by making some combinations more readable
and others less.

And I argue precisely that this change is unexpected and not good, from a
standardization side, as apps must be rewritten with knowledge about xterm
colour combinations that are readable, as opposed to all other terminals.

And if I haven't made this completely clear: I do not care about rgb bit
values used for colours, I only care about readability, which, overall,
seems to have been decreased rather than increased by xterms changes.

> They were picked because they were color values close to some ANSI
> terminal standard (I don't know which one) -- and which could be easily
> encoded in a 4-bit colormap.

This is factually wrong.


> I think the colors in common practice were the product initially of
> technological constraints, and subsequently due to laziness, inertia,
> and code reuse.

Yes.

> That's not standardization.

Well, this is, unfortunately, exactly how standards get created most of
the time, by writing and documenting existing practise. I agree that
this is often not the best thing, but that's how it happens.

To convince you, here is (part of) the merriam-webster entry of "standard":

   3 : something established by authority, custom, or general consent as a
   model or example : CRITERION
   4 : something set up and established by authority as a rule for the
   measure of quantity, weight, extent, value, or quality

You idea of "standard" is limited to 4, but 3 also means "standard".

Yes, you can disregard merriam webster, language is not an absolute
thing.

The fine point is that even your definiton of "standard" would be the
only valid one, the principial issue in my report is completely
untouched for.

That is why I think that arguing about words as both of you start to do
is completely backwards. You can't claim I haven't been constructive, I
laid down my reasoning in as best a way as I can.

Claiming I am just trying to annoy you (TD) is quite uncalled for. Just
as you, I am working very hard to improve free software in general and in
this case debian (even if in this case just by writing a bug report). I
don't feel that I deserved your behaviour at all :(

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |



Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#241717. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#241717; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to dickey@his.com (Thomas Dickey):
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. Full text and rfc822 format available.

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

From: dickey@his.com (Thomas Dickey)
To: 241717@bugs.debian.org
Cc: dickey@his.com (Thomas Dickey)
Subject: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241717
Date: Wed, 14 Apr 2004 20:56:16 -0400
>                       Debian Bug report logs - #241717
>       xterm: various colour problems (mouse cursor color, text colours)
...
>   framebuffer:  #0000aa (standard vga actually, and real vt100 AFAICR)
>   gnome-terminal#0000aa
>   Eterm:        #0000cc
>   rxvt:         #0000cd
>   mlterm:       #0000e6
>   pterm:        #0000eb
>   konsole:      #1818b2 (quite different, but still mostly the same blue)
>   xterm-debian: #1e90ff (drastically different colour, especially
>                          with regards to contrast)

Just for the record, I put up a screen dump showing xterm (with blue,
DodgerBlue and blue2 background in the left column), and rxvt, gnome-terminal
and konsole.  As will be noted, gnome-terminal's appearance is wholly unlike
the others, konsole is noticably darker (less legible than rxvt).  rxvt
coincidentally matches old-xterm colors.  Since the latter three are all
"standard", yet different, there's no point made, since the same arguments ad
nauseum can also be made against using blue2.  See

	ftp://invisible-island.net/temp/contrast.jpg

p.s: vt102 "advanced video option" refers to support for scrolling - it helps
to know what you're talking about if you choose to argue.
-- 
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net



Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#241717; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. Full text and rfc822 format available.

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

From: Branden Robinson <branden@debian.org>
To: Thomas Dickey <dickey@his.com>, 241717@bugs.debian.org
Subject: Re: Bug#241717: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241717
Date: Fri, 16 Apr 2004 23:09:38 -0500
[Message part 1 (text/plain, inline)]
On Wed, Apr 14, 2004 at 08:56:16PM -0400, Thomas Dickey wrote:
> Just for the record, I put up a screen dump showing xterm (with blue,
> DodgerBlue and blue2 background in the left column), and rxvt, gnome-terminal
> and konsole.  As will be noted, gnome-terminal's appearance is wholly unlike
> the others, konsole is noticably darker (less legible than rxvt).  rxvt
> coincidentally matches old-xterm colors.  Since the latter three are all
> "standard", yet different, there's no point made, since the same arguments ad
> nauseum can also be made against using blue2.  See
> 
> 	ftp://invisible-island.net/temp/contrast.jpg
> 
> p.s: vt102 "advanced video option" refers to support for scrolling - it helps
> to know what you're talking about if you choose to argue.

Color me persuaded, so to speak.  ;-)

(In the future, please use PNG format instead of JFIF for screenshots,
though.  8-) )

-- 
G. Branden Robinson                |    No executive devotes much effort to
Debian GNU/Linux                   |    proving himself wrong.
branden@debian.org                 |    -- Laurence J. Peter
http://people.debian.org/~branden/ |
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#241717; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to Thomas Dickey <dickey@his.com>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. Full text and rfc822 format available.

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

From: Thomas Dickey <dickey@his.com>
To: Branden Robinson <branden@debian.org>
Cc: 241717@bugs.debian.org
Subject: Re: Bug#241717: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241717
Date: Sat, 17 Apr 2004 06:31:06 -0400 (EDT)
On Fri, 16 Apr 2004, Branden Robinson wrote:

> Color me persuaded, so to speak.  ;-)

I'm not really persuaded on either side.  Rather than dragging the
irrelevant gnome-terminal and konsole (and "vt100 colors") into the
argument, it would be nice to have some reference to measured perception
of the different contrasts.

I don't see anything that I can refer to on the net - and am not sure
there's that much in research results, since the comment is made so often
that it's very subjective.

> (In the future, please use PNG format instead of JFIF for screenshots,
> though.  8-) )

I suppose so - had thought jpeg's were suitable enough.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#241717. Full text and rfc822 format available.

Message #118 received at 241717-submitter@bugs.debian.org (full text, mbox):

From: Thomas Dickey <dickey@radix.net>
To: 241717-submitter@bugs.debian.org
Subject: Re: Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Date: Sun, 18 Apr 2004 17:23:41 -0400
[Message part 1 (text/plain, inline)]
On Thu, Apr 08, 2004 at 08:50:07AM +0200, Branden Robinson wrote:
 
> However, the appearance of the X cursor when inside an xterm window has
> not changed in my experience in the 6 years I've been maintaining this
> package for Debian.

I don't suppose it changed for some time before that either - my guess is
that the dynamic colors were added in fall 1995.  I modified the initialization
in patch #186 (current) so it will default to inheriting colors from the
window's colors.  Of course that's done only at initialization (unlike the
text-cursor, whose color varies dynamically according to the ANSI colors).
 
I also updated the manpage to fix the inconsistent terminology.

But I didn't (yet) alter the selection for blue (am considering that still...)

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
[Message part 2 (application/pgp-signature, inline)]

Tags added: fixed-upstream Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: pending Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#241717. Full text and rfc822 format available.

Message #125 received at 241717-submitter@bugs.debian.org (full text, mbox):

From: Thomas Dickey <dickey@his.com>
To: Branden Robinson <branden@debian.org>, 241717-submitter@bugs.debian.org
Subject: Re: Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Date: Fri, 14 May 2004 16:18:11 -0400
[Message part 1 (text/plain, inline)]
On Thu, Apr 08, 2004 at 08:50:07AM +0200, Branden Robinson wrote:
 
> I find this color, "DodgerBlue1", much easer to read on a
> black-background xterm when using terminal fonts of very low weight.
Here's an interesting discussion on the general topic:
	http://www.fseric.demon.co.uk/skills/colour.htm

-- 
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net
[signature.asc (application/pgp-signature, inline)]

Tags set to: fixed-upstream, upstream, pending Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Reply sent to fabbione@fabbione.net (Fabio M. Di Nitto):
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Marc Lehmann <debian-reportbug@plan9.de>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #132 received at 241717-close@bugs.debian.org (full text, mbox):

From: fabbione@fabbione.net (Fabio M. Di Nitto)
To: 241717-close@bugs.debian.org
Subject: Bug#241717: fixed in xfree86 4.3.0.dfsg.1-2
Date: Tue, 25 May 2004 18:47:47 -0400
Source: xfree86
Source-Version: 4.3.0.dfsg.1-2

We believe that the bug you reported is fixed in the latest version of
xfree86, which is due to be installed in the Debian FTP archive:

lbxproxy_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/lbxproxy_4.3.0.dfsg.1-2_i386.deb
libdps-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libdps-dev_4.3.0.dfsg.1-2_i386.deb
libdps1-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libdps1-dbg_4.3.0.dfsg.1-2_i386.deb
libdps1_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libdps1_4.3.0.dfsg.1-2_i386.deb
libice-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libice-dev_4.3.0.dfsg.1-2_i386.deb
libice6-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libice6-dbg_4.3.0.dfsg.1-2_i386.deb
libice6_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libice6_4.3.0.dfsg.1-2_i386.deb
libsm-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libsm-dev_4.3.0.dfsg.1-2_i386.deb
libsm6-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libsm6-dbg_4.3.0.dfsg.1-2_i386.deb
libsm6_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libsm6_4.3.0.dfsg.1-2_i386.deb
libx11-6-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libx11-6-dbg_4.3.0.dfsg.1-2_i386.deb
libx11-6_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libx11-6_4.3.0.dfsg.1-2_i386.deb
libx11-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libx11-dev_4.3.0.dfsg.1-2_i386.deb
libxaw6-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxaw6-dbg_4.3.0.dfsg.1-2_i386.deb
libxaw6-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxaw6-dev_4.3.0.dfsg.1-2_i386.deb
libxaw6_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxaw6_4.3.0.dfsg.1-2_i386.deb
libxaw7-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxaw7-dbg_4.3.0.dfsg.1-2_i386.deb
libxaw7-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxaw7-dev_4.3.0.dfsg.1-2_i386.deb
libxaw7_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxaw7_4.3.0.dfsg.1-2_i386.deb
libxext-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxext-dev_4.3.0.dfsg.1-2_i386.deb
libxext6-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxext6-dbg_4.3.0.dfsg.1-2_i386.deb
libxext6_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxext6_4.3.0.dfsg.1-2_i386.deb
libxft1-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxft1-dbg_4.3.0.dfsg.1-2_i386.deb
libxft1_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxft1_4.3.0.dfsg.1-2_i386.deb
libxi-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxi-dev_4.3.0.dfsg.1-2_i386.deb
libxi6-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxi6-dbg_4.3.0.dfsg.1-2_i386.deb
libxi6_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxi6_4.3.0.dfsg.1-2_i386.deb
libxmu-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxmu-dev_4.3.0.dfsg.1-2_i386.deb
libxmu6-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxmu6-dbg_4.3.0.dfsg.1-2_i386.deb
libxmu6_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxmu6_4.3.0.dfsg.1-2_i386.deb
libxmuu-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxmuu-dev_4.3.0.dfsg.1-2_i386.deb
libxmuu1-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxmuu1-dbg_4.3.0.dfsg.1-2_i386.deb
libxmuu1_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxmuu1_4.3.0.dfsg.1-2_i386.deb
libxp-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxp-dev_4.3.0.dfsg.1-2_i386.deb
libxp6-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxp6-dbg_4.3.0.dfsg.1-2_i386.deb
libxp6_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxp6_4.3.0.dfsg.1-2_i386.deb
libxpm-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxpm-dev_4.3.0.dfsg.1-2_i386.deb
libxpm4-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxpm4-dbg_4.3.0.dfsg.1-2_i386.deb
libxpm4_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxpm4_4.3.0.dfsg.1-2_i386.deb
libxrandr-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxrandr-dev_4.3.0.dfsg.1-2_i386.deb
libxrandr2-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxrandr2-dbg_4.3.0.dfsg.1-2_i386.deb
libxrandr2_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxrandr2_4.3.0.dfsg.1-2_i386.deb
libxt-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxt-dev_4.3.0.dfsg.1-2_i386.deb
libxt6-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxt6-dbg_4.3.0.dfsg.1-2_i386.deb
libxt6_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxt6_4.3.0.dfsg.1-2_i386.deb
libxtrap-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxtrap-dev_4.3.0.dfsg.1-2_i386.deb
libxtrap6-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxtrap6-dbg_4.3.0.dfsg.1-2_i386.deb
libxtrap6_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxtrap6_4.3.0.dfsg.1-2_i386.deb
libxtst-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxtst-dev_4.3.0.dfsg.1-2_i386.deb
libxtst6-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxtst6-dbg_4.3.0.dfsg.1-2_i386.deb
libxtst6_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxtst6_4.3.0.dfsg.1-2_i386.deb
libxv-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxv-dev_4.3.0.dfsg.1-2_i386.deb
libxv1-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxv1-dbg_4.3.0.dfsg.1-2_i386.deb
libxv1_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/libxv1_4.3.0.dfsg.1-2_i386.deb
pm-dev_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/pm-dev_4.3.0.dfsg.1-2_all.deb
proxymngr_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/proxymngr_4.3.0.dfsg.1-2_i386.deb
twm_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/twm_4.3.0.dfsg.1-2_i386.deb
x-dev_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/x-dev_4.3.0.dfsg.1-2_all.deb
x-window-system-core_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/x-window-system-core_4.3.0.dfsg.1-2_i386.deb
x-window-system-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/x-window-system-dev_4.3.0.dfsg.1-2_i386.deb
x-window-system_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/x-window-system_4.3.0.dfsg.1-2_all.deb
xbase-clients_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xbase-clients_4.3.0.dfsg.1-2_i386.deb
xdm_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xdm_4.3.0.dfsg.1-2_i386.deb
xfonts-100dpi-transcoded_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xfonts-100dpi-transcoded_4.3.0.dfsg.1-2_all.deb
xfonts-100dpi_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xfonts-100dpi_4.3.0.dfsg.1-2_all.deb
xfonts-75dpi-transcoded_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xfonts-75dpi-transcoded_4.3.0.dfsg.1-2_all.deb
xfonts-75dpi_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xfonts-75dpi_4.3.0.dfsg.1-2_all.deb
xfonts-base-transcoded_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xfonts-base-transcoded_4.3.0.dfsg.1-2_all.deb
xfonts-base_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xfonts-base_4.3.0.dfsg.1-2_all.deb
xfonts-cyrillic_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xfonts-cyrillic_4.3.0.dfsg.1-2_all.deb
xfonts-scalable_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xfonts-scalable_4.3.0.dfsg.1-2_all.deb
xfree86-common_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xfree86-common_4.3.0.dfsg.1-2_all.deb
xfree86_4.3.0.dfsg.1-2.diff.gz
  to pool/main/x/xfree86/xfree86_4.3.0.dfsg.1-2.diff.gz
xfree86_4.3.0.dfsg.1-2.dsc
  to pool/main/x/xfree86/xfree86_4.3.0.dfsg.1-2.dsc
xfs_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xfs_4.3.0.dfsg.1-2_i386.deb
xfwp_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xfwp_4.3.0.dfsg.1-2_i386.deb
xlibmesa-dev_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xlibmesa-dev_4.3.0.dfsg.1-2_all.deb
xlibmesa-dri-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xlibmesa-dri-dbg_4.3.0.dfsg.1-2_i386.deb
xlibmesa-dri_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xlibmesa-dri_4.3.0.dfsg.1-2_i386.deb
xlibmesa-gl-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xlibmesa-gl-dbg_4.3.0.dfsg.1-2_i386.deb
xlibmesa-gl-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xlibmesa-gl-dev_4.3.0.dfsg.1-2_i386.deb
xlibmesa-gl_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xlibmesa-gl_4.3.0.dfsg.1-2_i386.deb
xlibmesa-glu-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xlibmesa-glu-dbg_4.3.0.dfsg.1-2_i386.deb
xlibmesa-glu-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xlibmesa-glu-dev_4.3.0.dfsg.1-2_i386.deb
xlibmesa-glu_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xlibmesa-glu_4.3.0.dfsg.1-2_i386.deb
xlibmesa3-dbg_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xlibmesa3-dbg_4.3.0.dfsg.1-2_all.deb
xlibmesa3_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xlibmesa3_4.3.0.dfsg.1-2_i386.deb
xlibosmesa-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xlibosmesa-dev_4.3.0.dfsg.1-2_i386.deb
xlibosmesa4-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xlibosmesa4-dbg_4.3.0.dfsg.1-2_i386.deb
xlibosmesa4_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xlibosmesa4_4.3.0.dfsg.1-2_i386.deb
xlibs-data_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xlibs-data_4.3.0.dfsg.1-2_all.deb
xlibs-dbg_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xlibs-dbg_4.3.0.dfsg.1-2_all.deb
xlibs-dev_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xlibs-dev_4.3.0.dfsg.1-2_all.deb
xlibs-pic_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xlibs-pic_4.3.0.dfsg.1-2_all.deb
xlibs-static-dev_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xlibs-static-dev_4.3.0.dfsg.1-2_i386.deb
xlibs-static-pic_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xlibs-static-pic_4.3.0.dfsg.1-2_i386.deb
xlibs_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xlibs_4.3.0.dfsg.1-2_all.deb
xmh_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xmh_4.3.0.dfsg.1-2_i386.deb
xnest_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xnest_4.3.0.dfsg.1-2_i386.deb
xprt_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xprt_4.3.0.dfsg.1-2_i386.deb
xserver-common_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xserver-common_4.3.0.dfsg.1-2_i386.deb
xserver-xfree86-dbg_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xserver-xfree86-dbg_4.3.0.dfsg.1-2_i386.deb
xserver-xfree86_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xserver-xfree86_4.3.0.dfsg.1-2_i386.deb
xspecs_4.3.0.dfsg.1-2_all.deb
  to pool/main/x/xfree86/xspecs_4.3.0.dfsg.1-2_all.deb
xterm_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xterm_4.3.0.dfsg.1-2_i386.deb
xutils_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xutils_4.3.0.dfsg.1-2_i386.deb
xvfb_4.3.0.dfsg.1-2_i386.deb
  to pool/main/x/xfree86/xvfb_4.3.0.dfsg.1-2_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 241717@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Fabio M. Di Nitto <fabbione@fabbione.net> (supplier of updated xfree86 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 25 May 2004 22:11:46 +0200
Source: xfree86
Binary: libx11-6-dbg libxtst6-dbg xserver-common xlibs-static-dev libxp6-dbg xbase-clients xlibmesa3-dbg libxtrap6-dbg xfonts-75dpi libxt6 libice6-dbg xmh libxaw6-dbg x-dev libxv1 libxext6-dbg xlibmesa-dev libxpm4 libxtst6 xlibmesa-gl-dev xfonts-cyrillic libx11-6 libsm6-dbg xlibs-pic xlibs-data x-window-system xfree86-common xlibmesa-dri xlibmesa3 libxv1-dbg libxrandr2 xlibmesa-glu libxaw7-dev xnest libxaw6 xterm libxp6 xlibmesa-dri-dbg libxrandr2-dbg libxmu6 xlibmesa-glu-dbg libx11-dev xlibs-static-pic libxpm4-dbg libxaw7-dbg libxmu6-dbg xlibmesa-glu-dev libxmuu-dev pm-dev libxext6 libxft1-dbg libxtst-dev libxv-dev libxp-dev twm x-window-system-dev libsm-dev xfonts-scalable libdps1-dbg libxmuu1-dbg xfwp libice6 libxmu-dev xlibs libdps-dev xserver-xfree86-dbg libxrandr-dev libsm6 xserver-xfree86 libdps1 proxymngr xfonts-base-transcoded libxaw6-dev lbxproxy x-window-system-core xutils xspecs libxtrap6 libice-dev libxt-dev xfs libxmuu1 libxi6-dbg xfonts-base xlibs-dbg libxpm-dev xlibmesa-gl xfonts-100dpi-transcoded libxtrap-dev xfonts-100dpi libxext-dev xfonts-75dpi-transcoded xlibosmesa4-dbg libxft1 xprt libxi-dev xlibosmesa-dev xlibosmesa4 xvfb libxaw7 xlibmesa-gl-dbg xdm xlibs-dev libxi6 libxt6-dbg
Architecture: source i386 all
Version: 4.3.0.dfsg.1-2
Distribution: unstable
Urgency: low
Maintainer: Debian X Strike Force <debian-x@lists.debian.org>
Changed-By: Fabio M. Di Nitto <fabbione@fabbione.net>
Description: 
 lbxproxy   - Low Bandwidth X (LBX) proxy server
 libdps-dev - Display PostScript (DPS) client library development files
 libdps1    - Display PostScript (DPS) client library
 libdps1-dbg - Display PostScript (DPS) client library (unstripped)
 libice-dev - Inter-Client Exchange library development files
 libice6    - Inter-Client Exchange library
 libice6-dbg - Inter-Client Exchange library (unstripped)
 libsm-dev  - X Window System Session Management library development files
 libsm6     - X Window System Session Management library
 libsm6-dbg - X Window System Session Management library (unstripped)
 libx11-6   - X Window System protocol client library
 libx11-6-dbg - X Window System protocol client library (unstripped)
 libx11-dev - X Window System protocol client library development files
 libxaw6    - X Athena widget set library (version 6)
 libxaw6-dbg - X Athena widget set library (version 6, unstripped)
 libxaw6-dev - X Athena widget set library development files (version 6)
 libxaw7    - X Athena widget set library
 libxaw7-dbg - X Athena widget set library (unstripped)
 libxaw7-dev - X Athena widget set library development files
 libxext-dev - X Window System miscellaneous extension library development files
 libxext6   - X Window System miscellaneous extension library
 libxext6-dbg - X Window System miscellaneous extension library (unstripped)
 libxft1    - FreeType-based font drawing library for X (version 1)
 libxft1-dbg - FreeType-based font drawing library for X (version 1, unstripped)
 libxi-dev  - X Window System Input extension library development files
 libxi6     - X Window System Input extension library
 libxi6-dbg - X Window System Input extension library (unstripped)
 libxmu-dev - X Window System miscellaneous utility library development files
 libxmu6    - X Window System miscellaneous utility library
 libxmu6-dbg - X Window System miscellaneous utility library (unstripped)
 libxmuu-dev - lightweight X Window System miscellaneous utility library develop
 libxmuu1   - lightweight X Window System miscellaneous utility library
 libxmuu1-dbg - lightweight X Window System miscellaneous utility library (unstri
 libxp-dev  - X Window System printing extension library development files
 libxp6     - X Window System printing extension library
 libxp6-dbg - X Window System printing extension library (unstripped)
 libxpm-dev - X pixmap library development files
 libxpm4    - X pixmap library
 libxpm4-dbg - X pixmap library (unstripped)
 libxrandr-dev - X Window System Resize, Rotate and Reflection extension library d
 libxrandr2 - X Window System Resize, Rotate and Reflection extension library
 libxrandr2-dbg - X Window System Resize, Rotate and Reflection extension library (
 libxt-dev  - X Toolkit Intrinsics development files
 libxt6     - X Toolkit Intrinsics
 libxt6-dbg - X Toolkit Intrinsics (unstripped)
 libxtrap-dev - X Window System protocol-trapping extension library development f
 libxtrap6  - X Window System protocol-trapping extension library
 libxtrap6-dbg - X Window System protocol-trapping extension library (unstripped)
 libxtst-dev - X Window System event recording and testing extension library dev
 libxtst6   - X Window System event recording and testing extension library
 libxtst6-dbg - X Window System event recording and testing extension library (un
 libxv-dev  - X Window System video extension library development files
 libxv1     - X Window System video extension library
 libxv1-dbg - X Window System video extension library (unstripped)
 pm-dev     - proxy management protocol development files
 proxymngr  - X proxy services manager
 twm        - Tab window manager
 x-dev      - X protocol development files
 x-window-system - X Window System
 x-window-system-core - X Window System core components
 x-window-system-dev - X Window System development components
 xbase-clients - miscellaneous X clients
 xdm        - X display manager
 xfonts-100dpi - 100 dpi fonts for X
 xfonts-100dpi-transcoded - 100 dpi fonts for X (transcoded from ISO 10646-1)
 xfonts-75dpi - 75 dpi fonts for X
 xfonts-75dpi-transcoded - 75 dpi fonts for X (transcoded from ISO 10646-1)
 xfonts-base - standard fonts for X
 xfonts-base-transcoded - standard fonts for X (transcoded from ISO 10646-1)
 xfonts-cyrillic - Cyrillic fonts for X
 xfonts-scalable - scalable fonts for X
 xfree86-common - X Window System (XFree86) infrastructure
 xfs        - X font server
 xfwp       - X firewall proxy server
 xlibmesa-dev - XFree86 Mesa development libraries pseudopackage
 xlibmesa-dri - Mesa 3D graphics library modules [XFree86]
 xlibmesa-dri-dbg - Mesa 3D graphics library modules (unstripped) [XFree86]
 xlibmesa-gl - Mesa 3D graphics library [XFree86]
 xlibmesa-gl-dbg - Mesa 3D graphics library (unstripped) [XFree86]
 xlibmesa-gl-dev - Mesa 3D graphics library development files [XFree86]
 xlibmesa-glu - Mesa OpenGL utility library [XFree86]
 xlibmesa-glu-dbg - Mesa OpenGL utility library (unstripped) [XFree86]
 xlibmesa-glu-dev - Mesa OpenGL utility library development files [XFree86]
 xlibmesa3  - XFree86 Mesa libraries pseudopackage
 xlibmesa3-dbg - XFree86 Mesa unstripped libraries pseudopackage
 xlibosmesa-dev - Mesa off-screen rendering library development files [XFree86]
 xlibosmesa4 - Mesa off-screen rendering library [XFree86]
 xlibosmesa4-dbg - Mesa off-screen rendering library (unstripped) [XFree86]
 xlibs      - X Window System client libraries metapackage and XKB data
 xlibs-data - X Window System client data
 xlibs-dbg  - X Window System unstripped client libraries pseudopackage
 xlibs-dev  - X Window System client library development files pseudopackage
 xlibs-pic  - XFree86 static PIC libraries pseudopackage
 xlibs-static-dev - X Window System client library development files
 xlibs-static-pic - X Window System client extension library PIC archives
 xmh        - X interface to the MH mail system
 xnest      - nested X server
 xprt       - X print server (XFree86 version)
 xserver-common - files and utilities common to all X servers
 xserver-xfree86 - the XFree86 X server
 xserver-xfree86-dbg - the XFree86 X server (static version with debugging symbols)
 xspecs     - X protocol, extension, and library technical specifications
 xterm      - X terminal emulator
 xutils     - X Window System utility programs
 xvfb       - virtual framebuffer X server
Closes: 107769 178812 179407 189764 198910 218169 219551 222530 223926 234025 234808 240581 240889 241717 242485 245044 245249 246087 246901 247525 247705 248144 248539 248632 249738 250061
Changes: 
 xfree86 (4.3.0.dfsg.1-2) unstable; urgency=low
 .
   Changes by Branden Robinson:
 .
   * Fix 30xfree86-common_xresources Xsession script to check for existence of
     xrdb command before attempting to execute it, and warn if it is not found
     (thanks, Ryan Murray).  (Closes: #242485)
 .
   * Fix shell scriptlets in Xsession.d to use shell's && and || operators
     instead of test(1)'s -a and -o operators, since the former is
     POSIX-compliant and the latter is not.
 .
   * Add support for the AMD64 architecture (thanks, Andreas Jochens!).
     (Closes: #240889)
 .
   * Grab updated list of PCI IDs from XFree86 CVS as of 2003-10-30.  Remove
     superseded parts of patches #030a, #030b, #099.
 .
   * Grab updated XFree86 X server I2C code from XFree86 CVS as of 2003-08-29.
     Implements and exposes xf86I2CGetScreenBuses() function.
 .
   * Grab updated XVideo (Xv) server-side implementation from XFree86 CVS as of
     2003-04-30.
     + Initialise v4l's XVideo adaptors last (Marc La France).
     + Reduce cut&paste effects by adding more helpers to Xv (derived from
       #5645, Björn Augustsson, Marc La France).
     + XvExtension driver cleanups (Marc La France).
     + Fix precision problems in xf86XVClipVideoHelper (Marc La France).
 .
   * Backport XFree86 X server ATI driver (including Rage 128 and Radeon
     sub-drivers) from XFree86 CVS as of 2004-02-11.  Drop superseded patches
     #030[a-h], #048, #049, #085, and #099.  Add patch #030 which fixes driver
     to work with not-backported overhaul of X server's region macros.  Resync
     patches #022, #024, #025, #027, #069, #079, #450, #451, and #600.
     + add display bandwidth calculation routine to Radeon driver to fix
       flickering/tearing display problem (Closes: #218169)
     + fixes Radeon register initialization for RGB offset to fix the
       "milky-screen" problem (Closes: #234025)
     + radeon driver now supports "ForceMinDotClockOption" (Closes: #240581)
 .
   * Grab from XFree86 CVS (2003-11-23) a fix to a problem resolving hostnames
     of indirect entries in xdm's Xaccess file.  Resync patch #002.
     (Closes: #245044)
 .
   * Update (from XFree86 CVS, 2003-12-18) the XFree86 X server's PCI bus
     handling code and device recognition databases from CVS.  Resync patch
     #452.  Delete superseded patch #453.
     + Simplify internal interfaces in the PCI code and remove the Xserver's
       interference with normal PCMCIA operation (Marc La France).
     + Fixed typo in getPciBiosTypes() (Bugzilla #382,  Jakub Bogusz).
     + Change DEVID macro to work around glitch in SCO's C compiler (Marc La
       France).
     + Fixed support for 64bit PCI bus on 32bit systems (Egbert Eich).
     + Be a little more precise about differentiating between active and
       inactive non-video PCI resources (Marc La France).
     + Fix bug in detection of multi-function PCI devices (Marc La France, in
       partial resolution of Bugzilla #574).
     + Rip out incorrect limits on the number of PCI buses an ix86 chipset can
       handle and implement an improved solution for avoiding "phantom" PCI
       buses (Marc La France, Bugzilla #604).
 .
   * Add dependencies on libxext-dev, libxi-dev, and xlibs-static-dev to
     libx11-dev, and explain why in the latter's extended description.  Thanks
     to Filip Van Raemdonck for noticing this problem.  (Closes: #247525)
 .
   * Backport XFre86 X server VIA driver from XFree86 CVS HEAD as of
     2004-02-12.  This driver adds support for the VIA CLE266 and related
     northbridge integrated chipsets, typically found in VIA EPIA-M Mini-ITX
     systems.  Add patch #048 (not from XFree86 CVS) to enable the driver in
     the build.  (Thanks, Adam Conrad!)
 .
   * Add package infrastructure in debian/ directory for the new VIA
     driver.  (Thanks, Adam Conrad!)
     + Add "via" to DRIVER_LIST for hurd-i386 and i386 in
       xserver-xfree86.config.in.
     + Add /usr/X11R6/lib/{modules/drivers/via_drv.o,man/man4/via.4x}
       to xserver-xfree86.install.{hurd-,}i386 and MANIFEST.{hurd-,}i386.
 .
   * Grab latest version of Thomas Winischhofer's SiS driver for the XFree86 X
     server from his website as of 2004-05-10.
     + display should no longer "melt" on SiS 630ST (Closes: #245249)
     + SiS 330 (Xabre) support improved and should no longer hang system
       (Closes: #246087)
 .
   * Stop shipping the "Xterm Control Sequences" document in the xspecs
     package; ship it only in xterm.  Add HTML version of this document to the
     xterm package.  Update xterm's extended description to mention the
     availability of this document.
 .
   * Grab latest version of XTerm from Thomas Dickey's website.  Revert
     inconsequential changes merged from XFree86 CVS after 2004-02-13 that
     could conceivably be under the XFree86 1.1 license's terms.
     + When deriving bold fontname from normal fontname, use the normal font's
       average width to avoid for example selecting 7x13bold from an 8x13
       normal font.  (Closes: #107769)
     + Modify xtermAddInput() to use the complete set of default keyboard
       translations so that one can use shifted pageup, wheel mouse, etc.,
       while the mouse pointer is over the scrollbar.  (Closes: #178812)
     + Improve description of utf8 resource in manpage.  (Closes: #179407)
     + Correct comment in terminfo file regarding modifier used for kDC.
       (Closes: #189764)
     + Correct typo in example for character classes in xterm manpage.
       (Closes: #198910)
     + Add translation to ASCII of commonly-used characters that groff
       translates to Unicode, when the font in use does not provide the
       corresponding glyphs.  (Closes: #219551)
     + Add a limit check to ScrnTstWrapped() (XFree86 Bugzilla #981).
       (Closes: #222530)
     + Modify uxterm script to interpret help and version options so xterm does
       not always create a window when the user requests this information.
       (Closes: #223926)
     + Modify initialization of terminal colors, e.g., mouse pointer and text
       cursor, to treat XtDefaultForeground and XtDefaultBackground values as
       the actual foreground and background colors of the terminal rather than
       white and black.  (Closes: #241717)
 .
   * XTerm's manual page now accurately documents the default set of VT
     terminal colors used in the XTerm-color app-defaults file.  (Upstream
     adopted Debian's changes.)  (Closes: #247705)
 .
   * Stop using an Xaw7 gradient for the backgrounds of the xterm menus; it
     produces an unappealing effect if the menus are configured to use a larger
     font than the stock configuration (also, xterm has added items to some
     menus since I last calculated the gradient size and I can't be bothered to
     do it again).
 .
   * If the X server is capable of color and has more than 8 planes of color
     depth available, set the menu colors to gray15 on antique white, and
     customize the appearance VT widget's scrollbar.  Otherwise, do not eat up
     precious entries in the color palette.
 .
   * Define the "xterm-debian" terminal type in the termcap and terminfo files
     as an alias for "xterm-new" instead of "xterm-xfree86", reflecting
     upstream change.
 .
   * Update references to Debian Policy Manual to cite the correct section for
     backspace key handling.
 .
   * Ship the new README.i18n document in /usr/share/doc/xterm.
 .
   * Grab a couple of minor documentation-related fixes from XFree86 CVS.
     + There's no config/util/rman.man (Peter Stromberg). [Matthieu Herrb]
       From XFree86 CVS 2003-04-07.  Delete superseded patch #006.
     + One xieperf reference left over.  Noticed by ISHIKAWA Mutsumi. Thanks.
       [Matthieu Herrb]  From XFree86 CVS 2003-04-14.
 .
   * Grab a fix to the XFree86 X server chips driver from XFree86 CVS
     2003-04-04.
     + Fixed DPMS problem on C&T 69000 due to incorrect LCD flag (Bugz: 101,
       Egbert Eich).
 .
   * Grab updates to XKB documentation and code from XFree86 CVS.
     + Fix typo in XKB README.config file.  (Egbert Eich, 2003-04-07)
     + Fix xkbcomp crash with some combinations of layouts in a multi-layout
       keyboard map (Ivan Pascal).  (2003-04-19)
 .
   * Grab updates to XKB data from XFree86 CVS, none later than 2003-04-30.
     Resync offsets in patches #082 and #084.  Update MANIFEST files and
     xlibs.install to recognize and ship new XKB symbols files hr_US, th_pat,
     and th_tis.
     + Add Thai (Pattachote) and Thai (TIS-820.2538) keymap support as layouts
       "th_pat" and "th_tis", respectively.  [Theppitak Karoonboonyanan, Visanu
       Euarchukiati, Supphachoke Santiwichaya, David Dawes]
     + Fix a typo that causes the 'yu' keymap to emit a lower case 'L' in both
       shift states (#A.1675, Nikola Smolenski). [David Dawes]
     + Add xkb symbols layout for BTC 5090 internet keyboard (Bugz: 57, Jack
       Angel). [Egbert Eich]
     + Add keys missed in multi-layout keyboard maps: LSGT key in [...]
       'old','phonetic' variants in Armenian map (Ivan Pascal).
     + Update Italian keyboard map (Bugzilla #109, Sebastiano Vigna). [Ivan
       Pascal]
     + Fix the <KPDL> mapping for the hr XKB map, and add an hr_US map
       (#A.1726, Vlatko Kosturjak). [David Dawes]
     + Keyboard maps cleanups, including:
       - fix incorrect aliases in a keycodes file.
       - remove unneeded type declarations.
       - remove ThirdLevel modifier key descriptions in maps and replace them
         with references to a common one in 'level3' file.
       - some cosmetic changes.
       (Ivan Pascal). [David Dawes]
 .
   * Apply Michel Dänzer's fix for Radeon driver trying forever to initialize
     card if card's firmware is not loaded.  Add patch #006.  Resync patches
     #024, #079.  (Closes: #246901)
 .
   * Add Turkish debconf template translations (thanks, Osman Yüksel).
     (Closes: #248144)
 .
   * Adjust package relationships of libxrandr2 and libxrandr2-dbg so that they
     no longer conflict with and replace xlibs (<< 4.3.0); there are no file
     overlaps in these cases (though there are with libxrandr-dev), so such
     declarations are spurious.  (Closes: #248539)
 .
   * Handle failure of "which" command when processing arguments to Xsession,
     so that the script is not aborted prematurely (thanks, Oliver Bausinger).
     (Closes: #248632)
 .
   * Update ARM support patch #315 to add #define guards against more instances
     of x86 and legacy VGA I/O code (thanks, Wookey).  (Closes: #234808)
 .
   * Add dependency of libxp-dev on xlibs-static-dev, since the former's
     Print.h #includes the latter's Xauth.h (thanks, Matt Kraai).
     (Closes: #249738)
 .
   * Remove spurious sourcing of debconf confmodule from maintainer scripts
     that do not actually need it (thanks, LaMont Jones).  (Closes: #250061)
 .
   Changes by Fabio Massimo Di Nitto:
 .
   * Update xutils's package description to refer to bdftruncate and ucs2any
     programs by their correct names.
Files: 
 f483b710346a5722da472130aaf40d77 2660 x11 optional xfree86_4.3.0.dfsg.1-2.dsc
 a25c66dcffe31a1c36eabbc254e13960 3057095 x11 optional xfree86_4.3.0.dfsg.1-2.diff.gz
 230cf9b716e37041408f9bd7aae36217 218542 x11 optional lbxproxy_4.3.0.dfsg.1-2_i386.deb
 64a2ede4e19da30f14acc058f857a7bd 255160 libs optional libdps1_4.3.0.dfsg.1-2_i386.deb
 a2f36b1cdbd4c3a11164e14bc59d9b5d 753512 libdevel extra libdps1-dbg_4.3.0.dfsg.1-2_i386.deb
 9170f280f22b81df2fc81441ffae1d46 312766 libdevel optional libdps-dev_4.3.0.dfsg.1-2_i386.deb
 3827aa0c857c8175dc29ba0b4375c799 172512 libs optional libice6_4.3.0.dfsg.1-2_i386.deb
 3c8c982945b0f1c698dd4eeac5c30854 256736 libdevel extra libice6-dbg_4.3.0.dfsg.1-2_i386.deb
 721f721ddb0f24fde12aba914c4fd91b 175854 libdevel optional libice-dev_4.3.0.dfsg.1-2_i386.deb
 1b9667f2ee8ef8d1a6346ded92931bfa 150222 libs optional libsm6_4.3.0.dfsg.1-2_i386.deb
 1f66f6f8aa3937aff033ebb9395ed3cc 175860 libdevel extra libsm6-dbg_4.3.0.dfsg.1-2_i386.deb
 21b40527786354c124e2416ca13a5c13 147194 libdevel optional libsm-dev_4.3.0.dfsg.1-2_i386.deb
 b3fa741acb8fd2e6e38a40ace6a6bb72 682694 libs optional libx11-6_4.3.0.dfsg.1-2_i386.deb
 823d8c41397a5d90b5d2a63bf8e98de2 9578400 libdevel extra libx11-6-dbg_4.3.0.dfsg.1-2_i386.deb
 553da34e10d28a85198d600aadcfd272 1333300 libdevel optional libx11-dev_4.3.0.dfsg.1-2_i386.deb
 96802b82571a6b3d793c2e8781e2565c 254342 libs optional libxaw6_4.3.0.dfsg.1-2_i386.deb
 7e38b2154620f9e82d8aeaba5b972c4b 860916 libdevel extra libxaw6-dbg_4.3.0.dfsg.1-2_i386.deb
 1c43e1eae369203e8d5ed2787768f44d 384610 libdevel extra libxaw6-dev_4.3.0.dfsg.1-2_i386.deb
 5861bd5a4a18c10185dcdf7546bb92e9 307444 libs optional libxaw7_4.3.0.dfsg.1-2_i386.deb
 ca90e6274f10852f43b70bdde61b8051 996004 libdevel extra libxaw7-dbg_4.3.0.dfsg.1-2_i386.deb
 6eddd0dc16d1ec8c78ebb005a77b321a 384502 libdevel optional libxaw7-dev_4.3.0.dfsg.1-2_i386.deb
 88f151a63f8693c62b8a2b86a74801a5 157402 libs optional libxext6_4.3.0.dfsg.1-2_i386.deb
 182aae340aa1a5b55e3800a3d687bbd2 478232 libdevel extra libxext6-dbg_4.3.0.dfsg.1-2_i386.deb
 a47636dc62634aacd8bd3c5a60e5cc13 217284 libdevel optional libxext-dev_4.3.0.dfsg.1-2_i386.deb
 8eceb607b39213c5740f77fd502e646b 159702 libs optional libxft1_4.3.0.dfsg.1-2_i386.deb
 55fb98028cd54059196dc453ea5a3141 440210 libdevel extra libxft1-dbg_4.3.0.dfsg.1-2_i386.deb
 8732a7a1fe2d8406284b5a2062611aff 148584 libs optional libxi6_4.3.0.dfsg.1-2_i386.deb
 39ac75e69b1836af8ec94ac8f2c71f27 1136286 libdevel extra libxi6-dbg_4.3.0.dfsg.1-2_i386.deb
 658cf8c2be68f93ab795382634df7676 201958 libdevel optional libxi-dev_4.3.0.dfsg.1-2_i386.deb
 662b92562d802f11fd5ab9ffb4fbda49 178808 libs optional libxmu6_4.3.0.dfsg.1-2_i386.deb
 910503d4539487084fd0b5880504b3b2 630586 libdevel extra libxmu6-dbg_4.3.0.dfsg.1-2_i386.deb
 aacc8b61ed897dab4c5c448a02f1da2e 188798 libdevel optional libxmu-dev_4.3.0.dfsg.1-2_i386.deb
 bd2d64fc3c09fa8e7ea6e9a24db0f1aa 140660 libs optional libxmuu1_4.3.0.dfsg.1-2_i386.deb
 0a1b18c2ac5e2edd39baf182b2233e94 178976 libdevel extra libxmuu1-dbg_4.3.0.dfsg.1-2_i386.deb
 5bbd4fc0f690217a363eea61d40e22f3 133522 libdevel optional libxmuu-dev_4.3.0.dfsg.1-2_i386.deb
 dfc4c40c5a542013a5cb8ff6cf7e0df9 147730 libs optional libxp6_4.3.0.dfsg.1-2_i386.deb
 62e72564aee22f144b093ce846da3dcf 535736 libdevel extra libxp6-dbg_4.3.0.dfsg.1-2_i386.deb
 90e2767ab4a757f86501392b4c11134a 149510 libdevel optional libxp-dev_4.3.0.dfsg.1-2_i386.deb
 c76d2093a8c03d92e2933a705e75a49a 163430 libs optional libxpm4_4.3.0.dfsg.1-2_i386.deb
 e21d3020c43d93f9c2ccb28648fc163a 208866 libdevel extra libxpm4-dbg_4.3.0.dfsg.1-2_i386.deb
 e5c1d093d5a7bfdc087b21c7995c65b8 162502 libdevel optional libxpm-dev_4.3.0.dfsg.1-2_i386.deb
 476c988ef007cc004fa672cc46b402bd 140404 libs optional libxrandr2_4.3.0.dfsg.1-2_i386.deb
 ee0aa1b7531be56de569332c198bf734 170894 libdevel extra libxrandr2-dbg_4.3.0.dfsg.1-2_i386.deb
 721f3cc98b3cf2d3aa3a2a08256ed0e1 141234 libdevel optional libxrandr-dev_4.3.0.dfsg.1-2_i386.deb
 31afbef7763e6876dd6a1c322f68d5da 286786 libs optional libxt6_4.3.0.dfsg.1-2_i386.deb
 d2e31621ee6bc8735f85fa2f973cf7eb 1500878 libdevel extra libxt6-dbg_4.3.0.dfsg.1-2_i386.deb
 504bf447eaf344ec321f4dac6d59cdd5 586936 libdevel optional libxt-dev_4.3.0.dfsg.1-2_i386.deb
 eb223d8e4c071c8bd6119d9074b2714b 149550 libs optional libxtrap6_4.3.0.dfsg.1-2_i386.deb
 b38099f6db7e79089e3f0efa85f9204b 380852 libdevel extra libxtrap6-dbg_4.3.0.dfsg.1-2_i386.deb
 19e4361b427599e6b3bf6e379a91665c 155326 libdevel optional libxtrap-dev_4.3.0.dfsg.1-2_i386.deb
 2942849fd994a95469398e4eac40401b 143374 libs optional libxtst6_4.3.0.dfsg.1-2_i386.deb
 7568145968a4362a00b5490ecd3d4a0f 207034 libdevel extra libxtst6-dbg_4.3.0.dfsg.1-2_i386.deb
 ddbe649607e970597798aac65562b4fd 141012 libdevel optional libxtst-dev_4.3.0.dfsg.1-2_i386.deb
 6a36d3ab30cf3516f29eb148d46ef3ed 141506 libs optional libxv1_4.3.0.dfsg.1-2_i386.deb
 d4bc43e43444480968bc58be640d0804 173698 libdevel extra libxv1-dbg_4.3.0.dfsg.1-2_i386.deb
 5c9119ed97ac9fab3d0b6587879aa98c 161160 libdevel optional libxv-dev_4.3.0.dfsg.1-2_i386.deb
 b1a05583064c4bc99d28444e31a19f2f 151730 x11 optional proxymngr_4.3.0.dfsg.1-2_i386.deb
 26585d5720ec15ba2e5605283594526b 234198 x11 optional twm_4.3.0.dfsg.1-2_i386.deb
 6f3294ea644456171ab093db08681699 1913040 x11 optional xbase-clients_4.3.0.dfsg.1-2_i386.deb
 dba7535e46238bdbd2517e137ede6742 269296 x11 optional xdm_4.3.0.dfsg.1-2_i386.deb
 f980e11da1b92a022e59661cb081021d 463784 x11 optional xfs_4.3.0.dfsg.1-2_i386.deb
 9879ef06fb6edfddb381d160ccab9b85 151120 x11 optional xfwp_4.3.0.dfsg.1-2_i386.deb
 984c9069fbfeeb645e2512634c8d02db 4972136 x11 optional xlibmesa-dri_4.3.0.dfsg.1-2_i386.deb
 32bfb45f8b122af9680fd0a2e1a6a321 49450246 x11 optional xlibmesa-dri-dbg_4.3.0.dfsg.1-2_i386.deb
 f04bfd223aef716f2fac9ba5b856af09 252418 libs optional xlibmesa-gl_4.3.0.dfsg.1-2_i386.deb
 22efe65f5feb9a598b77023052fce899 1200174 libdevel extra xlibmesa-gl-dbg_4.3.0.dfsg.1-2_i386.deb
 950057f6dc578a4ae64efd7afe98335d 675670 libdevel optional xlibmesa-gl-dev_4.3.0.dfsg.1-2_i386.deb
 3c97d4d42acecde791b6b0bb3dcc6971 334818 libs optional xlibmesa-glu_4.3.0.dfsg.1-2_i386.deb
 ea88f5cf780b417635beb26cd4f3402f 1081740 libdevel extra xlibmesa-glu-dbg_4.3.0.dfsg.1-2_i386.deb
 bc1e9ed2a8a34a1af4ba9531f734031a 405410 libdevel optional xlibmesa-glu-dev_4.3.0.dfsg.1-2_i386.deb
 efdc9350947432c1b944b2f42b0a2506 630512 libs optional xlibosmesa4_4.3.0.dfsg.1-2_i386.deb
 c568fae9ced3094fbb274239cc20fbbf 4553552 libdevel extra xlibosmesa4-dbg_4.3.0.dfsg.1-2_i386.deb
 715697c2cd122d567b0b0c072f10873d 760268 libdevel optional xlibosmesa-dev_4.3.0.dfsg.1-2_i386.deb
 deceae49d0540f94ef24a99e577de4a5 823816 libdevel optional xlibs-static-dev_4.3.0.dfsg.1-2_i386.deb
 44e81342beeddf78ad0c441b5a47148f 355872 libdevel extra xlibs-static-pic_4.3.0.dfsg.1-2_i386.deb
 b9f9021b2502744ad0148cf1738efcf0 197808 mail extra xmh_4.3.0.dfsg.1-2_i386.deb
 b7130a2ae5ceecb815ed356757d75b0a 1436450 x11 optional xnest_4.3.0.dfsg.1-2_i386.deb
 a6acc6708e67b7f589eb873d299ef068 1097142 x11 optional xprt_4.3.0.dfsg.1-2_i386.deb
 dff435f19c97c26db08b1d86fdcbbdf3 304310 x11 optional xserver-common_4.3.0.dfsg.1-2_i386.deb
 bf075f2a4680b91bf046ef65f563881e 5629838 x11 optional xserver-xfree86_4.3.0.dfsg.1-2_i386.deb
 96e4fed73eeac3f4e6a9def4fff7f9fb 53892396 x11 extra xserver-xfree86-dbg_4.3.0.dfsg.1-2_i386.deb
 cc7e86da135738bd7303e365c24ef3a7 644140 x11 optional xterm_4.3.0.dfsg.1-2_i386.deb
 700ca18b4fe4d9c14c84847a3bf46fb3 863340 x11 optional xutils_4.3.0.dfsg.1-2_i386.deb
 bc5ca92c4a489dbc441763045d806d0b 1571052 x11 optional xvfb_4.3.0.dfsg.1-2_i386.deb
 ab6b9681b042a61243a728ce8f91c21c 129240 x11 optional x-window-system-core_4.3.0.dfsg.1-2_i386.deb
 72e0011f68cc49ef7d71d903df52af82 129290 x11 extra x-window-system-dev_4.3.0.dfsg.1-2_i386.deb
 b0eafd52db68dee2139b1d562e3c11b8 129036 oldlibs optional xlibmesa3_4.3.0.dfsg.1-2_i386.deb
 fe9359ccf19c95805bc4fbc2351efd3f 129864 libdevel optional pm-dev_4.3.0.dfsg.1-2_all.deb
 2c643c1030c1328175555a8356f35cc5 186856 libdevel optional x-dev_4.3.0.dfsg.1-2_all.deb
 7441eb1c3511d021836031b0dbefca52 4331950 x11 optional xfonts-100dpi_4.3.0.dfsg.1-2_all.deb
 2868060cfa2250850eefd5733534b004 8164834 x11 optional xfonts-100dpi-transcoded_4.3.0.dfsg.1-2_all.deb
 6b147010f7fd1f884beaed99c43faaad 3809682 x11 optional xfonts-75dpi_4.3.0.dfsg.1-2_all.deb
 24e1c1870350b84a7ab546769ba2cbaa 7041810 x11 optional xfonts-75dpi-transcoded_4.3.0.dfsg.1-2_all.deb
 78a5666473f5d9362f9183391da63caf 5475834 x11 optional xfonts-base_4.3.0.dfsg.1-2_all.deb
 7b3d7ff15e393d1c30ca2ec461ee5646 1172552 x11 optional xfonts-base-transcoded_4.3.0.dfsg.1-2_all.deb
 5a1d3b0f1256b2647c25901d004fff28 509980 x11 optional xfonts-cyrillic_4.3.0.dfsg.1-2_all.deb
 07bc7b1cd36a949706aeb361f4cad1ba 869720 x11 optional xfonts-scalable_4.3.0.dfsg.1-2_all.deb
 2c95d050e5871ba07c8028e31ea48e38 695016 x11 optional xfree86-common_4.3.0.dfsg.1-2_all.deb
 fdd2c8df2914293ef2fcec2005b1f66d 381628 libs optional xlibs_4.3.0.dfsg.1-2_all.deb
 173f46660f1d2db5d9fe3fac022fe692 866872 libs optional xlibs-data_4.3.0.dfsg.1-2_all.deb
 84686bb4dac3b37d98a55be29ccc449a 5625314 x11 optional xspecs_4.3.0.dfsg.1-2_all.deb
 c90497298368ce5602dd8e6933b9a7aa 129166 x11 optional x-window-system_4.3.0.dfsg.1-2_all.deb
 23c8d39d379ba52358a12bf25a1e52f5 129022 oldlibs extra xlibmesa3-dbg_4.3.0.dfsg.1-2_all.deb
 c0f090f108939b3a0591fa51207c8d0e 129008 oldlibs optional xlibmesa-dev_4.3.0.dfsg.1-2_all.deb
 16d8789c39570d255e4cee402ba66c3b 129072 oldlibs extra xlibs-dbg_4.3.0.dfsg.1-2_all.deb
 6a904becfca620086ba83752ead2d975 129072 oldlibs extra xlibs-dev_4.3.0.dfsg.1-2_all.deb
 a13484be8e85120b9925c85281ef98c7 128978 oldlibs extra xlibs-pic_4.3.0.dfsg.1-2_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAs7yVhCzbekR3nhgRAgm7AJwKNyVgsk4tob0yU8NNshlBU+p+AQCfRlcV
dh0uY7FcBQbLosBVBEs2oqk=
=0YvL
-----END PGP SIGNATURE-----




Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 03:15:42 2014; Machine Name: buxtehude.debian.org

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