Bug#254288: xserver-xfree86: [ati] Drops blue bit at depth 24-bit

[Peter Dey]

>There's more than one bit of blue at depth 24; there are 8 bits of blue
>(and 8 bits of green, and 8 bits of red).
>
>Do you mean that the entire blue channel is missing at depth 24?

Yes, that's correct.  The entire blue channel is missing.

>
>> Colours very messed up at 16-bit.
>
>Can you elaborate?  What do solid red, blue, and green look like?
>
>% xlogo -fg red -bg black
>% xlogo -fg green -bg black
>% xlogo -fg blue -bg black
>

At 24-bit:
-fg red Red
-fg green   Green
-fg blueRed

White (e.g. the background of google) looks like Yellow.


At 16-bit:
-fg red swirly pink, black and blue?
-fg green   swirly pink, black and green?
-fg blueswirly blue, green and black?

However, White is still white
And black (e.g. background of a term window) is still black


Cheers,

Peter Dey
[EMAIL PROTECTED]

Bug#255282: xserver-xfree86: [libGLcore.a] Skipping -- No symbols found

[Michel Dänzer]

On Fri, 2004-07-09 at 15:34 -0700, Mike Mestnik wrote:
> --- Branden Robinson <[EMAIL PROTECTED]> wrote:
> > On Thu, Jul 08, 2004 at 01:22:18PM -0700, Mike Mestnik wrote:
> > > There are several problems...
> > > 1. I'm not getting "dri enabeled" or "dri disabled".
> > 
> > If there's no DRI support in the first place, it can't be disabled due
> > to problems.
> > 
> I'm trying to program DRI support into Debian's XF86.

Mach64 DRI support isn't even in X.Org or XFree86 CVS yet. There are
security issues that need to get addressed first. You can try my dri-
mach64-sid packages though, someone even contributed a sparc build of
those, I don't know whether he actually tested the DRI support though.


-- 
Earthling Michel Dänzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer

Bug#256442: [ATTACHED] iBook G4 British keymap

[Michel Dänzer]

On Fri, 2004-07-09 at 03:20 +0100, Sam Halliday wrote: 
> Branden Robinson wrote:
> > I don't see many differences between this and the current
> > /etc/X11/xkb/symbols/macintosh/gb file, which I fixed up in xlibs
> > 4.3.0.dfsg.1-5:
> 
> this is what is different:
> 
> // let the marked "alt" be AltGr (as it is in MacOS) 
> key  {  [  Mode_switch  ]   };
> // let the Apple key be Alt
> key  {  [  Alt_L]   };
> 
> the key physically marked "alt" on a macintosh keyboard is actually altgr (as
> can confirmed in MacOS X). The apple key should then be the alt key. this
> mapping does that.

There are XKB options to change the default behaviour of the modifiers,
e.g. I use compose:rwin and grp:lwin_switch .

I agree that the default should be what is physically written on the
keys whenever possible, and the option key says 'alt' here.


-- 
Earthling Michel Dänzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer

Bug#255282: xserver-xfree86: [libGLcore.a] Skipping -- No symbols found

[Mike Mestnik]

--- Branden Robinson <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 08, 2004 at 01:22:18PM -0700, Mike Mestnik wrote:
> > There are several problems...
> > 1. I'm not getting "dri enabeled" or "dri disabled".
> 
> If there's no DRI support in the first place, it can't be disabled due
> to
> problems.
> 
I'm trying to program DRI support into Debian's XF86.  I can't find where
it's not getting loaded, is this not a bug if there is no errormsg when
there is an error?

> > 2. These missing symbols.
> 
> These are harmless messages and this is not a bug.  If the module
> objects
> were unstripped, there'd be symbols in them, but policy says to strip
> them,
> so they're stripped.
> 
Thank you for clarifying.  Why dosen't it say that the mod is still being
loaded, I guess that's WW vs EE?

> > 3. A general not working of mach64 DRI on sparc.
> 
> This sounds like a feature request.
> 
Odd a request to add a feature that I'm attempting to add.

> > I have a Mesa tree that builds in linux, previously there was some
> solaris
> > only ASM.  The DRI tree still has this build problem, so I must use
> > another Xserver.  The bug here being that the SPARC debian X server is
> not
> > usefull for this, where the I386 is.
> > 
> > I'm now looking into AGP support, thought I think mach64 cards are
> only
> > PCI.
> 
> Can you please restate the issue for this particular bug report?
> 
I guess it dosen't however it's information that may help in debuging the
problem.

> -- 
> G. Branden Robinson| I'm a firm believer in not
> drawing
> Debian GNU/Linux   | trend lines before you have
> data
> [EMAIL PROTECTED] | points.
> http://people.debian.org/~branden/ | -- Tim Ottinger
> 

> ATTACHMENT part 2 application/pgp-signature name=signature.asc





__
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

Bug#253660: Test results

[Michel Dänzer]

On Fri, 2004-07-09 at 12:31 -0400, Graham Knap wrote:
> 
> /usr/games/neverball: relocation error: /usr/games/neverball: undefined 
> symbol: glMultiTexCoord2f

This is a bug in neverball, it violates the OpenGL ABI. It must use
either glXGetProcAddress("glMultiTexCoord2f") (if GL 1.3 is available)
or glXGetProcAddress("glMultiTexCoord2fARB") (if the GL_ARB_multitexture
extension is available) to obtain a pointer to that function.


-- 
Earthling Michel Dänzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer

Bug#256086: Bold characters and font change with VT100*boldMode off

[Branden Robinson]

retitle 256068 xterm: colorBDMode state can get lost when boldMode on, a 
boldFont resolves to the same font as its non-bold counterpart, and the font is 
changed
tag 256086 - moreinfo
thanks

On Thu, Jul 08, 2004 at 07:33:21PM -0500, dircha wrote:
> Branden Robinson wrote:
> >Uh, can you (or Thomas Dickey) please summarize what the bug is
> >here?
> 
> Yes, I believe I can get it right:
[...]
> It is not a major bug.

Whew, that's complicated.  No wonder there's a bug here.

Thanks for the clarification!

-- 
G. Branden Robinson|As people do better, they start
Debian GNU/Linux   |voting like Republicans -- unless
[EMAIL PROTECTED] |they have too much education and
http://people.debian.org/~branden/ |vote Democratic.   -- Karl Rove


signature.asc
Description: Digital signature

Bug#256468: xterm: utmp handling is broken for high pts

[Branden Robinson]

reassign 256468 kernel
thanks

On Thu, Jul 08, 2004 at 07:40:39PM -0400, Thomas Dickey wrote:
> On Thu, Jul 08, 2004 at 06:16:29PM -0500, Branden Robinson wrote:
> > Is it your opinion that this is a bug in the Linux kernel, then?
> 
> neither - I did read that this behavior is changed in the next version
> of the kernel, but it's something that xterm should (in principle) handle.
> 
> But if it's really changed as reported, then I may not have to fix anything.
>  
> > If so, I will reassign it.  If not, I would like your advice on what should
> > be done about this bug.  :)
> 
> I'd reassign it to kernel, and get them to state whether the change
> in behavior is by design or accident.

Your wish is my command.

Kernel folks:

Is it deliberate that pseudo-tty numbers are never "recycled" in recent
kernel versions?  This can lead to very large numbers; please see the logs
of #256468 for details.

-- 
G. Branden Robinson| The more ridiculous a belief
Debian GNU/Linux   | system, the higher the probability
[EMAIL PROTECTED] | of its success.
http://people.debian.org/~branden/ | -- Wayne R. Bartz


signature.asc
Description: Digital signature

Processed: reassign 229426 to icewm

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.7.95.1
>  # hmmm, neglected to actually reassign this
> reassign 229426 icewm
Bug#229426: Windows key buggy
Bug reassigned from package `xlibs-data' to `icewm'.

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Processed: retitle 257073 to xterm: manpage mixes up middle and left mouse button in CHARACTER CLASSES section

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.7.95.1
> retitle 257073 xterm: manpage mixes up middle and left mouse button in 
> CHARACTER CLASSES section
Bug#257073: xterm manpage mixes up middle and left mouse button in CHARACTER 
CLASSES section
Changed Bug title.

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Processed: Re: Bug#256468: xterm: utmp handling is broken for high pts

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 256468 kernel
Bug#256468: xterm: utmp handling is broken for high pts
Bug reassigned from package `xterm' to `kernel'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Processed: retitle 257062 to xserver-xfree86: please backport new Intel i910 driver

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.7.95.1
> retitle 257062 xserver-xfree86: please backport new Intel i910 driver
Bug#257062: Please include the new intel driver
Changed Bug title.

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Bug#256718: marked as done (x-window-system package forces xserver-xfree86)

[Branden Robinson]

> x-window-system should be stopping you from installing vncserver; if you
> want the latter, install it.

Sorry, "should" should be "shouldn't" above.

-- 
G. Branden Robinson| You could wire up a dead rat to a
Debian GNU/Linux   | DIMM socket and the PC BIOS memory
[EMAIL PROTECTED] | test would pass it just fine.
http://people.debian.org/~branden/ | -- Ethan Benson


signature.asc
Description: Digital signature

Bug#255224: xlibs-data: Patch for bug of ct_encoding sequence in zh_CN.gbk locale

[Branden Robinson]

tag 255224 - moreinfo
thanks

On Fri, Jul 09, 2004 at 05:13:07AM +0800, SU Yong wrote:
> On Thu, Jul 08, 2004 at 02:25:08PM -0500, Branden Robinson wrote:
> > Thanks!  I have reviewed the patch, and while compound text encoding is a
> > bit beyond me, I do appreciate the heads-up.  :)
>   Thanks to you and all the DDs :)
> > 
> > I notice you are the author of this fix.  Because of problems with
> > XFree86's recent change in licensing policy[1], I'd like to be certain I
> > know what the provenance of your patch is.
> > 
> > Can you confirm the following statements?
> Yes, I can. :)
[...]
> Yes, I'm the only author of this patch.
> 
> The bug report on http://bugs.xfree86.org/show_bug.cgi?id=1362
> has detailed how I found and fixed this bug[2]. My project
> `mule-gbk' mentioned in the report may be available on
> Sourceforge, later. One can find a very old version of mule-gbk from
> http://lists.debian.org/debian-chinese-big5/2002/04/msg00013.html. 
[...]
> If any copyright attaches to this patch, I hereby place it under the
> traditional MIT/X11 license[1].

Thanks a lot for putting up with my paranoia.  :)

This fix is queued up for the next package release, which we expect to be
4.3.0.dfsg.1-7.

When the fix has been applied to the Subversion repository, this bug will
be tagged "pending".

-- 
G. Branden Robinson| Communism is just one step on the
Debian GNU/Linux   | long road from capitalism to
[EMAIL PROTECTED] | capitalism.
http://people.debian.org/~branden/ | -- Russian saying


signature.asc
Description: Digital signature

Bug#256706: patch for Win-Tab bug

[Branden Robinson]

retitle 256706 xlibs: Win+Tab switching broken in many window managers
# this bug is not fixed ustream, applicable to experimental, nor does it
# have a usable patch
tag 256706 = upstream help
thanks

On Thu, Jul 08, 2004 at 07:37:04PM -0400, Nathaniel W. Turner wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Thursday 08 July 2004 07:26 pm, Branden Robinson wrote:
> > It's not nonsense, but I don't think it correct either.  I strongly suspect
> > that this will screw things up for people who use  for something
> > other than Super_L.
> 
> Yeah, I believe you're right.  In KDE just pressing and releasing LWIN used 
> to 
> open the K-Menu.  This no longer works on this box with my patch (but it does 
> work on a similar system where xlibs has been held at an older version).

I'm not sure I made myself clear; I'm saying the proposed fix isn't right
either, not because it doesn't fix KDE (which I would have expected,
actually), but because it would force a certain modifier to be bound to
 even for people who wanted a different modifier bound to that key.

I have mailed Ivan Pascal, a well-known XKB guru, and pleaded with him for
assistance.  So far he hasn't replied yet, but I'm hopeful.

-- 
G. Branden Robinson|
Debian GNU/Linux   |  Ignorantia judicis est calamitas
[EMAIL PROTECTED] |  innocentis.
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Bug#255282: xserver-xfree86: [libGLcore.a] Skipping -- No symbols found

[Branden Robinson]

On Thu, Jul 08, 2004 at 01:22:18PM -0700, Mike Mestnik wrote:
> There are several problems...
> 1. I'm not getting "dri enabeled" or "dri disabled".

If there's no DRI support in the first place, it can't be disabled due to
problems.

> 2. These missing symbols.

These are harmless messages and this is not a bug.  If the module objects
were unstripped, there'd be symbols in them, but policy says to strip them,
so they're stripped.

> 3. A general not working of mach64 DRI on sparc.

This sounds like a feature request.

> I have a Mesa tree that builds in linux, previously there was some solaris
> only ASM.  The DRI tree still has this build problem, so I must use
> another Xserver.  The bug here being that the SPARC debian X server is not
> usefull for this, where the I386 is.
> 
> I'm now looking into AGP support, thought I think mach64 cards are only
> PCI.

Can you please restate the issue for this particular bug report?

-- 
G. Branden Robinson| I'm a firm believer in not drawing
Debian GNU/Linux   | trend lines before you have data
[EMAIL PROTECTED] | points.
http://people.debian.org/~branden/ | -- Tim Ottinger


signature.asc
Description: Digital signature

Bug#255453: Back-slash and vertical-bar keys broken under X

[Everton da Silva Marques]

--- Branden Robinson <[EMAIL PROTECTED]> wrote:
> > This is how the keyboard is configured under X,
> > but those two keys remain incorrecly handled:
> > 
> >   # dpkg-reconfigure xserver-xfree86
> > 
> >   XKB rule: xfree86
> >   Keyboard model: pc104
> >   Keyboard layout: br
> >   Keyboard variant: abnt2
> 
> Please try this instead:
> 
> XKB rules: xfree86
> Keyboard model: abnt2
> Keyboard layout: br
> 
> Do the keys work then?

Yes, the keys work with this:

Option "XkbRules"   "abnt2"
Option "XkbModel"   "pc105"
Option "XkbLayout"  "br"
Option "XkbVariant" "abnt2"

It seems it's just a misconfiguration of mine. Sorry. :/

Thanks.






___
Yahoo! Mail agora com 100MB, anti-spam e antivírus grátis!
http://br.info.mail.yahoo.com/

Processed: Re: Bug#256706: patch for Win-Tab bug

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> retitle 256706 xlibs: Win+Tab switching broken in many window managers
Bug#256706: Win-Tab switching broken in dfsg.1-5
Changed Bug title.

> # this bug is not fixed ustream, applicable to experimental, nor does it
> # have a usable patch
> tag 256706 = upstream help
Bug#256706: xlibs: Win+Tab switching broken in many window managers
Tags were: sid experimental patch fixed-upstream upstream
Tags set to: upstream, help

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Processed: retitle 256360 to xfree86: Updated Turkish po-debconf translation [INTL:tr]

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.7.95.1
> retitle 256360 xfree86: Updated Turkish po-debconf translation [INTL:tr]
Bug#256360: [INTL:tr] Updated Turkish po-debconf translation
Changed Bug title.

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Processed: Re: Bug#255224: xlibs-data: Patch for bug of ct_encoding sequence in zh_CN.gbk locale

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> tag 255224 - moreinfo
Bug#255224: xlibs-data: GBK <-> COMPOUND_TEXT encoding broken
Tags were: moreinfo upstream patch
Tags removed: moreinfo

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Bug#253088: VT text display gets mangled with Radeon 9200 dualhead setup

[Branden Robinson]

retitle 253088 xserver-xfree86: [ati/radeon] VT switching corrupts text 
consoles on Radeon RV280 [Radeon 9200] rev 1
thanks

On Thu, Jul 08, 2004 at 10:54:50AM +0300, Heikki Kantola wrote:
> According to Branden Robinson <[EMAIL PROTECTED]>:
> > So the problem is that VTs are corrupt, but only while the X server is
> > running?
> > 
> > Do the VTs correct themselves once the X server exits?
> 
> If you shut down X from the VT running it, yes the corrupted VTs get
> restored to the original state, but if you do this from one of the 
> broken text VTs, there is no change.

Okay.  So if you were to disable VT switching while the X server were
running with the "DontVTSwitch" option described in XF86Config-4(5x), you
probably wouldn't notice this problem at all, right?

I thought the same VT restoration logic was used for switching as for
exiting, but I guess I am mistaken.

Does someone else on the debian-x list have a Radeon RV280 [Radeon 9200]
rev 1?  Can anyone reproduce this?

-- 
G. Branden Robinson|  If you don't think for yourself,
Debian GNU/Linux   |  others will think for you -- to
[EMAIL PROTECTED] |  their advantage.
http://people.debian.org/~branden/ |  -- Harold Gordon


signature.asc
Description: Digital signature

Processed: retitle 254565 to xserver-xfree86: [savage] two cursors display when using an ARGB cursor theme on LCD with VT8636A TwisterK

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.7.95.1
> retitle 254565 xserver-xfree86: [savage] two cursors display when using an 
> ARGB cursor theme on LCD with VT8636A TwisterK
Bug#254565: xserver-xfree86: [savage] two cursors display when using an ARGB 
cursor theme on VT8636A TwisterK
Changed Bug title.

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Processed: Re: Bug#253088: VT text display gets mangled with Radeon 9200 dualhead setup

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> retitle 253088 xserver-xfree86: [ati/radeon] VT switching corrupts text 
> consoles on Radeon RV280 [Radeon 9200] rev 1
Bug#253088: VT text display gets mangled with Radeon 9200 dualhead setup
Changed Bug title.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Time to take a decision [Re: Future of X packages in Debian]

[Fabio Massimo Di Nitto]

Ok the discussion is going nowhere useful now.

Daniel, you have expressed your points on the Future of X. Thanks, it was
very detailed and appreciated.

Branden, I would like to hear your point of view too. You are also a user
of your own packages.

I plan to post mine as soon as i can take 5 minutes break from real life
and work.

After that if noone we will add any comment i will prepare a summary and
post it for review. After the review there will be an official
announcement to all our users.

Thanks
Fabio

-- 
 fajita: step one
 Whatever the problem, step one is always to look in the error log.
 fajita: step two
 When in danger or in doubt, step two is to scream and shout.

Re: Future of X packages in Debian

[Daniel Stone]

On Fri, Jul 09, 2004 at 04:47:21AM -0500, Branden Robinson wrote:
> On Thu, Jul 08, 2004 at 11:48:24AM +1000, Daniel Stone wrote:
> > On Wed, Jul 07, 2004 at 01:20:49PM -0500, Branden Robinson wrote:
> > > The above *does* apply even if a given upstream package changes its
> > > upstream source.  When the Xpm library was incorporated into XFree86
> > > upstream, I expressed my interest in maintaining its packages as part of
> > > XFree86 to the then-current maintainer.  AFAIR, he had no objection.
> > 
> > BTW, what you decided to do at a given time, isn't necessarily
> > Debian-blessed practice.
> 
> So you're asserting that what I work out in mutual agreement with another
> package maintainer, under a procedure countenanced by the Debian
> Developers' Reference[1], "isn't necessarily Debian-blessed practice"?
> 
> Fascinating.

dict necessarily

-- 
Daniel Stone<[EMAIL PROTECTED]>
Debian: the universal operating system http://www.debian.org


signature.asc
Description: Digital signature

Re: Future of X packages in Debian

[Daniel Stone]

On Fri, Jul 09, 2004 at 04:33:16AM -0500, Branden Robinson wrote:
> On Tue, Jul 06, 2004 at 07:51:32PM +1000, Daniel Stone wrote:
> > On Mon, Jul 05, 2004 at 07:40:32PM -0500, Branden Robinson wrote:
> > > While it is true that only a fraction of these people actively use their
> > > commit access, it is also true that only one of the approximately 15 
> > > people
> > > who've ever had it did anything that required disciplinary action.
> > 
> > In the first instance, make an error of judgement and start reorganising
> > package names based on a misunderstanding. I was very uncomfortable with
> > that principle.
> 
> Error in judgement?  "My actions were a last-straw attempt to try and force
> two issues, which were quite successfully forced."
> 
> Or were you referring to the earlier incident?

'and start reorganising package names'

-- 
Daniel Stone<[EMAIL PROTECTED]>
Debian: the universal operating system http://www.debian.org


signature.asc
Description: Digital signature

Re: Future of X packages in Debian

[Daniel Stone]

On Fri, Jul 09, 2004 at 04:19:55AM -0500, Branden Robinson wrote:
> 2) his quasi-hijack of the xfree86 package by uploading an NMU in violation
>of the NMU policy, without prior warning or consultation with anyone
>else[1], and without satisfying the published criteria for the package
>release
>
> [...]
>
> [1] ...that I've been able to determine from his public comments on the
> subject.

No other XSF member, past, present, future, or potential, was involved
in my decision.

-- 
Daniel Stone<[EMAIL PROTECTED]>
Debian: the universal operating system http://www.debian.org


signature.asc
Description: Digital signature

Bug#253660: Test results

[Graham Knap]

Hi Branden,

I just tried what you suggested... but I think that recent software updates to 
both Neverball and X have changed things.

We're now at:

neverball 1.3.1-1
xserver-xfree86 4.3.0.dfsg.1-5

X no longer segfaults. Instead, when I try to launch Neverball, X exits with 
this error...

/usr/games/neverball: relocation error: /usr/games/neverball: undefined symbol: 
glMultiTexCoord2f

Should I try to dredge up the old version of Neverball and downgrade so we can 
try to diagnose the original problem... or should we go ahead with the new 
version?

(Sorry -- I now realize that I shouldn't have upgraded without asking you 
first...)

Bug#256855: No option for Radeon cards

[David Meggy]

On Fri, 2004-07-09 at 07:14, Michel Dänzer wrote:
> Ideally, please provide one log of a failure with 'ati' and another of a
> successful startup with 'radeon'.

Now I feel dumb.  I can't get it to fail anymore.  Something must have
changed between the sarge of now, and the sarge of the debian
installer.  If the logs are still useful I have the old logs.

David

Bug#256855: No option for Radeon cards

[Michel Dänzer]

On Fri, 2004-07-09 at 07:03 -0700, David Meggy wrote:
> On Fri, 2004-07-09 at 04:29, Michel Dänzer wrote:
> > We'd have to see server logs to be sure, but I can't think of another
> > reason why 'radeon' would work but not 'ati'.
> 
> /var/log/XFree86.0.log*   ?
> 
> Should I delete these and generate a new log, or can you find the data
> from a week ago?

Ideally, please provide one log of a failure with 'ati' and another of a
successful startup with 'radeon'.


-- 
Earthling Michel Dänzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer

Bug#256855: No option for Radeon cards

[David Meggy]

On Fri, 2004-07-09 at 04:29, Michel Dänzer wrote:
> We'd have to see server logs to be sure, but I can't think of another
> reason why 'radeon' would work but not 'ati'.

/var/log/XFree86.0.log*   ?

Should I delete these and generate a new log, or can you find the data
from a week ago?

David

Bug#253660: PCI information

[Graham Knap]

Hi Branden,

I've attached the output of "lspci -vvv" here. I don't think there's anything 
particularly weird about this machine, but I'll let you decide for yourself.

BTW: The backplane it is mounted in is ISA-only, and there are no additional 
ISA or PC104 cards installed.

I'll try the other stuff you suggested soon -- hopefully either today or Monday.

-- graham
:00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge 
(rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 

:00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge 
(rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- Reset- FastB2B+

:00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- 

Bug#258399: xlibs: dvorak keyboard layout is missing right alt key

[Adam C Powell IV]

Package: xlibs
Version: 4.3.0.dfsg.1-4
Severity: minor

Greetings,

On switching from a normal US layout to the dvorak layout in GNOME (on a
PC), I've lost the use of the right alt key...

Thanks,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Re: Future of X packages in Debian

[Michel Dänzer]

On Fri, 2004-07-09 at 04:08 -0500, Branden Robinson wrote:
> On Thu, Jul 01, 2004 at 11:54:36PM +0200, Michel Dänzer wrote:
> > > > Clearly there is some minimal filtering. We are not patch-o-matic 
> > > > robots.
> > > > And we take responsabilities for the changes we introduce. Personally 
> > > > if i
> > > > don't feel to comfortable in applying a patch, i rather prefer to check 
> > > > it
> > > > twice before inclusion. Specially because we will have to maintain it
> > > > during the time.
> > 
> > Sounds good, but as a matter of fact, the last couple of uploads all
> > contained more or less brown paper bag bugs.
> 
> I disagree with this assessment.  The last 2 brown paper bag bugs were in
> 4.3.0.dfsg.1-3, which was rushed to due to demand from DebConf, and
> 4.2.1-12 (which was just plain old stupidity).
> 
> Each saw prompt uploads to rectify the issue.
> 
> If you think something is a brown paper bag, speak up about it.  Noting it
> 2 weeks after the fact doesn't help us do a fast release.

I assumed the duplicate bug reports about the 'alt-tab problem' spoke
for themselves, or I might have sacrificed some of my ATM mostly non-
existing spare time to point it out.


-- 
Earthling Michel Dänzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer

Bug#258396: xlibmesa-gl-dev: Installation fails with unable to create `./usr/X11R6/lib/libGL.a': No such file or directory

[Sven Hoexter]

Package: xlibmesa-gl-dev
Version: 4.3.0.dfsg.1-6
Severity: important

Installation of all versions xlibmesa-gl-dev_4.3.0.dfsg.1-(4|5|6)
fails with the following error message:

dpkg -i xlibmesa-gl-dev_4.3.0.dfsg.1-6_i386.deb
(Reading database ... 136313 files and directories currently installed.)
Unpacking xlibmesa-gl-dev (from xlibmesa-gl-dev_4.3.0.dfsg.1-6_i386.deb) ...
dpkg: error processing xlibmesa-gl-dev_4.3.0.dfsg.1-6_i386.deb (--install):
 unable to create `./usr/X11R6/lib/libGL.a': No such file or directory
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
 xlibmesa-gl-dev_4.3.0.dfsg.1-6_i386.deb

With google I found a report on a mailinglist here:
http://lists.debian.org/debian-x/2004/03/msg03596.html
Output of ls -dl /usr /usr/X11R6 /usr/X11R6/lib is:
drwxr-xr-x   14 root root  368 May 18 08:47 /usr
drwxr-xr-x6 root root  144 Mar 29 20:07 /usr/X11R6
drwxr-xr-x4 root root 4240 Jul  9 13:30 /usr/X11R6/lib


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-bk16
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to de_DE)

Bug#256855: No option for Radeon cards

[Michel Dänzer]

On Thu, 2004-07-08 at 18:35 -0500, Branden Robinson wrote:
> On Tue, Jun 29, 2004 at 06:14:15PM +0200, Michel Dänzer wrote:
> > On Wed, 2004-06-30 at 00:52 +1000, Daniel Stone wrote:
> > > 
> > > If 'ati' doesn't work, then 'radeon' has no business working.
> > 
> > That's the theory, but the ati wrapper requires code of its own to
> > support the same chips as radeon does. Maybe that was missed for a patch
> > which adds support for newer Radeon chips. Been there, got bitten by
> > that. :\
> 
> Do we know that that's actually the case here?

We'd have to see server logs to be sure, but I can't think of another
reason why 'radeon' would work but not 'ati'.


-- 
Earthling Michel Dänzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer

Bug#256356: xserver-xfree86: X freezes the computer with 2.6.7 kernel

[Samuel Mimram]

> retitle 256356 xserver-xfree86: [ati/radeon] X server freezes computer
> with 2.6.7 kernel, but not 2.6.6 on Radeon Mobility M6 LY rev 0 tag
> 256356 + moreinfo thanks
> 
> On Sat, Jun 26, 2004 at 03:16:30PM +0200, Samuel Mimram wrote:
> > I have no problems running X under the 2.6.6 kernel (built from
> > Debian sources). However when I start it under a 2.6.7 kernel (built
> > from vanilla sources) there is a black screen when X starts and the 
> > computer is freezed (I am not able to switch to a console). I
> > believe this is related to the radeon driver:
> > - when I use the vesa driver or when I disable the hardware
> > acceleration (NoAccel option), X starts correctly
> > - when I enable hardware acceleration but I comment the line which
> > sets AGPMode to 4, X runs correctly for about 1 minute an then
> > freezes (I cannot switch to a console)
> > - when hardware acceleration is activated and AGPMode is set to 4 X 
> > freezes immediately
> > 
> > I did not find anything suspicious in the syslog but I might have
> > missed something. Feel free to tell me if you want me to do some
> > experiments, etc.
> 
> Can you tell me why you think this is an XFree86 bug, and not a kernel
> bug?


I don't really know and I have no way to know which one should be
incriminated. I have also posted a mail on the lkml about that but
nobody has replied to it.

Since I have no clue about that and it's xfree which takes 100% of the
CPU I decided to file a BR against xfree. If you think this is a kernel
bug you may reassign it.


Samuel.

-- 
Samuel Mimram

[EMAIL PROTECTED]



pgpcLnoRC1nhB.pgp
Description: PGP signature

Bug#257062: Please include the new intel driver

[Pedro Corte-Real]

On Thu, 2004-07-08 at 18:48 -0500, Branden Robinson wrote:
> On Wed, Jun 30, 2004 at 10:17:40PM +0100, Pedro Corte-Real wrote:
> > Package: xserver-xfree86
> > Version: 4.3.0.dfsg.1-5
> > Severity: wishlist
> > 
> > Keith Whitwell created a new driver for the intel graphics cards from
> > the i830 to the new i915. This driver supports more cards than the
> > existing one and according to the developers supports using the second
> > monitor (the external monitor on a laptop) as a different screen. Could
> > you please include this driver in the package?
> 
> We need to know if any part of it uses the new XFree86 1.1 license.  If so,
> we cannot include it.
> 
> Please see:
>   
> http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/local/FAQ.xhtml#xfree86license
> 
> for more information.
> 

I'll ask the developer, but since this is developed in the dri tree it
should be alright. Driver is at:

http://freedesktop.org/cgi-bin/viewcvs.cgi/mesa/Mesa/src/mesa/drivers/dri/i915/

So it's even in freedesktop.org so should be alright.

Pedro.


signature.asc
Description: This is a digitally signed message part

Bug#256863: This bug can probably be closed

[Bruce Stephens]

Branden Robinson <[EMAIL PROTECTED]> writes:

[...]

> I wonder if this would be explained by the following changelog entry:
>
> xfree86 (4.2.1-12) unstable; urgency=high
> [...]
>   * patch #097: new; add Bartosz Zapalowski's patch for supporting wheel mice
> with large numbers of buttons; the ZAxisMapping option "pushes up" the
> other buttons so that the mouse behaves sanely.  This addresses problems
> with how the X server parses wheel data from at least some devices that
> use the ExplorerPS/2 protocol. (Closes: #166550)
> [...]
>  -- Branden Robinson <[EMAIL PROTECTED]>  Tue, 30 Sep 2003 15:34:48 -0500

Could be that.  The changelog doesn't describe the behaviour I saw,
but it certainly looks like the right area of code.

> How recently did you notice this change in scroll wheel behavior?
> What version of the xfree86 packages were you running previously?

Very recently (in the last couple of weeks).  So September 2003
doesn't seem possible.  I've been running unstable for about a year,
(updating most days) so I've presumably been running 4.2.1-12 and
later for a long time.

xfree86_4.3.0.dfsg.1-6_powerpc.changes ACCEPTED

[Debian Installer]

Accepted:
lbxproxy_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/lbxproxy_4.3.0.dfsg.1-6_powerpc.deb
libdps-dev_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libdps-dev_4.3.0.dfsg.1-6_powerpc.deb
libdps1-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libdps1-dbg_4.3.0.dfsg.1-6_powerpc.deb
libdps1_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libdps1_4.3.0.dfsg.1-6_powerpc.deb
libice-dev_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libice-dev_4.3.0.dfsg.1-6_powerpc.deb
libice6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libice6-dbg_4.3.0.dfsg.1-6_powerpc.deb
libice6_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libice6_4.3.0.dfsg.1-6_powerpc.deb
libsm-dev_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libsm-dev_4.3.0.dfsg.1-6_powerpc.deb
libsm6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libsm6-dbg_4.3.0.dfsg.1-6_powerpc.deb
libsm6_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libsm6_4.3.0.dfsg.1-6_powerpc.deb
libx11-6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libx11-6-dbg_4.3.0.dfsg.1-6_powerpc.deb
libx11-6_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libx11-6_4.3.0.dfsg.1-6_powerpc.deb
libx11-dev_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libx11-dev_4.3.0.dfsg.1-6_powerpc.deb
libxaw6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxaw6-dbg_4.3.0.dfsg.1-6_powerpc.deb
libxaw6-dev_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxaw6-dev_4.3.0.dfsg.1-6_powerpc.deb
libxaw6_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxaw6_4.3.0.dfsg.1-6_powerpc.deb
libxaw7-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxaw7-dbg_4.3.0.dfsg.1-6_powerpc.deb
libxaw7-dev_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxaw7-dev_4.3.0.dfsg.1-6_powerpc.deb
libxaw7_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxaw7_4.3.0.dfsg.1-6_powerpc.deb
libxext-dev_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxext-dev_4.3.0.dfsg.1-6_powerpc.deb
libxext6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxext6-dbg_4.3.0.dfsg.1-6_powerpc.deb
libxext6_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxext6_4.3.0.dfsg.1-6_powerpc.deb
libxft1-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxft1-dbg_4.3.0.dfsg.1-6_powerpc.deb
libxft1_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxft1_4.3.0.dfsg.1-6_powerpc.deb
libxi-dev_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxi-dev_4.3.0.dfsg.1-6_powerpc.deb
libxi6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxi6-dbg_4.3.0.dfsg.1-6_powerpc.deb
libxi6_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxi6_4.3.0.dfsg.1-6_powerpc.deb
libxmu-dev_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxmu-dev_4.3.0.dfsg.1-6_powerpc.deb
libxmu6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxmu6-dbg_4.3.0.dfsg.1-6_powerpc.deb
libxmu6_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxmu6_4.3.0.dfsg.1-6_powerpc.deb
libxmuu-dev_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxmuu-dev_4.3.0.dfsg.1-6_powerpc.deb
libxmuu1-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxmuu1-dbg_4.3.0.dfsg.1-6_powerpc.deb
libxmuu1_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxmuu1_4.3.0.dfsg.1-6_powerpc.deb
libxp-dev_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxp-dev_4.3.0.dfsg.1-6_powerpc.deb
libxp6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxp6-dbg_4.3.0.dfsg.1-6_powerpc.deb
libxp6_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxp6_4.3.0.dfsg.1-6_powerpc.deb
libxpm-dev_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxpm-dev_4.3.0.dfsg.1-6_powerpc.deb
libxpm4-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxpm4-dbg_4.3.0.dfsg.1-6_powerpc.deb
libxpm4_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxpm4_4.3.0.dfsg.1-6_powerpc.deb
libxrandr-dev_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxrandr-dev_4.3.0.dfsg.1-6_powerpc.deb
libxrandr2-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxrandr2-dbg_4.3.0.dfsg.1-6_powerpc.deb
libxrandr2_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxrandr2_4.3.0.dfsg.1-6_powerpc.deb
libxt-dev_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxt-dev_4.3.0.dfsg.1-6_powerpc.deb
libxt6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxt6-dbg_4.3.0.dfsg.1-6_powerpc.deb
libxt6_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxt6_4.3.0.dfsg.1-6_powerpc.deb
libxtrap-dev_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxtrap-dev_4.3.0.dfsg.1-6_powerpc.deb
libxtrap6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxtrap6-dbg_4.3.0.dfsg.1-6_powerpc.deb
libxtrap6_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxtrap6_4.3.0.dfsg.1-6_powerpc.deb
libxtst-dev_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxtst-dev_4.3.0.dfsg.1-6_powerpc.deb
libxtst6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  to pool/main/x/xfree86/libxtst6-dbg_4

Re: Future of X packages in Debian

[Branden Robinson]

On Tue, Jul 06, 2004 at 07:51:36PM +1000, Daniel Stone wrote:
> On Mon, Jul 05, 2004 at 07:43:26PM -0500, Branden Robinson wrote:
> > On Thu, Jul 01, 2004 at 01:35:30PM +1000, Daniel Stone wrote:
> > > Yes, I indicated my extreme discomfort with the current XSF order. The
> > > current XSF order, however, is not necessarily something which need be
> > > set in stone, no?
> > 
> > No.  Did you have any reforms in mind beyond "give Daniel Stone as much
> > privilege as he wants?"
> 
> Yes.

Such as?

> Also, I do not want my name on the Uploaders or Maintainer field of the
> xfree86 source package.

But you do want it on the fields of packages that will replace xfree86, no?

-- 
G. Branden Robinson|Every aristocracy that has ever
Debian GNU/Linux   |existed has behaved, in all
[EMAIL PROTECTED] |essential points, exactly like a
http://people.debian.org/~branden/ |small mob.   -- G.K. Chesterton


signature.asc
Description: Digital signature

Re: Future of X packages in Debian

[Branden Robinson]

On Thu, Jul 08, 2004 at 11:48:24AM +1000, Daniel Stone wrote:
> On Wed, Jul 07, 2004 at 01:20:49PM -0500, Branden Robinson wrote:
> > On Wed, Jun 30, 2004 at 11:44:26PM +0200, Jonas Meurer wrote:
> > > On 30/06/2004 Branden Robinson wrote:
> > > > > Are you comfortable with an Uploaders: field for fd.o xlibs that
> > > > > includes myself?
> > > > 
> > > > I'm not sure *my* comfort level is the first-order term in this 
> > > > equation.
> > > > 
> > > > Quoting:
> > > > 
> > > > [...]
> > > > 
> > > > Daniel, disillusioned and disappoitned ex-'X Strike Force' member[1]
> 
> Artful dodge.

Not at all.  If you continue to stand by you words, I have no idea why
you'd even be interested in being on the same Uploaders: line as me.

Maybe you could explain it to me?

> > > is it required to be 'x strike force' member for uploading xlibs?
> > 
> > One normally doesn't hijack a package (or several of them) away from the
> > current maintainer.
> 
> xfree86, it should be noted, is one package.

It's not after it stops being monolithic.

> > The above does not apply, of course, to any parts of fd.o xlibs that aren't
> > already in Deebian.
> 
> Which is limited to libx{proto-,}{fixes,damage,composite}.

Okay.  But maintaining only those is not what you had in mind, is it?

> > The above *does* apply even if a given upstream package changes its
> > upstream source.  When the Xpm library was incorporated into XFree86
> > upstream, I expressed my interest in maintaining its packages as part of
> > XFree86 to the then-current maintainer.  AFAIR, he had no objection.
> 
> BTW, what you decided to do at a given time, isn't necessarily
> Debian-blessed practice.

So you're asserting that what I work out in mutual agreement with another
package maintainer, under a procedure countenanced by the Debian
Developers' Reference[1], "isn't necessarily Debian-blessed practice"?

Fascinating.

> Does Debian also bless uploading new major versions and adding yourself
> to Uploaders, when the previous one has been bitrotting in experimental
> for far too long?

Nope.

  It is not OK to simply take over a package that you feel is neglected —
  that would be package hijacking. You can, of course, contact the current
  maintainer and ask them if you may take over the package. If you have
  reason to believe a maintainer has gone AWOL (absent without leave), see
  Dealing with inactive and/or unreachable maintainers, Section 7.4.

  Generally, you may not take over the package without the assent of the
  current maintainer. Even if they ignore you, that is still not grounds to
  take over a package. Complaints about maintainers should be brought up on
  the developers' mailing list. If the discussion doesn't end with a
  positive conclusion, and the issue is of a technical nature, consider
  bringing it to the attention of the technical committee (see the
  technical committee web page for more information).[1]

A takeover is a takeover, be it for one release or forever.

> > If Mr. Stone feels there are exigent circumstances at work here, he should
> > say so.
> 
> Rather than going out and busting out phrases like 'exigent
> circumstances' and saying as much as possible between the lines[0],

> [0]: Which tends to be a great ploy to later jump out from behind some
> bushes and say 'WRONG! SUCK! I didn't say that!'.

If you want to avoid that, you should try harder not to put words into
people's mouths.  I've already caught you doing it once[2].

> would you like to share exactly what you think about a maintainership
> group for xlibs that includes myself?

I haven't decided yet.  More importantly, I'm not the sole decision maker
here.

A more fruitful tactic then tilting against my windmill with all this
impassioned rhetoric might be to organize a cadre of supporters among the
current X Strike Force.  Dare I defy them all?

If nothing else, the chance of greater personal satisfaction for you would
seem to be much higher.  (Not only would you get what you want, you'd get
to rub my nose in it!  Vindication could hardly be sweeter.)

[1] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-adopting
[2] Message-ID: <[EMAIL PROTECTED]>

-- 
G. Branden Robinson|  When dogma enters the brain, all
Debian GNU/Linux   |  intellectual activity ceases.
[EMAIL PROTECTED] |  -- Robert Anton Wilson
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: Future of X packages in Debian

[Branden Robinson]

On Tue, Jul 06, 2004 at 07:51:32PM +1000, Daniel Stone wrote:
> On Mon, Jul 05, 2004 at 07:40:32PM -0500, Branden Robinson wrote:
> > While it is true that only a fraction of these people actively use their
> > commit access, it is also true that only one of the approximately 15 people
> > who've ever had it did anything that required disciplinary action.
> 
> In the first instance, make an error of judgement and start reorganising
> package names based on a misunderstanding. I was very uncomfortable with
> that principle.

Error in judgement?  "My actions were a last-straw attempt to try and force
two issues, which were quite successfully forced."

Or were you referring to the earlier incident?

Neither sounds like an "error in judgement" to me; rather a plan of action
deliberately executed.

Besides which, the hijack upload of xfree86 was a far worse problem, and if
*that* wasn't the error in judgement, I'm not sure why the other one
matters.

> And, if you refuse to speak to me outside of the context of debian-x,

You have poor recall and even poorer quoting skills.

What I said was:
I will communicate with you on public mailing lists -- only.[1][2]

> how can I realistically avoid being so hideously wrong again?

But, what the hell, let's pretend I said "debian-x" instead of "public
mailing lists", since that seems to be your interpretation anyway:

What is it you expect to be hideously wrong about that both A) is not
germane to the debian-x mailing list; and B) would make any difference to
you or anyone else?

Be "hideously wrong" about international politics or the correct wording of
the Social Contract all you like; if it doesn't touch packages for which I
have responsibility in whole or part, it doesn't really matter much, does
it?

[1] Message-ID: <[EMAIL PROTECTED]>
[2] An exception would be bug reports against packages that I
maintain personally (i.e., not as part of the X Strike Force).  To date
that hasn't been an issue.  (XSF bug reports go to the -x list.)

-- 
G. Branden Robinson| "Why do we have to hide from the
Debian GNU/Linux   |  police, Daddy?"
[EMAIL PROTECTED] | "Because we use vi, son.  They use
http://people.debian.org/~branden/ |  emacs."


signature.asc
Description: Digital signature

Re: Future of X packages in Debian

[Branden Robinson]

On Tue, Jul 06, 2004 at 07:27:20AM +0200, Christian Perrier wrote:
> Quoting Branden Robinson ([EMAIL PROTECTED]):
> 
> > [EMAIL PROTECTED]:~$ grep xhackers /etc/group
> > xhackers:!:2000:branden,ishikawa,fabbione,jch,www-data,fenton,mdz,daenzer,mjg59,wt,rmh,dnusinow,bubulle,tretkowski
> > 
> > (www-data doesn't count.)
> > 
> > While it is true that only a fraction of these people actively use their
> 
> I'm afraid I'm not among this fraction of active people, for xfree86
> packages
> 
> I still need to figure this out properly as you have (and I perfectly
> understand this) very precise rule for commitslack of time, I'm
> afraid

If you mess up, I'll try to help you clean it up.  Most of the time I
expect it will be because I failed to document my expectations properly, so
don't worry too much about it.

> I could certainly help in sorting out l10n issues (debconf l10n at the
> minimum) if I can give some time to all this...:-)

If you're focusing on small-scale issues, I don't see how you can cause
all that much disruption.

What got me hacked off with Daniel Stone was:
1) his delegation of a significant package renaming decision to me,
   then revocation of that delegation (through a commit of his own
   approach) without warning less than a day later;
2) his quasi-hijack of the xfree86 package by uploading an NMU in violation
   of the NMU policy, without prior warning or consultation with anyone
   else[1], and without satisfying the published criteria for the package
   release

If you don't plan to behave as disruptively as the above, don't worry about
it.  Just do what you need and the rest of the group will help you figure
it out.  When in doubt, raise your plans to the mailing list first.  Not
taking people by surprise is a great way to earn trust.  :)

[1] ...that I've been able to determine from his public comments on the
subject.

-- 
G. Branden Robinson| Good judgement comes from
Debian GNU/Linux   | experience; experience comes from
[EMAIL PROTECTED] | bad judgement.
http://people.debian.org/~branden/ | -- Fred Brooks


signature.asc
Description: Digital signature

Processing of xfree86_4.3.0.dfsg.1-6_powerpc.changes

[Archive Administrator]

xfree86_4.3.0.dfsg.1-6_powerpc.changes uploaded successfully to localhost
along with the files:
  lbxproxy_4.3.0.dfsg.1-6_powerpc.deb
  libdps1_4.3.0.dfsg.1-6_powerpc.deb
  libdps1-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libdps-dev_4.3.0.dfsg.1-6_powerpc.deb
  libice6_4.3.0.dfsg.1-6_powerpc.deb
  libice6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libice-dev_4.3.0.dfsg.1-6_powerpc.deb
  libsm6_4.3.0.dfsg.1-6_powerpc.deb
  libsm6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libsm-dev_4.3.0.dfsg.1-6_powerpc.deb
  libx11-6_4.3.0.dfsg.1-6_powerpc.deb
  libx11-6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libx11-dev_4.3.0.dfsg.1-6_powerpc.deb
  libxaw6_4.3.0.dfsg.1-6_powerpc.deb
  libxaw6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libxaw6-dev_4.3.0.dfsg.1-6_powerpc.deb
  libxaw7_4.3.0.dfsg.1-6_powerpc.deb
  libxaw7-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libxaw7-dev_4.3.0.dfsg.1-6_powerpc.deb
  libxext6_4.3.0.dfsg.1-6_powerpc.deb
  libxext6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libxext-dev_4.3.0.dfsg.1-6_powerpc.deb
  libxft1_4.3.0.dfsg.1-6_powerpc.deb
  libxft1-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libxi6_4.3.0.dfsg.1-6_powerpc.deb
  libxi6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libxi-dev_4.3.0.dfsg.1-6_powerpc.deb
  libxmu6_4.3.0.dfsg.1-6_powerpc.deb
  libxmu6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libxmu-dev_4.3.0.dfsg.1-6_powerpc.deb
  libxmuu1_4.3.0.dfsg.1-6_powerpc.deb
  libxmuu1-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libxmuu-dev_4.3.0.dfsg.1-6_powerpc.deb
  libxp6_4.3.0.dfsg.1-6_powerpc.deb
  libxp6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libxp-dev_4.3.0.dfsg.1-6_powerpc.deb
  libxpm4_4.3.0.dfsg.1-6_powerpc.deb
  libxpm4-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libxpm-dev_4.3.0.dfsg.1-6_powerpc.deb
  libxrandr2_4.3.0.dfsg.1-6_powerpc.deb
  libxrandr2-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libxrandr-dev_4.3.0.dfsg.1-6_powerpc.deb
  libxt6_4.3.0.dfsg.1-6_powerpc.deb
  libxt6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libxt-dev_4.3.0.dfsg.1-6_powerpc.deb
  libxtrap6_4.3.0.dfsg.1-6_powerpc.deb
  libxtrap6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libxtrap-dev_4.3.0.dfsg.1-6_powerpc.deb
  libxtst6_4.3.0.dfsg.1-6_powerpc.deb
  libxtst6-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libxtst-dev_4.3.0.dfsg.1-6_powerpc.deb
  libxv1_4.3.0.dfsg.1-6_powerpc.deb
  libxv1-dbg_4.3.0.dfsg.1-6_powerpc.deb
  libxv-dev_4.3.0.dfsg.1-6_powerpc.deb
  proxymngr_4.3.0.dfsg.1-6_powerpc.deb
  twm_4.3.0.dfsg.1-6_powerpc.deb
  xbase-clients_4.3.0.dfsg.1-6_powerpc.deb
  xdm_4.3.0.dfsg.1-6_powerpc.deb
  xfs_4.3.0.dfsg.1-6_powerpc.deb
  xfwp_4.3.0.dfsg.1-6_powerpc.deb
  xlibmesa-dri_4.3.0.dfsg.1-6_powerpc.deb
  xlibmesa-dri-dbg_4.3.0.dfsg.1-6_powerpc.deb
  xlibmesa-gl_4.3.0.dfsg.1-6_powerpc.deb
  xlibmesa-gl-dbg_4.3.0.dfsg.1-6_powerpc.deb
  xlibmesa-gl-dev_4.3.0.dfsg.1-6_powerpc.deb
  xlibmesa-glu_4.3.0.dfsg.1-6_powerpc.deb
  xlibmesa-glu-dbg_4.3.0.dfsg.1-6_powerpc.deb
  xlibmesa-glu-dev_4.3.0.dfsg.1-6_powerpc.deb
  xlibosmesa4_4.3.0.dfsg.1-6_powerpc.deb
  xlibosmesa4-dbg_4.3.0.dfsg.1-6_powerpc.deb
  xlibosmesa-dev_4.3.0.dfsg.1-6_powerpc.deb
  xlibs-static-dev_4.3.0.dfsg.1-6_powerpc.deb
  xlibs-static-pic_4.3.0.dfsg.1-6_powerpc.deb
  xmh_4.3.0.dfsg.1-6_powerpc.deb
  xnest_4.3.0.dfsg.1-6_powerpc.deb
  xprt_4.3.0.dfsg.1-6_powerpc.deb
  xserver-common_4.3.0.dfsg.1-6_powerpc.deb
  xserver-xfree86_4.3.0.dfsg.1-6_powerpc.deb
  xserver-xfree86-dbg_4.3.0.dfsg.1-6_powerpc.deb
  xterm_4.3.0.dfsg.1-6_powerpc.deb
  xutils_4.3.0.dfsg.1-6_powerpc.deb
  xvfb_4.3.0.dfsg.1-6_powerpc.deb
  x-window-system-core_4.3.0.dfsg.1-6_powerpc.deb
  x-window-system-dev_4.3.0.dfsg.1-6_powerpc.deb
  xlibmesa3_4.3.0.dfsg.1-6_powerpc.deb

Greetings,

Your Debian queue daemon

Re: Future of X packages in Debian

[Branden Robinson]

On Thu, Jul 01, 2004 at 11:54:36PM +0200, Michel Dänzer wrote:
> > > Clearly there is some minimal filtering. We are not patch-o-matic robots.
> > > And we take responsabilities for the changes we introduce. Personally if i
> > > don't feel to comfortable in applying a patch, i rather prefer to check it
> > > twice before inclusion. Specially because we will have to maintain it
> > > during the time.
> 
> Sounds good, but as a matter of fact, the last couple of uploads all
> contained more or less brown paper bag bugs.

I disagree with this assessment.  The last 2 brown paper bag bugs were in
4.3.0.dfsg.1-3, which was rushed to due to demand from DebConf, and
4.2.1-12 (which was just plain old stupidity).

Each saw prompt uploads to rectify the issue.

If you think something is a brown paper bag, speak up about it.  Noting it
2 weeks after the fact doesn't help us do a fast release.

> It would be nice if those could be dealt with even more promptly, or even
> better prevented from happening in the first place. :)

People actually testing things when they're asked to would help.  :)

-- 
G. Branden Robinson|You should try building some of the
Debian GNU/Linux   |stuff in main that is
[EMAIL PROTECTED] |modern...turning on -Wall is like
http://people.debian.org/~branden/ |turning on the pain. -- James Troup


signature.asc
Description: Digital signature

keyboard not working under X,mouse works

[anand_12]

Hi all

 I am using a Debian system(2.4.20 kernel),P4 1.8 GHz
256 MB RAM/40 GB HDD and standard PS/2 keyboard and mouse.
My machine is shared by several users though I retain the root access.

 Normally I don't shut down my machine.I just log off.
Today when I tried logging in,the screen was blanking out for every key 
press.So the login was unsuccessful.

None of the keys were working.I could not open even other tty's ...i rebooted 
the machine..the problem persisted...
then i logged into my machine remotely...and issued a kill on X server...this 
gave the prompt on the screen..here all commands i typed worked perfectly 
fine..i have not lost any contents..i checked all my files..everything is 
fine...it is just none of my key presses are detected properly when i am inside 
x..otherwise..i am able to edit,compile and run programs...

one more thing..when i issue a startx command,i get the default display with 
all menus and contents(i use kde2)..also i am able to browse the contents of 
machine using the mouse(single click,right click etc)..but every key pressed on 
the keyboard blanks the screen..i don't understand whats going on...

my gdm.conf file says the server is attached to the standard VT7 terminal...

can anyone help me with this?

thanks a  bunch for any help in this regard.

V.Anand
(www.tenet.res.in)









-
  Trouble with windows? Re boot 
  Trouble with Linux? Be root

Bug#254563: xsm: does not see any clients

[Yann Dirson]

On Thu, Jul 08, 2004 at 01:19:30PM -0500, Branden Robinson wrote:
> Can you please provide some more information about this problem?
> 
> 1) Can you determine at least a ballpark figure of when this functionality
>broke?  The XSF hasn't been messing with session management, so my best
>guess would be that this broke upstream in 4.3.0.

I'm suspecting something like this, yes.

>The last 4.2.1
>packages are available for most architectures at snapshot.debian.net.
>  http://snapshot.debian.net/archive/2004/02/14/debian/pool/main/x/xfree86/
> 
>Please downgrade to that version (or install it in a chroot).

I'll try this, but will not have time this next week.

> 2) Can you provide a recipe for reproducing this problem?  I have to admit
>I don't use xsm myself.

Set your .xsession or whatever so that it runs eg. fvwm in the
backround, then xsm as session program.

Then when you run session-aware programs, you should see them in the
window open when you click on "client list" in the xsm button.  This
includes at least xterm, xemacs, galeon, xchat - I guess all gnome and
kde programs should be seen as well.

-- 
Yann Dirson<[EMAIL PROTECTED]> |
Debian-related: <[EMAIL PROTECTED]> |   Support Debian GNU/Linux:
|  Freedom, Power, Stability, Gratis
 http://ydirson.free.fr/| Check 

Processed: RUUUUAHHHRRR! HATE THE BTS! STUPID BTS!

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> unmerge 246782
Bug#246782: xserver-xfree86: [core server] fix domain-based PCI detection
Bug#225526: xserver-xfree86: [core server] domain-based PCI probing doesn't 
work on UltraSPARCs running Linux 2.6
Disconnected #246782 from all other report(s).

> reopen 246782
Bug#246782: xserver-xfree86: [core server] fix domain-based PCI detection
Bug reopened, originator not changed.

> retitle 246782 xserver-xfree86: PCI domain detection still doesn't work for me
Bug#246782: xserver-xfree86: [core server] fix domain-based PCI detection
Changed Bug title.

> tag 246782 = moreinfo unreproducible upstream
Bug#246782: xserver-xfree86: PCI domain detection still doesn't work for me
Tags were: patch upstream
Tags set to: moreinfo, unreproducible, upstream

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Bug#254923: xserver-xfree86: [keyboard] alt key not working when starting from display manager

[Branden Robinson]

On Wed, Jul 07, 2004 at 04:19:43PM +0200, JOSE MIGUEL MARTINEZ wrote:
> I have already fixed it setting up correctly kde keyboard preferences 
> (105keys keyboard) and XFree Config. I think after a lot of testing 
> some clients were changing keyboard (kde control panel) in my sessions 
> and I am not sure if some xfree86 upgrade had something to do too, but 
> now It works for me with no hacking, just configuring X and kde. :-) 

Glad to hear it!

-- 
G. Branden Robinson|Men use thought only to justify
Debian GNU/Linux   |their wrong doings, and speech only
[EMAIL PROTECTED] |to conceal their thoughts.
http://people.debian.org/~branden/ |-- Voltaire


signature.asc
Description: Digital signature

Processed: Re: Bug#258349: metacity: Changing workspaces with keys still requires a mouse click.

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> close 258349
Bug#258349: metacity: Changing workspaces with keys still requires a mouse 
click.
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to Nathan Hurst <[EMAIL PROTECTED]>

> merge 258349 254923
Bug#254923: xserver-xfree86: [keyboard] alt key not working when starting from 
display manager
Bug#258349: metacity: Changing workspaces with keys still requires a mouse 
click.
Bug#254973: metacity: Alt-Tab doesn't works
Bug#255063: capplets: Problem with keyboard shortcuts containing 
Bug#255192: Alt-Tab switching broken in dfsg.1-5
Bug#255216: kwin: alt+tab does not work shen tab is released first
Bug#255332: kde: hangs when switching windows with alt+tab
Bug#255467: FocusOut event instead KeyRelease
Bug#255778: metacity: Desktop list doesn't disappear after switching desktops 
with arrow
Bug#256192: xlibs: Alt_L is seen like a normal key instead a modifier [it]
Bug#256594: metacity: alt-tab doesn't change focus on release
Bug#256596: metacity: Tab does not switch windows, other keybindings does
Bug#256875: metacity: Alt-Tab fails to actually change windows
Bug#256939: metacity: alt+tab does not work
Bug#257044: gnome-core: Alt keys not being treated as meta keys
Bug#257294: desktop switcher stays visible
Bug#257305: metacity: Alt-Tab brings up popup, but won't switch to other apps
Bug#257454: desktop switcher stays on top
Bug#257498: capplets: Alt-Tab no longer working properly (Alt "sticking"?)
Bug#258003: metacity: Alt-tab switches window but doesn't give focus
Bug#258054: metacity: Cycle window does not work anymore.
Bug#258231: Window switching keys don't seem to actually switch windows
Merged 254923 254973 255063 255192 255216 255332 255467 255778 256192 256594 
256596 256875 256939 257044 257294 257305 257454 257498 258003 258054 258231 
258349.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Re: status of 2.6.7 ?

[Sven Luther]

On Thu, Jul 08, 2004 at 06:44:45PM -0500, Branden Robinson wrote:
> [I am not subscribed to debian-kernel.]
> 
> On Wed, Jun 30, 2004 at 09:06:39PM +0200, Sven Luther wrote:
> > On Wed, Jun 30, 2004 at 04:57:12PM +, Andreas Metzler wrote:
> > > * XFree starts treating /dev/psaux and /dev/input/mice equally if both
> > >   are listed, i.e. it will work if _either_ of them are accessible
> > >   instead of insiting on the primary one.
> > 
> > A huge XFree86 Change probably, i don't know that code so well, so am
> > CCing debian-x for advice.
> 
> No, just a bit of (attempted) cleverness in the generated XF86Config-4
> files.

Mmm, i think there is a misunderstanding here (maybe on my part).
Existing XF86Config-4 files will have this "cleverness" like you say
already generated, and thus break if there is no /dev/psaux as core
pointer.

The Huge change i was refering to was to have XFree86 be happy, even if
there is no corepointer detected, or be having more than one core
pointer.

Alternatively, it should (maybe) be possible to have /dev/input/mice be
the corepointer, and /dev/psaux sending core events. The
/dev/input/mice, in my understanding, will be available even if there is
no device attached to it, which is not the case of /dev/psaux.

Friendly,

Sven Luther

Processed: Re: Bug#258349: metacity: Changing workspaces with keys still requires a mouse click.

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 258349 xlibs
Bug#258349: metacity: Changing workspaces with keys still requires a mouse 
click.
Bug reassigned from package `metacity' to `xlibs'.

> severity 258349 serious
Bug#258349: metacity: Changing workspaces with keys still requires a mouse 
click.
Severity set to `serious'.

> tags 258349 + fixed-upstream patch sid upstream
Bug#258349: metacity: Changing workspaces with keys still requires a mouse 
click.
There were no tags set.
Tags added: fixed-upstream, patch, sid, upstream

> merge 258349 254923
Bug#254923: xserver-xfree86: [keyboard] alt key not working when starting from 
display manager
Bug#258349: metacity: Changing workspaces with keys still requires a mouse 
click.
Mismatch - only Bugs in same state can be merged:
Values for `done mark' don't match:
 #254923 has `done';
 #258349 has `open'

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Bug#257023: xlibs: xkbd-data not installed by default, should not be part of a dummy/meta package

[Andreas Metzler]

On 2004-07-09 Branden Robinson <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 30, 2004 at 04:36:48PM +0200, Andreas Metzler wrote:
> > Package: xlibs
> > Version: 4.3.0.dfsg.1-4
> > Severity: important
> > 
> > Hello,
> > I've just made a fresh sarge installation (without tasksel) and ended up
> > without xkbd data because xlibs is not depended on by any package
> > (including x-window-system-core).

> I'm sorry, but this is simply false.  Five packages in xfree86 depend on
> xlibs-data.
[5 examples for packages depending on /xlibs-data/ ]

Please reread. I was not talking about xlibs-data but about *xlibs*.

---
downhill:~# apt-get -s remove xlibs
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
  acroread asclock auctex doomlegacy-x11 efax-gtk emacs21 eterm feh fsviewer
  fsviewer-icons gcvs gdk-imlib1 geg gettext-el gtk-engines-raleigh gtkfontsel
  gv html2ps imagemagick imlib-progs imlib1 krecord libast2 libdockapp-dev
  libdockapp1 libgd-gd1-perl libgd-text-perl libgdk-pixbuf-dev libgdk-pixbuf2
  libgtk-imlib-perl libmagick++5.5.7 libmagick5.5.7 libplot2 libpstoedit0
  libwmf0.2-7 lincity mixer.app mtr perlmagick preview-latex pstoedit qiv
  quintuple-agent realplayer rxvt slrnface ssh-askpass t1lib1 tk8.3 tk8.4
  tkcvs tkdiff tkinfo tvtime w3m-img wmmount wv xaw3dg xcolors xemacs21
  xemacs21-bin xemacs21-nomule xemacs21-support xemacs21-supportel xfig xlibs
  xmms-wmdiscotux
---
As you can see these are simply packages that have not been rebuilt
since xlibs was split and therefore _only_ depend on xlibs.

   cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

X Strike Force XFree86 SVN commit: r1608 - in trunk/debian: . local

[X Strike Force SVN Repository Admin]

Author: branden
Date: 2004-07-09 00:12:05 -0500 (Fri, 09 Jul 2004)
New Revision: 1608

Modified:
   trunk/debian/CHANGESETS
   trunk/debian/local/FAQ.xhtml
Log:
(cosmetic) Add some markup.


Modified: trunk/debian/CHANGESETS
===
--- trunk/debian/CHANGESETS 2004-07-09 05:10:18 UTC (rev 1607)
+++ trunk/debian/CHANGESETS 2004-07-09 05:12:05 UTC (rev 1608)
@@ -13,6 +13,6 @@
 1606
 
 Miscellaneous cosmetic fixes.
-1607
+1607, 1608
 
 vim:set ai et sts=4 sw=4 tw=80:

Modified: trunk/debian/local/FAQ.xhtml
===
--- trunk/debian/local/FAQ.xhtml2004-07-09 05:10:18 UTC (rev 1607)
+++ trunk/debian/local/FAQ.xhtml2004-07-09 05:12:05 UTC (rev 1608)
@@ -101,8 +101,9 @@
   of readable text, some characters appear as little gray boxes.  Why?
 Why does the X server take up so much
   memory?
-Why do the menus in xterm have the wrong font,
-  size, background color, or foregound color?
+Why do the menus in xterm have the wrong font, size, background color, or
+  foregound color?
 I just upgraded the X server and it doesn't
   work; also, I'm using Matrox's proprietary mga_hal
   driver module or NVidia's proprietary nvidia 
driver
@@ -1925,13 +1926,15 @@
   kernel sources which implement it is about the best manual I know of.
 
 
-Why do the menus in xterm have the wrong font,
-size, background color, or foregound color?
+Why do the menus in xterm have the wrong font, size, background color, or
+  foregound color?
 
 Because, 99 times out of 100, you're not using X resources correctly.
 
-If you have X resource specifications (say, in your $HOME/.Xresources file)
-that look like this:
+If you have X resource specifications (say, in your $HOME/.Xresources file) that look like
+this:
 
 XTerm*foreground: black
 XTerm*background: white
@@ -1940,13 +1943,13 @@
 
 ...then be aware that you are, in fact, telling the menus, not just the
 VT100 widget, to use the 10x20 font with white-on-black text.  That
-asterisk is a wildcard, not an ordinary separator.  XTerm is doing exactly
-what you are telling it to do.  If you find X resources confusing, don't
-use them, or read the "RESOURCES" section of the X(7x) manual page.
+asterisk is a wildcard, not an ordinary separator.  xterm is doing exactly what you are telling it to do.  
If
+you find X resources confusing, don't use them, or read the "RESOURCES" section
+of the X(7x) manual page.
 
-If you want to set X resources for xterm that affect only its VT100 widget,
-then you need to say so:
+If you want to set X resources for xterm that
+affect only its VT100 widget, then you need to say so:
 
 XTerm.VT100.background: white
 XTerm.VT100.foreground: black

X Strike Force XFree86 SVN commit: r1607 - trunk/debian

[X Strike Force SVN Repository Admin]

Author: branden
Date: 2004-07-09 00:10:18 -0500 (Fri, 09 Jul 2004)
New Revision: 1607

Modified:
   trunk/debian/CHANGESETS
   trunk/debian/changelog
Log:
Credit myself for changes where I forgot to add this notation (including
the changelog entry for 4.3.0.dfsg.1-5).  Whoops.


Modified: trunk/debian/CHANGESETS
===
--- trunk/debian/CHANGESETS 2004-07-08 22:59:29 UTC (rev 1606)
+++ trunk/debian/CHANGESETS 2004-07-09 05:10:18 UTC (rev 1607)
@@ -12,4 +12,7 @@
 (Closes: #256360)
 1606
 
+Miscellaneous cosmetic fixes.
+1607
+
 vim:set ai et sts=4 sw=4 tw=80:

Modified: trunk/debian/changelog
===
--- trunk/debian/changelog  2004-07-08 22:59:29 UTC (rev 1606)
+++ trunk/debian/changelog  2004-07-09 05:10:18 UTC (rev 1607)
@@ -1,5 +1,7 @@
 xfree86 (4.3.0.dfsg.1-6+SVN) unstable; urgency=low
 
+  Changes by Branden Robinson:
+
   * Update Turkish debconf template translations (thanks, Recai Oktas).
 (Closes: #256360)
 
@@ -7,6 +9,8 @@
 
 xfree86 (4.3.0.dfsg.1-6) unstable; urgency=low
 
+  Changes by Branden Robinson:
+
   * Apply patch by David S. Miller via Ben Collins to add RENDER and X
 Acceleration Architecture (XAA) support to the Sun FFB driver, and use FB
 framebuffer layer instead of MFB and CFB.  (Closes: #245246)