Bug#187237: xserver-xfree86: [savage] strange display problems after upgrade

[Alex Krauss]

Package: xserver-xfree86
Version: 4.2.1-6
Severity: important
Tags: sid


After upgrading to 4.2.1-6, the savage driver stopped working for
me. The X-server still starts up normally, but many parts of the
display (including fonts and filled-rectangles) are not rendered at
all.  

from output of lspci:
01:01.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV
(rev 11)


Switching to "vesa" as display driver solves the problem, so I am
quite sure it is not a kde or other problem...








-- Package-specific info:
01:01.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 11)
01:01.0 Class 0300: 5333:8c12 (rev 11)

### BEGIN DEBCONF SECTION
# XF86Config-4 (XFree86 server configuration file) generated by dexconf, the
# Debian X Configuration tool, using values from the debconf database.
#
# Edit this file with caution, and see the XF86Config-4 manual page.
# (Type "man XF86Config-4" at the shell prompt.)
#
# If you want your changes to this file preserved by dexconf, only make changes
# before the "### BEGIN DEBCONF SECTION" line above, and/or after the
# "### END DEBCONF SECTION" line below.
#
# To change things within the debconf section, run the command:
#   dpkg-reconfigure xserver-xfree86
# as root.  Also see "How do I add custom sections to a dexconf-generated
# XF86Config or XF86Config-4 file?" in /usr/share/doc/xfree86-common/FAQ.gz.

Section "Files"
FontPath"unix/:7100"# local font server
# if the local font server has problems, we can fall back on these
FontPath"/usr/lib/X11/fonts/Type1"
FontPath"/usr/lib/X11/fonts/CID"
FontPath"/usr/lib/X11/fonts/Speedo"
FontPath"/usr/lib/X11/fonts/misc"
FontPath"/usr/lib/X11/fonts/cyrillic"
FontPath"/usr/lib/X11/fonts/100dpi"
FontPath"/usr/lib/X11/fonts/75dpi"
EndSection

Section "Module"
Load"GLcore"
Load"bitmap"
Load"dbe"
Load"ddc"
Load"dri"
Load"extmod"
Load"freetype"
Load"glx"
Load"int10"
Load"record"
Load"speedo"
Load"type1"
Load"vbe"
EndSection

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "keyboard"
Option  "CoreKeyboard"
Option  "XkbRules"  "xfree86"
Option  "XkbModel"  "pc104"
Option  "XkbLayout" "de"
Option  "XkbVariant""nodeadkeys"
EndSection

Section "InputDevice"
Identifier  "Configured Mouse"
Driver  "mouse"
Option  "CorePointer"
Option  "Device""/dev/psaux"
Option  "Protocol"  "PS/2"
Option  "Emulate3Buttons"   "true"
Option  "ZAxisMapping"  "4 5"
EndSection

Section "InputDevice"
Identifier  "Generic Mouse"
Driver  "mouse"
Option  "SendCoreEvents""true"
Option  "Device""/dev/input/mice"
Option  "Protocol"  "ImPS/2"
Option  "Emulate3Buttons"   "true"
Option  "ZAxisMapping"  "4 5"
EndSection

Section "Device"
Identifier  "Generic Video Card"
Driver  "vesa"
Option  "UseFBDev"  "true"
EndSection

Section "Monitor"
Identifier  "Generic Monitor"
HorizSync   28-38
VertRefresh 43-72
Option  "DPMS"
EndSection

Section "Screen"
Identifier  "Default Screen"
Device  "Generic Video Card"
Monitor "Generic Monitor"
DefaultDepth24
SubSection "Display"
Depth   1
Modes   "800x600"
EndSubSection
SubSection "Display"
Depth   4
Modes   "800x600"
EndSubSection
SubSection "Display"
Depth   8
Modes   "800x600"
EndSubSection
SubSection "Display"
Depth   15
Modes   "800x600"
EndSubSection
SubSection "Display"
Depth   16
Modes   "800x600"
EndSubSection
SubSection "Display"
Depth   24
Modes   "800x600"
EndSubSection
EndSection

Section "ServerLayout"
Identifier  "Default Layout"
Screen  "Default Screen"
InputDevice "Generic Keyboard"
InputDevice "Configured Mouse"
InputDevice "Generic Mouse"
EndSection

Section "DRI"
Mode0666
EndSection

### END DEBCONF SECTION


This is a pre-release version of XFre

gnome-randr-applet and Xfree86 4.3.0 ...

[Sven Luther]

Hello, ...

I have packaged GRandrApplet (renamed gnome-randr-applet) which is an
applet for changing the resolution using the randr extension.

Now, this will work (and build) only with the 4.3.0 version of X, as the
randr is not supported in earlier versions.

So i have added a build-dependency on xlibs-dev (>> 4.3.0), and added a
shlibs override to make the dependency of libXrandr be xlibs (>> 4.3.0).

So, what am i to do with this package ? If i upload it, it will not be
installeable with the current debian unstable, but will work with
daniel stone's X packages. It will also fail to build for all the
autobuilders, as there is no 4.3.0 package.

That said, it will still be of value for all debian's users which uses
daniel stone's 4.3.0 package, or maybe even for those who run self built
4.3.0 packages (altough they would need to override the dependencies),
and i think there is value of having it in the archive (be it only so
other people don't repackage it and such). And anyway, this package will
not enter testing until XFree86 4.3.0 does.

Also, i think there is plan for packaging 4.3.0 for sarge, isn't it ? Or
will the time to the sarge release be to short for that ?

Friendly,

Sven Luther

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Daniel Stone]

On Wed, Apr 02, 2003 at 11:32:24AM +0200, Sven Luther scrawled:
> Now, this will work (and build) only with the 4.3.0 version of X, as the
> randr is not supported in earlier versions.
> 
> So i have added a build-dependency on xlibs-dev (>> 4.3.0), and added a
> shlibs override to make the dependency of libXrandr be xlibs (>> 4.3.0).
> 
> So, what am i to do with this package ? If i upload it, it will not be
> installeable with the current debian unstable, but will work with
> daniel stone's X packages. It will also fail to build for all the
> autobuilders, as there is no 4.3.0 package.
> 
> That said, it will still be of value for all debian's users which uses
> daniel stone's 4.3.0 package, or maybe even for those who run self built
> 4.3.0 packages (altough they would need to override the dependencies),
> and i think there is value of having it in the archive (be it only so
> other people don't repackage it and such). And anyway, this package will
> not enter testing until XFree86 4.3.0 does.
> 
> Also, i think there is plan for packaging 4.3.0 for sarge, isn't it ? Or
> will the time to the sarge release be to short for that ?

Package it in an external repository for the time being, and release it
out to sid when 4.3.0 hits sid; there's really no other way to do it.

Ralf Nolden has done a woody backport of my packages, but IIRC sarge is
glibc 2.3 now, so the sid packages will probably work.

-- 
Daniel Stone <[EMAIL PROTECTED]>
Developer, Trinity College, University of Melbourne


pgpuCn73sBnCy.pgp
Description: PGP signature

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Sven Luther]

On Wed, Apr 02, 2003 at 08:02:12PM +1000, Daniel Stone wrote:
> On Wed, Apr 02, 2003 at 11:32:24AM +0200, Sven Luther scrawled:
> > Now, this will work (and build) only with the 4.3.0 version of X, as the
> > randr is not supported in earlier versions.
> > 
> > So i have added a build-dependency on xlibs-dev (>> 4.3.0), and added a
> > shlibs override to make the dependency of libXrandr be xlibs (>> 4.3.0).
> > 
> > So, what am i to do with this package ? If i upload it, it will not be
> > installeable with the current debian unstable, but will work with
> > daniel stone's X packages. It will also fail to build for all the
> > autobuilders, as there is no 4.3.0 package.
> > 
> > That said, it will still be of value for all debian's users which uses
> > daniel stone's 4.3.0 package, or maybe even for those who run self built
> > 4.3.0 packages (altough they would need to override the dependencies),
> > and i think there is value of having it in the archive (be it only so
> > other people don't repackage it and such). And anyway, this package will
> > not enter testing until XFree86 4.3.0 does.
> > 
> > Also, i think there is plan for packaging 4.3.0 for sarge, isn't it ? Or
> > will the time to the sarge release be to short for that ?
> 
> Package it in an external repository for the time being, and release it
> out to sid when 4.3.0 hits sid; there's really no other way to do it.

Why not just upload it to sid (it is already in the NEW queue btw), it
will not be installable for people not using 4.3.0 so it will not break
anything for anyone. How do i make it visible that i have packaged it if
nobody can see it ? Should i make a wnpp ITP bugreport and give the link
to the repository in it ?

> Ralf Nolden has done a woody backport of my packages, but IIRC sarge is
> glibc 2.3 now, so the sid packages will probably work.

I don't care about woody. I just want the package to be available for
whoever can use it, if someone wants to make a woody backport, fine for
him.

That said, i am a bit worried about XFree86 4.3.0 and sarge, 4.2.1 is
not yet ready for sarge, and if a release/freeze for around july is
planned, this let's little time to fully test 4.3.0, which seems to be
already somewhat obsolet by now, if you consider all the flaming in
upstreams xfree86-forum mailing list.

BTW, when i first login into X, and open an xterm, and try to type into
it, i get some garbage characters (either just a c, or a succession of
cs). Is this a known bug or something ?

Friendly,

Sven Luther

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Daniel Stone]

On Wed, Apr 02, 2003 at 12:18:08PM +0200, Sven Luther scrawled:
> Why not just upload it to sid (it is already in the NEW queue btw), it
> will not be installable for people not using 4.3.0 so it will not break
> anything for anyone. How do i make it visible that i have packaged it if
> nobody can see it ? Should i make a wnpp ITP bugreport and give the link
> to the repository in it ?

Well, it'll break the buildds, and be uninstallable in sid. That makes
it either contrib or experimental removal. I suggest ITPing it and
linking to your repository for the time being. The ftpmasters won't
accept it, I can guarantee that now.

> > Ralf Nolden has done a woody backport of my packages, but IIRC sarge is
> > glibc 2.3 now, so the sid packages will probably work.
> 
> I don't care about woody. I just want the package to be available for
> whoever can use it, if someone wants to make a woody backport, fine for
> him.

Fair enough.

> That said, i am a bit worried about XFree86 4.3.0 and sarge, 4.2.1 is
> not yet ready for sarge, and if a release/freeze for around july is
> planned, this let's little time to fully test 4.3.0, which seems to be
> already somewhat obsolet by now, if you consider all the flaming in
> upstreams xfree86-forum mailing list.

Well, considering it's the best we have to work with right now, that's
what we're running with.

> BTW, when i first login into X, and open an xterm, and try to type into
> it, i get some garbage characters (either just a c, or a succession of
> cs). Is this a known bug or something ?

Not that I know of, and certainly not without more info.

-- 
Daniel Stone <[EMAIL PROTECTED]>
Developer, Trinity College, University of Melbourne


pgpADSHbtR2o0.pgp
Description: PGP signature

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Sven Luther]

On Wed, Apr 02, 2003 at 08:41:57PM +1000, Daniel Stone wrote:
> On Wed, Apr 02, 2003 at 12:18:08PM +0200, Sven Luther scrawled:
> > Why not just upload it to sid (it is already in the NEW queue btw), it
> > will not be installable for people not using 4.3.0 so it will not break
> > anything for anyone. How do i make it visible that i have packaged it if
> > nobody can see it ? Should i make a wnpp ITP bugreport and give the link
> > to the repository in it ?
> 
> Well, it'll break the buildds, and be uninstallable in sid. That makes
> it either contrib or experimental removal. I suggest ITPing it and
> linking to your repository for the time being. The ftpmasters won't
> accept it, I can guarantee that now.

I can let it sit in the NEW queue though, or should i ask for its
removal ? What about uploading it to experimental instead or something
such ?

> > > Ralf Nolden has done a woody backport of my packages, but IIRC sarge is
> > > glibc 2.3 now, so the sid packages will probably work.
> > 
> > I don't care about woody. I just want the package to be available for
> > whoever can use it, if someone wants to make a woody backport, fine for
> > him.
> 
> Fair enough.
> 
> > That said, i am a bit worried about XFree86 4.3.0 and sarge, 4.2.1 is
> > not yet ready for sarge, and if a release/freeze for around july is
> > planned, this let's little time to fully test 4.3.0, which seems to be
> > already somewhat obsolet by now, if you consider all the flaming in
> > upstreams xfree86-forum mailing list.
> 
> Well, considering it's the best we have to work with right now, that's
> what we're running with.

I am not sure i really understood you here, you are saying that 4.2.1 is
the best we have, and we have to make do with it, right ?

I think the main problem here is that debian has been playing catchup
since i joined in 1998 at least for X. It would be refreshing that it be
otherwise, but i guess we just don't have the manpower for it, right. We
could very well decide to drop 4.2.1 and go with 4.3.0 for unstable,
even before 4.3.0 was released, and have more of our patches be
incorporated upstream before the release. Such a thing would be
especially important if the XFree86 project will go for more frequent
releases, like the discussion on the future of X on the xforum mailing
list seems to hint at. I also don't see anyone from the debian X team on
that list, but maybe i have missed it, the list being rather high volume
after all.

> > BTW, when i first login into X, and open an xterm, and try to type into
> > it, i get some garbage characters (either just a c, or a succession of
> > cs). Is this a known bug or something ?
> 
> Not that I know of, and certainly not without more info.

What kind of info would be needed ?

Friendly,

Sven Luther

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Daniel Stone]

On Wed, Apr 02, 2003 at 12:53:19PM +0200, Sven Luther scrawled:
> On Wed, Apr 02, 2003 at 08:41:57PM +1000, Daniel Stone wrote:
> > On Wed, Apr 02, 2003 at 12:18:08PM +0200, Sven Luther scrawled:
> > > Why not just upload it to sid (it is already in the NEW queue btw), it
> > > will not be installable for people not using 4.3.0 so it will not break
> > > anything for anyone. How do i make it visible that i have packaged it if
> > > nobody can see it ? Should i make a wnpp ITP bugreport and give the link
> > > to the repository in it ?
> > 
> > Well, it'll break the buildds, and be uninstallable in sid. That makes
> > it either contrib or experimental removal. I suggest ITPing it and
> > linking to your repository for the time being. The ftpmasters won't
> > accept it, I can guarantee that now.
> 
> I can let it sit in the NEW queue though, or should i ask for its
> removal ? What about uploading it to experimental instead or something
> such ?

I really don't know; that's up to you.

> > > That said, i am a bit worried about XFree86 4.3.0 and sarge, 4.2.1 is
> > > not yet ready for sarge, and if a release/freeze for around july is
> > > planned, this let's little time to fully test 4.3.0, which seems to be
> > > already somewhat obsolet by now, if you consider all the flaming in
> > > upstreams xfree86-forum mailing list.
> > 
> > Well, considering it's the best we have to work with right now, that's
> > what we're running with.
> 
> I am not sure i really understood you here, you are saying that 4.2.1 is
> the best we have, and we have to make do with it, right ?

Well, considering 4.3.0 only runs on i386/powerpc/sparc/ia64/alpha at
the moment, and s390/hurd-i386 support is in the works, it still has a
way to go. Getting a complete 4.2.1 is an admirable goal, *just in case*
4.3 doesn't make it to sarge.

> I think the main problem here is that debian has been playing catchup
> since i joined in 1998 at least for X. It would be refreshing that it be
> otherwise, but i guess we just don't have the manpower for it, right. We
> could very well decide to drop 4.2.1 and go with 4.3.0 for unstable,
> even before 4.3.0 was released, and have more of our patches be
> incorporated upstream before the release. Such a thing would be
> especially important if the XFree86 project will go for more frequent
> releases, like the discussion on the future of X on the xforum mailing
> list seems to hint at. I also don't see anyone from the debian X team on
> that list, but maybe i have missed it, the list being rather high volume
> after all.

The problem is that we have by far the best packages of any
distribution, with RedHat our closest competitor in this regard. They're
of an amazingly high quality, and XFree86 upstream releases aren't;
they're code drops that don't work on anything other than i386/powerpc,
usually, and half the time they're even severely brokenn on i386.
Porting it to other architectures is quite a monumental task, so having
4.3.0 as far as we have it is quite a great achievement IMHO.

I've personally stayed silent because that discussion is largely full of
vested political interests, and looks likely to go nowhere. I'm waiting
until real code comes forth.

> > > BTW, when i first login into X, and open an xterm, and try to type into
> > > it, i get some garbage characters (either just a c, or a succession of
> > > cs). Is this a known bug or something ?
> > 
> > Not that I know of, and certainly not without more info.
> 
> What kind of info would be needed ?

XF86Config-4, XFree86.0.log.

-- 
Daniel Stone <[EMAIL PROTECTED]>
Developer, Trinity College, University of Melbourne


pgpf9VcxFHS1b.pgp
Description: PGP signature

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Sven Luther]

On Wed, Apr 02, 2003 at 09:21:31PM +1000, Daniel Stone wrote:
> > > > That said, i am a bit worried about XFree86 4.3.0 and sarge, 4.2.1 is
> > > > not yet ready for sarge, and if a release/freeze for around july is
> > > > planned, this let's little time to fully test 4.3.0, which seems to be
> > > > already somewhat obsolet by now, if you consider all the flaming in
> > > > upstreams xfree86-forum mailing list.
> > > 
> > > Well, considering it's the best we have to work with right now, that's
> > > what we're running with.
> > 
> > I am not sure i really understood you here, you are saying that 4.2.1 is
> > the best we have, and we have to make do with it, right ?
> 
> Well, considering 4.3.0 only runs on i386/powerpc/sparc/ia64/alpha at
> the moment, and s390/hurd-i386 support is in the works, it still has a
> way to go. Getting a complete 4.2.1 is an admirable goal, *just in case*
> 4.3 doesn't make it to sarge.

Yes, sure, but we will get flamed for being out of date.

> > I think the main problem here is that debian has been playing catchup
> > since i joined in 1998 at least for X. It would be refreshing that it be
> > otherwise, but i guess we just don't have the manpower for it, right. We
> > could very well decide to drop 4.2.1 and go with 4.3.0 for unstable,
> > even before 4.3.0 was released, and have more of our patches be
> > incorporated upstream before the release. Such a thing would be
> > especially important if the XFree86 project will go for more frequent
> > releases, like the discussion on the future of X on the xforum mailing
> > list seems to hint at. I also don't see anyone from the debian X team on
> > that list, but maybe i have missed it, the list being rather high volume
> > after all.
> 
> The problem is that we have by far the best packages of any
> distribution, with RedHat our closest competitor in this regard. They're
> of an amazingly high quality, and XFree86 upstream releases aren't;
> they're code drops that don't work on anything other than i386/powerpc,
> usually, and half the time they're even severely brokenn on i386.
> Porting it to other architectures is quite a monumental task, so having
> 4.3.0 as far as we have it is quite a great achievement IMHO.

Yes, sure, but it is a fork, and thus more work.

> I've personally stayed silent because that discussion is largely full of
> vested political interests, and looks likely to go nowhere. I'm waiting
> until real code comes forth.

:)))

I was one of the first to post in the list, and it was with technical
issues, it degenerated since then.

> > > > BTW, when i first login into X, and open an xterm, and try to type into
> > > > it, i get some garbage characters (either just a c, or a succession of
> > > > cs). Is this a known bug or something ?
> > > 
> > > Not that I know of, and certainly not without more info.
> > 
> > What kind of info would be needed ?
> 
> XF86Config-4, XFree86.0.log.

A sure, but they yield nothing really important, but then, maybe i
missed something.

Friendly,

Sven Luther
 XF86Config-4 
# $XFree86: xc/programs/Xserver/hw/xfree86/XF86Conf.cpp,v 3.43 1999/12/03 
19:17:20 eich Exp $
#
# Copyright (c) 1994-1998 by The XFree86 Project, Inc.
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
# 
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
# 
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
# THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
# OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
# 
# Except as contained in this notice, the name of the XFree86 Project shall
# not be used in advertising or otherwise to promote the sale, use or other
# dealings in this Software without prior written authorization from the
# XFree86 Project.
#
# $XConsortium: XF86Conf.cpp /main/22 1996/10/23 11:43:51 kaleb $

# **
# This is a sample configuration file only, intended to illustrate
# what a config file might look like.  Refer to the XF86Config(4/5)
# man page for details about the format of this file. This man page
# is installed as /usr/X11R6/man/man5/XF86Config.5x 
# *

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Daniel Stone]

On Wed, Apr 02, 2003 at 01:55:24PM +0200, Sven Luther scrawled:
> On Wed, Apr 02, 2003 at 09:21:31PM +1000, Daniel Stone wrote:
> > Well, considering 4.3.0 only runs on i386/powerpc/sparc/ia64/alpha at
> > the moment, and s390/hurd-i386 support is in the works, it still has a
> > way to go. Getting a complete 4.2.1 is an admirable goal, *just in case*
> > 4.3 doesn't make it to sarge.
> 
> Yes, sure, but we will get flamed for being out of date.

Although the nv and i845g stuff is important, if it means more
stability, it's something I can live with, personally.

> > The problem is that we have by far the best packages of any
> > distribution, with RedHat our closest competitor in this regard. They're
> > of an amazingly high quality, and XFree86 upstream releases aren't;
> > they're code drops that don't work on anything other than i386/powerpc,
> > usually, and half the time they're even severely brokenn on i386.
> > Porting it to other architectures is quite a monumental task, so having
> > 4.3.0 as far as we have it is quite a great achievement IMHO.
> 
> Yes, sure, but it is a fork, and thus more work.

Yeah, but there's nothing we can do about the amount of patching we have
to do. We support over a dozen architectures, that's it. XFree86 doesn't
have the same sort of release engineering or quality assurance we do.

> > I've personally stayed silent because that discussion is largely full of
> > vested political interests, and looks likely to go nowhere. I'm waiting
> > until real code comes forth.
> 
> :)))
> 
> I was one of the first to post in the list, and it was with technical
> issues, it degenerated since then.

I got a feeling of dread when I saw the initial mail, looked at the
archives, and my suspicions were confirmed. I posted once to correct a
misperception about KDE.

> > XF86Config-4, XFree86.0.log.
> 
> A sure, but they yield nothing really important, but then, maybe i
> missed something.

Hmm, no idea, sorry.

-- 
Daniel Stone <[EMAIL PROTECTED]>
Developer, Trinity College, University of Melbourne


pgpTQdSvLWMYo.pgp
Description: PGP signature

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Sven Luther]

On Wed, Apr 02, 2003 at 10:49:42PM +1000, Daniel Stone wrote:
> On Wed, Apr 02, 2003 at 01:55:24PM +0200, Sven Luther scrawled:
> > On Wed, Apr 02, 2003 at 09:21:31PM +1000, Daniel Stone wrote:
> > > Well, considering 4.3.0 only runs on i386/powerpc/sparc/ia64/alpha at
> > > the moment, and s390/hurd-i386 support is in the works, it still has a
> > > way to go. Getting a complete 4.2.1 is an admirable goal, *just in case*
> > > 4.3 doesn't make it to sarge.
> > 
> > Yes, sure, but we will get flamed for being out of date.
> 
> Although the nv and i845g stuff is important, if it means more
> stability, it's something I can live with, personally.

I think these are not the only improvement, the DRI stuff is also part
of it, altough the DRI snapshot packages from Michel help somewhat.

> > > The problem is that we have by far the best packages of any
> > > distribution, with RedHat our closest competitor in this regard. They're
> > > of an amazingly high quality, and XFree86 upstream releases aren't;
> > > they're code drops that don't work on anything other than i386/powerpc,
> > > usually, and half the time they're even severely brokenn on i386.
> > > Porting it to other architectures is quite a monumental task, so having
> > > 4.3.0 as far as we have it is quite a great achievement IMHO.
> > 
> > Yes, sure, but it is a fork, and thus more work.
> 
> Yeah, but there's nothing we can do about the amount of patching we have
> to do. We support over a dozen architectures, that's it. XFree86 doesn't
> have the same sort of release engineering or quality assurance we do.

Maybe things will change in the future, but that said, i think that if
the debian porting effort happened during the same time as the XFree86
developpment, it would be easier, since we would have to check the
XFree86 changes in order of them not to break stuff for us and not the
other way around. Also detecting broken stuff earlier and feeding our
patches more quickly to upstream may make live easier as well.

That said, i don't really have been following the debian X issue, not
since i had the bad idea of doing an X NMU in early 99 and suffered
Branden's backlash then. Also, i have been more involved in low level
driver writing, so i needed to run my own X anyway.

> > > I've personally stayed silent because that discussion is largely full of
> > > vested political interests, and looks likely to go nowhere. I'm waiting
> > > until real code comes forth.
> > 
> > :)))
> > 
> > I was one of the first to post in the list, and it was with technical
> > issues, it degenerated since then.
> 
> I got a feeling of dread when I saw the initial mail, looked at the
> archives, and my suspicions were confirmed. I posted once to correct a
> misperception about KDE.

I think it is a good thing though, and many good things will come of it
in the long run, that is if you avoid many of the uniformed postings
that is.

> > > XF86Config-4, XFree86.0.log.
> > 
> > A sure, but they yield nothing really important, but then, maybe i
> > missed something.
> 
> Hmm, no idea, sorry.

Thought so.

BTW, do you per chance know if there is an XF86Config way of disabling
the RGBA pointer ? I was developping a driver using an mid january CVS
snapshot, but since i updated to 4.3.0 X crashes when the cursor reaches
the bottom part of the screen in Gnome 2.2. I guess i will have to gdb
it, and now that i have a borrowed second computer, it will perhaps be
easier.

Friendly,

Sven Luther
> 
> -- 
> Daniel Stone <[EMAIL PROTECTED]>
> Developer, Trinity College, University of Melbourne

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Daniel Stone]

On Wed, Apr 02, 2003 at 03:29:51PM +0200, Sven Luther scrawled:
> Maybe things will change in the future, but that said, i think that if
> the debian porting effort happened during the same time as the XFree86
> developpment, it would be easier, since we would have to check the
> XFree86 changes in order of them not to break stuff for us and not the
> other way around. Also detecting broken stuff earlier and feeding our
> patches more quickly to upstream may make live easier as well.

That means that we'll be unable to support the version in sid, then.
There's only a limited number of maintainers and porters.

The issue here isn't skill or anything like it, just time, pure and
simple.

> BTW, do you per chance know if there is an XF86Config way of disabling
> the RGBA pointer ? I was developping a driver using an mid january CVS
> snapshot, but since i updated to 4.3.0 X crashes when the cursor reaches
> the bottom part of the screen in Gnome 2.2. I guess i will have to gdb
> it, and now that i have a borrowed second computer, it will perhaps be
> easier.

Set an Xresource:
Xcursor.core: 1

Another FAQ entry for me to add to -0ds3v2 (patch merge from hell - 4.3
branch, bits of HEAD, plus Michel's Radeon DDC patch), along with the
other 3 I haven't even written yet. *sigh*.

-- 
Daniel Stone <[EMAIL PROTECTED]>
Developer, Trinity College, University of Melbourne


pgpXqkuXCTxzo.pgp
Description: PGP signature

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Sven Luther]

On Wed, Apr 02, 2003 at 11:49:27PM +1000, Daniel Stone wrote:
> On Wed, Apr 02, 2003 at 03:29:51PM +0200, Sven Luther scrawled:
> > Maybe things will change in the future, but that said, i think that if
> > the debian porting effort happened during the same time as the XFree86
> > developpment, it would be easier, since we would have to check the
> > XFree86 changes in order of them not to break stuff for us and not the
> > other way around. Also detecting broken stuff earlier and feeding our
> > patches more quickly to upstream may make live easier as well.
> 
> That means that we'll be unable to support the version in sid, then.

No, why, it only is a problem right now because we are one version
behind the XFree86 releases. If we had ready working X 4.3 packages by
the time of its release (and 4.3 was frozen since early november, that
gives us more than 4 month time), then we can start packaging the new
developpment branch, and release it simultaneously or a short time after
the new upstream release, instead of still being fixing 4.2.1. In some
way, you do already that with your 4.3.0 packages, which are not
strictly 4.3.0, but borrow parts of head. If we had a more advanced pool
feature, like it was promissed back then, we could even have a 4.2.1
pool (on which Branden would work on) and an official 4.3.0 pool on
which you and other would work on.

> There's only a limited number of maintainers and porters.

Yes, that is the real problem. But doing double job with upstream will
not help much here.

> The issue here isn't skill or anything like it, just time, pure and
> simple.

But the attitude of Branden with regard to anything related to 4.3.0
doesn't help here. If we were to say that we will start now and try to
set up a second XFree86 team which will be packaging the developpment
release of X, still work in common with Branden on some issues, and hand
him the baby once the official release is made, i think you will
possibly attract more people who are interested in just that, and not
frigthen them away. After all, if Branden says not to ask questions
about 4.3.0 until he is ready, who is willing to risk entering his line
of fire about it ?

> > BTW, do you per chance know if there is an XF86Config way of disabling
> > the RGBA pointer ? I was developping a driver using an mid january CVS
> > snapshot, but since i updated to 4.3.0 X crashes when the cursor reaches
> > the bottom part of the screen in Gnome 2.2. I guess i will have to gdb
> > it, and now that i have a borrowed second computer, it will perhaps be
> > easier.
> 
> Set an Xresource:
> Xcursor.core: 1

Mmm, will try, but maybe a "NoARGBCursor" option in XF86Config would be
nice also.

> Another FAQ entry for me to add to -0ds3v2 (patch merge from hell - 4.3
> branch, bits of HEAD, plus Michel's Radeon DDC patch), along with the
> other 3 I haven't even written yet. *sigh*.

So you see, you are no more packaging 4.3, you are already ahead of it.

Friendly,

Sven Luther

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Michel Dänzer]

On Mit, 2003-04-02 at 13:21, Daniel Stone wrote:
> On Wed, Apr 02, 2003 at 12:53:19PM +0200, Sven Luther scrawled:
> 
> > I think the main problem here is that debian has been playing catchup
> > since i joined in 1998 at least for X. It would be refreshing that it be
> > otherwise, but i guess we just don't have the manpower for it, right. We
> > could very well decide to drop 4.2.1 and go with 4.3.0 for unstable,
> > even before 4.3.0 was released, and have more of our patches be
> > incorporated upstream before the release. Such a thing would be
> > especially important if the XFree86 project will go for more frequent
> > releases, like the discussion on the future of X on the xforum mailing
> > list seems to hint at. I also don't see anyone from the debian X team on
> > that list, but maybe i have missed it, the list being rather high volume
> > after all.
> 
> The problem is that we have by far the best packages of any
> distribution, with RedHat our closest competitor in this regard. They're
> of an amazingly high quality, and XFree86 upstream releases aren't;
> they're code drops that don't work on anything other than i386/powerpc,
> usually, and half the time they're even severely brokenn on i386.
> Porting it to other architectures is quite a monumental task, so having
> 4.3.0 as far as we have it is quite a great achievement IMHO.

Like Sven, I hope that there has been or will be an effort to get the
fixes integrated upstream then.


-- 
Earthling Michel Dänzer   \  Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast  \ http://svcs.affero.net/rm.php?r=daenzer

Processed: Re: Bug#187218: xserver-xfree86: Clients are rejected after a while

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> tag 187218 + unreproducible
Bug#187218: xserver-xfree86: Clients are rejected after a while
There were no tags set.
Tags added: unreproducible

> severity 187218 normal
Bug#187218: xserver-xfree86: Clients are rejected after a while
Severity set to `normal'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

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

Bug#187218: xserver-xfree86: Clients are rejected after a while

[Branden Robinson]

tag 187218 + unreproducible
severity 187218 normal
thanks

I have no other reports of this, and have not been experiencing it
myself.  Are you sure your ~/.Xauthority didn't get clobbered somehow?

-- 
G. Branden Robinson|If you make people think they're
Debian GNU/Linux   |thinking, they'll love you; but if
[EMAIL PROTECTED] |you really make them think, they'll
http://people.debian.org/~branden/ |hate you.


pgpu2JMQoMuBZ.pgp
Description: PGP signature

Bug#126519: Why can't you call me?

[moorekfjoi]

Title: Untitled Document





Lowest 
  price on viagra guaranteed 
  !
START LIVING TODAY!

  We are the cheapest suppliers 
  of Sildenafil Citrate (Viagra) !
  
  We are THE BEST solution for impotence. Our world-renowned products are created 
  in a state-of-the-art FDA-approved laboratory, with no side effects… 
100 
  % Guaranteed
  
ENERGIZE your SEX LIFE ! Click 
  here
 
 
 
Click here to be removed remove 

Bug#187237: marked as done (xserver-xfree86: [savage] strange display problems after upgrade)

[Debian Bug Tracking System]

Your message dated Wed, 2 Apr 2003 11:20:58 -0500
with message-id <[EMAIL PROTECTED]>
and subject line Bug#187237: xserver-xfree86: [savage] strange display problems 
after upgrade
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

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

--
Received: (at submit) by bugs.debian.org; 2 Apr 2003 08:04:07 +
>From [EMAIL PROTECTED] Wed Apr 02 02:04:04 2003
Return-path: <[EMAIL PROTECTED]>
Received: from p50816a1b.dip0.t-ipconnect.de (omnibuch) [80.129.106.27] 
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 190dE1-0002Wu-00; Wed, 02 Apr 2003 02:04:01 -0600
Received: from aks by omnibuch with local (Exim 3.36 #1 (Debian))
id 190dDz-000163-00; Wed, 02 Apr 2003 10:03:59 +0200
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Alex Krauss <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: xserver-xfree86: [savage] strange display problems after upgrade
X-Mailer: reportbug 2.10.1
Date: Wed, 02 Apr 2003 10:03:59 +0200
Message-Id: <[EMAIL PROTECTED]>
Sender: Alex Krauss <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-0.3 required=4.0
tests=BALANCE_FOR_LONG_20K,BALANCE_FOR_LONG_40K,HAS_PACKAGE,
  MAILTO_TO_SPAM_ADDR,SPAM_PHRASE_00_01
version=2.44
X-Spam-Level: 

Package: xserver-xfree86
Version: 4.2.1-6
Severity: important
Tags: sid


After upgrading to 4.2.1-6, the savage driver stopped working for
me. The X-server still starts up normally, but many parts of the
display (including fonts and filled-rectangles) are not rendered at
all.  

from output of lspci:
01:01.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV
(rev 11)


Switching to "vesa" as display driver solves the problem, so I am
quite sure it is not a kde or other problem...








-- Package-specific info:
01:01.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 11)
01:01.0 Class 0300: 5333:8c12 (rev 11)

### BEGIN DEBCONF SECTION
# XF86Config-4 (XFree86 server configuration file) generated by dexconf, the
# Debian X Configuration tool, using values from the debconf database.
#
# Edit this file with caution, and see the XF86Config-4 manual page.
# (Type "man XF86Config-4" at the shell prompt.)
#
# If you want your changes to this file preserved by dexconf, only make changes
# before the "### BEGIN DEBCONF SECTION" line above, and/or after the
# "### END DEBCONF SECTION" line below.
#
# To change things within the debconf section, run the command:
#   dpkg-reconfigure xserver-xfree86
# as root.  Also see "How do I add custom sections to a dexconf-generated
# XF86Config or XF86Config-4 file?" in /usr/share/doc/xfree86-common/FAQ.gz.

Section "Files"
FontPath"unix/:7100"# local font server
# if the local font server has problems, we can fall back on these
FontPath"/usr/lib/X11/fonts/Type1"
FontPath"/usr/lib/X11/fonts/CID"
FontPath"/usr/lib/X11/fonts/Speedo"
FontPath"/usr/lib/X11/fonts/misc"
FontPath"/usr/lib/X11/fonts/cyrillic"
FontPath"/usr/lib/X11/fonts/100dpi"
FontPath"/usr/lib/X11/fonts/75dpi"
EndSection

Section "Module"
Load"GLcore"
Load"bitmap"
Load"dbe"
Load"ddc"
Load"dri"
Load"extmod"
Load"freetype"
Load"glx"
Load"int10"
Load"record"
Load"speedo"
Load"type1"
Load"vbe"
EndSection

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "keyboard"
Option  "CoreKeyboard"
Option  "XkbRules"  "xfree86"
Option  "XkbModel"  "pc104"
Option  "XkbLayout" "de"
Option  "XkbVariant""nodeadkeys"
EndSection

Section "InputDevice"
Identifier  "Configured Mouse"
Driver  "mouse"
Option  "CorePointer"
Option  "Device""/dev/psaux"
Option  "Protocol"  "PS/2"
Option  "Emulate3Buttons"   "true"
Option  "ZAxisMapping"  "4 5"
EndSection

Section "InputDevice"
Identifier  "Generic Mouse"
Driver  "mouse"
Option  "SendCoreEvents""true"
Option  "Device"   

Never worry about roaming again v qsnzkfr

Debian-vote

Push Now
Below is the HOTTEST cellular phone deal on the market!!


- 500 Whenever Minutes & Unlimited Weekends for Only $39.99 Per Month!
- Free Cellular Phone
- Free Car Charger
- Free Belt Clip
- Free Handsfree Kit
- Free Nationwide Long Distance
- Free Voice Mail
- Free Call Waiting
- Free 3 Way Calling
- Free Battery Charger

 
Push Now


If you aren't interested in this simply respond to my email.
ywctwmtfgzhcjofdnzg sclham


bgnn upempzoyvyh aroivmh 

Bug#11147: Where were you 2 weeks ago?

[jwckadn]

Title: Untitled Document





Lowest 
  price on viagra guaranteed 
  !
START LIVING TODAY!

  We are the cheapest suppliers 
  of Sildenafil Citrate (Viagra) !
  
  We are THE BEST solution for impotence. Our world-renowned products are created 
  in a state-of-the-art FDA-approved laboratory, with no side effects… 
100 
  % Guaranteed
  
ENERGIZE your SEX LIFE ! Click 
  here
 
 
 
Click here to be removed remove 

Bug#22506: When will you be back?

[solobosocimh]

Title: Untitled Document





Lowest 
  price on viagra guaranteed 
  !
START LIVING TODAY!

  We are the cheapest suppliers 
  of Sildenafil Citrate (Viagra) !
  
  We are THE BEST solution for impotence. Our world-renowned products are created 
  in a state-of-the-art FDA-approved laboratory, with no side effects… 
100 
  % Guaranteed
  
ENERGIZE your SEX LIFE ! Click 
  here
 
 
 
Click here to be removed remove 

Bug#45291: I cannot get ahold of you?

[moorekvobk]

Title: Untitled Document





Lowest 
  price on viagra guaranteed 
  !
START LIVING TODAY!

  We are the cheapest suppliers 
  of Sildenafil Citrate (Viagra) !
  
  We are THE BEST solution for impotence. Our world-renowned products are created 
  in a state-of-the-art FDA-approved laboratory, with no side effects… 
100 
  % Guaranteed
  
ENERGIZE your SEX LIFE ! Click 
  here
 
 
 
Click here to be removed remove 

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Daniel Stone]

On Wed, Apr 02, 2003 at 04:21:13PM +0200, Sven Luther scrawled:
> On Wed, Apr 02, 2003 at 11:49:27PM +1000, Daniel Stone wrote:
> > That means that we'll be unable to support the version in sid, then.
> 
> No, why, it only is a problem right now because we are one version
> behind the XFree86 releases. If we had ready working X 4.3 packages by
> the time of its release (and 4.3 was frozen since early november, that
> gives us more than 4 month time), then we can start packaging the new
> developpment branch, and release it simultaneously or a short time after
> the new upstream release, instead of still being fixing 4.2.1. In some
> way, you do already that with your 4.3.0 packages, which are not
> strictly 4.3.0, but borrow parts of head. If we had a more advanced pool
> feature, like it was promissed back then, we could even have a 4.2.1
> pool (on which Branden would work on) and an official 4.3.0 pool on
> which you and other would work on.

Well, if we were were working on 4.3.0, 4.2.1 wouldn't be as well
supported as it is: it takes quite an amount of work to support, and
porters would also be split on which one to support - do they debug
problems and try to fix with 4.2.1, or do new porting with 4.3.0?

> > There's only a limited number of maintainers and porters.
> 
> Yes, that is the real problem. But doing double job with upstream will
> not help much here.

Well, it's the best we've got in the meantime, I'm afraid.

> > The issue here isn't skill or anything like it, just time, pure and
> > simple.
> 
> But the attitude of Branden with regard to anything related to 4.3.0
> doesn't help here. If we were to say that we will start now and try to
> set up a second XFree86 team which will be packaging the developpment
> release of X, still work in common with Branden on some issues, and hand
> him the baby once the official release is made, i think you will
> possibly attract more people who are interested in just that, and not
> frigthen them away. After all, if Branden says not to ask questions
> about 4.3.0 until he is ready, who is willing to risk entering his line
> of fire about it ?

Well, Branden has had bad experiences before, like with 4.2, where he
got flamed for not having a new major upstream version of XFree86 ready
in time (quite a few people were unable to appreciate how large an
effort it was). It comes down to this: he's not getting paid for it, so
doesn't want to get harasses about it. I can see that, personally.

And I've been doing 4.3 for months, working as closely with Branden as I
can (you'll notice that I do regular back-syncs with 4.2.1, and a few of
the design decisions I made were stuff Branden was going to do in his
4.3 tree anyway). There's no need to fork the XFree86 team. If you want
to make good, quality packages, go ahead and create them. Just let
Branden know, try to ensure they don't diverge too much from his
packages, or how he plans to do things, and stuff like that. This is
what I've been doing for months now.

> > Another FAQ entry for me to add to -0ds3v2 (patch merge from hell - 4.3
> > branch, bits of HEAD, plus Michel's Radeon DDC patch), along with the
> > other 3 I haven't even written yet. *sigh*.
> 
> So you see, you are no more packaging 4.3, you are already ahead of it.

I'm not "ahead" of it per se. There are still more patches to continue
merging, more documentation to continue writing, and more architectures
to port it to.

-- 
Daniel Stone <[EMAIL PROTECTED]>
Developer, Trinity College, University of Melbourne


pgpV8EySzEBPK.pgp
Description: PGP signature

Bug#187365: xlibmesa3-glu: libraries not correctly linked

[Marco d'Itri]

Package: xlibmesa3-glu
Version: 4.2.1-6
Severity: normal

[This is a standard text.]

One or more libraries in this package are buggy.
All libraries need to be linked against other libraries which they
reference. You can check this by running this command:

LD_TRACE_LOADED_OBJECTS=1 LD_BIND_NOW=1 LD_TRACE_PRELINKING=t \
  /lib/ld-linux.so.2 /usr/lib/libYOUR-LIBRARY.so | grep ^undefined

Then you will have to find which other libraries contain the undefined
symbols and rebuild your library by explicitly linking it against them
(e.g. -lglib).

The broken libraries are:

/usr/X11R6/lib/libGLU.so.1  -lGL

Bug#187374: xlibs: libraries not correctly linked

[Marco d'Itri]

Package: xlibs
Version: 4.2.1-6
Severity: normal

[This is a standard text.]

One or more libraries in this package are buggy.
All libraries need to be linked against other libraries which they
reference. You can check this by running this command:

LD_TRACE_LOADED_OBJECTS=1 LD_BIND_NOW=1 LD_TRACE_PRELINKING=t \
  /lib/ld-linux.so.2 /usr/lib/libYOUR-LIBRARY.so | grep ^undefined

Then you will have to find which other libraries contain the undefined
symbols and rebuild your library by explicitly linking it against them
(e.g. -lglib).

The broken libraries are:

/usr/X11R6/lib/libXmuu.so.1 -lX11
/usr/X11R6/lib/libXp.so.6   -lX11 -lXext
/usr/X11R6/lib/libXrandr.so.1   -lX11

Bug#187374: xlibs: libraries not correctly linked

[Daniel Stone]

On Wed, Apr 02, 2003 at 11:25:02PM +0200, Marco d'Itri scrawled:
> [This is a standard text.]
> 
> One or more libraries in this package are buggy.
> All libraries need to be linked against other libraries which they
> reference. You can check this by running this command:
> 
> LD_TRACE_LOADED_OBJECTS=1 LD_BIND_NOW=1 LD_TRACE_PRELINKING=t \
>   /lib/ld-linux.so.2 /usr/lib/libYOUR-LIBRARY.so | grep ^undefined
> 
> Then you will have to find which other libraries contain the undefined
> symbols and rebuild your library by explicitly linking it against them
> (e.g. -lglib).
> 
> The broken libraries are:
> 
> /usr/X11R6/lib/libXmuu.so.1   -lX11
> /usr/X11R6/lib/libXp.so.6 -lX11 -lXext
> /usr/X11R6/lib/libXrandr.so.1 -lX11

On Thu, Apr 03, 2003 at 12:12:09AM +0200, Marco d'Itri scrawled:
> /usr/X11R6/lib/libGLU.so.1-lGL

Thanks Marco; I'll check this out and fix it for 4.3 if applicable, too.

-- 
Daniel Stone <[EMAIL PROTECTED]>
Developer, Trinity College, University of Melbourne


pgpYBKQlerGst.pgp
Description: PGP signature

Bug#187237: xserver-xfree86: [savage] strange display problems after upgrade

[Alex Krauss]

Package: xserver-xfree86
Version: 4.2.1-6
Severity: important
Tags: sid


After upgrading to 4.2.1-6, the savage driver stopped working for
me. The X-server still starts up normally, but many parts of the
display (including fonts and filled-rectangles) are not rendered at
all.  

from output of lspci:
01:01.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV
(rev 11)


Switching to "vesa" as display driver solves the problem, so I am
quite sure it is not a kde or other problem...








-- Package-specific info:
01:01.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 11)
01:01.0 Class 0300: 5333:8c12 (rev 11)

### BEGIN DEBCONF SECTION
# XF86Config-4 (XFree86 server configuration file) generated by dexconf, the
# Debian X Configuration tool, using values from the debconf database.
#
# Edit this file with caution, and see the XF86Config-4 manual page.
# (Type "man XF86Config-4" at the shell prompt.)
#
# If you want your changes to this file preserved by dexconf, only make changes
# before the "### BEGIN DEBCONF SECTION" line above, and/or after the
# "### END DEBCONF SECTION" line below.
#
# To change things within the debconf section, run the command:
#   dpkg-reconfigure xserver-xfree86
# as root.  Also see "How do I add custom sections to a dexconf-generated
# XF86Config or XF86Config-4 file?" in /usr/share/doc/xfree86-common/FAQ.gz.

Section "Files"
FontPath"unix/:7100"# local font server
# if the local font server has problems, we can fall back on these
FontPath"/usr/lib/X11/fonts/Type1"
FontPath"/usr/lib/X11/fonts/CID"
FontPath"/usr/lib/X11/fonts/Speedo"
FontPath"/usr/lib/X11/fonts/misc"
FontPath"/usr/lib/X11/fonts/cyrillic"
FontPath"/usr/lib/X11/fonts/100dpi"
FontPath"/usr/lib/X11/fonts/75dpi"
EndSection

Section "Module"
Load"GLcore"
Load"bitmap"
Load"dbe"
Load"ddc"
Load"dri"
Load"extmod"
Load"freetype"
Load"glx"
Load"int10"
Load"record"
Load"speedo"
Load"type1"
Load"vbe"
EndSection

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "keyboard"
Option  "CoreKeyboard"
Option  "XkbRules"  "xfree86"
Option  "XkbModel"  "pc104"
Option  "XkbLayout" "de"
Option  "XkbVariant""nodeadkeys"
EndSection

Section "InputDevice"
Identifier  "Configured Mouse"
Driver  "mouse"
Option  "CorePointer"
Option  "Device""/dev/psaux"
Option  "Protocol"  "PS/2"
Option  "Emulate3Buttons"   "true"
Option  "ZAxisMapping"  "4 5"
EndSection

Section "InputDevice"
Identifier  "Generic Mouse"
Driver  "mouse"
Option  "SendCoreEvents""true"
Option  "Device""/dev/input/mice"
Option  "Protocol"  "ImPS/2"
Option  "Emulate3Buttons"   "true"
Option  "ZAxisMapping"  "4 5"
EndSection

Section "Device"
Identifier  "Generic Video Card"
Driver  "vesa"
Option  "UseFBDev"  "true"
EndSection

Section "Monitor"
Identifier  "Generic Monitor"
HorizSync   28-38
VertRefresh 43-72
Option  "DPMS"
EndSection

Section "Screen"
Identifier  "Default Screen"
Device  "Generic Video Card"
Monitor "Generic Monitor"
DefaultDepth24
SubSection "Display"
Depth   1
Modes   "800x600"
EndSubSection
SubSection "Display"
Depth   4
Modes   "800x600"
EndSubSection
SubSection "Display"
Depth   8
Modes   "800x600"
EndSubSection
SubSection "Display"
Depth   15
Modes   "800x600"
EndSubSection
SubSection "Display"
Depth   16
Modes   "800x600"
EndSubSection
SubSection "Display"
Depth   24
Modes   "800x600"
EndSubSection
EndSection

Section "ServerLayout"
Identifier  "Default Layout"
Screen  "Default Screen"
InputDevice "Generic Keyboard"
InputDevice "Configured Mouse"
InputDevice "Generic Mouse"
EndSection

Section "DRI"
Mode0666
EndSection

### END DEBCONF SECTION


This is a pre-release version of XFre

gnome-randr-applet and Xfree86 4.3.0 ...

[Sven Luther]

Hello, ...

I have packaged GRandrApplet (renamed gnome-randr-applet) which is an
applet for changing the resolution using the randr extension.

Now, this will work (and build) only with the 4.3.0 version of X, as the
randr is not supported in earlier versions.

So i have added a build-dependency on xlibs-dev (>> 4.3.0), and added a
shlibs override to make the dependency of libXrandr be xlibs (>> 4.3.0).

So, what am i to do with this package ? If i upload it, it will not be
installeable with the current debian unstable, but will work with
daniel stone's X packages. It will also fail to build for all the
autobuilders, as there is no 4.3.0 package.

That said, it will still be of value for all debian's users which uses
daniel stone's 4.3.0 package, or maybe even for those who run self built
4.3.0 packages (altough they would need to override the dependencies),
and i think there is value of having it in the archive (be it only so
other people don't repackage it and such). And anyway, this package will
not enter testing until XFree86 4.3.0 does.

Also, i think there is plan for packaging 4.3.0 for sarge, isn't it ? Or
will the time to the sarge release be to short for that ?

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Daniel Stone]

On Wed, Apr 02, 2003 at 11:32:24AM +0200, Sven Luther scrawled:
> Now, this will work (and build) only with the 4.3.0 version of X, as the
> randr is not supported in earlier versions.
> 
> So i have added a build-dependency on xlibs-dev (>> 4.3.0), and added a
> shlibs override to make the dependency of libXrandr be xlibs (>> 4.3.0).
> 
> So, what am i to do with this package ? If i upload it, it will not be
> installeable with the current debian unstable, but will work with
> daniel stone's X packages. It will also fail to build for all the
> autobuilders, as there is no 4.3.0 package.
> 
> That said, it will still be of value for all debian's users which uses
> daniel stone's 4.3.0 package, or maybe even for those who run self built
> 4.3.0 packages (altough they would need to override the dependencies),
> and i think there is value of having it in the archive (be it only so
> other people don't repackage it and such). And anyway, this package will
> not enter testing until XFree86 4.3.0 does.
> 
> Also, i think there is plan for packaging 4.3.0 for sarge, isn't it ? Or
> will the time to the sarge release be to short for that ?

Package it in an external repository for the time being, and release it
out to sid when 4.3.0 hits sid; there's really no other way to do it.

Ralf Nolden has done a woody backport of my packages, but IIRC sarge is
glibc 2.3 now, so the sid packages will probably work.

-- 
Daniel Stone <[EMAIL PROTECTED]>
Developer, Trinity College, University of Melbourne


pgp0.pgp
Description: PGP signature

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Sven Luther]

On Wed, Apr 02, 2003 at 08:02:12PM +1000, Daniel Stone wrote:
> On Wed, Apr 02, 2003 at 11:32:24AM +0200, Sven Luther scrawled:
> > Now, this will work (and build) only with the 4.3.0 version of X, as the
> > randr is not supported in earlier versions.
> > 
> > So i have added a build-dependency on xlibs-dev (>> 4.3.0), and added a
> > shlibs override to make the dependency of libXrandr be xlibs (>> 4.3.0).
> > 
> > So, what am i to do with this package ? If i upload it, it will not be
> > installeable with the current debian unstable, but will work with
> > daniel stone's X packages. It will also fail to build for all the
> > autobuilders, as there is no 4.3.0 package.
> > 
> > That said, it will still be of value for all debian's users which uses
> > daniel stone's 4.3.0 package, or maybe even for those who run self built
> > 4.3.0 packages (altough they would need to override the dependencies),
> > and i think there is value of having it in the archive (be it only so
> > other people don't repackage it and such). And anyway, this package will
> > not enter testing until XFree86 4.3.0 does.
> > 
> > Also, i think there is plan for packaging 4.3.0 for sarge, isn't it ? Or
> > will the time to the sarge release be to short for that ?
> 
> Package it in an external repository for the time being, and release it
> out to sid when 4.3.0 hits sid; there's really no other way to do it.

Why not just upload it to sid (it is already in the NEW queue btw), it
will not be installable for people not using 4.3.0 so it will not break
anything for anyone. How do i make it visible that i have packaged it if
nobody can see it ? Should i make a wnpp ITP bugreport and give the link
to the repository in it ?

> Ralf Nolden has done a woody backport of my packages, but IIRC sarge is
> glibc 2.3 now, so the sid packages will probably work.

I don't care about woody. I just want the package to be available for
whoever can use it, if someone wants to make a woody backport, fine for
him.

That said, i am a bit worried about XFree86 4.3.0 and sarge, 4.2.1 is
not yet ready for sarge, and if a release/freeze for around july is
planned, this let's little time to fully test 4.3.0, which seems to be
already somewhat obsolet by now, if you consider all the flaming in
upstreams xfree86-forum mailing list.

BTW, when i first login into X, and open an xterm, and try to type into
it, i get some garbage characters (either just a c, or a succession of
cs). Is this a known bug or something ?

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Daniel Stone]

On Wed, Apr 02, 2003 at 12:18:08PM +0200, Sven Luther scrawled:
> Why not just upload it to sid (it is already in the NEW queue btw), it
> will not be installable for people not using 4.3.0 so it will not break
> anything for anyone. How do i make it visible that i have packaged it if
> nobody can see it ? Should i make a wnpp ITP bugreport and give the link
> to the repository in it ?

Well, it'll break the buildds, and be uninstallable in sid. That makes
it either contrib or experimental removal. I suggest ITPing it and
linking to your repository for the time being. The ftpmasters won't
accept it, I can guarantee that now.

> > Ralf Nolden has done a woody backport of my packages, but IIRC sarge is
> > glibc 2.3 now, so the sid packages will probably work.
> 
> I don't care about woody. I just want the package to be available for
> whoever can use it, if someone wants to make a woody backport, fine for
> him.

Fair enough.

> That said, i am a bit worried about XFree86 4.3.0 and sarge, 4.2.1 is
> not yet ready for sarge, and if a release/freeze for around july is
> planned, this let's little time to fully test 4.3.0, which seems to be
> already somewhat obsolet by now, if you consider all the flaming in
> upstreams xfree86-forum mailing list.

Well, considering it's the best we have to work with right now, that's
what we're running with.

> BTW, when i first login into X, and open an xterm, and try to type into
> it, i get some garbage characters (either just a c, or a succession of
> cs). Is this a known bug or something ?

Not that I know of, and certainly not without more info.

-- 
Daniel Stone <[EMAIL PROTECTED]>
Developer, Trinity College, University of Melbourne


pgp0.pgp
Description: PGP signature

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Sven Luther]

On Wed, Apr 02, 2003 at 08:41:57PM +1000, Daniel Stone wrote:
> On Wed, Apr 02, 2003 at 12:18:08PM +0200, Sven Luther scrawled:
> > Why not just upload it to sid (it is already in the NEW queue btw), it
> > will not be installable for people not using 4.3.0 so it will not break
> > anything for anyone. How do i make it visible that i have packaged it if
> > nobody can see it ? Should i make a wnpp ITP bugreport and give the link
> > to the repository in it ?
> 
> Well, it'll break the buildds, and be uninstallable in sid. That makes
> it either contrib or experimental removal. I suggest ITPing it and
> linking to your repository for the time being. The ftpmasters won't
> accept it, I can guarantee that now.

I can let it sit in the NEW queue though, or should i ask for its
removal ? What about uploading it to experimental instead or something
such ?

> > > Ralf Nolden has done a woody backport of my packages, but IIRC sarge is
> > > glibc 2.3 now, so the sid packages will probably work.
> > 
> > I don't care about woody. I just want the package to be available for
> > whoever can use it, if someone wants to make a woody backport, fine for
> > him.
> 
> Fair enough.
> 
> > That said, i am a bit worried about XFree86 4.3.0 and sarge, 4.2.1 is
> > not yet ready for sarge, and if a release/freeze for around july is
> > planned, this let's little time to fully test 4.3.0, which seems to be
> > already somewhat obsolet by now, if you consider all the flaming in
> > upstreams xfree86-forum mailing list.
> 
> Well, considering it's the best we have to work with right now, that's
> what we're running with.

I am not sure i really understood you here, you are saying that 4.2.1 is
the best we have, and we have to make do with it, right ?

I think the main problem here is that debian has been playing catchup
since i joined in 1998 at least for X. It would be refreshing that it be
otherwise, but i guess we just don't have the manpower for it, right. We
could very well decide to drop 4.2.1 and go with 4.3.0 for unstable,
even before 4.3.0 was released, and have more of our patches be
incorporated upstream before the release. Such a thing would be
especially important if the XFree86 project will go for more frequent
releases, like the discussion on the future of X on the xforum mailing
list seems to hint at. I also don't see anyone from the debian X team on
that list, but maybe i have missed it, the list being rather high volume
after all.

> > BTW, when i first login into X, and open an xterm, and try to type into
> > it, i get some garbage characters (either just a c, or a succession of
> > cs). Is this a known bug or something ?
> 
> Not that I know of, and certainly not without more info.

What kind of info would be needed ?

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Daniel Stone]

On Wed, Apr 02, 2003 at 12:53:19PM +0200, Sven Luther scrawled:
> On Wed, Apr 02, 2003 at 08:41:57PM +1000, Daniel Stone wrote:
> > On Wed, Apr 02, 2003 at 12:18:08PM +0200, Sven Luther scrawled:
> > > Why not just upload it to sid (it is already in the NEW queue btw), it
> > > will not be installable for people not using 4.3.0 so it will not break
> > > anything for anyone. How do i make it visible that i have packaged it if
> > > nobody can see it ? Should i make a wnpp ITP bugreport and give the link
> > > to the repository in it ?
> > 
> > Well, it'll break the buildds, and be uninstallable in sid. That makes
> > it either contrib or experimental removal. I suggest ITPing it and
> > linking to your repository for the time being. The ftpmasters won't
> > accept it, I can guarantee that now.
> 
> I can let it sit in the NEW queue though, or should i ask for its
> removal ? What about uploading it to experimental instead or something
> such ?

I really don't know; that's up to you.

> > > That said, i am a bit worried about XFree86 4.3.0 and sarge, 4.2.1 is
> > > not yet ready for sarge, and if a release/freeze for around july is
> > > planned, this let's little time to fully test 4.3.0, which seems to be
> > > already somewhat obsolet by now, if you consider all the flaming in
> > > upstreams xfree86-forum mailing list.
> > 
> > Well, considering it's the best we have to work with right now, that's
> > what we're running with.
> 
> I am not sure i really understood you here, you are saying that 4.2.1 is
> the best we have, and we have to make do with it, right ?

Well, considering 4.3.0 only runs on i386/powerpc/sparc/ia64/alpha at
the moment, and s390/hurd-i386 support is in the works, it still has a
way to go. Getting a complete 4.2.1 is an admirable goal, *just in case*
4.3 doesn't make it to sarge.

> I think the main problem here is that debian has been playing catchup
> since i joined in 1998 at least for X. It would be refreshing that it be
> otherwise, but i guess we just don't have the manpower for it, right. We
> could very well decide to drop 4.2.1 and go with 4.3.0 for unstable,
> even before 4.3.0 was released, and have more of our patches be
> incorporated upstream before the release. Such a thing would be
> especially important if the XFree86 project will go for more frequent
> releases, like the discussion on the future of X on the xforum mailing
> list seems to hint at. I also don't see anyone from the debian X team on
> that list, but maybe i have missed it, the list being rather high volume
> after all.

The problem is that we have by far the best packages of any
distribution, with RedHat our closest competitor in this regard. They're
of an amazingly high quality, and XFree86 upstream releases aren't;
they're code drops that don't work on anything other than i386/powerpc,
usually, and half the time they're even severely brokenn on i386.
Porting it to other architectures is quite a monumental task, so having
4.3.0 as far as we have it is quite a great achievement IMHO.

I've personally stayed silent because that discussion is largely full of
vested political interests, and looks likely to go nowhere. I'm waiting
until real code comes forth.

> > > BTW, when i first login into X, and open an xterm, and try to type into
> > > it, i get some garbage characters (either just a c, or a succession of
> > > cs). Is this a known bug or something ?
> > 
> > Not that I know of, and certainly not without more info.
> 
> What kind of info would be needed ?

XF86Config-4, XFree86.0.log.

-- 
Daniel Stone <[EMAIL PROTECTED]>
Developer, Trinity College, University of Melbourne


pgp0.pgp
Description: PGP signature

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Sven Luther]

On Wed, Apr 02, 2003 at 09:21:31PM +1000, Daniel Stone wrote:
> > > > That said, i am a bit worried about XFree86 4.3.0 and sarge, 4.2.1 is
> > > > not yet ready for sarge, and if a release/freeze for around july is
> > > > planned, this let's little time to fully test 4.3.0, which seems to be
> > > > already somewhat obsolet by now, if you consider all the flaming in
> > > > upstreams xfree86-forum mailing list.
> > > 
> > > Well, considering it's the best we have to work with right now, that's
> > > what we're running with.
> > 
> > I am not sure i really understood you here, you are saying that 4.2.1 is
> > the best we have, and we have to make do with it, right ?
> 
> Well, considering 4.3.0 only runs on i386/powerpc/sparc/ia64/alpha at
> the moment, and s390/hurd-i386 support is in the works, it still has a
> way to go. Getting a complete 4.2.1 is an admirable goal, *just in case*
> 4.3 doesn't make it to sarge.

Yes, sure, but we will get flamed for being out of date.

> > I think the main problem here is that debian has been playing catchup
> > since i joined in 1998 at least for X. It would be refreshing that it be
> > otherwise, but i guess we just don't have the manpower for it, right. We
> > could very well decide to drop 4.2.1 and go with 4.3.0 for unstable,
> > even before 4.3.0 was released, and have more of our patches be
> > incorporated upstream before the release. Such a thing would be
> > especially important if the XFree86 project will go for more frequent
> > releases, like the discussion on the future of X on the xforum mailing
> > list seems to hint at. I also don't see anyone from the debian X team on
> > that list, but maybe i have missed it, the list being rather high volume
> > after all.
> 
> The problem is that we have by far the best packages of any
> distribution, with RedHat our closest competitor in this regard. They're
> of an amazingly high quality, and XFree86 upstream releases aren't;
> they're code drops that don't work on anything other than i386/powerpc,
> usually, and half the time they're even severely brokenn on i386.
> Porting it to other architectures is quite a monumental task, so having
> 4.3.0 as far as we have it is quite a great achievement IMHO.

Yes, sure, but it is a fork, and thus more work.

> I've personally stayed silent because that discussion is largely full of
> vested political interests, and looks likely to go nowhere. I'm waiting
> until real code comes forth.

:)))

I was one of the first to post in the list, and it was with technical
issues, it degenerated since then.

> > > > BTW, when i first login into X, and open an xterm, and try to type into
> > > > it, i get some garbage characters (either just a c, or a succession of
> > > > cs). Is this a known bug or something ?
> > > 
> > > Not that I know of, and certainly not without more info.
> > 
> > What kind of info would be needed ?
> 
> XF86Config-4, XFree86.0.log.

A sure, but they yield nothing really important, but then, maybe i
missed something.

Friendly,

Sven Luther
 XF86Config-4 
# $XFree86: xc/programs/Xserver/hw/xfree86/XF86Conf.cpp,v 3.43 1999/12/03 19:17:20 
eich Exp $
#
# Copyright (c) 1994-1998 by The XFree86 Project, Inc.
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
# 
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
# 
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
# THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
# OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
# 
# Except as contained in this notice, the name of the XFree86 Project shall
# not be used in advertising or otherwise to promote the sale, use or other
# dealings in this Software without prior written authorization from the
# XFree86 Project.
#
# $XConsortium: XF86Conf.cpp /main/22 1996/10/23 11:43:51 kaleb $

# **
# This is a sample configuration file only, intended to illustrate
# what a config file might look like.  Refer to the XF86Config(4/5)
# man page for details about the format of this file. This man page
# is installed as /usr/X11R6/man/man5/XF86Config.5x 
# *

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Daniel Stone]

On Wed, Apr 02, 2003 at 01:55:24PM +0200, Sven Luther scrawled:
> On Wed, Apr 02, 2003 at 09:21:31PM +1000, Daniel Stone wrote:
> > Well, considering 4.3.0 only runs on i386/powerpc/sparc/ia64/alpha at
> > the moment, and s390/hurd-i386 support is in the works, it still has a
> > way to go. Getting a complete 4.2.1 is an admirable goal, *just in case*
> > 4.3 doesn't make it to sarge.
> 
> Yes, sure, but we will get flamed for being out of date.

Although the nv and i845g stuff is important, if it means more
stability, it's something I can live with, personally.

> > The problem is that we have by far the best packages of any
> > distribution, with RedHat our closest competitor in this regard. They're
> > of an amazingly high quality, and XFree86 upstream releases aren't;
> > they're code drops that don't work on anything other than i386/powerpc,
> > usually, and half the time they're even severely brokenn on i386.
> > Porting it to other architectures is quite a monumental task, so having
> > 4.3.0 as far as we have it is quite a great achievement IMHO.
> 
> Yes, sure, but it is a fork, and thus more work.

Yeah, but there's nothing we can do about the amount of patching we have
to do. We support over a dozen architectures, that's it. XFree86 doesn't
have the same sort of release engineering or quality assurance we do.

> > I've personally stayed silent because that discussion is largely full of
> > vested political interests, and looks likely to go nowhere. I'm waiting
> > until real code comes forth.
> 
> :)))
> 
> I was one of the first to post in the list, and it was with technical
> issues, it degenerated since then.

I got a feeling of dread when I saw the initial mail, looked at the
archives, and my suspicions were confirmed. I posted once to correct a
misperception about KDE.

> > XF86Config-4, XFree86.0.log.
> 
> A sure, but they yield nothing really important, but then, maybe i
> missed something.

Hmm, no idea, sorry.

-- 
Daniel Stone <[EMAIL PROTECTED]>
Developer, Trinity College, University of Melbourne


pgp0.pgp
Description: PGP signature

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Sven Luther]

On Wed, Apr 02, 2003 at 10:49:42PM +1000, Daniel Stone wrote:
> On Wed, Apr 02, 2003 at 01:55:24PM +0200, Sven Luther scrawled:
> > On Wed, Apr 02, 2003 at 09:21:31PM +1000, Daniel Stone wrote:
> > > Well, considering 4.3.0 only runs on i386/powerpc/sparc/ia64/alpha at
> > > the moment, and s390/hurd-i386 support is in the works, it still has a
> > > way to go. Getting a complete 4.2.1 is an admirable goal, *just in case*
> > > 4.3 doesn't make it to sarge.
> > 
> > Yes, sure, but we will get flamed for being out of date.
> 
> Although the nv and i845g stuff is important, if it means more
> stability, it's something I can live with, personally.

I think these are not the only improvement, the DRI stuff is also part
of it, altough the DRI snapshot packages from Michel help somewhat.

> > > The problem is that we have by far the best packages of any
> > > distribution, with RedHat our closest competitor in this regard. They're
> > > of an amazingly high quality, and XFree86 upstream releases aren't;
> > > they're code drops that don't work on anything other than i386/powerpc,
> > > usually, and half the time they're even severely brokenn on i386.
> > > Porting it to other architectures is quite a monumental task, so having
> > > 4.3.0 as far as we have it is quite a great achievement IMHO.
> > 
> > Yes, sure, but it is a fork, and thus more work.
> 
> Yeah, but there's nothing we can do about the amount of patching we have
> to do. We support over a dozen architectures, that's it. XFree86 doesn't
> have the same sort of release engineering or quality assurance we do.

Maybe things will change in the future, but that said, i think that if
the debian porting effort happened during the same time as the XFree86
developpment, it would be easier, since we would have to check the
XFree86 changes in order of them not to break stuff for us and not the
other way around. Also detecting broken stuff earlier and feeding our
patches more quickly to upstream may make live easier as well.

That said, i don't really have been following the debian X issue, not
since i had the bad idea of doing an X NMU in early 99 and suffered
Branden's backlash then. Also, i have been more involved in low level
driver writing, so i needed to run my own X anyway.

> > > I've personally stayed silent because that discussion is largely full of
> > > vested political interests, and looks likely to go nowhere. I'm waiting
> > > until real code comes forth.
> > 
> > :)))
> > 
> > I was one of the first to post in the list, and it was with technical
> > issues, it degenerated since then.
> 
> I got a feeling of dread when I saw the initial mail, looked at the
> archives, and my suspicions were confirmed. I posted once to correct a
> misperception about KDE.

I think it is a good thing though, and many good things will come of it
in the long run, that is if you avoid many of the uniformed postings
that is.

> > > XF86Config-4, XFree86.0.log.
> > 
> > A sure, but they yield nothing really important, but then, maybe i
> > missed something.
> 
> Hmm, no idea, sorry.

Thought so.

BTW, do you per chance know if there is an XF86Config way of disabling
the RGBA pointer ? I was developping a driver using an mid january CVS
snapshot, but since i updated to 4.3.0 X crashes when the cursor reaches
the bottom part of the screen in Gnome 2.2. I guess i will have to gdb
it, and now that i have a borrowed second computer, it will perhaps be
easier.

Friendly,

Sven Luther
> 
> -- 
> Daniel Stone <[EMAIL PROTECTED]>
> Developer, Trinity College, University of Melbourne



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Daniel Stone]

On Wed, Apr 02, 2003 at 03:29:51PM +0200, Sven Luther scrawled:
> Maybe things will change in the future, but that said, i think that if
> the debian porting effort happened during the same time as the XFree86
> developpment, it would be easier, since we would have to check the
> XFree86 changes in order of them not to break stuff for us and not the
> other way around. Also detecting broken stuff earlier and feeding our
> patches more quickly to upstream may make live easier as well.

That means that we'll be unable to support the version in sid, then.
There's only a limited number of maintainers and porters.

The issue here isn't skill or anything like it, just time, pure and
simple.

> BTW, do you per chance know if there is an XF86Config way of disabling
> the RGBA pointer ? I was developping a driver using an mid january CVS
> snapshot, but since i updated to 4.3.0 X crashes when the cursor reaches
> the bottom part of the screen in Gnome 2.2. I guess i will have to gdb
> it, and now that i have a borrowed second computer, it will perhaps be
> easier.

Set an Xresource:
Xcursor.core: 1

Another FAQ entry for me to add to -0ds3v2 (patch merge from hell - 4.3
branch, bits of HEAD, plus Michel's Radeon DDC patch), along with the
other 3 I haven't even written yet. *sigh*.

-- 
Daniel Stone <[EMAIL PROTECTED]>
Developer, Trinity College, University of Melbourne


pgp0.pgp
Description: PGP signature

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Sven Luther]

On Wed, Apr 02, 2003 at 11:49:27PM +1000, Daniel Stone wrote:
> On Wed, Apr 02, 2003 at 03:29:51PM +0200, Sven Luther scrawled:
> > Maybe things will change in the future, but that said, i think that if
> > the debian porting effort happened during the same time as the XFree86
> > developpment, it would be easier, since we would have to check the
> > XFree86 changes in order of them not to break stuff for us and not the
> > other way around. Also detecting broken stuff earlier and feeding our
> > patches more quickly to upstream may make live easier as well.
> 
> That means that we'll be unable to support the version in sid, then.

No, why, it only is a problem right now because we are one version
behind the XFree86 releases. If we had ready working X 4.3 packages by
the time of its release (and 4.3 was frozen since early november, that
gives us more than 4 month time), then we can start packaging the new
developpment branch, and release it simultaneously or a short time after
the new upstream release, instead of still being fixing 4.2.1. In some
way, you do already that with your 4.3.0 packages, which are not
strictly 4.3.0, but borrow parts of head. If we had a more advanced pool
feature, like it was promissed back then, we could even have a 4.2.1
pool (on which Branden would work on) and an official 4.3.0 pool on
which you and other would work on.

> There's only a limited number of maintainers and porters.

Yes, that is the real problem. But doing double job with upstream will
not help much here.

> The issue here isn't skill or anything like it, just time, pure and
> simple.

But the attitude of Branden with regard to anything related to 4.3.0
doesn't help here. If we were to say that we will start now and try to
set up a second XFree86 team which will be packaging the developpment
release of X, still work in common with Branden on some issues, and hand
him the baby once the official release is made, i think you will
possibly attract more people who are interested in just that, and not
frigthen them away. After all, if Branden says not to ask questions
about 4.3.0 until he is ready, who is willing to risk entering his line
of fire about it ?

> > BTW, do you per chance know if there is an XF86Config way of disabling
> > the RGBA pointer ? I was developping a driver using an mid january CVS
> > snapshot, but since i updated to 4.3.0 X crashes when the cursor reaches
> > the bottom part of the screen in Gnome 2.2. I guess i will have to gdb
> > it, and now that i have a borrowed second computer, it will perhaps be
> > easier.
> 
> Set an Xresource:
> Xcursor.core: 1

Mmm, will try, but maybe a "NoARGBCursor" option in XF86Config would be
nice also.

> Another FAQ entry for me to add to -0ds3v2 (patch merge from hell - 4.3
> branch, bits of HEAD, plus Michel's Radeon DDC patch), along with the
> other 3 I haven't even written yet. *sigh*.

So you see, you are no more packaging 4.3, you are already ahead of it.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Michel Dänzer]

On Mit, 2003-04-02 at 13:21, Daniel Stone wrote:
> On Wed, Apr 02, 2003 at 12:53:19PM +0200, Sven Luther scrawled:
> 
> > I think the main problem here is that debian has been playing catchup
> > since i joined in 1998 at least for X. It would be refreshing that it be
> > otherwise, but i guess we just don't have the manpower for it, right. We
> > could very well decide to drop 4.2.1 and go with 4.3.0 for unstable,
> > even before 4.3.0 was released, and have more of our patches be
> > incorporated upstream before the release. Such a thing would be
> > especially important if the XFree86 project will go for more frequent
> > releases, like the discussion on the future of X on the xforum mailing
> > list seems to hint at. I also don't see anyone from the debian X team on
> > that list, but maybe i have missed it, the list being rather high volume
> > after all.
> 
> The problem is that we have by far the best packages of any
> distribution, with RedHat our closest competitor in this regard. They're
> of an amazingly high quality, and XFree86 upstream releases aren't;
> they're code drops that don't work on anything other than i386/powerpc,
> usually, and half the time they're even severely brokenn on i386.
> Porting it to other architectures is quite a monumental task, so having
> 4.3.0 as far as we have it is quite a great achievement IMHO.

Like Sven, I hope that there has been or will be an effort to get the
fixes integrated upstream then.


-- 
Earthling Michel Dänzer   \  Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast  \ http://svcs.affero.net/rm.php?r=daenzer


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: Re: Bug#187218: xserver-xfree86: Clients are rejected after a while

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> tag 187218 + unreproducible
Bug#187218: xserver-xfree86: Clients are rejected after a while
There were no tags set.
Tags added: unreproducible

> severity 187218 normal
Bug#187218: xserver-xfree86: Clients are rejected after a while
Severity set to `normal'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

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



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#187218: xserver-xfree86: Clients are rejected after a while

[Branden Robinson]

tag 187218 + unreproducible
severity 187218 normal
thanks

I have no other reports of this, and have not been experiencing it
myself.  Are you sure your ~/.Xauthority didn't get clobbered somehow?

-- 
G. Branden Robinson|If you make people think they're
Debian GNU/Linux   |thinking, they'll love you; but if
[EMAIL PROTECTED] |you really make them think, they'll
http://people.debian.org/~branden/ |hate you.


pgp0.pgp
Description: PGP signature

Bug#126519: Why can't you call me?

[moorekfjoi]

Title: Untitled Document





Lowest 
  price on viagra guaranteed 
  !
START LIVING TODAY!

  We are the cheapest suppliers 
  of Sildenafil Citrate (Viagra) !
  
  We are THE BEST solution for impotence. Our world-renowned products are created 
  in a state-of-the-art FDA-approved laboratory, with no side effects… 
100 
  % Guaranteed
  
ENERGIZE your SEX LIFE ! Click 
  here
 
 
 
Click here to be removed remove 

Bug#187237: marked as done (xserver-xfree86: [savage] strange display problems after upgrade)

[Debian Bug Tracking System]

Your message dated Wed, 2 Apr 2003 11:20:58 -0500
with message-id <[EMAIL PROTECTED]>
and subject line Bug#187237: xserver-xfree86: [savage] strange display problems after 
upgrade
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

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

--
Received: (at submit) by bugs.debian.org; 2 Apr 2003 08:04:07 +
>From [EMAIL PROTECTED] Wed Apr 02 02:04:04 2003
Return-path: <[EMAIL PROTECTED]>
Received: from p50816a1b.dip0.t-ipconnect.de (omnibuch) [80.129.106.27] 
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 190dE1-0002Wu-00; Wed, 02 Apr 2003 02:04:01 -0600
Received: from aks by omnibuch with local (Exim 3.36 #1 (Debian))
id 190dDz-000163-00; Wed, 02 Apr 2003 10:03:59 +0200
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Alex Krauss <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: xserver-xfree86: [savage] strange display problems after upgrade
X-Mailer: reportbug 2.10.1
Date: Wed, 02 Apr 2003 10:03:59 +0200
Message-Id: <[EMAIL PROTECTED]>
Sender: Alex Krauss <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-0.3 required=4.0
tests=BALANCE_FOR_LONG_20K,BALANCE_FOR_LONG_40K,HAS_PACKAGE,
  MAILTO_TO_SPAM_ADDR,SPAM_PHRASE_00_01
version=2.44
X-Spam-Level: 

Package: xserver-xfree86
Version: 4.2.1-6
Severity: important
Tags: sid


After upgrading to 4.2.1-6, the savage driver stopped working for
me. The X-server still starts up normally, but many parts of the
display (including fonts and filled-rectangles) are not rendered at
all.  

from output of lspci:
01:01.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV
(rev 11)


Switching to "vesa" as display driver solves the problem, so I am
quite sure it is not a kde or other problem...








-- Package-specific info:
01:01.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 11)
01:01.0 Class 0300: 5333:8c12 (rev 11)

### BEGIN DEBCONF SECTION
# XF86Config-4 (XFree86 server configuration file) generated by dexconf, the
# Debian X Configuration tool, using values from the debconf database.
#
# Edit this file with caution, and see the XF86Config-4 manual page.
# (Type "man XF86Config-4" at the shell prompt.)
#
# If you want your changes to this file preserved by dexconf, only make changes
# before the "### BEGIN DEBCONF SECTION" line above, and/or after the
# "### END DEBCONF SECTION" line below.
#
# To change things within the debconf section, run the command:
#   dpkg-reconfigure xserver-xfree86
# as root.  Also see "How do I add custom sections to a dexconf-generated
# XF86Config or XF86Config-4 file?" in /usr/share/doc/xfree86-common/FAQ.gz.

Section "Files"
FontPath"unix/:7100"# local font server
# if the local font server has problems, we can fall back on these
FontPath"/usr/lib/X11/fonts/Type1"
FontPath"/usr/lib/X11/fonts/CID"
FontPath"/usr/lib/X11/fonts/Speedo"
FontPath"/usr/lib/X11/fonts/misc"
FontPath"/usr/lib/X11/fonts/cyrillic"
FontPath"/usr/lib/X11/fonts/100dpi"
FontPath"/usr/lib/X11/fonts/75dpi"
EndSection

Section "Module"
Load"GLcore"
Load"bitmap"
Load"dbe"
Load"ddc"
Load"dri"
Load"extmod"
Load"freetype"
Load"glx"
Load"int10"
Load"record"
Load"speedo"
Load"type1"
Load"vbe"
EndSection

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "keyboard"
Option  "CoreKeyboard"
Option  "XkbRules"  "xfree86"
Option  "XkbModel"  "pc104"
Option  "XkbLayout" "de"
Option  "XkbVariant""nodeadkeys"
EndSection

Section "InputDevice"
Identifier  "Configured Mouse"
Driver  "mouse"
Option  "CorePointer"
Option  "Device""/dev/psaux"
Option  "Protocol"  "PS/2"
Option  "Emulate3Buttons"   "true"
Option  "ZAxisMapping"  "4 5"
EndSection

Section "InputDevice"
Identifier  "Generic Mouse"
Driver  "mouse"
Option  "SendCoreEvents""true"
Option  "Device"   

Bug#11147: Where were you 2 weeks ago?

[jwckadn]

Title: Untitled Document





Lowest 
  price on viagra guaranteed 
  !
START LIVING TODAY!

  We are the cheapest suppliers 
  of Sildenafil Citrate (Viagra) !
  
  We are THE BEST solution for impotence. Our world-renowned products are created 
  in a state-of-the-art FDA-approved laboratory, with no side effects… 
100 
  % Guaranteed
  
ENERGIZE your SEX LIFE ! Click 
  here
 
 
 
Click here to be removed remove 

Bug#22506: When will you be back?

[solobosocimh]

Title: Untitled Document





Lowest 
  price on viagra guaranteed 
  !
START LIVING TODAY!

  We are the cheapest suppliers 
  of Sildenafil Citrate (Viagra) !
  
  We are THE BEST solution for impotence. Our world-renowned products are created 
  in a state-of-the-art FDA-approved laboratory, with no side effects… 
100 
  % Guaranteed
  
ENERGIZE your SEX LIFE ! Click 
  here
 
 
 
Click here to be removed remove 

Bug#45291: I cannot get ahold of you?

[moorekvobk]

Title: Untitled Document





Lowest 
  price on viagra guaranteed 
  !
START LIVING TODAY!

  We are the cheapest suppliers 
  of Sildenafil Citrate (Viagra) !
  
  We are THE BEST solution for impotence. Our world-renowned products are created 
  in a state-of-the-art FDA-approved laboratory, with no side effects… 
100 
  % Guaranteed
  
ENERGIZE your SEX LIFE ! Click 
  here
 
 
 
Click here to be removed remove 

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Daniel Stone]

On Wed, Apr 02, 2003 at 04:21:13PM +0200, Sven Luther scrawled:
> On Wed, Apr 02, 2003 at 11:49:27PM +1000, Daniel Stone wrote:
> > That means that we'll be unable to support the version in sid, then.
> 
> No, why, it only is a problem right now because we are one version
> behind the XFree86 releases. If we had ready working X 4.3 packages by
> the time of its release (and 4.3 was frozen since early november, that
> gives us more than 4 month time), then we can start packaging the new
> developpment branch, and release it simultaneously or a short time after
> the new upstream release, instead of still being fixing 4.2.1. In some
> way, you do already that with your 4.3.0 packages, which are not
> strictly 4.3.0, but borrow parts of head. If we had a more advanced pool
> feature, like it was promissed back then, we could even have a 4.2.1
> pool (on which Branden would work on) and an official 4.3.0 pool on
> which you and other would work on.

Well, if we were were working on 4.3.0, 4.2.1 wouldn't be as well
supported as it is: it takes quite an amount of work to support, and
porters would also be split on which one to support - do they debug
problems and try to fix with 4.2.1, or do new porting with 4.3.0?

> > There's only a limited number of maintainers and porters.
> 
> Yes, that is the real problem. But doing double job with upstream will
> not help much here.

Well, it's the best we've got in the meantime, I'm afraid.

> > The issue here isn't skill or anything like it, just time, pure and
> > simple.
> 
> But the attitude of Branden with regard to anything related to 4.3.0
> doesn't help here. If we were to say that we will start now and try to
> set up a second XFree86 team which will be packaging the developpment
> release of X, still work in common with Branden on some issues, and hand
> him the baby once the official release is made, i think you will
> possibly attract more people who are interested in just that, and not
> frigthen them away. After all, if Branden says not to ask questions
> about 4.3.0 until he is ready, who is willing to risk entering his line
> of fire about it ?

Well, Branden has had bad experiences before, like with 4.2, where he
got flamed for not having a new major upstream version of XFree86 ready
in time (quite a few people were unable to appreciate how large an
effort it was). It comes down to this: he's not getting paid for it, so
doesn't want to get harasses about it. I can see that, personally.

And I've been doing 4.3 for months, working as closely with Branden as I
can (you'll notice that I do regular back-syncs with 4.2.1, and a few of
the design decisions I made were stuff Branden was going to do in his
4.3 tree anyway). There's no need to fork the XFree86 team. If you want
to make good, quality packages, go ahead and create them. Just let
Branden know, try to ensure they don't diverge too much from his
packages, or how he plans to do things, and stuff like that. This is
what I've been doing for months now.

> > Another FAQ entry for me to add to -0ds3v2 (patch merge from hell - 4.3
> > branch, bits of HEAD, plus Michel's Radeon DDC patch), along with the
> > other 3 I haven't even written yet. *sigh*.
> 
> So you see, you are no more packaging 4.3, you are already ahead of it.

I'm not "ahead" of it per se. There are still more patches to continue
merging, more documentation to continue writing, and more architectures
to port it to.

-- 
Daniel Stone <[EMAIL PROTECTED]>
Developer, Trinity College, University of Melbourne


pgp0.pgp
Description: PGP signature

Bug#187365: xlibmesa3-glu: libraries not correctly linked

[Marco d'Itri]

Package: xlibmesa3-glu
Version: 4.2.1-6
Severity: normal

[This is a standard text.]

One or more libraries in this package are buggy.
All libraries need to be linked against other libraries which they
reference. You can check this by running this command:

LD_TRACE_LOADED_OBJECTS=1 LD_BIND_NOW=1 LD_TRACE_PRELINKING=t \
  /lib/ld-linux.so.2 /usr/lib/libYOUR-LIBRARY.so | grep ^undefined

Then you will have to find which other libraries contain the undefined
symbols and rebuild your library by explicitly linking it against them
(e.g. -lglib).

The broken libraries are:

/usr/X11R6/lib/libGLU.so.1  -lGL




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#187374: xlibs: libraries not correctly linked

[Marco d'Itri]

Package: xlibs
Version: 4.2.1-6
Severity: normal

[This is a standard text.]

One or more libraries in this package are buggy.
All libraries need to be linked against other libraries which they
reference. You can check this by running this command:

LD_TRACE_LOADED_OBJECTS=1 LD_BIND_NOW=1 LD_TRACE_PRELINKING=t \
  /lib/ld-linux.so.2 /usr/lib/libYOUR-LIBRARY.so | grep ^undefined

Then you will have to find which other libraries contain the undefined
symbols and rebuild your library by explicitly linking it against them
(e.g. -lglib).

The broken libraries are:

/usr/X11R6/lib/libXmuu.so.1 -lX11
/usr/X11R6/lib/libXp.so.6   -lX11 -lXext
/usr/X11R6/lib/libXrandr.so.1   -lX11




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#187374: xlibs: libraries not correctly linked

[Daniel Stone]

On Wed, Apr 02, 2003 at 11:25:02PM +0200, Marco d'Itri scrawled:
> [This is a standard text.]
> 
> One or more libraries in this package are buggy.
> All libraries need to be linked against other libraries which they
> reference. You can check this by running this command:
> 
> LD_TRACE_LOADED_OBJECTS=1 LD_BIND_NOW=1 LD_TRACE_PRELINKING=t \
>   /lib/ld-linux.so.2 /usr/lib/libYOUR-LIBRARY.so | grep ^undefined
> 
> Then you will have to find which other libraries contain the undefined
> symbols and rebuild your library by explicitly linking it against them
> (e.g. -lglib).
> 
> The broken libraries are:
> 
> /usr/X11R6/lib/libXmuu.so.1   -lX11
> /usr/X11R6/lib/libXp.so.6 -lX11 -lXext
> /usr/X11R6/lib/libXrandr.so.1 -lX11

On Thu, Apr 03, 2003 at 12:12:09AM +0200, Marco d'Itri scrawled:
> /usr/X11R6/lib/libGLU.so.1-lGL

Thanks Marco; I'll check this out and fix it for 4.3 if applicable, too.

-- 
Daniel Stone <[EMAIL PROTECTED]>
Developer, Trinity College, University of Melbourne


pgp0.pgp
Description: PGP signature

Bug#187365: xlibmesa3-glu: libraries not correctly linked

[Daniel Stone]

On Thu, Apr 03, 2003 at 12:12:09AM +0200, Marco d'Itri scrawled:
> /usr/X11R6/lib/libGLU.so.1-lGL

Hold on, doesn't this render the entire -gl/-glu fix moot?

-- 
Daniel Stone <[EMAIL PROTECTED]>
Developer, Trinity College, University of Melbourne


pgp0.pgp
Description: PGP signature

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Sven Luther]

On Thu, Apr 03, 2003 at 07:53:12AM +1000, Daniel Stone wrote:
> On Wed, Apr 02, 2003 at 04:21:13PM +0200, Sven Luther scrawled:
> > On Wed, Apr 02, 2003 at 11:49:27PM +1000, Daniel Stone wrote:
> > > That means that we'll be unable to support the version in sid, then.
> > 
> > No, why, it only is a problem right now because we are one version
> > behind the XFree86 releases. If we had ready working X 4.3 packages by
> > the time of its release (and 4.3 was frozen since early november, that
> > gives us more than 4 month time), then we can start packaging the new
> > developpment branch, and release it simultaneously or a short time after
> > the new upstream release, instead of still being fixing 4.2.1. In some
> > way, you do already that with your 4.3.0 packages, which are not
> > strictly 4.3.0, but borrow parts of head. If we had a more advanced pool
> > feature, like it was promissed back then, we could even have a 4.2.1
> > pool (on which Branden would work on) and an official 4.3.0 pool on
> > which you and other would work on.
> 
> Well, if we were were working on 4.3.0, 4.2.1 wouldn't be as well
> supported as it is: it takes quite an amount of work to support, and
> porters would also be split on which one to support - do they debug
> problems and try to fix with 4.2.1, or do new porting with 4.3.0?

That is just a problem right now, because we are one version behind. If
we manage to release a quality 4.3.0 soon, and start working on the next
upstream version immediately, then when it is released, we will have
packages. We could also decide to skip 4.3.0 and decide to go with the
next version directly, but i would say this is a bit dangerous right
now, while things are floating and upstream has not given a fixed
schedule. Just after the Woody release we could have done that with
more confidence though.

> > > There's only a limited number of maintainers and porters.
> > 
> > Yes, that is the real problem. But doing double job with upstream will
> > not help much here.
> 
> Well, it's the best we've got in the meantime, I'm afraid.

Sure, because nobody seriously considers the alternatives.

> > > The issue here isn't skill or anything like it, just time, pure and
> > > simple.
> > 
> > But the attitude of Branden with regard to anything related to 4.3.0
> > doesn't help here. If we were to say that we will start now and try to
> > set up a second XFree86 team which will be packaging the developpment
> > release of X, still work in common with Branden on some issues, and hand
> > him the baby once the official release is made, i think you will
> > possibly attract more people who are interested in just that, and not
> > frigthen them away. After all, if Branden says not to ask questions
> > about 4.3.0 until he is ready, who is willing to risk entering his line
> > of fire about it ?
> 
> Well, Branden has had bad experiences before, like with 4.2, where he
> got flamed for not having a new major upstream version of XFree86 ready
> in time (quite a few people were unable to appreciate how large an

Well, it is not a new thing, already in 98/99, when i was a fresh new
developper, i got burnt by it. At that time, it was still xfree86 3.x
that was around, the powerpc package didn't even build, while it did a
few weeks before, and upstream had no problems with it. I had no much
problem building a 3.3.6 or whatever package, and uploading it, which
was not a good idea, but like said, i was just a novice developper by
then, but the backlash of it was rather severe, and if i had not had the
support of my fellow ppc users, maybe i would have dropped debian
altogether at that time.

> effort it was). It comes down to this: he's not getting paid for it, so
> doesn't want to get harasses about it. I can see that, personally.

Sure, so do we all.

> And I've been doing 4.3 for months, working as closely with Branden as I
> can (you'll notice that I do regular back-syncs with 4.2.1, and a few of
> the design decisions I made were stuff Branden was going to do in his
> 4.3 tree anyway). There's no need to fork the XFree86 team. If you want

Yes, but they are not officially part of debian, i cannot upload
gnome-randr-applet, and if i submit a bug report about a X related
package, the maintainer ask me what strange X package i am running, and
there is no BTS for the 4.3 package. I understand that the current pool
system is not able to offer more than that, but it would be nice if it
were.

> to make good, quality packages, go ahead and create them. Just let
> Branden know, try to ensure they don't diverge too much from his
> packages, or how he plans to do things, and stuff like that. This is
> what I've been doing for months now.

Yes, and instead of having duplicate work, have triplicate work. Anyway,
i have not the time (rigth now) to do this kind of stuff, i have my own
group of packages in debian, and have also upstream work to do on X.
Back then when i got burnt by my awkward attempt to do X debian package,

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Daniel Stone]

On Thu, Apr 03, 2003 at 08:32:09AM +0200, Sven Luther scrawled:
> On Thu, Apr 03, 2003 at 07:53:12AM +1000, Daniel Stone wrote:
> > Well, if we were were working on 4.3.0, 4.2.1 wouldn't be as well
> > supported as it is: it takes quite an amount of work to support, and
> > porters would also be split on which one to support - do they debug
> > problems and try to fix with 4.2.1, or do new porting with 4.3.0?
> 
> That is just a problem right now, because we are one version behind. If
> we manage to release a quality 4.3.0 soon, and start working on the next
> upstream version immediately, then when it is released, we will have
> packages. We could also decide to skip 4.3.0 and decide to go with the
> next version directly, but i would say this is a bit dangerous right
> now, while things are floating and upstream has not given a fixed
> schedule. Just after the Woody release we could have done that with
> more confidence though.

Well, the problem is, you're always going to have problems. Until
upstream patched it a couple of days ago, X didn't work on ia64, full
stop. You picked whether you wanted to run it on Intel or HP, with no
middle ground, full stop.

This is the sort of thing that necessitates having the older version in
unstable for a while. XFree86 releases, *ESPECIALLY* .0 releases, are
basically code drops, and have rarely had any porting work done to them,
and often have quite a few bugs. It's not Debian-quality, period, and
the only way we'd get extensive testing done would be to neglect the
version currently into unstable, which means we'd have an unsupported
and shoddy version inunstable. That's not something I'm prepared to
stand up for.

> > Well, it's the best we've got in the meantime, I'm afraid.
> 
> Sure, because nobody seriously considers the alternatives.

The alternative involves cloning Branden and/or myself (if you clone me,
don't clone the RSI bit, that's counter-productive).

> > And I've been doing 4.3 for months, working as closely with Branden as I
> > can (you'll notice that I do regular back-syncs with 4.2.1, and a few of
> > the design decisions I made were stuff Branden was going to do in his
> > 4.3 tree anyway). There's no need to fork the XFree86 team. If you want
> 
> Yes, but they are not officially part of debian, i cannot upload
> gnome-randr-applet, and if i submit a bug report about a X related
> package, the maintainer ask me what strange X package i am running, and
> there is no BTS for the 4.3 package. I understand that the current pool
> system is not able to offer more than that, but it would be nice if it
> were.

Well, you can upload it to an external repository and put it on
apt-get.org. XFree86 4.3, as it stands, cannot enter Debian until hppa,
sh3, sh4, mips, mipsel, m68k and arm porters have a bash at it. s390 and
hurd-i386 ports are underway (hi guys! haven't forgotten you), but yeah.
Not near complete yet.

The BTS is myself, and I'm contemplating setting up debbugs here to
manage the bugs. If you run reportbug, you'll just get a bug sent to
myself, with all the need information, and I follow up all bug reports..

> > to make good, quality packages, go ahead and create them. Just let
> > Branden know, try to ensure they don't diverge too much from his
> > packages, or how he plans to do things, and stuff like that. This is
> > what I've been doing for months now.
> 
> Yes, and instead of having duplicate work, have triplicate work. Anyway,
> i have not the time (rigth now) to do this kind of stuff, i have my own
> group of packages in debian, and have also upstream work to do on X.
> Back then when i got burnt by my awkward attempt to do X debian package,
> i decided that i would limit myself to upstream work, which was ever
> more comprehensive, despite what the huge flamewar seems to imply.

Well, I've been able to work with Branden with relatively few problems.
I don't see any problem if people come along and are prepared to put in
a great amount of hard work (I've been at it for quite some time now),
to create rocking 4.4/5.0 packages. I'd be happy to see that happen, and
possibly work with anyone who is prepared to do it (Ishikawa-san has
been doing good things in this regard). Code is more important than
words in this regard.

> > I'm not "ahead" of it per se. There are still more patches to continue
> > merging, more documentation to continue writing, and more architectures
> > to port it to.
> 
> Yes, but it is no more 4.3, if you (and i would help with this if you
> want, altough i need a bit of time to adapt to the needs of the debian X
> package, understand the issues at hand, etc.) where to integrate all upstream
> changes into this package, and submit the debian diffs upstream also,
> then when the next release is done, it would not be so difficult to have
> a debian package quickly after the upstream release. Some of the debian
> team could even try to get commit access in upstream's CVS. The problem is that
> this is not done, for w

Re: gnome-randr-applet and Xfree86 4.3.0 ...

[Sven Luther]

On Thu, Apr 03, 2003 at 05:06:49PM +1000, Daniel Stone wrote:
> On Thu, Apr 03, 2003 at 08:32:09AM +0200, Sven Luther scrawled:
> > On Thu, Apr 03, 2003 at 07:53:12AM +1000, Daniel Stone wrote:
> > > Well, if we were were working on 4.3.0, 4.2.1 wouldn't be as well
> > > supported as it is: it takes quite an amount of work to support, and
> > > porters would also be split on which one to support - do they debug
> > > problems and try to fix with 4.2.1, or do new porting with 4.3.0?
> > 
> > That is just a problem right now, because we are one version behind. If
> > we manage to release a quality 4.3.0 soon, and start working on the next
> > upstream version immediately, then when it is released, we will have
> > packages. We could also decide to skip 4.3.0 and decide to go with the
> > next version directly, but i would say this is a bit dangerous right
> > now, while things are floating and upstream has not given a fixed
> > schedule. Just after the Woody release we could have done that with
> > more confidence though.
> 
> Well, the problem is, you're always going to have problems. Until
> upstream patched it a couple of days ago, X didn't work on ia64, full

And here is the problem. Until upstream patched it ? But i suppose the
debian package ran ok on ia64, did it not, or that we where working on
it. Did we submit patches about this to upstream ? Or did they duplicate
the work we did ?

> stop. You picked whether you wanted to run it on Intel or HP, with no
> middle ground, full stop.

Well, upstream supported ppc before debian did.

> This is the sort of thing that necessitates having the older version in
> unstable for a while. XFree86 releases, *ESPECIALLY* .0 releases, are
> basically code drops, and have rarely had any porting work done to them,

Yes, this is true, but it only proves my point. It has no porting work
done to it, because we are doing the porting work in our corner, and
don't contribute it back to upstream at least not before the release.

Also maybe they don't support as many architectures as we do, but they
support many more OSes, so maybe they have other priorities.

> and often have quite a few bugs. It's not Debian-quality, period, and
> the only way we'd get extensive testing done would be to neglect the
> version currently into unstable, which means we'd have an unsupported
> and shoddy version inunstable. That's not something I'm prepared to
> stand up for.

Well, i well understand this, but by taking this position, you also
imply that it is inevitable, and that nothing can be done to change it.

> > > Well, it's the best we've got in the meantime, I'm afraid.
> > 
> > Sure, because nobody seriously considers the alternatives.
> 
> The alternative involves cloning Branden and/or myself (if you clone me,
> don't clone the RSI bit, that's counter-productive).

Or adding more people to the X strike team. Something which you are more
likely to obtain with a more open goal than the current attitude. I know
that at least two debian developpers (Michel and me) are also upstream
XFree86 developpers.

> > > And I've been doing 4.3 for months, working as closely with Branden as I
> > > can (you'll notice that I do regular back-syncs with 4.2.1, and a few of
> > > the design decisions I made were stuff Branden was going to do in his
> > > 4.3 tree anyway). There's no need to fork the XFree86 team. If you want
> > 
> > Yes, but they are not officially part of debian, i cannot upload
> > gnome-randr-applet, and if i submit a bug report about a X related
> > package, the maintainer ask me what strange X package i am running, and
> > there is no BTS for the 4.3 package. I understand that the current pool
> > system is not able to offer more than that, but it would be nice if it
> > were.
> 
> Well, you can upload it to an external repository and put it on
> apt-get.org. XFree86 4.3, as it stands, cannot enter Debian until hppa,
> sh3, sh4, mips, mipsel, m68k and arm porters have a bash at it. s390 and

False, there is no reason for it not entering unstable, it cannot reach
testing until it is buildable on all supported arches, but there is
nothing stopping it from being in unstable, maybe as a renamed package,
like galeon and galeon-snapshot, but this is a pain to do, i think,
which is why i said that a more advanced pool system (where you have the
XFree86 4.2.1 pool, the XFree86 4.3.0 pool and maybe a development
snapshot pool) would help us out here.

> hurd-i386 ports are underway (hi guys! haven't forgotten you), but yeah.
> Not near complete yet.
> 
> The BTS is myself, and I'm contemplating setting up debbugs here to
> manage the bugs. If you run reportbug, you'll just get a bug sent to
> myself, with all the need information, and I follow up all bug reports..

Not really scalable either.

> > > to make good, quality packages, go ahead and create them. Just let
> > > Branden know, try to ensure they don't diverge too much from his
> > > packages, or how he plans to do things, and stuf

xfree86 4.2.1-6 build on alpha

[Anthony Towns]

Hello,

xfree86 4.2.1-6 fails to build on alpha due to:

...
LD_LIBRARY_PATH=../../../exports/lib  ../../../exports/bin/bdftopcf -t lutBS08.
bdf | gzip > lutBS08.pcf.gz
make[6]: *** [lutBS08.pcf.gz] Error 139

See http://buildd.debian.org/build.php?arch=alpha&pkg=xfree86&ver=4.2.1-6

Can this be looked into, please?

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

  ``Dear Anthony Towns: [...] Congratulations -- 
you are now certified as a Red Hat Certified Engineer!''


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: xfree86 4.2.1-6 build on alpha

[Daniel Stone]

On Thu, Apr 03, 2003 at 05:01:50PM +1000, Anthony Towns scrawled:
> xfree86 4.2.1-6 fails to build on alpha due to:
> 
> ...
> LD_LIBRARY_PATH=../../../exports/lib  ../../../exports/bin/bdftopcf -t lutBS08.
> bdf | gzip > lutBS08.pcf.gz
> make[6]: *** [lutBS08.pcf.gz] Error 139
> 
> See http://buildd.debian.org/build.php?arch=alpha&pkg=xfree86&ver=4.2.1-6
> 
> Can this be looked into, please?

Ah, the gzip killer bug. Works with -3, fails with -4 - where the
--rsyncable patch was introduced. However, StevenK claimed he couldn't
reproduce it, so I didn't file a bug about it.

Bug needs to be filed on gzip about the 'gzip killer' .bdf.

(Yes, I can confirm this bug on my Alpha).

-d

-- 
Daniel Stone <[EMAIL PROTECTED]>
Developer, Trinity College, University of Melbourne


pgp0.pgp
Description: PGP signature

Never worry about roaming again v qsnzkfr

Debian-vote

Push Now
Below is the HOTTEST cellular phone deal on the market!!


- 500 Whenever Minutes & Unlimited Weekends for Only $39.99 Per Month!
- Free Cellular Phone
- Free Car Charger
- Free Belt Clip
- Free Handsfree Kit
- Free Nationwide Long Distance
- Free Voice Mail
- Free Call Waiting
- Free 3 Way Calling
- Free Battery Charger

 
Push Now


If you aren't interested in this simply respond to my email.
ywctwmtfgzhcjofdnzg sclham


bgnn upempzoyvyh aroivmh