Bug#2297: Tested, verified in xterm, konsole

[Nathanael Nerode]

You can run "trickle" on a single machine by ssh'ing to localhost.  :-)

I can reproduce this behavior with xterm, getting the paste to come
through after the return key even though
the return key was hit first.  konsole shows different, but very
similar behavior:
the fast konsole drops the paste request on the floor -- the paste
never happens --
when the return key comes through ahead of the paste request.

Which behavior is better?

This does apply to pretty much every X application which handles paste requests;
so I think this is a matter of"best failure mode".


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

Bug#2297: Able to reproduce, behavior of other terminal emulators, thoughts?

[Nathanael Nerode]

I tested this scenario with xterm, and reproduced it (thanks to trickle; 
incidentally it's actually possible to use trickle on a single machine: ssh
from the machine to itself)

Then I tested it with a fast konsole.  Interestingly, I don't get exactly the 
same behavior.  But I do get a similar bug.  konsole drops the pasted text
on the floor when the return key comes through first; it just gets lost.

Is this better or worse behavior than xterm's behavior?

Since this problem is common to all X apps which use selections, I think the 
best
we can do is choose a "best failure mode".  This may well be a "wontfix".  
Thoughts?

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Make sure your vote will count.
http://www.verifiedvoting.org/


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

Bug#303146: Closing bug with no response

[Nathanael Nerode]

close 303146
thanks

This bug was pinged in 2005 and the submitter didn't respond.  It appears to
be a bug which only happens with misconfiguration.  This shouldn't remain open.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Make sure your vote will count.
http://www.verifiedvoting.org/


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

Bug#232345: Control sequences document now not located anywhere

[Nathanael Nerode]

retitle 232345 xterm: Control sequences document is not installed anywhere
severity 232345 important
thanks

Well, this old bug has actually gotten *worse*.  While xterm (1) refers 
repeatedly to the control sequences document, now that document is not located
*anywhere* in the files installed by Debian's 'xterm' package.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Make sure your vote will count.
http://www.verifiedvoting.org/


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

Bug#12261: Followup, possible patch for second oldest bug in xterm

[Nathanael Nerode]

This bug still exists in current xterm, as far as I can tell.

The following untested patch implements Richard Braakman's suggestion from 1997,
slightly more portably.

Open questions:
(1) Where should the logging be closed?
(2) Is any additional portability goo needed to send this upstream (e.g. for 
systems without termios.h)?
(3) Is anyone interested in testing it?

I assign these changes to the public domain, since they're trivial.

--- main.c  2007-04-10 04:39:13.0 -0400
+++ main.c.new  2007-04-10 04:56:45.0 -0400
@@ -4613,11 +4613,9 @@
 #endif /* USE_SYSV_UTMP */
 #endif /* HAVE_UTMP */
 
-close(screen->respond);/* close explicitly to avoid race with slave 
side */
-#ifdef ALLOWLOGGING
-if (screen->logging)
-   CloseLog(screen);
-#endif
+/* Flush pending data before releasing ownership, so nobody else can
+   grab it */
+tcflush(screen->respond, TCOFLUSH);
 
 if (am_slave < 0) {
/* restore ownership of tty and pty */
@@ -4625,6 +4623,16 @@
 #if (defined(USE_PTY_DEVICE) && !defined(__sgi) && !defined(__hpux))
set_owner(ptydev, 0, 0, 0666U);
 #endif
+
+   /* Close after releasing ownership to avoid race condition: other programs 
+  grabbing it, and *then* having us release ownership... */
+
+close(screen->respond);/* close explicitly to avoid race with slave 
side */
+#ifdef ALLOWLOGGING
+if (screen->logging)
+   CloseLog(screen);
+#endif
+
 }
 #ifdef NO_LEAKS
 if (n == 0) {

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

This space intentionally left blank.



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

Re: Processed: Reassigning xserver-xfree86 bugs

[Nathanael Nerode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michel Dänzer wrote:
> [ Did you intentionally not CC: debian-x? Feel free to quote this
> there. ]
No, I'm just very bad at Cc:ing properly. Redirecting.

> On Sat, 2006-06-10 at 19:14 -0400, Nathanael Nerode wrote:
>>> and because it removes their
>>> association with the old packages which are now gone in sid and testing
>>> but which are still in stable and most likely still affected by them. 
>> They're not going to be fixed in stable if they're still present there,
>> though, because of the stable update policy leaving them assigned to
>> a package where they won't ever be fixed is sort of a recipe for
>> ignoring them.
> 
> Maybe, but it also helps prevent them from getting reported again
> against the packages in stable.
> 
> OTOH, I can say that old bugs cluttering up the current packages doesn't
> exactly motivate me to work even on the current bugs... but maybe that's
> just me.
> 
> 
>>> The other XSF folks may not agree on this, but at any rate I think at
>>> least a set of clear rules on how to handle this would be good.
>> I kind of realized this after I'd started, hence stopping partway
>> through.  Sorry I didn't realize it earlier there's a very large
>> volume of bugs here, and we do indeed have to come up with some sensible
>> way to deal with them.  I managed to spot some which were definitely
>> fixed upstream and close them while I was at it.
>>
>> I'd rather not just close them all perhaps we should go on a more
>> systematic effort to contact the submitters and close the ones where we
>> don't get replies?
> 
> Yeah, basically, I think we should only reassign bugs to the current
> packages that have been confirmed to still be there. Then, once a
> package goes away completely, close all its bugs that were attempted to
> be confirmed without success.
OK.  It's significantly easier to close the bugs one at a time as they
are "unconfirmed" because it allows me to keep track of which ones I've
checked and which ones I haven't.  That OK?

> 
> 
>> FYI, The bugs which I *retitled* are bugs which have been proven to
>> still be present.  (Showing that some of the bugs are definitely still
>> present.  :-/)  The ones which still have "xserver-free86" in the title
>> are the ones which haven't been checked yet.  In case you needed to tell
>> the difference.
> 
> Nice.
> 
> 

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

iD8DBQFEmDXvRGZ0aC4lkIIRAt0NAJ9jLNt/ck5x8ml3g8VBNWSAyF7ExACcCLpX
EvzwtUPIdb2Z365uAuLQFDQ=
=xKcr
-END PGP SIGNATURE-


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

Bug#368565: mesa-utils: Copyright file appears to be almost entirely wrong

[Nathanael Nerode]

Package: mesa-utils
Severity: serious
Justification: Policy 2.3

Looking at the actual files, they are mostly

Copyright (C) 1999-2001  Brian Paul   All Rights Reserved.

(Some have fewer years; that's the union of the years.)
One of these (opencloseopen.c) is additionally

 * (C) Copyright IBM Corporation 2003

All of these files have the license:
---

 * 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
 * BRIAN PAUL 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.
-

One file (offset.c) is copyrighted and licensed as follows:
-
Copyright 1995 by Silicon Graphics Incorporated, Mountain View, California.

All Rights Reserved

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation, and that the name of Silicon Graphics not be
used in advertising or publicity pertaining to distribution of the
software without specific, written prior permission.

SILICON GRAPHICS DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
EVENT SHALL SILICON GRAPHICS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR
OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THIS SOFTWARE.


In addition, some files are by Brian Paul and put in the public domain 
by him.

The above needs to be documented in the debian/copyright file.

A few files (glxpbdemo.c, pbdemo.c, pbutil.c, pbutil.h) are by Brian Paul and 
have no explicit license (contact him; I'm sure he'll either license them along
with the other files, or put them in the public domain.)

descrip.mms (only used under VMS) has no license and is
"contributed by Jouk Jansen  [EMAIL PROTECTED]"

yuvrect.h has no license and is "Dave Airlie - Feb 2005".

Makefile and xuserrotfont.h have no copyright statement, authorship statement, 
or 
license.

These files are technically undistributable until licenses are obtained.  I am 
sure
that this was not the intention of the authors, and I suspect that a little 
research
would identify the origins of these files and might indicate the correct 
licenses.

Unfortunately, the debian/copyright file says:
--

Copyright 1989,1998  The Open Group

Permission to use, copy, modify, distribute, and sell this software and its
documentation for any purpose is hereby granted without fee, provided that
the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting
documentation.

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
OPEN GROUP 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 Open Group 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 Open Group.

---

This is just wrong.  I suppose it might possibly be true of the files without 
licenses,
but with the Brian Paul files, either this is wrong or the actual files are 
wrong,
and I'm inclined to believe the actual files.

So the debian/copyright file is apparently just totally wrong.  Please replace 
it
with something more accurate.


-- 
To UNSUBSCRI

Bug#368563: xorg-server: debian/copyright missing SGI Free Software License B

[Nathanael Nerode]

Package: xorg-server
Severity: serious
Justification: Policy 2.3

Do a search for "/FreeB".  The source package contains a bunch of code under 
this
license, but the license is not in the debian/copyright file.  (Indeed, it's not
even in the package -- the license header points to a URL, and you have to go to
that URL to find the actual license.)

This bug is independent of the bug regarding the freeness of code under this 
license
(and the GLX Public License).


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

Bug#368558: x11proto-gl: debian/copyright does not contain actual licenses

[Nathanael Nerode]

Package: x11proto-gl-dev
Severity: serious
Justification: Policy 2.3

The copyright file contains a copy of the license notices from the top of the
header files.  So far so good.  HOWEVER, those notices do not contain the actual
licenses.  They merely refer to them by reference:

http://oss.sgi.com/projects/FreeB
and
http://www.sgi.com/software/opensource/glx/license.html

Policy requires that an actual verbatim copy of each license be included in the 
package.
Neither license is in fact included in the package.

(This is also quite dangerous; if those websites ever vanish, we have *no* 
license.)

The FreeB license is available upstream only in two rather inconvenient formats:
Postscript and Microsoft Word.  Nevertheless, including the Postscript version 
is
far better than the current situation.

Unfortunately, it is not entirely clear that we actually have permission to 
redistribute the text of the FreeB license.  Does anyone have a contact 
at SGI?

This bug is independent from the bug regarding the freeness of these licenses.


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

Bug#211765: Where have these files gone?

[Nathanael Nerode]

With the modular split of Xorg 7, these files have probably scattered to 
different packages.

Can someone suggest a good strategy for figuring out which packages currently 
contain the affected files?  I don't want to download every single package 
source one at a time and grep through it, but I'll do it if that's the only 
way.  I also suspect that most of the files have gone to a small number of 
packages, and that a fair number of them may have disappeared (the 
Imakefiles).

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Theocracy, fascism, or absolute monarchy -- I don't care which it is, I don't 
like it.


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

Bug#346377: xterm: Now that manpages are in /usr/share/man, they should drop the .1x

[Nathanael Nerode]

Package: xterm
Version: 208-1
Severity: minor

Now that all the xterm manpages are installed in /usr/share/man/man1 instead
of in /usr/X11R6/man/man1, I believe they should drop the '1x' suffix and
revert to '.1'.  Right?

-- remove the appropriate part of debian/patches/901_xterm_manpage.diff
   (the part which changes it from '1' to '1x')
-- rename the three manpages in debian/local from .1x to .1
-- and change their internal references to remove the 'x'
-- remove the 'manext=1x' bit from the main "$(MAKE) install"
   line in debian/rules
-- fix all the references in debian/rules to the manpages in debian/local,
   so they refer to them by the correct names

I think this is all that needs to be done.


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

Bug#2297: Is there a way to reproduce this on a single machine?

[Nathanael Nerode]

In order to test whether this affects other terminal emulators,  I'd like to 
create a "slow konsole" and a "fast konsole", but I don't see how to create 
them both on one machine.  Is there a way to artificially slow an xterm (or a 
konsole) to a crawl so that it behaves as if it's at the other end of a 14.4K 
link?

Reply to bug trail please.


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

#725 FIXED!!!!

[Nathanael Nerode]

close 725 6.9.0.dfsg.1-1
thanks

# Yay!

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

[Insert famous quote here]


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

Re: XSF Homepage -> wiki.debian.org

[Nathanael Nerode]

Anyone who does this please maintain copyright and licensing cleanliness
for the web page.  Get the copyright statement and a license from Branden 
(presumably it'll be MIT/X11 licensed), and make a note that any new material 
added by wiki editors must be licensed under the same terms.

Most of wiki.debian.org is not properly licensed, and it would be nice if the 
X Strike Force could maintain its traditional high licensing standards.


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

Bug#14940: Can you still reproduce Debian bug 14940

[Nathanael Nerode]

It's very old, Branden can't reproduce it, and if you the submitter can't,
perhaps it should be closed.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

This space intentionally left blank.



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

Bug#14940: Antique xserver bug

[Nathanael Nerode]

tags 14940 +unreproducible
submitter 14940 [EMAIL PROTECTED]
thanks

Raul, can you reproduce this antique bug, or should we close it?

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

This space intentionally left blank.



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

Experimental packages can close bug 725

[Nathanael Nerode]

Bug 725 is fixed in the upstream which is being packaged in experimental.

So a "Closes: #725" should be added to the changelog for the xorg-x11 versions
in experimental.  :-)

The bug's only 10 years old now it would be a nice touch.


-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

[Insert famous quote here]


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

Re: [tex-live] Re: License of fonts included in X.org sources

[Nathanael Nerode]

Daniel Stone wrote:

> On Thu, Oct 20, 2005 at 08:21:08PM +0200, Reinhard Kotucha wrote:
>> > "Daniel" == Daniel Stone <[EMAIL PROTECTED]> writes:

>> Maybe it is sufficient to find someone at X.org who is willing to care
>> about the legal stuff.  It is a great advantage that Thanh found
>> someone at Adobe who remembers.


> It may have been granted to:
>   * the defunct MIT-based X Consortium,
>   * directly to The Open Group,
>   * X.Org as part of TOG,
>   * X.Org Foundation.
> 
> All the XOF people swear that they haven't heard of it.  If it's
> trapped in XC, then we're stuffed.  If it's deep within the annals of
> TOG, then they don't know about it on a surface inspection, and it
> would take absolutely ages to find out either way.  If it's within
> TOG-X.Org, then no-one who was around during those days knows about it,
> so it's likely been lost.
> 
> See the problem?
Perhaps Thanh's man from Adobe can track down the original Adobe paperwork,
which would say who it was granted to (and what was granted).  That seems
like the most promising route.

-- 
ksig --random|


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

Re: [tex-live] Re: License of fonts included in X.org sources

[Nathanael Nerode]

Ralf Stubner wrote:

> I digged into groups.google.com and found the original press release:
> 
>
http://groups.google.de/group/comp.windows.x/browse_thread/thread/d351921a604a4039/a3e406813544b498
> 
> Mountain View, Calif. (October 9, 1991) - Adobe Systems Incorporated today
> announced it has donated four typefaces from its Utopia(R) typeface family
> in Adobe's Type 1 font format to the Massachusetts Institute of
> Technology's X Consortium.
> []
> 
> Of course, it says nothing about the license agreement between Adobe and
> the MIT X Consortium. There are several quotes from the README as found
> in X11R5:
> 
>
http://groups.google.de/group/comp.fonts/browse_thread/thread/e9fb6bf9e7307b55/0fb5cf456fc7c5bb
>
http://groups.google.de/group/comp.fonts/browse_thread/thread/f220077dbf0a69e0/dcce8a6a0702ffdb
>
http://groups.google.de/group/comp.fonts/browse_thread/thread/66b0e1a98caf514f/c3f51fb7aa5641af
> 
> ,
> | In the interests of furthering standards for the X Window System, Adobe
> | Systems Incorporated has contributed to the X Consortium and its members
> | the Adobe typeface software listed below. This Adobe Type 1 font
> | software donation will now allow users to experience and freely use
> | traditional high-quality Adobe type in the X Window environment.
> | 
> | Permission to use, reproduce, display and distribute the listed
> | typefaces is hereby granted, provided that the Adobe Copyright notice
> | appears in all whole and partial copies of the software and that the
> | following trademark symbol and attribution appear in all unmodified
> | copies of the software:
> | 
> | Copyright (c) 1989 Adobe Systems Incorporated
> | Utopia (R)
> | Utopia is a registered trademark of Adobe Systems Incorporated
> | 
> | The Adobe typefaces (Type 1 font program, bitmaps and Adobe Font Metric
> | files) donated are:
> | 
> | Utopia Regular
> | Utopia Italic
> | Utopia Bold
> | Utopia Bold Italic
> | 
> | Adobe Systems Incorporated
> `

OK, based on this, Adobe still holds the copyrights.  It hasn't granted
explicit modification permission -- but appears to have intended to, given
the word 'unmodfied' in the trademark clause.

Perhaps we could simply ask Adobe's legal department for a clarification
that this license means that we can make and redistribute modified
versions.  I think we should be able to get these fonts in Debian proper.

> Which is more or less what we have on CTAN now. I think it would be good
> if this were readded to the X.org CVS, so that the utopia fonts could be
> included in xfonts-scalable-nonfree again.
> 
> Of course, asking Adobe to clarify the situation would be even better.

-- 
ksig --random|


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

Re: X Strike Force X.Org X11 SVN commit: r385 - trunk/debian

[Nathanael Nerode]

>   Do not forget the gcc-4.0/libvgahw.a bug as well. I would like to ship 
> well-built code in testing. As Eugene stated a couple of days ago, there are 
> spreaded volatile's all along the code, not only in libvgbahw.a.

Yeah.  Well, my proposed change to the macros in compiler.h should catch most 
if not all of them!  You want me to work on it now?  :-)


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

Re: Procedure reminders on updating a lib package for a C++ ABI change

[Nathanael Nerode]

Marcello Magellon wrote:
> Keyword: implemented.
>
> All of GLU's interfaces are C, not C++, so "transitioning" libGLU is
> ill-advised at best.

Hmm.  I guess if libGLU *uses* C++ interfaces, but does not *export* any C++ 
interfaces, then it's effectively a program, not a library, for the purposes 
of the ABI change; it needs to be recompiled, but nothing depending upon it 
does.  Is that what's going on here?  Fun.  That's a corner case none of us 
thought of.

...but wait.  If this is the case, isn't there a potential problem when a C++ 
program uses libGLU?  Couldn't we end up with conflicting symbols from two 
different versions of libstdc++, one linked into libGLU and the other linked 
into the program which uses libGLU, and therefore possibly get unreliable or 
incorrect linkage at runtime?  Or is libstdc++ using versioned symbols (in 
which case that can't happen)?

--Nathanael


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

Re: Procedure reminders on updating a lib package for a C++ ABI change

[Nathanael Nerode]

I just checked.  Indeed it appears that libstdc++ uses versioned
symbols.  :-)  So the conflict I was thinking of can't happen, and so it is
OK to Provides: libglu1.  :-)

--
Don't say I didn't warn you.


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

Bug#315195: *xterm manpages

[Nathanael Nerode]

> Fix xterm postinst script to setup proper manpage alternatives for
> x-terminal-emulator, as *xterm.1.gz have changed to *xterm.1x.gz in
> xorg (Closes #315195).

Um.  I think we want them to be xterm.1.gz, not xterm.1x.gz, and we should fix 
*that*.  Right?


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

Bug#318218: Thoughts :-)

[Nathanael Nerode]

This can probably be fixed by changing the following stanza from
xc/programs/Xserver/hw/xfree86/common/compiler.h:

# else /* !__alpha__ && !__powerpc__ && !__sparc__ */

#  define MMIO_IN8(base, offset) \
*(volatile CARD8 *)(((CARD8*)(base)) + (offset))
#  define MMIO_IN16(base, offset) \
*(volatile CARD16 *)(void *)(((CARD8*)(base)) + (offset))
#  define MMIO_IN32(base, offset) \
*(volatile CARD32 *)(void *)(((CARD8*)(base)) + (offset))
#  define MMIO_OUT8(base, offset, val) \
*(volatile CARD8 *)(((CARD8*)(base)) + (offset)) = (val)
#  define MMIO_OUT16(base, offset, val) \
*(volatile CARD16 *)(void *)(((CARD8*)(base)) + (offset)) = (val)
#  define MMIO_OUT32(base, offset, val) \
*(volatile CARD32 *)(void *)(((CARD8*)(base)) + (offset)) = (val)

OK.  The problem with this is that the cast to volatile CARD8* (et al) doesn't 
create a volatile object from the point of view of GCC4.  (GCC4 may be wrong 
here.)  However, code like the following, if I'm not mistaken, *does* create 
a volatile object, and GCC4 notices:

static inline unsigned char
xorgReadMmio8(volatile void * base, const unsigned long offset)
{
  volatile CARD8 * tmp;
  tmp = (CARD8*)base + offset;
  return *tmp;
}
#define MMIO_IN8(base, offset) xorgReadMmio8(base, offset)

(Based on a little testing of simplified code, GCC is smart enough to optimize 
away nearly everything in this, leaving nicely optimized assembly which still
does the memory read, even when the resulting data is never accessed.)

So a consistent replacement along these lines should do the trick.
Shall I whip up a patch?


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

Re: C++ Transition Patches

[Nathanael Nerode]

Daniel Stone wrote:
>Er, you don't get to choose.  The DDX driver nominates which DRI module
>to load, and libGL loads it.  The only chance of confusion is people
>upgrading xserver-xorg but not xlibmesa-dri, in which case you're going
>to get exactly what you deserve.
I was thinking of people saying "I had acceleration and now I don't, what 
happened?"

>> I worry about the masses of dropped dependencies on
>> xfree86-common/x11-common though.  It doesn't look correct to me, but
>> perhaps /etc/init.d/x{free86|11}-common and /etc/X11/Xsession.d really
>> aren't needed by (for instance) libice6.
>
>No.  No, they aren't.

Oh, good.  :-)  I was wondering about the ICE socket directory, which is set 
up in /etc/init.d/x11-common, but I suppose libice6 doesn't use it directly?

Now, what does libx11-6 need x11-common for?... does it need the server socket 
directory, or does it need Xsession.d?  The rest of x11-common is actually 
man pages and the like, but that presumably doesn't justify a Depends: 
anywhere.

I'm also awfully curious as to what part of xutils depends on x11-common.  
Because the only three packages left depending on x11-common are 
xserver-common, libx11-6, and xutils.


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

Bug#725: Forwarded upstream

[Nathanael Nerode]

I forwarded this bug upstream to x.org, with patch, as
freedesktop.org bug number 3754.

-- 
Nathanael Nerode  
Doom!  Doom!


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

Re: C++ Transition Patches

[Nathanael Nerode]

xfonts-base lost an encoding:
/usr/X11R6/lib/X11/fonts/encodings/large/jisx0208.1983-0.enc.gz
xlibs lost:
/etc/X11/xkb/geometry/omnibook
/etc/X11/xkb/symbols/ru_yawerty

I don't know what to make of those changes; they're presumably upstream
changes and not to be worried about?

The i830 and ffb DRI modules vanished, while the i915 and sis modules
appeared.  This is probably due to upstream, but I'm sure this ought to
be documented somewhere, so as not to totally confuse people (if any)
using the vanished modules.  Probably in NEWS.

xlibs-static-dev acquired:
/usr/X11R6/include/X11/XprintAppUtil/xpapputil.h
/usr/X11R6/include/X11/XprintUtil/xprintutil.h
/usr/X11R6/lib/libXprintAppUtil.a
/usr/X11R6/lib/libXprintUtil.a

xlibs-static-pic acquired:
/usr/X11R6/lib/libXprintAppUtil_pic.a
/usr/X11R6/lib/libXprintUtil_pic.a

Is this right?  Are we deliberately suppling X.org's version of
libXprint in this form?  If so, it should be listed in the descriptions
of the packages, and it isn't.

OK, that's the last nitpick.  I wouldn't hold up the release to unstable
for most of them, but they should be looked at before the next release.

I worry about the masses of dropped dependencies on
xfree86-common/x11-common though.  It doesn't look correct to me, but
perhaps /etc/init.d/x{free86|11}-common and /etc/X11/Xsession.d really
aren't needed by (for instance) libice6.


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

Re: C++ Transition Patches

[Nathanael Nerode]

David Nusinow wrote:
> On Sun, Jul 10, 2005 at 01:17:32AM -0400, Nathanael Nerode wrote:
> 
>>>If I get packages built that are ready to go, I can post them with
>>>source on my repo for people to check over before upload to unstable if
>>>they like
>>
>>Do that; I'll give them a once-over.
> 
> 
> Ok, I just checked upgrades from both unstable (although I had to fight
> with libisgc++ a bit in the chroot) and the previous experimental packages
> and both worked well. We seem to be good to go. Please let me know ASAP if
> they pass muster. I'd love to get them uploaded today if possible, or
> barring that tomorrow. I want to give the debconf attendees something to
> celebrate :-)
> 
>  - David Nusinow
> 

Stupid typo in the control file for libxp6-dbg:
+Description: X Window System printing extension library (unstripped)
+ his package is useful to provide a backtrace with symbol names in a

Should be "This package", of course.  Caught with debdiff.


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

Re: C++ Transition Patches

[Nathanael Nerode]

* Previously-mentioned problems with leftover xprt-xprintorg references

* A lot of packages (all the libs, lbxproxy, possibly others) lost
dependencies on xfree86-common and didn't gain dependencies on
x11-common.  Please check that that is really correct!

Must go eat.  More later this evening.


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

Re: C++ Transition Patches

[Nathanael Nerode]

David Nusinow wrote:
> On Sun, Jul 10, 2005 at 01:17:32AM -0400, Nathanael Nerode wrote:
> 
>>>If I get packages built that are ready to go, I can post them with
>>>source on my repo for people to check over before upload to unstable if
>>>they like
>>
>>Do that; I'll give them a once-over.
> 
> 
> Ok, I just checked upgrades from both unstable (although I had to fight
> with libisgc++ a bit in the chroot) and the previous experimental packages
> and both worked well. We seem to be good to go. Please let me know ASAP if
> they pass muster. I'd love to get them uploaded today if possible, or
> barring that tomorrow. I want to give the debconf attendees something to
> celebrate :-)
> 
>  - David Nusinow
> 

Did you get my previous message?

There are two stupid and trivial leftover references to xprt-xprintorg
which should be changed to xprint; one in NEWS, and one in the
dependencies of x-window-system.


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

Re: C++ Transition Patches

[Nathanael Nerode]

>If I get packages built that are ready to go, I can post them with
>source on my repo for people to check over before upload to unstable if
>they like

Do that; I'll give them a once-over.


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

Re: Bug#317024: xdm: Please turn on SELinux support

[Nathanael Nerode]

David Nusinow wrote:

> On Tue, Jul 05, 2005 at 11:59:23AM -0500, Manoj Srivastava wrote:
>  
>> Bug#233551 added support for SELinux, but turned it off by
>>  default. (Thanks for incrporating the patch, BTW). However, for Etch,
>>  I think the time has come to compile in the SELinux support by
>>  default; dpkg and ssh already support it, and logrotate/coreutils
>>  shall follow suit soon.
>> 
>> I think all that needs be done is that the default for
>>  HasSELinux in XFree86ServerOSDefines be reversed.

Also
Build-Depends: libselinux1-dev
would be needed.

-- 
Don't say I didn't warn you.


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

Re: X Strike Force X.Org X11 SVN commit: r317 - in trunk/debian: . patches

[Nathanael Nerode]

David Nusinow wrote:

> On Tue, Jul 05, 2005 at 11:40:59PM -0500, X Strike Force SVN Repository
> Admin wrote:
>> Log:
>> - Patch audit
>>   - 913_debian_remove_code_ref_to_object_code_files.diff ported
>> - patch to xc/programs/Xserver/hw/xfree86/drivers/rendition/vboard.c
>>   re-added to comply with post-sarge SC
>>   - 031_glxinfo_makefile.diff
>> - Removing from TODO. This is a porter issue and I'm going to leave
>> it
>> to them.
>> 
>> 
>> Modified: trunk/debian/TODO
>> ===
>> --- trunk/debian/TODO2005-07-06 03:51:41 UTC (rev 316)
>> +++ trunk/debian/TODO2005-07-06 04:40:53 UTC (rev 317)
>> @@ -7,17 +7,7 @@
>>  
>>  xorg-x11 6.8.2-1 (unstable)
>>  -
>> -* Review all xfree86 4.3.0.dfsg.1-13 and -14 patches. [neroden]
>>  
>> -031_glxinfo_makefile.diff
>> -  -- Upstream says that it's incorrect and due to a toolchain bug.
>> - Have to see whether it's still needed for GNU/kFreeBSD, and if so,
>> - fix the bug.  See Freedesktop Bugzilla #1902.
>> -913_debian_remove_code_ref_to_object_code_files.diff - needs validation
>> - * patch to xc/programs/Xserver/hw/xfree86/drivers/rendition/vboard.c
>> lost - * patches to
>> xc/programs/Xserver/hw/xfree86/drivers/{mga,rendition}/Imakefile
>> -   now in patch 908
>> -
>>  * C++ ABI Transition
>>  
>>  xorg-x11 6.8.2-2 (unstable)
> 
> And with that, we now have a fully audited X.Org source tree. I want to
> thank everyone who's helped out with the patch audit, you guys are
> awesome, and I'm hoping you stick around to keep working on X in the
> future, I know I could use the help.
> 
> I'm going to try building packages tonight and testing them locally to
> make sure we have them. The next step is the C++ ABI transition, which has
> recently become inevitable to avoid, and as such it has to be done before
> a first upload to unstable. I'm way too tired to come up with a coherent
> plan as of now (having only skimmed the outline from Matthias) so I'll
> tackle this soon.

I'll help you.  :-)
xorg-x11 apparently doesn't build-depend on any external C++ libraries
except libstdc++, which makes this rather straightforward.

Of the library packages, only xlibmesa-glu depends on libstdc++.  In fact,
it's the only C++ package in the entire xorg tree.
xlibmesa-glu
-- This will need a new package name.  It has a really weird package
   name right now, so that's good anyway.  Ubuntu used libglu1-xorg, which
   sounds good to me.  :-)
-- And the new package will need to Conflicts:/Replaces: with the old
   package.
-- Ubuntu also made this "Provides: libglu1c2" instead of "Provides:
   libglu1".  This makes sense since there are alternative
   providers of libGLU.1.
xlibmesa-glu-dev
-- A new name is desirable because we're cleaning up the package
   name.  Probably Conflicts:/Provides:/Replaces: in this case.
   Ubuntu used libglu-dev-xorg, which sounds good to me.
xlibmesa-glu-dbg
-- Likewise, new name and Conflicts:/Replaces:.  Ubuntu used
   libglu1-dbg-xorg, which sounds good to me.

This migration was done in Ubuntu's 6.8.2-11.  Along with gobs of other
stuff, of course.

xlibmesa3 (transitional package) depends on xlibmesa-glu
xlibmesa-dev (transitional package) depends on xlibmesa-glu-dev
-- These two should IMNSHO just be dropped, since direct upgrades from woody
   to etch aren't supported anyway IIRC.  Ubuntu kept them, but I don't know
   why.

xbase-clients depends on xlibmesa-glu
x-window-system-core (metapackage) depends on xlibmesa-glu and xbase-clients
x-window-system-dev (metapackage) depends on xlibmesa-glu-dev
-- these will have dependency changes only

The remaining packages depend only on program packages, not library
packages, but I list them anyway just in case:

xdm depends on xbase-clients
x-window-system (metapackage) depends on xdm
xprint-common (from xprint) depends on xbase-clients,
and xprt depends on xprt-common
-- Incidentally, the xprint dependencies are *broken* in the current tree,
   since xprint-common doesn't provide xprt-common.
   xprt should "Depends: xprint-common | xpt-common", I think.

That's it for the actual ABI transition.  GCC4 build fixes may also be
needed.

> Daniel and Ubuntu have already made the transition, and 
> if it doesn't involve very much then we can get it done quickly.

I believe he's included a number of GCC4 build fixes, some of which may be
needed.

> After that, I'm going to get approval from the release team for the actual
> upload.

First we should review the packages to make sure they're all
(a) installable in unstable -- the xprt-common thing would suck
(b) haven't had large accidental manifest changes (debdiff)
(c) haven't had accidental soname changes (which would really cause trouble;
debdiff again)

Those should *not* take long.

> They're wary of having too many major transitions going on at 
> once, but I know they want to see X.Org in the archive as well, so
> hopeful

Re: Suggestion: pull two TODO items forward

[Nathanael Nerode]

David Nusinow wrote:

> On Mon, Jul 04, 2005 at 02:50:31PM -0400, Nathanael Nerode wrote:
>> This is just a suggestion.
>> 
>> I think these two items, scheduled for 6.8.2-2, really ought to be done
>> before the first upload to unstable, just to avoid potential serious
>> breakage. The rest of the items look like they're reasonable to postpone.
>> 
>> --- TODO 2005-07-04 14:42:29.617091629 -0400
>> +++ TODO.new 2005-07-04 14:48:34.351739368 -0400
>> @@ -25,6 +25,13 @@
>>  
>>  * Make sure xdm upgrades work properly
>>  
>> +* Review the changes to the MANIFEST files between xfree86
>> 4.3.0.dfsg.1-14 and
>> +  xorg-x11, per David Nusinow.

I think this is just asking for, basically, a debdiff to make sure no files
got lost by mistake, and no files got shipped by mistake.

>> +* Finalize all library build/versioning/arrangement decisions as much as
>> +  possible before uploading to unstable, so we don't wreak havoc on the
>> entire
>> +  world via dpkg-shlibdeps.
Yeah, this is vague, isn't it.

> These two items are *very* vague. Again, I don't know what they mean
> exactly, so I'm not willing to delay anything for them without some more
> specific criteria.
> 
>  - David Nusinow

-- 
Don't say I didn't warn you.


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

Fix patch offsets

[Nathanael Nerode]

This fixes all remaining offset bugs in the patch-audit target
(after:
 * my additions of upstream patches to _backport_from_upstream.diff
 * my patch to 000_stolen_from linuxwacom_wacom_driver.diff
 * Eugene Konev's ports of 003b and 099u, as modified by me
 * My patch to 044
 * Eugene Konev's patch to 304
)

Index: 058_support_external_Xcursor_Xft_Xrender_libs.diff
===
--- 058_support_external_Xcursor_Xft_Xrender_libs.diff  (revision 309)
+++ 058_support_external_Xcursor_Xft_Xrender_libs.diff  (working copy)
@@ -731,7 +731,7 @@
 diff -ruN xc-old/programs/xterm/Imakefile xc/programs/xterm/Imakefile
 --- xc-old/programs/xterm/Imakefile2004-08-13 12:57:19.0 +
 +++ xc/programs/xterm/Imakefile2004-10-26 09:59:37.322950392 +
-@@ -97,7 +97,7 @@
+@@ -99,7 +99,7 @@
  UTF8SRC = charclass.c precompose.c wcwidth.c xutf8.c
  UTF8OBJ = charclass.o precompose.o wcwidth.o xutf8.o
  #endif
Index: 000_backport_from_author_xterm.diff
===
--- 000_backport_from_author_xterm.diff (revision 309)
+++ 000_backport_from_author_xterm.diff (working copy)
@@ -14252,7 +14252,7 @@
  /*
   *$Xorg: input.c,v 1.3 2000/08/17 19:55:08 cpqbld Exp $
   */
-@@ -2,6 +4,6 @@
+@@ -4,6 +6,6 @@
  
 -/* $XFree86: xc/programs/xterm/input.c,v 3.71 2004/12/01 01:27:46 dickey Exp 
$ */
 +/* $XFree86: xc/programs/xterm/input.c,v 3.72 2005/01/14 01:50:03 dickey Exp 
$ */
Index: 045_chips_default_to_swcursor_on_69k.diff
===
--- 045_chips_default_to_swcursor_on_69k.diff   (revision 309)
+++ 045_chips_default_to_swcursor_on_69k.diff   (working copy)
@@ -4,7 +4,7 @@
 
 --- xc/programs/Xserver/hw/xfree86/drivers/chips/ct_driver.c~  2004-08-12 
17:31:33.0 -0500
 +++ xc/programs/Xserver/hw/xfree86/drivers/chips/ct_driver.c   2004-08-12 
17:31:41.0 -0500
-@@ -1519,6 +1519,18 @@
+@@ -1525,6 +1525,18 @@
  } else {
cPtr->Accel.UseHWCursor = TRUE;
  }
Index: 099c_support_loadable_external_Xcursor_lib.diff
===
--- 099c_support_loadable_external_Xcursor_lib.diff (revision 309)
+++ 099c_support_loadable_external_Xcursor_lib.diff (working copy)
@@ -25,7 +25,7 @@
 diff -ruN xc-old/lib/X11/Imakefile xc/lib/X11/Imakefile
 --- xc-old/lib/X11/Imakefile   2004-10-27 08:40:37.114775000 +
 +++ xc/lib/X11/Imakefile   2004-10-27 08:41:15.188986920 +
-@@ -133,7 +133,10 @@
+@@ -131,7 +131,10 @@
  THRSTUBSRCS = UIThrStubs.c
  THRSTUBOBJS = UIThrStubs.o
  #endif
Index: 099g_xkb_symbols_polish_fix_keypad_separator.diff
===
--- 099g_xkb_symbols_polish_fix_keypad_separator.diff   (revision 309)
+++ 099g_xkb_symbols_polish_fix_keypad_separator.diff   (working copy)
@@ -1,4 +1,4 @@
-$Id: 099g_xkb_symbols_polish_fix_keypad_separator.diff 1735 2004-08-13 
06:43:54Z branden $
+$Id$
 
 This patch by Branden Robinson, based on a report from Emil Novak.
 
@@ -34,7 +34,7 @@
 diff -ruN xc-old/programs/xkbcomp/symbols/pl xc/programs/xkbcomp/symbols/pl
 --- xc-old/programs/xkbcomp/symbols/pl 2004-04-23 19:54:52.0 +
 +++ xc/programs/xkbcomp/symbols/pl 2004-10-26 12:35:38.879777432 +
-@@ -35,8 +35,12 @@
+@@ -37,8 +37,12 @@
[   zabovedot,   Zabovedot  ]   };
  // End alphanumeric section
  
@@ -52,7 +52,7 @@
 diff -ruN xc-old/programs/xkbcomp/symbols/pl2 xc/programs/xkbcomp/symbols/pl2
 --- xc-old/programs/xkbcomp/symbols/pl22003-11-14 16:49:23.0 
+
 +++ xc/programs/xkbcomp/symbols/pl22004-10-26 12:36:05.506729520 +
-@@ -94,6 +94,10 @@
+@@ -95,6 +95,10 @@
  
  // End alphanumeric section
  
Index: 803_gnu_xterm_openpty.diff
===
--- 803_gnu_xterm_openpty.diff  (revision 309)
+++ 803_gnu_xterm_openpty.diff  (working copy)
@@ -1,4 +1,4 @@
-$Id: 803_gnu_xterm_openpty.diff 1706 2004-07-29 19:16:40Z branden $
+$Id$
 
 On glibc-based systems, openpty needs -lutil.
 
@@ -8,7 +8,7 @@
 
 --- xc/programs/xterm/Imakefile~   2004-03-15 01:22:17.0 +0100
 +++ xc/programs/xterm/Imakefile2004-03-15 02:01:31.0 +0100
-@@ -58,6 +58,7 @@
+@@ -60,6 +60,7 @@
  #endif
  
  #if defined(NetBSDArchitecture) || defined(OpenBSDArchitecture) || \
Index: 823_gnu-freebsd_xterm.diff
===
--- 823_gnu-freebsd_xterm.diff  (revision 309)
+++ 823_gnu-freebsd_xterm.diff  (working copy)
@@ -1,4 +1,4 @@
-$Id: 823_gnu-freebsd_xterm.diff 1400 2004-05-13 17:23:09Z branden $
+$Id$
 
 GNU/FreeBSD needs the termios.h header included to know what "B38400" is.
 
@@ -8,7 +8,7 @@
 
 --- xc/programs/xterm/main.c~  2004-05-12 02:25:06.0 -0500
 +++ xc/programs/xterm/main.c   2004-05-1

Revised 003b, 099u :-)

[Nathanael Nerode]

OK, I finally got correct versions of Konev's ported patches together
with the annotations.

-- 
Don't say I didn't warn you.
$Id: 003b_xfs_fixes.diff 2151 2005-01-24 16:54:48Z branden $

This patch by Branden Robinson, Matthieu Herrb, and Nikita V. Youshchenko.

os/utils.c:
  - Handle pid files the way most other Unix daemons do.  Use Matthieu
Herrb's version of StorePid(), which refuses to open pre-existing pid
files, and is more careful with the type of Pid_t.
  - Allow the user to specify the pid filename on the command line with a
"-pid" option (courtesy of Nikita V. Youshchenko).
  - Add RemovePid() function which removes the process ID file, and
register it with atexit() so that it is automatically invoked when xfs
exits.
  - Sort options in usage message alphabetically.
  - Refer to "user ID" and "process ID" in diagnostic messages, not
"userid" and "process-id".
  - Remove duplicate unconditional #include of stdlib.h.
  - Wrap long lines.
  - Whitespace police.

xfs.man:
  - Document the new "-pid" option (courtesy of Nikita V. Youshchenko).
  - Add "FUTURE DIRECTIONS" section.
  - Perform massive cleanup and reformatting.

Not submitted upstream yet.

Index: xc/programs/xfs/os/utils.c
===
--- xc/programs/xfs/os/utils.c  (revision 309)
+++ xc/programs/xfs/os/utils.c  (working copy)
@@ -3,7 +3,7 @@
  * misc os utilities
  */
 /*
- 
+
 Copyright 1990, 1991, 1998  The Open Group
 
 Permission to use, copy, modify, distribute, and sell this software and its
@@ -27,7 +27,7 @@
 in this Software without prior written authorization from The Open Group.
 
  * Copyright 1990, 1991 Network Computing Devices;
- * Portions Copyright 1987 by Digital Equipment Corporation 
+ * Portions Copyright 1987 by Digital Equipment Corporation
  *
  * Permission to use, copy, modify, distribute, and sell this software and
  * its documentation for any purpose is hereby granted without fee, provided
@@ -90,8 +90,6 @@
 #define SIGNALS_RESET_WHEN_CAUGHT
 #endif
 
-#include 
-
 extern char *configfilename;
 static Bool dropPriv = FALSE; /* whether or not to drop root privileges */
 #ifdef DEFAULT_DAEMON
@@ -116,7 +114,8 @@
 static char *pidFile = XFSPIDDIR "/xfs.pid";
 static int  pidFd;
 static FILE *pidFilePtr;
-static int  StorePid (void);
+static long StorePid (void);
+static void RemovePid (void);
 
 /* ARGSUSED */
 SIGVAL
@@ -219,7 +218,9 @@
 static void
 usage(void)
 {
-fprintf(stderr, "usage: %s [-config config_file] [-port tcp_port] 
[-droppriv] [-daemon] [-nodaemon] [-user user_name] [-ls listen_socket]\n",
+fprintf(stderr, "usage: %s [-config config_file] [-daemon] [-droppriv]"
+   " [-ls listen_socket] [-nodaemon] [-pid pid_file]"
+   " [-port tcp_port] [-user user_name]\n",
progname);
 exit(1);
 }
@@ -242,7 +243,7 @@
  *
  * [] denotes optional and ... denotes repitition.
  *
- * The string must be _exactly_ in the above format. 
+ * The string must be _exactly_ in the above format.
  */
 
 void
@@ -260,7 +261,7 @@
count++;
ptr++;
 }
-  
+
 OldListenCount = count + 1;
 OldListen = (OldListenRec *) malloc (
OldListenCount * sizeof (OldListenRec));
@@ -349,6 +350,11 @@
configfilename = argv[++i];
else
usage();
+   } else if (!strcmp(argv[i], "-pid")) {
+   if (argv[i + 1])
+   pidFile = argv[++i];
+   else
+   usage();
}
 #ifdef MEMBUG
else if ( strcmp( argv[i], "-alloc") == 0)
@@ -392,7 +398,7 @@
 FSalloc (unsigned long amount)
 {
 register pointer  ptr;
-   
+
 if ((long)amount < 0)
return 0;
 if (amount == 0)
@@ -462,21 +468,21 @@
FatalError("out of memory\n");
 return 0;
 }
-
+
 /*
  *  FSfree
- *calls free 
- */
+ *calls free
+ */
 
 void
 FSfree(pointer ptr)
 {
 #ifdef MEMBUG
 if (ptr)
-   ffree((char *)ptr); 
+   ffree((char *)ptr);
 #else
 if (ptr)
-   free((char *)ptr); 
+   free((char *)ptr);
 #endif
 }
 
@@ -511,11 +517,12 @@
}
 #endif /* QNX4 */
if (setuid(pwent->pw_uid)) {
-   FatalError("fatal: couldn't set userid to %s user\n", user);
+   FatalError("fatal: couldn't set user ID to %s user\n", user);
}
}
 } else if (dropPriv || userId) {
-   FatalError("fatal: -droppriv or -user flag specified, but xfs not run 
as root\n");
+   FatalError("fatal: -droppriv or -user flag specified, but xfs not"
+  " invoked by root user\n");
 }
 }
 
@@ -523,48 +530,76 @@
 void
 SetDaemonState(void)
 {
-intoldpid;
+long   oldpid;
 
 if (becomeDaemon) {
BecomeDaemon();
if ((oldpid = StorePid ())) {
if (oldpid == -1)
-   ErrorF ("error op

Aaargh. (003b)

[Nathanael Nerode]

I keep getting tabs mangled.  Use Konev's 003b but with the annotations --
I can't seem to manfuacture such an item at the moment.

-- 
Don't say I didn't warn you.


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

Improved 003b

[Nathanael Nerode]

Likewise, Eugene Konev ported the 003b patch but lost the comments.
Version with comments attached.

-- 
Don't say I didn't warn you.
$Id: 003b_xfs_fixes.diff 2151 2005-01-24 16:54:48Z branden $

This patch by Branden Robinson, Matthieu Herrb, and Nikita V. Youshchenko.

os/utils.c:
  - Handle pid files the way most other Unix daemons do.  Use Matthieu
Herrb's version of StorePid(), which refuses to open pre-existing pid
files, and is more careful with the type of Pid_t.
  - Allow the user to specify the pid filename on the command line with a
"-pid" option (courtesy of Nikita V. Youshchenko).
  - Add RemovePid() function which removes the process ID file, and
register it with atexit() so that it is automatically invoked when xfs
exits.
  - Sort options in usage message alphabetically.
  - Refer to "user ID" and "process ID" in diagnostic messages, not
"userid" and "process-id".
  - Remove duplicate unconditional #include of stdlib.h.
  - Wrap long lines.
  - Whitespace police.

xfs.man:
  - Document the new "-pid" option (courtesy of Nikita V. Youshchenko).
  - Add "FUTURE DIRECTIONS" section.
  - Perform massive cleanup and reformatting.

Not submitted upstream yet.

Index: xc/programs/xfs/os/utils.c
===
--- xc.orig/programs/xfs/os/utils.c 2005-03-01 00:35:18.0 +0700
+++ xc/programs/xfs/os/utils.c  2005-07-03 13:48:14.0 +0800
@@ -3,7 +3,7 @@
  * misc os utilities
  */
 /*
- 
+
 Copyright 1990, 1991, 1998  The Open Group
 
 Permission to use, copy, modify, distribute, and sell this software and its
@@ -27,7 +27,7 @@
 in this Software without prior written authorization from The Open Group.
 
  * Copyright 1990, 1991 Network Computing Devices;
- * Portions Copyright 1987 by Digital Equipment Corporation 
+ * Portions Copyright 1987 by Digital Equipment Corporation
  *
  * Permission to use, copy, modify, distribute, and sell this software and
  * its documentation for any purpose is hereby granted without fee, provided
@@ -90,8 +90,6 @@
 #define SIGNALS_RESET_WHEN_CAUGHT
 #endif
 
-#include 
-
 extern char *configfilename;
 static Bool dropPriv = FALSE; /* whether or not to drop root privileges */
 #ifdef DEFAULT_DAEMON
@@ -116,7 +114,8 @@
 static char *pidFile = XFSPIDDIR "/xfs.pid";
 static int  pidFd;
 static FILE *pidFilePtr;
-static int  StorePid (void);
+static long StorePid (void);
+static void RemovePid (void);
 
 /* ARGSUSED */
 SIGVAL
@@ -219,7 +218,9 @@
 static void
 usage(void)
 {
-fprintf(stderr, "usage: %s [-config config_file] [-port tcp_port] 
[-droppriv] [-daemon] [-nodaemon] [-user user_name] [-ls listen_socket]\n",
+fprintf(stderr, "usage: %s [-config config_file] [-daemon] [-droppriv]"
+   " [-ls listen_socket] [-nodaemon] [-pid pid_file]"
+   " [-port tcp_port] [-user user_name]\n",
progname);
 exit(1);
 }
@@ -242,7 +243,7 @@
  *
  * [] denotes optional and ... denotes repitition.
  *
- * The string must be _exactly_ in the above format. 
+ * The string must be _exactly_ in the above format.
  */
 
 void
@@ -260,7 +261,7 @@
count++;
ptr++;
 }
-  
+
 OldListenCount = count + 1;
 OldListen = (OldListenRec *) malloc (
OldListenCount * sizeof (OldListenRec));
@@ -349,6 +350,11 @@
configfilename = argv[++i];
else
usage();
+   } else if (!strcmp(argv[i], "-pid")) {
+   if (argv[i + 1])
+   pidFile = argv[++i];
+   else
+   usage();
}
 #ifdef MEMBUG
else if ( strcmp( argv[i], "-alloc") == 0)
@@ -392,7 +398,7 @@
 FSalloc (unsigned long amount)
 {
 register pointer  ptr;
-   
+
 if ((long)amount < 0)
return 0;
 if (amount == 0)
@@ -462,21 +468,21 @@
FatalError("out of memory\n");
 return 0;
 }
-
+
 /*
  *  FSfree
- *calls free 
- */
+ *calls free
+ */
 
 void
 FSfree(pointer ptr)
 {
 #ifdef MEMBUG
 if (ptr)
-   ffree((char *)ptr); 
+   ffree((char *)ptr);
 #else
 if (ptr)
-   free((char *)ptr); 
+   free((char *)ptr);
 #endif
 }
 
@@ -511,11 +517,12 @@
}
 #endif /* QNX4 */
if (setuid(pwent->pw_uid)) {
-   FatalError("fatal: couldn't set userid to %s user\n", user);
+   FatalError("fatal: couldn't set user ID to %s user\n", user);
}
}
 } else if (dropPriv || userId) {
-   FatalError("fatal: -droppriv or -user flag specified, but xfs not run 
as root\n");
+   FatalError("fatal: -droppriv or -user flag specified, but xfs not"
+  " invoked by root user\n");
 }
 }
 
@@ -523,48 +530,76 @@
 void
 SetDaemonState(void)
 {
-intoldpid;
+long   oldpid;
 
 if (becomeDaemon) {
BecomeDaemon();
if ((oldpid = StorePid ())) {
 

Forget previous 099u patch...

[Nathanael Nerode]

It was mangled.

Attached is a correct version.

-- 
Don't say I didn't warn you.
$Id: 099u_mkdirhier_rewrite.diff 2171 2005-02-08 07:13:50Z branden $

Reimplement mkdirhier; see Debian #141347 and #232357 for some reasons why.

This shell script and manpage by Branden Robinson.

Not submitted upstream to XFree86 or X.Org.

Index: xc/config/util/mkdirhier.man
===
--- xc.orig/config/util/mkdirhier.man   2005-03-01 00:35:18.0 +0700
+++ xc/config/util/mkdirhier.man2005-07-03 14:03:47.0 +0800
@@ -1,42 +1,111 @@
-.\" $Xorg: mkdirhier.man,v 1.4 2001/02/09 02:03:17 xorgcvs Exp $
-.\" Copyright (c) 1993, 1994, 1998 The Open Group
-.\" 
-.\" Permission to use, copy, modify, distribute, and sell this software and its
-.\" documentation for any purpose is hereby granted without fee, provided that
-.\" the above copyright notice appear in all copies and that both that
-.\" copyright notice and this permission notice appear in supporting
-.\" documentation.
-.\" 
-.\" 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 OPEN GROUP 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 Open Group shall not 
-.\" be used in advertising or otherwise to promote the sale, use or other 
-.\" dealing in this Software without prior written authorization from The 
-.\" Open Group.
+.\" Copyright 2005 Branden Robinson.
 .\"
-.\" $XFree86: xc/config/util/mkdirhier.man,v 1.2 2001/01/27 18:19:55 dawes Exp 
$
+.\" 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 condition:
 .\"
-.TH MKDIRHIER 1 __xorgversion__
+.\" 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
+.\" SOFTWARE IN THE PUBLIC INTEREST, INC. 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.
+.TH mkdirhier __mansuffix__ __xorgversion__
 .SH NAME
-mkdirhier \- makes a directory hierarchy
+mkdirhier \- create a directory hierarchy
 .SH SYNOPSIS
 .B mkdirhier
-directory ...
+.I directory
+\&...
 .SH DESCRIPTION
-The
-.I mkdirhier
-command creates the specified directories. Unlike
-.I mkdir
-if any of the parent directories of the specified directory
-do not exist, it creates them as well.
+.B mkdirhier
+creates the specified directories.
+Unlike some versions of
+.BR mkdir ,
+if any of the parent directories of the specified directory do not exist,
+.B mkdirhier
+creates them as well.
+.PP
+.B mkdirhier
+is a wrapper for
+.BR mkdir ;
+systems with
+.BR mkdir (__osmansuffix__)
+implementations conformant with the Single Unix Specification may simply
+use
+.B mkdir \-p
+instead \(em this includes all systems using the GNU Core Utilities'
+version of
+.BR mkdir .
+.SH DIAGNOSTICS
+If
+.B mkdirhier
+is not supplied with any arguments, a usage message is printed.
+.PP
+.B mkdirhier
+prefixes its diagnostic messages with the name under which it was invoked,
+followed by a colon (\(oq:\(cq) so that its messages can be distingushed
+from others.
+.TP
+.B could not create directory \(dq\fIdirectory\fP\(dq
+indicates that there was a failure while creating
+.IR directory .
+This message will likely be preceded by a diagnostic message from
+.BR mkdir .
+.SH "EXIT STATUS"
+.TP
+.B 64
+.B mkdirhier
+was not given any directory names to create.
+.PP
+.B mkdirhier
+otherwise exits with the exit status of the last
+.B mkdir
+command that failed.
+.SH BUGS
+.B mkdirhier
+does not create all the requested directories as an atomic operation;
+therefore, it is is susceptible to race conditions.
+For example, if
+.B mkdirhier
+is directed to create a hierarchy
+.I a/b/

Slightly revised 099u

[Nathanael Nerode]

Eugene Konev ported 099u.  Unfortunately he accidentally lost the comments.
The attached version has the comments restored.
-- 
Don't say I didn't warn you.
$Id: 099u_mkdirhier_rewrite.diff 2171 2005-02-08 07:13:50Z branden $

Reimplement mkdirhier; see Debian #141347 and #232357 for some reasons why.

This shell script and manpage by Branden Robinson.

Not submitted upstream.

Index: xc/config/util/mkdirhier.man
===
--- xc.orig/config/util/mkdirhier.man   2005-03-01 00:35:18.0 +0700
+++ xc/config/util/mkdirhier.man2005-07-03 14:03:47.0 +0800
@@ -1,42 +1,111 @@
-.\" $Xorg: mkdirhier.man,v 1.4 2001/02/09 02:03:17 xorgcvs Exp $
-.\" Copyright (c) 1993, 1994, 1998 The Open Group
-.\" 
-.\" Permission to use, copy, modify, distribute, and sell this software 
and its
-.\" documentation for any purpose is hereby granted without fee, provided 
that
-.\" the above copyright notice appear in all copies and that both that
-.\" copyright notice and this permission notice appear in supporting
-.\" documentation.
-.\" 
-.\" 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 OPEN GROUP 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 Open Group shall 
not 
-.\" be used in advertising or otherwise to promote the sale, use or other 
-.\" dealing in this Software without prior written authorization from The 
-.\" Open Group.
+.\" Copyright 2005 Branden Robinson.
 .\"
-.\" $XFree86: xc/config/util/mkdirhier.man,v 1.2 2001/01/27 18:19:55 
dawes Exp $
+.\" 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 condition:
 .\"
-.TH MKDIRHIER 1 __xorgversion__
+.\" 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
+.\" SOFTWARE IN THE PUBLIC INTEREST, INC. 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.
+.TH mkdirhier __mansuffix__ __xorgversion__
 .SH NAME
-mkdirhier \- makes a directory hierarchy
+mkdirhier \- create a directory hierarchy
 .SH SYNOPSIS
 .B mkdirhier
-directory ...
+.I directory
+\&...
 .SH DESCRIPTION
-The
-.I mkdirhier
-command creates the specified directories. Unlike
-.I mkdir
-if any of the parent directories of the specified directory
-do not exist, it creates them as well.
+.B mkdirhier
+creates the specified directories.
+Unlike some versions of
+.BR mkdir ,
+if any of the parent directories of the specified directory do not exist,
+.B mkdirhier
+creates them as well.
+.PP
+.B mkdirhier
+is a wrapper for
+.BR mkdir ;
+systems with
+.BR mkdir (__osmansuffix__)
+implementations conformant with the Single Unix Specification may simply
+use
+.B mkdir \-p
+instead \(em this includes all systems using the GNU Core Utilities'
+version of
+.BR mkdir .
+.SH DIAGNOSTICS
+If
+.B mkdirhier
+is not supplied with any arguments, a usage message is printed.
+.PP
+.B mkdirhier
+prefixes its diagnostic messages with the name under which it was invoked,
+followed by a colon (\(oq:\(cq) so that its messages can be distingushed
+from others.
+.TP
+.B could not create directory \(dq\fIdirectory\fP\(dq
+indicates that there was a failure while creating
+.IR directory .
+This message will likely be preceded by a diagnostic message from
+.BR mkdir .
+.SH "EXIT STATUS"
+.TP
+.B 64
+.B mkdirhier
+was not given any directory names to create.
+.PP
+.B mkdirhier
+otherwise exits with the exit status of the last
+.B mkdir
+command that failed.
+.SH BUGS
+.B mkdirhier
+does not create all the requested directories as an atomic operation;
+therefore, it is is susceptible to race conditions.
+

Suggestion: pull two TODO items forward

[Nathanael Nerode]

This is just a suggestion.

I think these two items, scheduled for 6.8.2-2, really ought to be done
before the first upload to unstable, just to avoid potential serious breakage.
The rest of the items look like they're reasonable to postpone.

--- TODO2005-07-04 14:42:29.617091629 -0400
+++ TODO.new2005-07-04 14:48:34.351739368 -0400
@@ -25,6 +25,13 @@
 
 * Make sure xdm upgrades work properly
 
+* Review the changes to the MANIFEST files between xfree86 4.3.0.dfsg.1-14 and
+  xorg-x11, per David Nusinow.
+
+* Finalize all library build/versioning/arrangement decisions as much as
+  possible before uploading to unstable, so we don't wreak havoc on the entire
+  world via dpkg-shlibdeps.
+
 xorg-x11 6.8.2-2 (unstable)
 ---
 * Update manifest-install-reconcile's data lists so the tool is usable again.
@@ -77,9 +84,6 @@
   headers may be present that don't correspond to any of the static objects
   shipped.
 
-* Review the changes to the MANIFEST files between xfree86 4.3.0.dfsg.1-14 and
-  xorg-x11, per David Nusinow.
-
 * Review debian/po/*.po files, per David Nusinow.
 
 * Ensure the removal of the contents of debian/scripts/vars.amd64 was the right
@@ -95,10 +99,6 @@
 
 * Decide whether to drop xmh or not.
 
-* Finalize all library build/versioning/arrangement decisions as much as
-  possible before uploading to unstable, so we don't wreak havoc on the entire
-  world via dpkg-shlibdeps.
-
 * Use ucf to handle xorg.conf instead of Branden's own md5summy thing.
 
 * Stop compiling libXft1 since we (apparently) ain't shippin' it.

-- 
Don't say I didn't warn you.


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

Patch audit: recover remaining upstream patches

[Nathanael Nerode]

This integrates the remaining upstream patches which had to be merged.

Index: TODO
===
--- TODO(revision 309)
+++ TODO(working copy)
@@ -33,17 +23,6 @@
  * patches to xc/programs/Xserver/hw/xfree86/drivers/{mga,rendition}/Imakefile
now in patch 908
 
-   + The following need to be backported from upstream (upstream CVS revisions
- noted):
-   xc/include/extensions/xf86mscstr.h @ 1.3
-   xc/programs/Xserver/Xext/xf86misc.c @ 1.2
-   xc/programs/Xserver/Xext/xf86misc.c @ 1.3
-   xc/programs/Xserver/hw/xfree86/common/compiler.h @ 1.5
-   xc/programs/Xserver/hw/xfree86/loader/elfloader.c @ 1.5
-
-  + Grab Thomas Winischhofer's post-6.8.2 fixes to MiscPassMessage() from CVS
-(see Debian #285807).
-
 * Make sure xdm upgrades work properly
 
 xorg-x11 6.8.2-2 (unstable)
Index: patches/_backport_from_upstream.diff
===
--- patches/_backport_from_upstream.diff(revision 309)
+++ patches/_backport_from_upstream.diff(working copy)
@@ -42,6 +42,16 @@
Rename XFree86CustomVersion to XorgCustomVersion in the Debian
Maintainer section.
 
+2004-12-15  Thomas Winischhofer  <[EMAIL PROTECTED]>
+
+* Fix MISC extension's PassMessage(). Make it actually
+  work (MsgVal was trashed) and fix memory leaks.
+* Increase MISC extension's minor number to 9 to indicate
+  that PassMessage() is actually usable
+
+[No changelog entry, but it's Thomas Winischhofer again: message from CVS log]
+   Another fix for MiscPassMessage(): Initialize returned "status".
+
 2004-12-17  Alex Deucher  <[EMAIL PROTECTED]>
 
* programs/Xserver/hw/xfree86/drivers/ati/r128.h:
@@ -107,6 +117,15 @@
intended to prevent this, but it apparently is not in effect yet
when linux.cf is parsed.)
 
+2005-04-04  Egbert Eich  
+
+* programs/Xserver/hw/xfree86/common/compiler.h:
+* programs/Xserver/hw/xfree86/loader/elfloader.c:
+(ELFCollectSections):
+When not using dlopen ia64 needs an extra cache
+flush to ensure the icache is coherent when modules
+are loaded (Alex Williamson).
+
 2005-04-05  Daniel Stone  <[EMAIL PROTECTED]>
 
* programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c:
@@ -1495,3 +1514,96 @@
  if ((image->bits_per_pixel | image->depth) == 1) {
ibu = image->bitmap_unit;
for (y = 0; y < height; y++)
+Index: xc/include/extensions/xf86mscstr.h
+===
+--- xc/include/extensions/xf86mscstr.h (revision 309)
 xc/include/extensions/xf86mscstr.h (working copy)
+@@ -14,7 +14,7 @@
+ #define XF86MISCNAME  "XFree86-Misc"
+ 
+ #define XF86MISC_MAJOR_VERSION0   /* current version numbers */
+-#define XF86MISC_MINOR_VERSION8
++#define XF86MISC_MINOR_VERSION9
+ 
+ typedef struct _XF86MiscQueryVersion {
+ CARD8 reqType;/* always XF86MiscReqCode */
+Index: xc/programs/Xserver/hw/xfree86/common/compiler.h
+===
+--- xc/programs/Xserver/hw/xfree86/common/compiler.h   (revision 309)
 xc/programs/Xserver/hw/xfree86/common/compiler.h   (working copy)
+@@ -478,7 +478,7 @@
+ #ifndef __INTEL_COMPILER
+ #   define ia64_flush_cache(Addr) \
+   __asm__ __volatile__ ( \
+-  "fc %0;;;" \
++  "fc.i %0;;;" \
+   "sync.i;;;" \
+   "mf;;;" \
+   "srlz.i;;;" \
+Index: xc/programs/Xserver/hw/xfree86/loader/elfloader.c
+===
+--- xc/programs/Xserver/hw/xfree86/loader/elfloader.c  (revision 309)
 xc/programs/Xserver/hw/xfree86/loader/elfloader.c  (working copy)
+@@ -2785,6 +2785,14 @@
+   mprotect( (char *)elffile->lsection[j].saddr - round,
+SecSize(i) + round, PROT_READ | PROT_WRITE | 
PROT_EXEC);
+   }
++#ifdef __ia64__
++  {
++  int k;
++  for (k = 0; k < SecSize(i); k += 32)
++  ia64_flush_cache(elffile->lsection[j].saddr+k);
++  ia64_flush_cache(elffile->lsection[j].saddr+SecSize(i)-1);
++  }
++#endif
+   break;
+ #endif
+   case SHT_SYMTAB:
+Index: xc/programs/Xserver/Xext/xf86misc.c
+===
+--- xc/programs/Xserver/Xext/xf86misc.c(revision 309)
 xc/programs/Xserver/Xext/xf86misc.c(working copy)
+@@ -582,20 +582,29 @@
+   strncpy(msgtype,(char*)(&stuff[1]),stuff->typelen);
+ } else return BadValue;
+ if (stuff->vallen) {
+-  if (!(msgval = xalloc(stuff->vallen)))
++  if (!(msgval = xalloc(stuff->vallen))) {
++  xfree(msgtype);
+   return BadAlloc;
+-  strncpy(msgval,(char*)(&stuff[1] + ((stuff->

Improve patch 044

[Nathanael Nerode]

Full patch below.  This incorporates Dan Christensen's suggested changes,
with relatively florid commentary.


$Id: 044_chips_default_to_noaccel_on_69k.diff 189 2005-06-11 00:04:27Z branden $

This patch by Nathanael Nerode, based on
original patches from Mike A. Harris and Dan Christensen.

Index: xc/programs/Xserver/hw/xfree86/drivers/chips/ct_driver.c
===
--- xc/programs/Xserver/hw/xfree86/drivers/chips/ct_driver.c(revision 309)
+++ xc/programs/Xserver/hw/xfree86/drivers/chips/ct_driver.c(working copy)
@@ -1492,8 +1492,28 @@
   "rgb bits %d\n", val);
}
 }
+/* FIXME: Disable 2D acceleration on C&T 69000 by default, since it is
+ * reported to be broken, but nobody who has this hardware has narrowed
+ * it down to individual acceleration primitives yet.  This is a Red Hat
+ * workaround for a bug reported in bugzilla at:
+ * https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74841
+ * Mike A. Harris <[EMAIL PROTECTED]>
+ *
+ * However, it works for some people, so allow them to turn it on
+ * in the config file.  Just change the *default*.
+ * Thanks to Dan Christensen <[EMAIL PROTECTED]>
+ */
+if (cPtr->Chipset == CHIPS_CT69000 && (cPtr->Flags & ChipsAccelSupport) ) {
+   xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
+   "Acceleration is disabled by default on C&T 69000 as it has been 
reported\n"
+   "to be broken: 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74841\n";
+   "You can turn it on by adding Option \"NoAccel\" \"false\" to the 
Screen\n"
+   "section of your xorg.conf file\n" );
+}
+
 if ((cPtr->Flags & ChipsAccelSupport) &&
-   (xf86ReturnOptValBool(cPtr->Options, OPTION_NOACCEL, FALSE))) {
+   (xf86ReturnOptValBool(cPtr->Options, OPTION_NOACCEL,
+ cPtr->Chipset == CHIPS_CT96000))) {
cPtr->Flags &= ~ChipsAccelSupport;
xf86DrvMsg(pScrn->scrnIndex, X_CONFIG, "Acceleration disabled\n");
 }

-- 
Don't say I didn't warn you.


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

Re: [RFC] Synaptics Touchpad driver for xorg

[Nathanael Nerode]

>Why not dropping the "f86" part at all?
I believe this is because the drivers use the "xfree86 DDX", or something like 
that.  (Because they don't work with the xnest, darwin, vfb, dmx, cygwin, 
kdrive, etc. versions of the X server.)  They are located in 
xc/programs/Xserver/hw/xfree86, even in the x.org server.  

>maybe "x11-input-synaptics" looks better.
Too generic.  It only works with certain X servers, not with xnest or xvfb for 
instance.  "x11" implies a pure x11 program, when in fact it depends on the 
"xfree86 DDX".


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

Re: [RFC] Synaptics Touchpad driver for xorg

[Nathanael Nerode]

Mattia Dongili wrote:

> Hello XFS and other readers (like me).
> 
> I'm working on the transition of the xfree86-driver-synaptics toward the
> new XOrg packages and they will closely follow the same route of the
> XOrg packages.
> They are available at:
>  http://people.debian.org/~malattia/debian
> or for the impatients:
>  deb http://people.debian.org/~malattia/debian binary/
>  deb-src http://people.debian.org/~malattia/debian source/
> and are called xorg-driver-synaptics.
> 
> One question to the XSF tough (which I already asked when first naming
> the package): having to rename the package wouldn't make sense finding
> a less explicit name?
Totally.  X.org seems to be using funny names for its drivers along the
lines of "xf86-input-synaptics"; maybe that would work for you?

> I mean, as the same binary package of the 
> synaptics driver can actually work with both xserver-xfree86 and
> xserver-xorg (tested) maybe something like xdriver-synaptics-touchpad or
> xdriver-input-synaptics. This way I could also relax dependencies
> (xserver instead of xserver-*) and probably make thing easier for
> backports. What do you think?
> 
> Greetings!

-- 
This space intentionally left blank.


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

[PATCH] Fix the bugs I introduced in 011a

[Nathanael Nerode]

This fixes a few tiny glitches I found in 011a, all my fault.

- 011a_recognize_glibc_2.3.2_locale_names.diff
  - make the lowercase version of zh_*.gb2312/.gbk the canonical one.
  - fix some GBK/GB2312 confusion which I introduced
  - remove accidental duplicate alias for ar_KW.iso88596

Index: 011a_recognize_glibc_2.3.2_locale_names.diff
===
--- 011a_recognize_glibc_2.3.2_locale_names.diff(revision 292)
+++ 011a_recognize_glibc_2.3.2_locale_names.diff(working copy)
@@ -52,11 +52,12 @@
 This patch by Branden Robinson.
 Major "forward port" by Nathanael Nerode.
 
-Not submitted upstream.
+Partially submitted upstream.  This is so large I don't expect it to all go in 
at once,
+but any bit would help.  --Nathanael
 
 Index: xc/nls/compose.dir
 ===
 xc/nls/compose.dir (revision 271)
+--- xc/nls/compose.dir (revision 292)
 +++ xc/nls/compose.dir (working copy)
 @@ -1,14 +1,22 @@
  XCOMM $Xorg: compose.dir,v 1.3 2000/08/17 19:46:48 cpqbld Exp $
@@ -294,15 +295,16 @@
 +iso8859-1/Compose:xh_ZA.ISO8859-1
 +XCOMM microsoft-cp1255/Compose:   yi_US.CP1255
  zh_CN/Compose:zh_CN.eucCN
- zh_CN/Compose:zh_CN.GB2312
+-zh_CN/Compose:zh_CN.GB2312
 -zh_CN.gbk/Compose:zh_CN.GBK
++zh_CN/Compose:zh_CN.gb2312
 +zh_CN.gbk/Compose:zh_CN.gbk
 +zh_HK.big5/Compose:   zh_HK.big5
 +zh_HK.big5hkscs/Compose:  zh_HK.big5-hkscs
 +zh_HK.big5hkscs/Compose:  zh_HK.Big5-HKSCS
 +zh_HK.big5hkscs/Compose:  zh_HK.big5hkscs
 +zh_HK.big5hkscs/Compose:  zh_HK.Big5HKSCS
-+zh_CN/Compose:zh_SG.GB2312
++zh_CN/Compose:zh_SG.gb2312
 +zh_CN.gbk/Compose:zh_SG.gbk
  zh_TW.big5/Compose:   zh_TW.big5
 -zh_TW.big5/Compose:   zh_TW.Big5
@@ -485,9 +487,9 @@
 +en_US.UTF-8/Compose:  zu_ZA.UTF-8
 Index: xc/nls/locale.alias
 ===
 xc/nls/locale.alias(revision 271)
+--- xc/nls/locale.alias(revision 292)
 +++ xc/nls/locale.alias(working copy)
-@@ -17,58 +17,105 @@
+@@ -17,58 +17,104 @@
  Cextend:  en_US.ISO8859-1
  Cextend.en:   en_US.ISO8859-1
  English_United-States.437:C
@@ -544,7 +546,6 @@
  ar_JO.utf8:   ar_JO.UTF-8
  ar_KW:ar_KW.ISO8859-6
 +ar_KW.iso88596:   ar_KW.ISO8859-6
-+ar_KW.iso88596:   ar_KW.ISO8859-6
 +ar_KW.ISO-8859-6: ar_KW.ISO8859-6
  ar_KW.utf8:   ar_KW.UTF-8
  ar_LB:ar_LB.ISO8859-6
@@ -596,7 +597,7 @@
  be:   be_BY.CP1251
  be_BY:be_BY.CP1251
  be_BY.cp1251: be_BY.CP1251
-@@ -76,7 +123,6 @@
+@@ -76,7 +122,6 @@
  be_BY.microsoft-cp1251:   be_BY.CP1251
  be_BY.MICROSOFT-CP1251:   be_BY.CP1251
  be_BY.utf8:   be_BY.UTF-8
@@ -604,7 +605,7 @@
  bg:   bg_BG.CP1251
  bg_BG:bg_BG.CP1251
  bg_BG.cp1251: bg_BG.CP1251
-@@ -84,21 +130,35 @@
+@@ -84,21 +129,35 @@
  bg_BG.microsoft-cp1251:   bg_BG.CP1251
  bg_BG.MICROSOFT-CP1251:   bg_BG.CP1251
  bg_BG.iso88595:   bg_BG.ISO8859-5
@@ -642,7 +643,7 @@
  cs:   cs_CZ.ISO8859-2
  cs_CS:cs_CZ.ISO8859-2
  cs_CS.ISO8859-2:  cs_CZ.ISO8859-2
-@@ -107,14 +167,19 @@
+@@ -107,14 +166,19 @@
  cs_CZ.ISO-8859-2: cs_CZ.ISO8859-2
  cs_CZ.ISO_8859-2: cs_CZ.ISO8859-2
  cs_CZ.utf8:   cs_CZ.UTF-8
@@ -663,7 +664,7 @@
  da:   da_DK.ISO8859-1
  da_DK:da_DK.ISO8859-1
  DA_DK:da_DK.ISO8859-1
-@@ -124,24 +189,31 @@
+@@ -124,24 +188,31 @@
  da_DK.ISO-8859-1: da_DK.ISO8859-1
  da_DK.ISO_8859-1: da_DK.ISO8859-1
  da_DK.iso885915:  da_DK.ISO8859-15
@@ -697,7 +698,7 @@
  de_CH:de_CH.ISO8859-1
 

when to upload x.org packages to unstable

[Nathanael Nerode]

This one's listed for -2 in the TODO:
* Finalize all library build/versioning/arrangement decisions as much as
  possible before uploading to unstable, so we don't wreak havoc on the
entire
  world via dpkg-shlibdeps.

But it seems likely that that should be done before the *first* upload
to unstable, for exactly the specified reason!  

Also, what are the plans for integrating with the toolchain change?  There
are a number of C++ programs in the XWindows distribution.  Is the plan to
go through that messy transition *after* going through the X.org
transition?  Could there be advanatages to waiting to upload X.org until it
can be built against the new toolchain?  Or not?

-- 
This space intentionally left blank.


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

Re: X Strike Force X.Org X11 SVN commit: r291 - trunk/debian

[Nathanael Nerode]

X Strike Force SVN Repository Admin wrote:
>  000_stolen_from_author_xterm.diff -- NEEDS PORTING
>Upstream is up to Dickey's patch #197.  This is up to his patch #199,
>or possibly #200.

FYI, I've gone to the trouble of making a patch to bring us up to his patch
#202.  The patch doesn't seem to have made it through to the list yet, but
nobody should duplicate the effort.  I think the effort was worth it even
if xterm is being split out soon, as it provides a baseline to compare the
independent package to, to avoid regressions.

There is one issue: there are three tiny changes by "tsi" from XFree86
*after* the last version we found clean.  (Yes, I vetted it for any other
changes originating from XFree86.)  Two of them are just additions of CVS
keywords and the other one is a small change to an error message.  More
detail was in my message.

-- 
This space intentionally left blank.


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

Patch audit 099 patches

[Nathanael Nerode]

Um, David, you seem to have gotten slightly confused in revision 286:

- 099d_Imake.rules_fix_RawCppFileTarget.diff -- lost
- 099i_pro_savage_ddr_set_use_bios_to_false.diff -- lost
- 099s_selinux_support.diff -- lost
- 099t_xkb_remove_hidden_attributes.diff -- lost
- 099u_mkdirhier_rewrite.diff -- lost
- 099v_fontserver_fix_SEGV.diff -- lost
- 099x_xdm_support_logfile_rotation.diff -- lost

"Lost" means "needs porting".  But you deleted these from the TODO list
without adding anything, apparently.

-- 
This space intentionally left blank.


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

Patch audit "F": 090-098

[Nathanael Nerode]

090_xkb_fix_uk_macintosh_problems.diff -- present and ported
091_xkb_implement_compose:caps.diff -- present and ported
092_Xserver_sunffb_xaa_extension.diff -- present and ported
093_xkb_fix_macintosh_problems.diff
  "Keypad equal" fix is missing and needs to be ported.
  The other fix has been committed (although other things have changed since.)

094_gbk_compound_text_transformation_fix.diff -- present and ported
095_fontutils_are_not_fonts.diff -- present and ported
096_Xlib_l10n_pt_BR.UTF-8.diff -- upstream
097_mouse_zaxis_mapping_pushes_up_buttons.diff -- present and ported
098_en_US.UTF-8_Compose_fix_Unicode_plane_1.diff -- present and ported

-- 
This space intentionally left blank.


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

Patch audit "F" -- rest of 060-079

[Nathanael Nerode]

071_nonexecutable_malloced_mem.diff -- upstream
072_Xserver_fb_convert_RGB_to_BGR.diff -- present and forward-ported
074_freetype_fix_underlining.diff -- upstream

077_xdm_honor_request_port_zero.diff
  Missing, needs to be forward-ported.

079_ati_radeon_fix_power_resume.diff -- upstream
087_SECURITY_libXpm_vulnerabilities.diff -- upstream
088_fix_keyboard_rate_ioctls.diff -- upstream

-- 
This space intentionally left blank.


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

Patch audit "E": remainder of 060-069

[Nathanael Nerode]

061_savage_driver_1.1.27t.diff
  Upstream has an altered version of 1.1.27 derived from the DRI trunk.
  I think that that had already merged 1.1.27t.
  Furthermore, this patch appears to have a *reversionary* effect.
  I believe the patch is actually simply wrong.

063_fix_weak_deps.diff
  Complicated.

  The patch to xc/lib/GL/mesa/drivers/osmesa/Imakefile is present in the
  new patch of the same name.  Which is now upstream (but not in 6.8.2),
  as of revision 1.4 of xc/lib/GL/mesa/drivers/osmesa/Imakefile.  This means
  that it should perhaps be moved into _backport_from_upstream.diff (it
  is miniscule).

  The patch to xc/config/cf/lnxLib.tmpl is not upstream.  However, some
  similar changes are upstream.  (Sigh.)  Differences:
   + SharedGLUReqs includes $(XLIB) upstream
   + SharedXpmReqs includes $(XLIB) rather than $(XONLYLIB) upstream
   + SharedDPSReqs includes $(SMLIB) $(ICELIB) upstream
   + SharedDPSTKReqs includes $(SMLIB) $(ICELIB) $(XTOOLLIB),
 and does *not* include MathLibrary, upstream.

  Probably the best thing to do is to check that there aren't any weak
  references with the upstream version (if so, it's OK.)

064_remove_duplicate_XShm_prototype.diff
  Upstream.

066_XKB_recognize_keypad_period_on_ABNT2_keyboards.diff
  Upstream.

067_fix_X11_and_xdm_build_problems.diff
  Needs porting.


-- 
This space intentionally left blank.


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

Re: xterm.deb build from Thomas E. Dickey's tree directly

[Nathanael Nerode]

Nathanael Nerode wrote:

> I don't think that a debdiff is a good enough method of avoiding
> regressions
> here.  You might consider -- and I know this is a bit odd -- doing a build
> of the new packaging with the exact version used in the monolithic
> package, and doing a full diff between that build and the build from the
> monolithic
> package.  That seems like the best way to avoid configuration regressions.

Followup. I did a debdiff anyway.
* New dependencies on libx11-6 and zlib1g
* Dropped dependencies on libexpat1, libxp6, libxpm4
* Includes "resize", which is in xutils
* programs and manpages in FHS locations rather than /usr/X11R6/* locations. 
Which is good but requires careful transition work.

-- 
This space intentionally left blank.


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

Re: xterm.deb build from Thomas E. Dickey's tree directly

[Nathanael Nerode]

ISHIKAWA Mutsumi wrote:

> 
>  Hi, all.
> 
>  I've tried to build new xterm.deb package from Thomas' tree last
> weekend. I think it is 1st step for pruning xterm from xorg-x11 orig
> tarball (it is listed in TODO list of xorg-x11)
> 
>  Sources and binary (for i386) are available bellow:
> 
>  http://people.debian.org/~ishikawa/xterm/
> 
>  * based on xorg-x11 6.8.2.dfsg.1-0pre1v1
>  * TODO:
> - {pre,post}{rm,insta} scripts cleanup
> - patch audit (patches are roughly merged from xorg-x11)

I just did most of that for you.

Additional patches from the xfree86 packaging which impact xterm are:
803_gnu_xterm_openpty.diff -- needed for Hurd
059_external_XrenderXftXcursor_programs.diff -- needed for external Render

In xorg-x11 tree:
058_support_external_Xcursor_Xft_Xrender_libs.diff -- New version of 059.
803_gnu_xterm_openpty.diff -- Same as old 803.

That's it; none of the other patches patch anything *in* xterm.

Xterm also appears to be xdm's "failsafe" client, so it might be wise for
xdm to "Recommend" xterm; I don't know.

You'll want (obviously) to check that the same files get installed as in the
build from the main package; Imake is a tricky beast and it wouldn't do to
lose something due to a bad Imake interaction.  And if you're switching
from the Imake build to the configure/Make build, it's even more dicey.  

I don't think that a debdiff is a good enough method of avoiding regressions
here.  You might consider -- and I know this is a bit odd -- doing a build
of the new packaging with the exact version used in the monolithic package,
and doing a full diff between that build and the build from the monolithic
package.  That seems like the best way to avoid configuration regressions.

-- 
This space intentionally left blank.


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

Patch audit patch "C" (or is it "D"?)

[Nathanael Nerode]

For various reasons, I'm omitting the "delete this from the list" patches
to TODO at the moment.

I'll be taking a short break now.  More this evening perhaps.  :-)

- Patch audit.
 - 049_Xserver_recognize_Linux_2.6_proc_bus_pci.diff - different, but
   equivalent, patch upstream
 - 050_fix_lnx_io_kbd_rate_fix.diff - slightly worse, but good enough,
   version upstream.
 - 052_glint_fix_unresolved_symbols.diff - upstream
 - 055_lnx_evdev_keyboard.diff - present and ported (slight changes)
 - 056_xdmcp_Wrap.h_fixes.diff - near-equivalent upstream.  However,
   upstream's version only works if HASXDMAUTH is defined, so check that.
 - 057_X11.tmpl_warning_fix.diff - present and ported (no changes)

--- TODO.old2005-06-26 16:44:37.063162666 -0400
+++ TODO2005-06-26 16:44:13.249599701 -0400
@@ -47,6 +47,9 @@
  Have to see whether it's still needed for GNU/kFreeBSD, and if so,
  fix the bug.  See Freedesktop Bugzilla #1902.
 056_xdmcp_Wrap.h_fixes.diff
+  -- near-equivalent upstream, but conditional on HASXDMAUTH.  Check that
+ that is defined everywhere its needed, or make a patch to
+ unconditionalize it.
 061_savage_driver_1.1.27t.diff
 062_make_libGL_PIC_compliant.diff
 063_fix_weak_deps.diff

-- 
This space intentionally left blank.


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

Patch audit patch "C"

[Nathanael Nerode]

- Patch audit.
  - 039_mkfontdir_force_correct_perms.diff: Irrelevant, as mkfontdir
is now essentially an alias to mkfontscale, and the patched file is gone.
  - 043_ati_r128_update_chip_identification.diff: Forward-ported by me,
attached below.

-- 
This space intentionally left blank.
$Id: 043_ati_r128_update_chip_identification.diff 1370 2004-05-07 19:37:27Z bran
den $

Change descriptions of unidentified boards to be more clear about their
unidentifiedness.

This patch from Mike A. Harris.

Not submitted upstream.

Index: xc/programs/Xserver/hw/xfree86/drivers/ati/r128_chipset.h
===
--- xc/programs/Xserver/hw/xfree86/drivers/ati/r128_chipset.h   (revision 275)
+++ xc/programs/Xserver/hw/xfree86/drivers/ati/r128_chipset.h   (working copy)
@@ -7,43 +7,43 @@
 { PCI_CHIP_RAGE128LF, "ATI Rage 128 Mobility M3 LF (AGP)" },
 { PCI_CHIP_RAGE128MF, "ATI Rage 128 Mobility M4 MF (AGP)" },
 { PCI_CHIP_RAGE128ML, "ATI Rage 128 Mobility M4 ML (AGP)" },
-{ PCI_CHIP_RAGE128PA, "ATI Rage 128 Pro GL PA (PCI/AGP)" },
-{ PCI_CHIP_RAGE128PB, "ATI Rage 128 Pro GL PB (PCI/AGP)" },
-{ PCI_CHIP_RAGE128PC, "ATI Rage 128 Pro GL PC (PCI/AGP)" },
+{ PCI_CHIP_RAGE128PA, "ATI Rage 128 Pro GL PA (AGP?)" },
+{ PCI_CHIP_RAGE128PB, "ATI Rage 128 Pro GL PB (AGP?)" },
+{ PCI_CHIP_RAGE128PC, "ATI Rage 128 Pro GL PC (AGP?)" },
 { PCI_CHIP_RAGE128PD, "ATI Rage 128 Pro GL PD (PCI)" },
-{ PCI_CHIP_RAGE128PE, "ATI Rage 128 Pro GL PE (PCI/AGP)" },
+{ PCI_CHIP_RAGE128PE, "ATI Rage 128 Pro GL PE (AGP?)" },
 { PCI_CHIP_RAGE128PF, "ATI Rage 128 Pro GL PF (AGP)" },
-{ PCI_CHIP_RAGE128PG, "ATI Rage 128 Pro VR PG (PCI/AGP)" },
-{ PCI_CHIP_RAGE128PH, "ATI Rage 128 Pro VR PH (PCI/AGP)" },
-{ PCI_CHIP_RAGE128PI, "ATI Rage 128 Pro VR PI (PCI/AGP)" },
-{ PCI_CHIP_RAGE128PJ, "ATI Rage 128 Pro VR PJ (PCI/AGP)" },
-{ PCI_CHIP_RAGE128PK, "ATI Rage 128 Pro VR PK (PCI/AGP)" },
-{ PCI_CHIP_RAGE128PL, "ATI Rage 128 Pro VR PL (PCI/AGP)" },
-{ PCI_CHIP_RAGE128PM, "ATI Rage 128 Pro VR PM (PCI/AGP)" },
-{ PCI_CHIP_RAGE128PN, "ATI Rage 128 Pro VR PN (PCI/AGP)" },
-{ PCI_CHIP_RAGE128PO, "ATI Rage 128 Pro VR PO (PCI/AGP)" },
+{ PCI_CHIP_RAGE128PG, "ATI Rage 128 Pro VR PG (AGP?)" },
+{ PCI_CHIP_RAGE128PH, "ATI Rage 128 Pro VR PH (AGP?)" },
+{ PCI_CHIP_RAGE128PI, "ATI Rage 128 Pro VR PI (AGP?)" },
+{ PCI_CHIP_RAGE128PJ, "ATI Rage 128 Pro VR PJ (AGP?)" },
+{ PCI_CHIP_RAGE128PK, "ATI Rage 128 Pro VR PK (AGP?)" },
+{ PCI_CHIP_RAGE128PL, "ATI Rage 128 Pro VR PL (AGP?)" },
+{ PCI_CHIP_RAGE128PM, "ATI Rage 128 Pro VR PM (AGP?)" },
+{ PCI_CHIP_RAGE128PN, "ATI Rage 128 Pro VR PN (AGP?)" },
+{ PCI_CHIP_RAGE128PO, "ATI Rage 128 Pro VR PO (AGP?)" },
 { PCI_CHIP_RAGE128PP, "ATI Rage 128 Pro VR PP (PCI)" },
-{ PCI_CHIP_RAGE128PQ, "ATI Rage 128 Pro VR PQ (PCI/AGP)" },
+{ PCI_CHIP_RAGE128PQ, "ATI Rage 128 Pro VR PQ (AGP?)" },
 { PCI_CHIP_RAGE128PR, "ATI Rage 128 Pro VR PR (PCI)" },
-{ PCI_CHIP_RAGE128PS, "ATI Rage 128 Pro VR PS (PCI/AGP)" },
-{ PCI_CHIP_RAGE128PT, "ATI Rage 128 Pro VR PT (PCI/AGP)" },
-{ PCI_CHIP_RAGE128PU, "ATI Rage 128 Pro VR PU (PCI/AGP)" },
-{ PCI_CHIP_RAGE128PV, "ATI Rage 128 Pro VR PV (PCI/AGP)" },
-{ PCI_CHIP_RAGE128PW, "ATI Rage 128 Pro VR PW (PCI/AGP)" },
-{ PCI_CHIP_RAGE128PX, "ATI Rage 128 Pro VR PX (PCI/AGP)" },
+{ PCI_CHIP_RAGE128PS, "ATI Rage 128 Pro VR PS (AGP?)" },
+{ PCI_CHIP_RAGE128PT, "ATI Rage 128 Pro VR PT (AGP?)" },
+{ PCI_CHIP_RAGE128PU, "ATI Rage 128 Pro VR PU (AGP?)" },
+{ PCI_CHIP_RAGE128PV, "ATI Rage 128 Pro VR PV (AGP?)" },
+{ PCI_CHIP_RAGE128PW, "ATI Rage 128 Pro VR PW (AGP?)" },
+{ PCI_CHIP_RAGE128PX, "ATI Rage 128 Pro VR PX (AGP?)" },
 { PCI_CHIP_RAGE128RE, "ATI Rage 128 GL RE (PCI)" },
 { PCI_CHIP_RAGE128RF, "ATI Rage 128 GL RF (AGP)" },
 { PCI_CHIP_RAGE128RG, "ATI Rage 128 RG (AGP)" },
 { PCI_CHIP_RAGE128RK, "ATI Rage 128 VR RK (PCI)" },
 { PCI_CHIP_RAGE128RL, "ATI Rage 128 VR RL (AGP)" },
-{ PCI_CHIP_RAGE128SE, "ATI Rage 128 4X SE (PCI/AGP)" },
-{ PCI_CHIP_RAGE128SF, "ATI Rage 128 4X SF (PCI/AGP)" },
-{ PCI_CHIP_RAGE128SG, "ATI Rage 128 4X SG (PCI/AGP)" },
-{ PCI_CHIP_RAGE128SH, "ATI Rage 128 4X SH (PCI/AGP)" },
-{ PCI_CHIP_RAGE128SK, "ATI Rage 128 4X SK (PCI/AGP)" },
-{ PCI_CHIP_RAGE128SL, "ATI Rage 128 4X SL (PCI/AGP)" },
+{ PCI_CHIP_RAGE128SE, "ATI Rage 128 4X SE (AGP?)" },
+{ PCI_CHIP_RAGE128SF, "ATI Rage 128 4X SF (AGP?)" },
+{ PCI_CHIP_RAGE128SG, "ATI Rage 128 4X SG (AGP?)" },
+{ PCI_CHIP_RAGE128SH, "ATI Rage 128 4X SH (AGP?)" },
+{ PCI_CHIP_RAGE128SK, "ATI Rage 128 4X SK (AGP?)" },
+{ PCI_CHIP_RAGE128SL, "ATI Rage 128 4X SL (AGP?)" },
 { PCI_CHIP_RAGE128SM, "ATI Rage 128 4X SM (AGP)" },
-{ PCI_CHIP_RAGE128SN, "ATI Rage 128 4X SN (PCI/AGP)" },
+{ PCI_CHIP_RAGE128SN, "ATI Rage 128 4X SN (AGP?)" },
   

Patch audit patch "B"

[Nathanael Nerode]

- TODO update for patch audit.
  - 027_ati_driver_message_cleanups.diff - upstream
  - 028_fbdev_depth24_support.diff - upstream
  - 029_xinerama_needs_xlib.h.diff - upstream
  - 030_Xserver_and_driver_region_primitive_fixups.diff - not needed;
it's a kludge to allow the ATI backport to work with the old server
version, so it's not needed with the new server version
  - 031_glxinfo_makefile.diff - requires further examination.
Upstream says that it's incorrect and due to a toolchain bug.
Have to see whether it's still needed for GNU/kFreeBSD, and if so,
fix the bug.  See Freedesktop Bugzilla #1902.
  - 032_xserver_manpage_fix.diff - upstream
  - 033_no_specindex.html.diff - Present in 033_no_html.diff --
but undesirable; we're supposed to be shipping HTML documentation
when possible per policy.  Note this in appropriate place.
  - 034_xset_manpage_update.diff - upstream
  - 036_fix_r200_DRI_driver_assertion_failures.diff - the affected files
have been completely relocated, but I eventually found them, and it's
upstream.
  - 037_mga_fix_unresolved_symbols.diff - upstream
  - 038_ICE_remove_bogus_delay.diff - upstream

Index: TODO
===
--- TODO(revision 275)
+++ TODO(working copy)
@@ -41,17 +41,11 @@
  But it's possible that the xorg version is the xfree86 version with parts
  deliberately removed.  I need to know.  :-)
 024_ati_r128_and_radeon_enable_build_without_vgahw.diff
-027_ati_driver_message_cleanups.diff
-028_fbdev_depth24_support.diff
-029_xinerama_needs_xlib.h.diff
-030_Xserver_and_driver_region_primitive_fixups.diff
+  -- changed a lot, needs investigation
 031_glxinfo_makefile.diff
-032_xserver_manpage_fix.diff
-033_no_specindex.html.diff
-034_xset_manpage_update.diff
-036_fix_r200_DRI_driver_assertion_failures.diff
-037_mga_fix_unresolved_symbols.diff
-038_ICE_remove_bogus_delay.diff
+  -- Upstream says that it's incorrect and due to a toolchain bug.
+ Have to see whether it's still needed for GNU/kFreeBSD, and if so,
+ fix the bug.  See Freedesktop Bugzilla #1902.
 039_mkfontdir_force_correct_perms.diff
 043_ati_r128_update_chip_identification.diff
 049_Xserver_recognize_Linux_2.6_proc_bus_pci.diff
@@ -183,6 +177,7 @@
 
 * Ship the HTML docs in xspecs again.  Debian Policy section 12.4 says that we
   should ship HTML documentation if possible.
+  + Kill 033_no_html.diff
 
 * Either restore the Speedo fonts or create a NEWS item about their removal.
   Affects:

-- 
This space intentionally left blank.


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

Patch audit patch "A"

[Nathanael Nerode]

I'm "lettering" them now.  ;-)  This is little bitty bits.

- Update TODO for patch audit.
  - break out things which need to be backported from upstream
  - 011_SECURITY_makedepend_safer.diff present unchanged.  Comments updated
by me because Dawes references are unnecessary now.
  - 011a_recognize_glibc_2.3.2_locale_names.diff needs serious porting.
  - 005_rgb.txt_in_etc_X11.diff comments fixed; references to Dawes are
quite irrelevant now.

Index: TODO
===
--- TODO(revision 271)
+++ TODO(working copy)
@@ -18,15 +18,6 @@
   Probably replaced by 000_stolen_from_linuxwacom_wacom_driver.diff.
   Unfortunately that patch does not say which upstream version was taken,
   unlike the old patch.  That should be fixed.
-000_stolen_from_xorg.diff -- upstream except
-  xc/programs/Xserver/hw/xfree86/i2c/xf86i2c.c @ 1.4
-  -- part of new 000_stolen_from_HEAD
-  xc/include/extensions/xf86mscstr.h @ 1.3
-  xc/programs/Xserver/Xext/xf86misc.c @ 1.2
-  xc/programs/Xserver/Xext/xf86misc.c @ 1.3
-  xc/programs/Xserver/hw/xfree86/common/compiler.h @ 1.5
-  xc/programs/Xserver/hw/xfree86/loader/elfloader.c @ 1.5
-  -- NEED PORTING to new 000_stolen_from_HEAD
 002_xdm_fixes.diff -- most changes NEED PORTING
   -- except non-user-visible whitespace changes, which can be dropped
   * xc/config/cf/gnu.cf:
@@ -49,8 +40,8 @@
   -- The xfree86 version looks more up-to-date than the xorg version.
  But it's possible that the xorg version is the xfree86 version with parts
  deliberately removed.  I need to know.  :-)
-011_SECURITY_makedepend_safer.diff
 011a_recognize_glibc_2.3.2_locale_names.diff
+  -- needs porting.  Ubuntu version lost a lot. [neroden]
 012_Xaw_StripChart_fix.diff
 013_xkb_symbols_euro_support.diff
 014_startx_hostname_fix.diff
@@ -175,6 +166,14 @@
 
 914_debian_Xserver_send_bugs_to_us.diff - needs porting?
 
+  + The following need to be backported from upstream (upstream CVS revisions
+noted):
+  xc/include/extensions/xf86mscstr.h @ 1.3
+  xc/programs/Xserver/Xext/xf86misc.c @ 1.2
+  xc/programs/Xserver/Xext/xf86misc.c @ 1.3
+  xc/programs/Xserver/hw/xfree86/common/compiler.h @ 1.5
+  xc/programs/Xserver/hw/xfree86/loader/elfloader.c @ 1.5
+
   + Grab Thomas Winischhofer's post-6.8.2 fixes to MiscPassMessage() from CVS
 (see Debian #285807).
 
Index: patches/011_SECURITY_makedepend_safer.diff
===
--- patches/011_SECURITY_makedepend_safer.diff  (revision 271)
+++ patches/011_SECURITY_makedepend_safer.diff  (working copy)
@@ -1,14 +1,11 @@
-$Id: 011_SECURITY_makedepend_safer.diff 51 2004-10-18 14:29:56Z fabbione $
+$Id$
 
 This patch by Branden Robinson.
 
 makedepend still isn't really safe.  This makes it much safer.
 
-I think this should go into xf-4_0_2-branch if it passes scrutiny.
+Not submitted upstream.
 
-[UPDATE] David Dawes is of the opinion that makedepend is safe enough since
-it writes to pwd.  That's why this patch isn't upstream.
-
 diff -ruN xc-old/config/util/mdepend.cpp xc/config/util/mdepend.cpp
 --- xc-old/config/util/mdepend.cpp 2004-04-23 20:42:00.0 +0200
 +++ xc/config/util/mdepend.cpp 2004-10-18 13:21:29.772427816 +0200
Index: patches/005_rgb.txt_in_etc_X11.diff
===
--- patches/005_rgb.txt_in_etc_X11.diff (revision 271)
+++ patches/005_rgb.txt_in_etc_X11.diff (working copy)
@@ -1,10 +1,11 @@
-$Id: 005_rgb.txt_in_etc_X11.diff 491 2003-09-10 08:31:58Z branden $
+$Id$
 
 This patch by Branden Robinson.
 
-Need to generalize this, deal with the db version of rgb, etc, then
-resubmit per David Dawes.
+Need to generalize this, deal with the db version of rgb, etc.
 
+Not submitted upstream.
+
 --- xc/programs/rgb/Imakefile.orig Tue Aug 15 17:38:09 2000
 +++ xc/programs/rgb/Imakefile  Tue Aug 15 17:43:54 2000
 @@ -54,7 +54,7 @@

-- 
This space intentionally left blank.


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

Re: Re: X Strike Force X.Org X11 SVN commit: r259 - trunk/debian

[Nathanael Nerode]

Nathanael, here's your chance to
shine some more!


Well, I'm a little bit dispirited by the overwhelming silence which my last
submissions received.  :-P

Apparently nobody has bothered to commit:
http://lists.debian.org/debian-x/2005/06/msg00204.html

Nor has anyone done anything about the NV commit backports:
http://lists.debian.org/debian-x/2005/06/msg00203.html

Perhaps if nobody has time to look at such things, you could give me
commit access so you wouldn't have to?

--Nathanael



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

Lost xfree86 packaging changes -- more than there should be

[Nathanael Nerode]

Daniel Stone wrote:
>Again, you seem to be excluding the possibility of further development
>happening in xfree86 that didn't happen to get synced.

Hate to tell you this, but I was right first time.  Somebody did lose part of 
the locales patch.

* The grammar changes were present in xfree86 Debian packaging SVN revision 
1799.

* The changelog.Ubuntu entry for xorg (6.8.1-1ubuntu9) says 
"Merge changes from Debian XFree86 packaging since we moved to X.Org (current 
with SVN 2113..."

* The differences between SVN 1799 and SVN 2113 are miniscule and do not 
include the grammar changes.

So.  It looks like the "merge" up to SVN 2113 can't be trusted.

Perhaps the resync up to SVN 1793 can be trusted, though at this point I doubt 
it; I think we'll need to check every change since 4.3.0.dfsg.1-6.  :-(


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

Patch: TODO update [replaces #3-6]

[Nathanael Nerode]

Pure update to the TODO for the patch audit.  Subsequent submissions
will fix some of these and other problems.  Consider my previous submissions
#3-6 to be obsolete.

Could someone commit for me?

Index: TODO
===
--- TODO(revision 193)
+++ TODO(working copy)
@@ -46,27 +46,38 @@
   unlike the old patch.  That should be fixed.
 000_stolen_from_xorg.diff -- upstream except
   xc/programs/Xserver/hw/xfree86/i2c/xf86i2c.c @ 1.4
-  -- part of new 000_stolen_from_HEAD
+  -- part of new _backport_from_upstream
   xc/include/extensions/xf86mscstr.h @ 1.3
   xc/programs/Xserver/Xext/xf86misc.c @ 1.2
   xc/programs/Xserver/Xext/xf86misc.c @ 1.3
   xc/programs/Xserver/hw/xfree86/common/compiler.h @ 1.5
   xc/programs/Xserver/hw/xfree86/loader/elfloader.c @ 1.5
-  -- NEED PORTING to new 000_stolen_from_HEAD
+  -- NEED PORTING to new _backport_from_upstream
 000_stolen_from_xorg_nv_driver.diff
 001_kernel_version_in_banner.diff
-002_xdm_fixes.diff
-003_linux.cf_and_xfree86.cf.diff
-003b_xfs_fixes.diff
-004_imake_manpage_handling_overhaul.diff
-005_rgb.txt_in_etc_X11.diff
-006_ati_radeon_fix_eternal_initialization.diff
-007_fix_xfree86_man_version_string.diff
-008_fix_xgetpw_macro.diff
-009_ati_r128_retry_idle_until_timeout.diff
-010_s3_trio64_dx_and_gx_support.diff
-011_SECURITY_makedepend_safer.diff
-011a_recognize_glibc_2.3.2_locale_names.diff
+002_xdm_fixes.diff -- NEEDS PORTING
+  * xc/config/cf/gnu.cf:
+  * xc/config/cf/linux.cf:
+  -- these changes are present under same name
+003_linux.cf_and_xfree86.cf.diff -- NEEDS HELP
+003b_xfs_fixes.diff -- NEEDS PORTING
+  -- present under same name
+004_imake_manpage_handling_overhaul.diff -- present under same name
+005_rgb.txt_in_etc_X11.diff -- present under same name
+  -- comment needs updating to reflect Xorg transition
+006_ati_radeon_fix_eternal_initialization.diff -- upstream
+007_fix_xfree86_man_version_string.diff -- NEEDS HELP
+008_fix_xgetpw_macro.diff -- present under same name
+009_ati_r128_retry_idle_until_timeout.diff -- upstream
+010_s3_trio64_dx_and_gx_support.diff -- NEEDS INFO
+  -- mostly upstream
+  -- patch includes higher MaxClock settings for TRIO64V2_DXGX than upstream,
+ is this good or bad?
+011_SECURITY_makedepend_safer.diff -- NEEDS INFO
+  -- present under same name
+  -- mysterious change from rm -rf ${TMP} to rm -rf ${TMP}*
+  -- comments need updating to reflect change in upstream
+011a_recognize_glibc_2.3.2_locale_names.diff -- NEEDS PORTING
 012_Xaw_StripChart_fix.diff
 013_xkb_symbols_euro_support.diff
 014_startx_hostname_fix.diff

-- 
This space intentionally left blank.


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

Backported patch annotations for nv, etc.

[Nathanael Nerode]

Branden Robinson wrote:
> Consolidate most patches that were in 000_stolen_from_HEAD into
> _backport_from_upstream.
Can we find a *good* name for this patch?

We want:
(a) a name for the patch for pieces ported from the upstream *release branch*
(currently empty, but will no doubt reappear sometime)
(b) a name for the patch for pieces ported from upstream *head*
in that order.

The name backport_from_upstream doesn't clearly distinguish which it is, 
although it's (b).

> Improve documentation and provide better 
> examples of how to backport patches (including upstream commit log messge
> describing what backported patches actually do -> good).
> 
> This regresses some post-6.8.2 updates to xf86PciInfo.h and the ati and nv
> drivers relative to Ubuntu, mainly because it was difficult to tell exactly
> which upstream commits were backported.  Add TODO item so that we restore
> this functionality before releasing to unstable.

Ahem.  You don't read my messages, I guess.  We know exactly which upstream 
commits to the NV drivers were backported, although I haven't checked the 
ChangeLog for all of them.  Two clearly belong in, one clearly doesn't.

NV commits backported:

+* programs/Xserver/hw/xfree86/drivers/nv/nv_hw.c: [@ 1.6]
+Bugzilla #2533 (https://bugs.freedesktop.org/show_bug.cgi?id=2533)
+Feb. 3, 2005 "nv" driver update from Mark Vojkovich
+(Mainly driver updates for nVidia cards with
+  ((pNv->Chipset & 0xfff0) == 0x0090) )
+
+2005-01-25  Alan Coopersmith  <[EMAIL PROTECTED]>
+
+* programs/Xserver/hw/xfree86/drivers/nv/nv_driver.c: [@ 1.10]
+* programs/Xserver/hw/xfree86/drivers/nv/nv_hw.c: [@ 1.5]
+Jan. 2005 nv chipset update from Mark Vojkovich
+Bug #2380 
+Patch #1752 
+
+[programs/Xserver/hw/xfree86/drivers/nv/riva_driver.c @ 1.6]
+   Bug #1192: Remove cfb support from drivers where its use is an option.
+   Delete xf24_32bpp, as s3virge was the last user.  Fix up some comments
+   to refer to fb rather than cfb.
+   [comment change only!]


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

Re: Patch audit TODO update

[Nathanael Nerode]

Daniel Stone wrote:
> > + * Portions appear to be formatting changes and rearrangements
> > +   which probably should be dropped if they're not accepted upstream
> 
> Does it really matter?
It just makes the patch harder to read and causes unnecessary interference 
with subsequent patches (significant because this is such an early-numbered 
patch).  This is in keeping with the "try to minimize the amount of patching 
we're doing" theory.


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

Re: Patch audit TODO update

[Nathanael Nerode]

Daniel Stone wrote:
>xfree86 got updates after we forked that I never merged back.
:-)

Do you happen to know the revision range I should be looking in?  i.e What's 
the fork point, or the last point in the xfree86 patches at which everything 
was merged to Ubuntu?  Knowing this would make the porting and auditing much 
simpler, as I could just assume that anything introduced into xfree86 after 
that point needed to be merged across, and I could just do that.

Thanks in advance,
Nathanael


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

Re: Patch audit continued, mostly locales

[Nathanael Nerode]

Daniel Stone wrote:
>Again, you seem to be excluding the possibility of further development
>happening in xfree86 that didn't happen to get synced.

Yes.
(1) I didn't look at xfree86 upstream
(2) I didn't check the history of Debian's xfree86 patches back very far.
(3) I made the assumption that the Ubuntu folks would have pulled all the 
changes from Debian except possibly the most recent ones.
(4) the changes appeared to have been present since before the Ubuntu fork.

I guess either (3) or (4) was just wrong.  If (4) is wrong, it's just my 
stupidity.  If (3) is wrong, it shows the necessity of a patch audit.

>> +  -- Branden's grammar fixes deserve to return.
>
>s/return/be ported
Yes.

>> +  -- more likely, the xfree86 version is right and the version from Ubuntu
>> + lost stuff.
>
>s/lost stuff/didn't get updated to follow Debian/

Yes, that's fine. :-)  I didn't mean to be hostile to Ubuntu.

> > +  -- some substantial upstream submission wouldn't hurt here
> 
> Already been submitted, and it's blocking on someone from Sun who,
> AFAICT, hasn't meaningfully existed in any X.Org sense for years now.
Eeeew.  What is this Sun guy complaining about?  Can't the current upstream 
maintainers just "do it"?  :-(


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

Patch audit continued, mostly locales [#6]

[Nathanael Nerode]

OK, it's another update to TODO.  UNfortunately, the locales patch seems
to have lost a bunch of stuff (with no explanation), and several others
also need some TLC, so this patch makes TODO blow up a bit.  *sigh*  Maybe
I ought to split it into several TODOs.

--- TODO2005-06-08 00:26:24.137360110 -0400
+++ TODO.newest 2005-06-08 00:25:39.183779778 -0400
@@ -73,13 +73,118 @@
 004_imake_manpage_handling_overhaul.diff -- present under same name
 005_rgb.txt_in_etc_X11.diff -- present under same name
   -- comment needs updating to reflect X.org transition
-006_ati_radeon_fix_eternal_initialization.diff
-007_fix_xfree86_man_version_string.diff
-008_fix_xgetpw_macro.diff
-009_ati_r128_retry_idle_until_timeout.diff
-010_s3_trio64_dx_and_gx_support.diff
-011_SECURITY_makedepend_safer.diff
-011a_recognize_glibc_2.3.2_locale_names.diff
+006_ati_radeon_fix_eternal_initialization.diff -- upstream
+007_fix_xfree86_man_version_string.diff -- NEEDS HELP
+  -- present under same name
+  -- this is a patch to xfree86.cf.  It should become obsolete eventually,
+ and it may already be.
+  -- closely related patch present in 060_fix_XOrgManDefs.diff
+  -- check to see if X11.tmpl needs a parallel change to VendorManDefs
+ (it probably does), in which case this should probably be altered to
+ patch that file (which ought to have the same effects plus).
+008_fix_xgetpw_macro.diff -- present under same name
+009_ati_r128_retry_idle_until_timeout.diff -- upstream
+010_s3_trio64_dx_and_gx_support.diff -- NEEDS INFO
+  -- mostly upstream
+  -- patch includes higher MaxClock settings for TRIO64V2_DXGX than upstream,
+ is this good or bad?
+011_SECURITY_makedepend_safer.diff -- NEEDS INFO
+  -- present under same name
+  -- mysterious change from rm -rf ${TMP} to rm -rf ${TMP}*
+  -- comments need updating to reflect change in upstream
+011a_recognize_glibc_2.3.2_locale_names.diff -- NEEDS PORTING
+  -- partly present under same name
+  -- Branden's grammar fixes deserve to return.
+  -- Excluding comment, whitespace, and diff offset changes, changes merged
+ upstream, and changes to upstream, there still seem to be some mysterious
+ substantive changes:
+
+   In OLD locale.aliases patch, but not NEW:
+   [EMAIL PROTECTED]:  br_FR.ISO8859-15
+   [EMAIL PROTECTED]:  eu_ES.ISO8859-15
+   +id_ID.ISO-8859-1:  id_ID.ISO8859-1
+   +mi_NZ.iso885913:   mi_NZ.ISO8859-13
+   +mi_NZ.ISO-8859-13: mi_NZ.ISO8859-13
+   +mr_IN: mr_IN.UTF-8
+   [EMAIL PROTECTED]:  nl_BE.UTF-8
+   +oc_FR.ISO-8859-1:  oc_FR.ISO8859-1
+   +oc_FR.ISO-8859-15: oc_FR.ISO8859-15
+   -pt_BR.iso885915:pt_BR.ISO8859-15
+   [EMAIL PROTECTED]:  sv_FI.ISO8859-15
+   +uz_UZ: uz_UZ.ISO8859-1
+   +uz_UZ.ISO-8859-1:  uz_UZ.ISO8859-1
+   [EMAIL PROTECTED]:  uz_UZ.UTF-8
+   [EMAIL PROTECTED]:  uz_UZ.UTF-8
+   (different uz_UZ upstream, though)
+   +wa_BE.ISO-8859-1:  wa_BE.ISO8859-1
+   +wa_BE.ISO-8859-15: wa_BE.ISO8859-15
+   [EMAIL PROTECTED]:  wa_BE.ISO8859-15
+   +xh_ZA: xh_ZA.ISO8859-1
+   +xh_ZA.ISO-8859-1:  xh_ZA.ISO8859-1
+   +zh_SG: zh_SG.GB2312
+   +zh_SG.GBK: zh_SG.gbk
+   +zh_TW.BIG5:zh_TW.big5
+   +zh_TW.EUC-TW:  zh_TW.eucTW
+   +zu_ZA: zu_ZA.ISO8859-1
+   +zu_ZA.ISO-8859-1:  zu_ZA.ISO8859-1
+   ...and all changes to the "SCO 3.0" locale names,
+   and to the Microsoft Windows/NT 4.0 locale names.
+
+   In NEW locale.aliases patch, but not OLD:
+   +mi_NZ.iso88591:mi_NZ.ISO8859-13
+   (this *really* looks wrong)
+
+   In OLD locale.dir patch, but not NEW (lots):
+   +XCOMM a3 is not an ISO 639 language code, but in Cyrillic, "Z" looks 
like "3".
+   +koi8-c/XLC_LOCALE: a3_AZ.KOI8-C
+   (koi8 at top of list)
+   +iso8859-1/XLC_LOCALE:  aa_DJ.ISO8859-1
+   +iso8859-15/XLC_LOCALE: an_ES.ISO8859-15
+   +iso8859-6/XLC_LOCALE:  ar_AE.ISO8859-6
+   +iso8859-2/XLC_LOCALE:  bs_BA.ISO8859-2
+   -iso8859-2/XLC_LOCALE:  cz_CZ.ISO8859-2
+  

Patch audit TODO update [#5]

[Nathanael Nerode]

Eeew.  This one was ugly.  Just updates the TODO, but unfortunately there's
a fair amount of unclear and messy stuff in the part I went through.

Index: TODO
===
--- TODO(revision 150)
+++ TODO(working copy)
@@ -46,13 +46,33 @@
   xc/programs/Xserver/hw/xfree86/common/compiler.h @ 1.5
   xc/programs/Xserver/hw/xfree86/loader/elfloader.c @ 1.5
   -- NEED PORTING to new 000_stolen_from_HEAD
-000_stolen_from_xorg_nv_driver.diff
-001_kernel_version_in_banner.diff
-002_xdm_fixes.diff
-003_linux.cf_and_xfree86.cf.diff
-003b_xfs_fixes.diff
-004_imake_manpage_handling_overhaul.diff
-005_rgb.txt_in_etc_X11.diff
+000_stolen_from_xorg_nv_driver.diff -- upstream
+001_kernel_version_in_banner.diff -- present under same name
+002_xdm_fixes.diff -- most changes NEED PORTING
+  -- except non-user-visible whitespace changes, which can be dropped
+  * xc/config/cf/gnu.cf:
+  * xc/config/cf/linux.cf:
+  -- and these changes are present under same name
+003_linux.cf_and_xfree86.cf.diff -- NEEDS HELP
+  -- present under same name (with changes)
+  -- New patch has a few issues left to check:
+ * comments indicate that this belongs in the 900-series; but some of it
+   appears to in fact belong upstream
+ * Portions appear to be formatting changes and rearrangements
+   which probably should be dropped if they're not accepted upstream
+ * Fallback definition of NothingOutsideProjectRoot removed;
+   is this unneccesary due to change in 000_stolen_from_HEAD.diff ?
+ * A bad m68k kernel assumption is deleted.  Should that be upstream?
+ * Portion not moved to 900-series should be renamed to
+   003_linux.cf_and_xorg.cf.diff
+003b_xfs_fixes.diff -- NEEDS INFO, probably NEEDS PORTING
+  -- similar patch present under same name
+  -- The xfree86 version looks more up-to-date than the xorg version.
+ But it's possible that the xorg version is the xfree86 version with parts
+ deliberately removed.  I need to know.  :-)
+004_imake_manpage_handling_overhaul.diff -- present under same name
+005_rgb.txt_in_etc_X11.diff -- present under same name
+  -- comment needs updating to reflect X.org transition
 006_ati_radeon_fix_eternal_initialization.diff
 007_fix_xfree86_man_version_string.diff
 008_fix_xgetpw_macro.diff

-- 
This space intentionally left blank.


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

Integrate 0000_backport_from_upstream into 000_stolen_from_HEAD [#4]

[Nathanael Nerode]

This integrates the remainder of _backport_from_upstream.diff into
000_stolen_from_HEAD.diff.

Combined with a "rm" and "svn rm" of _backport_from_upstream.diff, of
course, which I haven't included here.

Intended to apply after the previous ones.

--- 000_stolen_from_HEAD.diff   2005-06-07 20:26:29.218500169 -0400
+++ 000_stolen_from_HEAD.diff.newest2005-06-07 20:41:34.446848946 -0400
@@ -5,6 +5,15 @@
 Diffs from CVS may have hunks that change only RCS/CVS keyword lines
 elided so that they apply cleanly.
 
+2005-03-06 Branden Robinson <[EMAIL PROTECTED]>
+
+   * xc/config/cf/linux.cf [@ 1.24]
+   Shut up (tons of) Imake warnings on Debian systems by testing for
+   variable being defined before testing its value.  (Presumably the
+   fallback definition of NothingOutsideProjectRoot in Imake.tmpl was
+   intended to prevent this, but it apparently is not in effect yet
+   when linux.cf is parsed.)
+
 [???]
* config/cf/linux.cf: [@ 1.23]
* config/cf/xorg.cf: [@ 1.45]
@@ -69,9 +78,35 @@
 xc/programs/Xserver/hw/xfree86/i2c/xf86i2c.c @ 1.4
Bug #2004: Make DDC delay slightly longer.  (Thomas J. Moore)
 
-diff -urN xc.orig/config/cf/linux.cf xc/config/cf/linux.cf
 xc.orig/config/cf/linux.cf 2005-03-29 00:50:32.412972192 +1000
-+++ xc/config/cf/linux.cf  2005-03-29 00:52:27.671450240 +1000
+Index: xc/config/cf/linux.cf
+===
+--- xc/config/cf/linux.cf  (revision 150)
 xc/config/cf/linux.cf  (working copy)
+@@ -95,13 +95,13 @@
+ XCOMM binutils:   (LinuxBinUtilsMajorVersion)
+ 
+ #if LinuxDistribution == LinuxDebian
+-# if !NothingOutsideProjectRoot
++# if !defined(NothingOutsideProjectRoot) || !NothingOutsideProjectRoot
+ #  define SystemManDirectory  /usr/share/man
+ # endif
+ # define HasPam   YES
+ /* un-comment this when it is un-broken */
+ /* # define JoystickSupport YES */
+-# if !NothingOutsideProjectRoot
++# if !defined(NothingOutsideProjectRoot) || !NothingOutsideProjectRoot
+ #  define XAppLoadDir EtcX11Directory/app-defaults
+ # define XFileSearchPathDefault   
Concat4(EtcX11Directory/%L/%T/%N%C,%S:EtcX11Directory/%l/%T/%N%C,%S:EtcX11Directory/%T/%N%C,%S:EtcX11Directory/%L/%T/%N%S:EtcX11Directory/%l/%T/%N%S:EtcX11Directory/%T/%N%S):Concat4($(LIBDIR)/%L/%T/%N%C,%S:$(LIBDIR)/%l/%T/%N%C,%S:$(LIBDIR)/%T/%N%C,%S:$(LIBDIR)/%L/%T/%N%S:$(LIBDIR)/%l/%T/%N%S:$(LIBDIR)/%T/%N%S)
+ /* the relative symlink created by this rule causes problems for us */
+@@ -112,7 +112,7 @@
+ #  define InstallAppDefaultsLong(file,class)  @@\
+ 
InstallNamedTargetNoClobber(install,file.ad,$(INSTAPPFLAGS),$(XAPPLOADDIR),class)
+ # endif /* InstallAppDefFiles */
+-# endif /* !NothingOutsideProjectRoot */
++# endif /* !defined(NotingOutsideProjectRoot) || !NothingOutsideProjectRoot */
+ # define SharedLibXdmGreetNO
+ # define LinkGLToUsrInclude   NO
+ # define LinkGLToUsrLib   NO
 @@ -136,8 +136,8 @@
   */
  

-- 
This space intentionally left blank.


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

Comment improvement for 000_stolen_from_HEAD.diff [#3]

[Nathanael Nerode]

Not sure my last message went through correctly.

This addes comments to 000_stolen_from_HEAD.diff for all the patches
therein except the Radeon driver ones (which I haven't quite worked out yet).
Of note is the riva_driver patch, which is purely a comment patch, so I don't
see why it's included.

--- 000_stolen_from_HEAD.diff   2005-06-07 20:27:42.531007488 -0400
+++ 000_stolen_from_HEAD.diff.new   2005-06-07 20:26:29.218500169 -0400
@@ -5,6 +5,27 @@
 Diffs from CVS may have hunks that change only RCS/CVS keyword lines
 elided so that they apply cleanly.
 
+[???]
+   * config/cf/linux.cf: [@ 1.23]
+   * config/cf/xorg.cf: [@ 1.45]
+   Re-enable building of tdfx for ia64 and amd64, since libglide3 is
+   available there.
+
+2004-11-08 Fabio M. Di Nitto <[EMAIL PROTECTED]>
+
+* programs/Xserver/hw/darwin/Imakefile [omitted]
+* programs/Xserver/hw/darwin/quartz/Imakefile [omitted]
+* programs/Xserver/hw/xfree86/common/Imakefile [@ 1.9]
+Rename XFREE86_CUSTOM_VERSION to XORG_CUSTOM_VERSION, since
+the former is not used anymore.
+Also ensure tohandle properly XFree86CustomVersion to not break
+actual build systems and provide smooth transition.
+If both XorgCustomVersion and XFree86CustomVersion are defined,
+the former is always preferred.
+* config/cf/linux.cf [@ 1.17]
+Rename XFree86CustomVersion to XorgCustomVersion in the Debian
+Maintainer section.
+
 2005-02-21  Matthieu Herrb <[EMAIL PROTECTED]>
 
* extras/Xpm/lib/create.c: [@ 1.5]
@@ -15,10 +36,38 @@
execute arbitrary code via a negative bitmap_unit value that leads
to a buffer overflow.]
 
-xc/programs/Xserver/hw/xfree86/i2c/xf86i2c.c @ 1.4
-   Bug #2004: Make DDC delay slightly longer.  (Thomas J. Moore)
+[include/extensions/scrnsaver.h @ 1.3]
+   Include X11/Xlib.h in scrnsaver.h
+
+2004-11-07 Fabio M. Di Nitto <[EMAIL PROTECTED]>
+
+* programs/Xserver/hw/dmx/config/Imakefile [@ 1.3]
+Add missing InstallProgram targets for the Xdmx configuration tools.
 
+2005-02-13  Alan Coopersmith  <[EMAIL PROTECTED]>
 
+* programs/Xserver/hw/xfree86/drivers/nv/nv_hw.c: [@ 1.6]
+Bugzilla #2533 (https://bugs.freedesktop.org/show_bug.cgi?id=2533)
+Feb. 3, 2005 "nv" driver update from Mark Vojkovich
+(Mainly driver updates for nVidia cards with
+  ((pNv->Chipset & 0xfff0) == 0x0090) )
+
+2005-01-25  Alan Coopersmith  <[EMAIL PROTECTED]>
+
+* programs/Xserver/hw/xfree86/drivers/nv/nv_driver.c: [@ 1.10]
+* programs/Xserver/hw/xfree86/drivers/nv/nv_hw.c: [@ 1.5]
+Jan. 2005 nv chipset update from Mark Vojkovich
+Bug #2380 
+Patch #1752 
+
+[programs/Xserver/hw/xfree86/drivers/nv/riva_driver.c @ 1.6]
+   Bug #1192: Remove cfb support from drivers where its use is an option.
+   Delete xf24_32bpp, as s3virge was the last user.  Fix up some comments
+   to refer to fb rather than cfb.
+   [comment change only!]
+
+xc/programs/Xserver/hw/xfree86/i2c/xf86i2c.c @ 1.4
+   Bug #2004: Make DDC delay slightly longer.  (Thomas J. Moore)
 
 diff -urN xc.orig/config/cf/linux.cf xc/config/cf/linux.cf
 --- xc.orig/config/cf/linux.cf 2005-03-29 00:50:32.412972192 +1000

-- 
This space intentionally left blank.


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

Enhance comments in 000_stolen_from_HEAD [#3]

[Nathanael Nerode]

This patch adds comments to 000_stolen_from_HEAD for everything included
except the radeon patches.  This is desirable so that people don't have
difficulty figuring out later whether the patches are in the newest upstream
release, etc.  (I haven't done the radeon patches yet because they're just
a tad more complicated, covering at least 3 separate ChangeLog entries.)

Of note is the fact that the change in riva_driver.c is only a comment
change. (And as such I'm not sure why it's being included!)

-- 
This space intentionally left blank.
--- 000_stolen_from_HEAD.diff   2005-06-07 20:27:42.531007488 -0400
+++ 000_stolen_from_HEAD.diff.new   2005-06-07 20:26:29.218500169 -0400
@@ -5,6 +5,27 @@
 Diffs from CVS may have hunks that change only RCS/CVS keyword lines
 elided so that they apply cleanly.
 
+[???]
+   * config/cf/linux.cf: [@ 1.23]
+   * config/cf/xorg.cf: [@ 1.45]
+   Re-enable building of tdfx for ia64 and amd64, since libglide3 is
+   available there.
+
+2004-11-08 Fabio M. Di Nitto <[EMAIL PROTECTED]>
+
+* programs/Xserver/hw/darwin/Imakefile [omitted]
+* programs/Xserver/hw/darwin/quartz/Imakefile [omitted]
+* programs/Xserver/hw/xfree86/common/Imakefile [@ 1.9]
+Rename XFREE86_CUSTOM_VERSION to XORG_CUSTOM_VERSION, since
+the former is not used anymore.
+Also ensure tohandle properly XFree86CustomVersion to not break
+actual build systems and provide smooth transition.
+If both XorgCustomVersion and XFree86CustomVersion are defined,
+the former is always preferred.
+* config/cf/linux.cf [@ 1.17]
+Rename XFree86CustomVersion to XorgCustomVersion in the Debian
+Maintainer section.
+
 2005-02-21  Matthieu Herrb <[EMAIL PROTECTED]>
 
* extras/Xpm/lib/create.c: [@ 1.5]
@@ -15,10 +36,38 @@
execute arbitrary code via a negative bitmap_unit value that leads
to a buffer overflow.]
 
-xc/programs/Xserver/hw/xfree86/i2c/xf86i2c.c @ 1.4
-   Bug #2004: Make DDC delay slightly longer.  (Thomas J. Moore)
+[include/extensions/scrnsaver.h @ 1.3]
+   Include X11/Xlib.h in scrnsaver.h
+
+2004-11-07 Fabio M. Di Nitto <[EMAIL PROTECTED]>
+
+* programs/Xserver/hw/dmx/config/Imakefile [@ 1.3]
+Add missing InstallProgram targets for the Xdmx configuration tools.
 
+2005-02-13  Alan Coopersmith  <[EMAIL PROTECTED]>
 
+* programs/Xserver/hw/xfree86/drivers/nv/nv_hw.c: [@ 1.6]
+Bugzilla #2533 (https://bugs.freedesktop.org/show_bug.cgi?id=2533)
+Feb. 3, 2005 "nv" driver update from Mark Vojkovich
+(Mainly driver updates for nVidia cards with
+  ((pNv->Chipset & 0xfff0) == 0x0090) )
+
+2005-01-25  Alan Coopersmith  <[EMAIL PROTECTED]>
+
+* programs/Xserver/hw/xfree86/drivers/nv/nv_driver.c: [@ 1.10]
+* programs/Xserver/hw/xfree86/drivers/nv/nv_hw.c: [@ 1.5]
+Jan. 2005 nv chipset update from Mark Vojkovich
+Bug #2380 
+Patch #1752 
+
+[programs/Xserver/hw/xfree86/drivers/nv/riva_driver.c @ 1.6]
+   Bug #1192: Remove cfb support from drivers where its use is an option.
+   Delete xf24_32bpp, as s3virge was the last user.  Fix up some comments
+   to refer to fb rather than cfb.
+   [comment change only!]
+
+xc/programs/Xserver/hw/xfree86/i2c/xf86i2c.c @ 1.4
+   Bug #2004: Make DDC delay slightly longer.  (Thomas J. Moore)
 
 diff -urN xc.orig/config/cf/linux.cf xc/config/cf/linux.cf
 --- xc.orig/config/cf/linux.cf 2005-03-29 00:50:32.412972192 +1000

Cleanup on xorg-x11/debian/patches/000* [#2]

[Nathanael Nerode]

Second "patch audit"-related patch from me, since the first is committed.
This does two things:

* avoids the presence of duplicate copies of the Xpm/lib patches
* cleans up and improves the commentary in the first two patches in the
  directory

Index: _backport_from_upstream.diff
===
--- _backport_from_upstream.diff(revision 150)
+++ _backport_from_upstream.diff(working copy)
@@ -16,16 +16,6 @@
intended to prevent this, but it apparently is not in effect yet
when linux.cf is parsed.)
 
-2005-02-21  Matthieu Herrb <[EMAIL PROTECTED]>
-
-   * extras/Xpm/lib/create.c:
-   * extras/Xpm/lib/scan.c:
-   Avoid inifite loops. From Chris Gilbert in bug #1920.
-
-   [Fixes CAN-2005-0605: scan.c for LibXPM may allow attackers to
-   execute arbitrary code via a negative bitmap_unit value that leads
-   to a buffer overflow.]
-
 Index: xc/config/cf/linux.cf
 ===
 RCS file: /cvs/xorg/xc/config/cf/linux.cf,v
@@ -59,53 +49,3 @@
  # define SharedLibXdmGreetNO
  # define LinkGLToUsrInclude   NO
  # define LinkGLToUsrLib   NO
-Index: xc/extras/Xpm/lib/create.c
-===
-RCS file: /cvs/xorg/xc/extras/Xpm/lib/create.c,v
-retrieving revision 1.4
-retrieving revision 1.5
-diff -u -r1.4 -r1.5
 xc/extras/Xpm/lib/create.c 25 Nov 2004 21:19:11 -  1.4
-+++ xc/extras/Xpm/lib/create.c 21 Feb 2005 20:52:32 -  1.5
-@@ -1215,10 +1215,10 @@
- register char *src;
- register char *dst;
- register unsigned int *iptr;
--register unsigned int x, y, i;
-+register unsigned int x, y;
- register char *data;
- Pixel pixel, px;
--int nbytes, depth, ibu, ibpp;
-+int nbytes, depth, ibu, ibpp, i;
- 
- data = image->data;
- iptr = pixelindex;
-Index: xc/extras/Xpm/lib/scan.c
-===
-RCS file: /cvs/xorg/xc/extras/Xpm/lib/scan.c,v
-retrieving revision 1.4
-retrieving revision 1.5
-diff -u -r1.4 -r1.5
 xc/extras/Xpm/lib/scan.c   25 Nov 2004 21:19:11 -  1.4
-+++ xc/extras/Xpm/lib/scan.c   21 Feb 2005 20:52:32 -  1.5
-@@ -621,8 +621,8 @@
- char *dst;
- unsigned int *iptr;
- char *data;
--unsigned int x, y, i;
--int bits, depth, ibu, ibpp, offset;
-+unsigned int x, y;
-+int bits, depth, ibu, ibpp, offset, i;
- unsigned long lbt;
- Pixel pixel, px;
- 
-@@ -633,6 +633,9 @@
- ibpp = image->bits_per_pixel;
- offset = image->xoffset;
- 
-+if (image->bitmap_unit < 0)
-+  return (XpmNoMemory);
-+
- if ((image->bits_per_pixel | image->depth) == 1) {
-   ibu = image->bitmap_unit;
-   for (y = 0; y < height; y++)
Index: 000_stolen_from_HEAD.diff
===
--- 000_stolen_from_HEAD.diff   (revision 150)
+++ 000_stolen_from_HEAD.diff   (working copy)
@@ -1,3 +1,25 @@
+Change descriptions are taken from xc/ChangeLog or the CVS logs,
+with comments in [brackets] added by Debian where necessary for further
+explanation or context.
+
+Diffs from CVS may have hunks that change only RCS/CVS keyword lines
+elided so that they apply cleanly.
+
+2005-02-21  Matthieu Herrb <[EMAIL PROTECTED]>
+
+   * extras/Xpm/lib/create.c: [@ 1.5]
+   * extras/Xpm/lib/scan.c: [@ 1.5]
+   Avoid inifite loops. From Chris Gilbert in bug #1920.
+
+   [Fixes CAN-2005-0605: scan.c for LibXPM may allow attackers to
+   execute arbitrary code via a negative bitmap_unit value that leads
+   to a buffer overflow.]
+
+xc/programs/Xserver/hw/xfree86/i2c/xf86i2c.c @ 1.4
+   Bug #2004: Make DDC delay slightly longer.  (Thomas J. Moore)
+
+
+
 diff -urN xc.orig/config/cf/linux.cf xc/config/cf/linux.cf
 --- xc.orig/config/cf/linux.cf 2005-03-29 00:50:32.412972192 +1000
 +++ xc/config/cf/linux.cf  2005-03-29 00:52:27.671450240 +1000

-- 
This space intentionally left blank.


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

xorg-x11 Patch for patch auditing (#1)

[Nathanael Nerode]

Yep.  I put it in the TODO.

Anyone care to commit for me?

Index: TODO
===
--- TODO(revision 149)
+++ TODO(working copy)
@@ -9,7 +9,221 @@
 -
 * Copy over applicable packaging infrastructure from xfree86.
 
-* Review all xfree86 4.3.0.dfsg.1-13 and -14 patches.
+* Review all xfree86 4.3.0.dfsg.1-13 and -14 patches. [neroden]
+
+000_post430.diff -- upstream
+000_stolen_from_HEAD.diff -- upstream
+000_stolen_from_HEAD_ati_driver.diff -- upstream but
+  verify that no reversions are necessary regarding DRI revision.
+000_stolen_from_HEAD_bsdsupport.diff -- upstream
+000_stolen_from_HEAD_i830_driver.diff -- upstream
+000_stolen_from_HEAD_int10.diff -- upstream
+000_stolen_from_HEAD_mouse_driver.diff -- upstream
+000_stolen_from_HEAD_netbsd.diff -- upstream
+000_stolen_from_HEAD_pci_support.diff -- upstream
+000_stolen_from_HEAD_trident_driver.diff -- upstream
+000_stolen_from_HEAD_via_driver.diff -- upstream
+000_stolen_from_HEAD_xaa.diff -- upstream
+000_stolen_from_HEAD_xedit.diff -- upstream
+000_stolen_from_HEAD_xineramify_xscreensaver.diff -- upstream
+000_stolen_from_HEAD_xkb_data.diff -- upstream
+000_stolen_from_Mesa_5.1.diff -- Mesa 6.1 is upstream (different files)
+000_stolen_from_Mesa_CVS.diff -- Mesa 6.1 is upstream (different files)
+000_stolen_from_author_sis_driver.diff -- upstream
+000_stolen_from_author_xterm.diff -- NEEDS PORTING
+  Upstream is up to Dickey's patch #197.  This is up to his patch #199,
+  or possibly #200.
+000_stolen_from_sourceforge_wacom_driver.diff -- NEEDS HELP
+  Probably replaced by 000_stolen_from_linuxwacom_wacom_driver.diff.
+  Unfortunately that patch does not say which upstream version was taken,
+  unlike the old patch.  That should be fixed.
+000_stolen_from_xorg.diff -- upstream except
+  xc/programs/Xserver/hw/xfree86/i2c/xf86i2c.c @ 1.4
+  -- part of new 000_stolen_from_HEAD
+  xc/include/extensions/xf86mscstr.h @ 1.3
+  xc/programs/Xserver/Xext/xf86misc.c @ 1.2
+  xc/programs/Xserver/Xext/xf86misc.c @ 1.3
+  xc/programs/Xserver/hw/xfree86/common/compiler.h @ 1.5
+  xc/programs/Xserver/hw/xfree86/loader/elfloader.c @ 1.5
+  -- NEED PORTING to new 000_stolen_from_HEAD
+000_stolen_from_xorg_nv_driver.diff
+001_kernel_version_in_banner.diff
+002_xdm_fixes.diff
+003_linux.cf_and_xfree86.cf.diff
+003b_xfs_fixes.diff
+004_imake_manpage_handling_overhaul.diff
+005_rgb.txt_in_etc_X11.diff
+006_ati_radeon_fix_eternal_initialization.diff
+007_fix_xfree86_man_version_string.diff
+008_fix_xgetpw_macro.diff
+009_ati_r128_retry_idle_until_timeout.diff
+010_s3_trio64_dx_and_gx_support.diff
+011_SECURITY_makedepend_safer.diff
+011a_recognize_glibc_2.3.2_locale_names.diff
+012_Xaw_StripChart_fix.diff
+013_xkb_symbols_euro_support.diff
+014_startx_hostname_fix.diff
+015_vesa_ifdef_afb_calls.diff
+016_ICE_subprotocol_reply_fix.diff
+017_fix_Xlib_depend_target.diff
+018_xtt_1.4.1.diff
+019_iso8859-15_Compose_fix.diff
+020_conditionalize_xie_headers.diff
+021_riscpc_ioport_fix.diff
+022_ati_r128_support_800_byte_pitch.diff
+023_specs_doc_fixes.diff
+024_ati_r128_and_radeon_enable_build_without_vgahw.diff
+025_fix_dri_resume.diff
+026_xc_programs_manpage_overhaul.diff
+027_ati_driver_message_cleanups.diff
+028_fbdev_depth24_support.diff
+029_xinerama_needs_xlib.h.diff
+030_Xserver_and_driver_region_primitive_fixups.diff
+031_glxinfo_makefile.diff
+032_xserver_manpage_fix.diff
+033_no_specindex.html.diff
+034_xset_manpage_update.diff
+035_tdfx_disable_dri_on_16mb_with_highres.diff
+036_fix_r200_DRI_driver_assertion_failures.diff
+037_mga_fix_unresolved_symbols.diff
+038_ICE_remove_bogus_delay.diff
+039_mkfontdir_force_correct_perms.diff
+040_extend_netmouse_support.diff
+041_make_xcursor_icondir_configurable.diff
+042_savage_fix_pci_ids.diff
+043_ati_r128_update_chip_identification.diff
+044_chips_default_to_noaccel_on_69k.diff
+045_chips_default_to_swcursor_on_69k.diff
+046_fix_cyrillic_font_aliases.diff
+047_mga_manpage_updates.diff
+048_via_driver_enable.diff
+049_Xserver_recognize_Linux_2.6_proc_bus_pci.diff
+050_fix_lnx_io_kbd_rate_fix.diff
+051_xkb_documentation_updates.diff
+052_glint_fix_unresolved_symbols.diff
+053_lnx_evdev.diff
+054_lnx_evdev_mouse.diff
+055_lnx_evdev_keyboard.diff
+056_xdmcp_Wrap.h_fixes.diff
+057_X11.tmpl_warning_fix.diff
+058_external_XrenderXftXcursor_X11.tmpl.diff
+059_external_XrenderXftXcursor_programs.diff
+060_external_XrenderXftXcursor_lib.diff
+061_savage_driver_1.1.27t.diff
+062_make_libGL_PIC_compliant.diff
+063_fix_weak_deps.diff
+064_remove_duplicate_XShm_prototype.diff
+065_Xft1_manpage_conflict.diff
+066_XKB_recognize_keypad_period_on_ABNT2_keyboards.diff
+067_fix_X11_and_xdm_build_problems.diff
+068_fix_InstallAppDefFiles_screwage.diff
+069_ati_r128_fix_ugly_warning.diff
+070_fbdevhw_device_node_warnings.diff
+071_nonexecutable_malloced_mem.diff
+072_Xserver_fb_convert_RGB_to_BGR.diff
+073_xev_flush_standard_output.diff
+

Re: [decision] new patch management system in xorg-x11

[Nathanael Nerode]

Daniel Stone wrote:
> The modular transition is very tricky -- indeed, large swathes are not
> completed.
Wasn't the idea that one piece at a time could be modularized?
That still seems wise.

>  If we continue to dance around with
> ludicrous patch audits
Hey, if it's done right (meaning "the way I do it") it takes, say, a month max 
and can be done in parallel with other things.  Basically it's a way to avoid 
regressions, and I think it's worthwhile for that reason.


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

Re: X Strike Force X.Org X11 SVN commit: r137 - in trunk/debian: .patches

[Nathanael Nerode]

> Comments?
[1]
Keep a file tracking patch audit status.  You'll want to do two things:
(a) check that each patch currently in the X11 tree is correct
(b) check that each patch in the XFree86 tree is either obsolete or 
forward-ported

For this, you really, really, want a file keeping track of the status.  It 
makes sure that you don't suffer from brain fades, and allows multiple people 
to work on the patch audit, which is quite impossible without some form of 
coordination.

Please note that I have volunteered to work on this:
http://lists.debian.org/debian-x/2005/05/msg00421.html
http://lists.debian.org/debian-x/2005/05/msg00425.html

[2]
Your last change was broken in a fairly obvious way:

+diff -ur xc.orig/extras/Xpm/lib/create.c xc/extras/Xpm/lib/create.c
+--- xc.orig/extras/Xpm/lib/create.c2005-06-04 11:27:07.0 -0400
 xc/extras/Xpm/lib/create.c 2005-06-04 11:29:07.0 -0400
+@@ -1218,7 +1218,7 @@
+ register unsigned int x, y, i;
  ^^^
+ register char *data;
+ Pixel pixel, px;
+-int nbytes, depth, ibu, ibpp;
++int nbytes, depth, ibu, ibpp, i;
  ^^^
+ 
+ data = image->data;
+ iptr = pixelindex;

You lost the change in the upper line.  It needs to change to
register unsigned int x, y;
so that you aren't declaring i twice with inconsistent declarations.

Thanks for your time,
Nathanael


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

xorg-x11 partial patch review

[Nathanael Nerode]

_backport_from_upstream.diff
  does not serve a functionally different purpose from
000_stolen_from_HEAD.diff

At this point both contain patches which are on upstream HEAD but not
upstream branch.  They should probably be merged.  And perhaps reorganized by
module; in particular, splitting out the radeon and nv patches into separate
modules is reasonable.  Yes, I'm volunteering.

However I wouldn't do it until there's a patch audit list so that such
things can be noted on it; otherwise it will just confuse people doing
the patch audit.

More small-scale thoughts (would patches be welcome?):

001_kernel_version_in_banner.diff
won't apply cleanly to 6.8.2, because the name sanitization in that file
didn't go in until revision 1.9 of the Imakefile, and 6.8.2 tagged
revision 1.7.  Either the patch can be respun (without changes)
against 6.8.2, or the name work can be stolen from HEAD.

Incidentally, would people be interested in annotations in the stolen_from_HEAD
patches indicating which upstream revisions they're present in?  It could make
future work of this sort easier.

007_fix_xfree86_man_version_string.diff
It looks like this is still wanted.   (It's cosmetic, right, to add the word
"Version" and some quotation marks so it's formatted right?)  But I suspect
that changing xfree86.cf won't help, and we should instead (or additionally?)
change xorg.cf.   I could do some testing if necessary.  Actually, I suspect
this change belongs right in X11.tmpl.  Hmm.

010_donot_build_XpConfig.diff
Does this really belong upstream?  I wouldn't think so; it looks like it
depends on the particular packaging format with an xprint-common.  In any
case it's not entirely clear that Debian will need to keep xprint-common
forever.  Suggest moving this to a 900-series patch.

099z_xkb_fix_rules_xfree86.diff
The patch has been updated to X.org, but oddly the comments and patch name
haven't been.

990_ubuntu_accept_enabled_for_extensions.diff
probably deserves to go upstream

Comments regarding upstream submission to XFree86 should probably be
replaced with "Not submitted upstream"; I'd be willing to prepare such
a patch as well.

-- 
This space intentionally left blank.


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

Patch audit status?

[Nathanael Nerode]

So, I was thinking I could help with the patch audit going from the
xfree86 repo to the xorg-x11 repo, since I had so much fun with the last
patch audit.  However, there's nothing which actually indicates

(a) what still has to be checked
(b) what has already been checked

Since I don't want to duplicate work, I'd appreciate such a list somewhere
(xorg-x11/trunk/debian/TODO ?)

-- 
This space intentionally left blank.


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

Re: Newer VIA driver for xfree86-4.3.0.dfsg.1

[Nathanael Nerode]

Martijn van de Streek wrote:

> Hi,
> 
> I've created a patch to upgrade the VIA/Unichrome driver in the current
> XFree86 in unstable to the R20 version from http://unichrome.
> sourceforge.net/, and I've patched in their released XvMC patch.
> 
> The only thing that's missing seems to be the dri part of the driver,
> xc/lib/GL/mesa/src/via, from dri CVS.
> 
> I've built, installed and tested this driver and haven't found any
> obvious (to me) bugs.
> 
> All code seems to be under an MIT license, so it should be safe to add
> this.

The VIA driver from http://unichrome.sourceforge.net/ contains a merge from
XFree86 4.4.0.  :-P  The only code changes in the via driver from the
DFSG-clean source to 4.4.0 are two by Luc Verhaegen:

xc/programs/Xserver/hw/xfree86/drivers/via/via_bios.c
  XFree86 Revision 1.11

xc/programs/Xserver/hw/xfree86/drivers/via/via_driver.c
  XFree86 Revision 1.33

If it can be verified that he is not doing "aggressive relicensing", then it
is safe.  If he is doing "aggressive relicesning" like Dawes, who claims
that all his additions after some date or other are under the XFree86 1.1
license, then these two tiny bits are not safe.

Unfortunately, it's important to ask.

-- 
There are none so blind as those who will not see.

Re: Support for VIA driver, patch against SVN HEAD

[Nathanael Nerode]

Branden Robinson wrote:

> This leaves a few questions open:
> 
> A) What does David Dawes regard as "attribution to [him]"?[1]  If the
>responsibility for the CVS commit is attributed to him, as it appears
>to be in several of the above, does he consider the XFree86 1.1
>license to attach to those changes?
I would really like to know this.  I have not included such commits in my
most recent summary of potential XFree86 1.1 license issues in X.org.

The changes would generally be copyright their authors.  If the authors were
contacted directly and released the patches, Dawes could be ignored.

> B) What is Marc La France's policy regarding the application of the
>XFree86 1.1 license to modifications he makes to files that bear no
>copyright notice by him or by the XFree86 Project, Inc.?
Maybe someone could ask him personally?  (Or is he not responding to your
mail either?) There were quite a lot of these, and likewise I have not
included them in that summary.

> C) Does the XFree86 Project, Inc., consider patches submitted to their
>Bugzilla system to have any applicable copyrights therein assigned to
>them?

It had better not; to my knowledge, that doesn't actually happen under US
law.  There's no way that a voluntarily submitted thing from an outsider is
a "work for hire", and copyright assignments have to be signed and on
paper, last time I checked.

> Is there someone who'd like to broach these questions with the XFree86
> Project?  My mails seem to go unanswered.
Don't mail them.  Mail the individual authors, perhaps?

> At any rate, for any of the above where we can get the licensing
> straightened out, I'd be happly to apply the relevant patches.  It may
> be worth contacting Thomas Hellström and Luc Verhaegen to inquire as to
> the provenance of their patches.
Would it be worth contacting the others?

> For the others, I am willing to write up a plain-English description as
> I did for the AT ioctl() issue.
> 
> [1] http://www.mail-archive.com/devel%40xfree86.org/msg05906.html

-- 
There are none so blind as those who will not see.

List of post-2-12 Dawes code and X-Oz code in X.org repo HEAD

[Nathanael Nerode]

This lists code by David Dawes which is not in the 'sanitized' tree prepared
by Branden, but is in the x.org tree.  This would be the code with potential
X-Oz/XFree86 1.1 license issues.

The notes here note the commits for the XFree86 repo.  In the X.org repo,
most of these appear to have been introduced by these commits:
 18. Merged in XFree86 code up to 4.4.0 including changes to files that
 had a changed license. There was only one change which happened to
 be from me (Egbert Eich).
  23.  Merged with XFree86 4.4.0. Added changes that went into infected
   files. Reverted darwin/bundle/**/Credits.rtf to XFree86 versions
   to avoid future conflicts on ASCII but not humal readable files.
   (There should probably be separate CreditsXorg.rtf files)
   (Egbert Eich).

The exception is the X-Oz commit, which was already present and is probably
the biggest hunk of problem code.

Please feel free to forward this to any list which is appropriate.

Unknown: I need help

xc/RELNOTES
xc/programs/Xserver/hw/xfree86/doc/BUILD
xc/programs/Xserver/hw/xfree86/doc/Install
xc/programs/Xserver/hw/xfree86/doc/LICENSE
xc/programs/Xserver/hw/xfree86/doc/README
xc/programs/Xserver/hw/xfree86/doc/README.DECtga
xc/programs/Xserver/hw/xfree86/doc/README.Darwin
xc/programs/Xserver/hw/xfree86/doc/README.LynxOS
xc/programs/Xserver/hw/xfree86/doc/README.NetBSD
xc/programs/Xserver/hw/xfree86/doc/README.OpenBSD
xc/programs/Xserver/hw/xfree86/doc/README.SiS
xc/programs/Xserver/hw/xfree86/doc/README.apm
xc/programs/Xserver/hw/xfree86/doc/README.chips
xc/programs/Xserver/hw/xfree86/doc/README.mouse
xc/programs/Xserver/hw/xfree86/doc/README.s3virge
xc/programs/Xserver/hw/xfree86/doc/RELNOTES
  Commits by Dawes.  But I'm unsure.  Are these autogenerated from
  something else?

Files modified by Dawes: X-Oz commit

(New files)
xc/programs/Xserver/hw/xfree86/common/xf86AutoConfig.c
xc/programs/Xserver/hw/xfree86/getconfig/Imakefile
xc/programs/Xserver/hw/xfree86/getconfig/cfg.sample
xc/programs/Xserver/hw/xfree86/getconfig/getconfig.pl
xc/programs/Xserver/hw/xfree86/getconfig/getconfig.sh
xc/programs/Xserver/hw/xfree86/getconfig/xfree86.cfg

(Modified files)
xc/programs/Xserver/hw/xfree86/CHANGELOG
xc/programs/Xserver/hw/xfree86/Imakefile
xc/programs/Xserver/hw/xfree86/XF86Config.man
xc/programs/Xserver/hw/xfree86/common/Imakefile
xc/programs/Xserver/hw/xfree86/common/xf86Config.c
xc/programs/Xserver/hw/xfree86/common/xf86Config.h
xc/programs/Xserver/hw/xfree86/common/xf86Configure.c
xc/programs/Xserver/hw/xfree86/common/xf86Helper.c
xc/programs/Xserver/hw/xfree86/common/xf86Init.c
xc/programs/Xserver/hw/xfree86/common/xf86Mode.c
xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c
xc/programs/Xserver/hw/xfree86/os-support/bsd/bsd_mouse.c
xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_mouse.c
xc/programs/Xserver/hw/xfree86/os-support/xf86OSmouse.h
xc/programs/Xserver/hw/xfree86/parser/scan.c
xc/programs/Xserver/hw/xfree86/parser/xf86Parser.h
xc/programs/Xserver/hw/xfree86/drivers/vesa/vesa.c

Other files modified by Dawes;
possibly (not necessarily) copyrightable

xc/programs/Xserver/hw/xfree86/etc/bindist/Linux-amd64
(directory)
  An entire new directory committed by Dawes.  Commit logs claim the
  entire mess to be under the XFree86 1.1 license.

  The only way I can see that this would be safe is if it's autogenerated.

xc/programs/Xserver/hw/xfree86/etc/Xinstall.sh
  Revisions 1.69-1.73, David Dawes.
  Significant functional changes.  Includes XFree86 1.1 notice on one commit.

xc/config/cf/Imake.rules
  Revision 3.129, David Dawes
  Introduces a new #define'd routine.
  Apparently only affects Speedo fonts

xc/config/cf/X11.tmpl
  Revisions 1.248, 1.249, David Dawes
  Adds logic (about 8 lines).
  Apparently only affects Speedo fonts

xc/programs/Xserver/hw/xfree86/doc/sgml/README.sgml
  Commit 3.141 by dawes; "update source information"
  (Commit 3.140 is by Georgina Economou, plus trivialities)

xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml
  Commit 1.116 by dawes, adding 'known problems' section
  (Commit 1.115 is by Georgina Economou, plus trivialities)

==
The rest of this message is purely informational since I think the rest of
this is OK.

By Dawes, probably not copyrightable

xc/programs/Xserver/hw/xfree86/drivers/neomagic/neo_driver.c
  Revision 1.75, David Dawes.  Replacement of hex constant in three
  places (1A -> A1).

xc/programs/Xserver/hw/xfree86/etc/bindist/NetBSD-aout-ix86/bin-list
  Revision 1.11, David Dawes.  Changes two .so versions.

xc/config/cf/apollo.cf
  Revision 1.2, David Dawes
  #ifndef'ing of #defines;
  Use of $(NROFF)$(MANMACROS) instead of 'nroff -man';
  removed dependency

xc/fonts/scaled/Speedo/Imakefile
  Revision 1.7, David Dawes
  One-line 'workaround'

xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c
  Revision 1.184 b

Re: Potential future licensing issues with X.org (code merged from XFree86)

[Nathanael Nerode]

Daniel Stone wrote:

On Mon, May 17, 2004 at 06:25:42PM -0400, Nathanael Nerode wrote:


Daniel Stone wrote:


Replying from my PDA is hard, so I'll just briefly say that I have one
hundred per cent confidence in the tree as it stands,


Um, in the X.org tree, you mean?  (Or in the Debian tree, in which I have 
confidence as well?)



freedesktop.org:/cvs/x{org,libs,apps,server}


If you refer to the X.org tree, well, I am specifically worried about the code 
written by David Dawes after and committed 2-12-04 (I assume nobody else is 
obsessed with spreading the XFree86 1.1 license as far as possible).
FYI, I mean I assume nobody but David Dawes is obsessed with spreading 
it, so for these 'implictly-but-not-explicitly 1.1' commits, we only 
really have to worry about the stuff he wrote.  :-)


Luckily, most of this is in the config files which will probably never be 
used in the modular trees, but some of it isn't.



I do not want to see the 1.1 license spread anywhere, something I have
repeatedly said. I even nuked the AutoConfig() stuff from the XFree86
DDX.

:-)



I personally don't have the time to be spending on licensing issues as
it is (hell, I'm not even doing that much code work as it stands). Are
you able to continue like this?


Yeah, given that it's a one-time thing (this is just due to David 
Dawes's claims about what is under the 1.1 license, and presumably there 
will be no future unchecked merges from the XFree86 tree).


I'm a bit paranoid about licensing issues; I have actually avoided code 
work on projects until their licensing was cleared up.



AIUI, most of the 'questionable' code was contributed by others, and/or
is non-copyrightable.

Right.  Unfortunately, that's most of it, not all of it.  :-P

Does it seem reasonable to worry about
* the code from post-2-12-2004 commits which appears to be actually 
contributed by David Dawes, excluding that which is not of significant 
length

* the code from the 'X-Oz' commit
and to not worry about any other commits?

If so, I will check these repos for traces of code from those specific 
categories:

> freedesktop.org:/cvs/x{org,libs,apps,server}
and report back with the short list, if there is any.  (I believe there 
is a little, unfortunately.)

Re: Potential future licensing issues with X.org (code merged from XFree86)

[Nathanael Nerode]

Daniel Stone wrote:
>Replying from my PDA is hard, so I'll just briefly say that I have one
>hundred per cent confidence in the tree as it stands,
Um, in the X.org tree, you mean?  (Or in the Debian tree, in which I have 
confidence as well?)

If you refer to the X.org tree, well, I am specifically worried about the code 
written by David Dawes after and committed 2-12-04 (I assume nobody else is 
obsessed with spreading the XFree86 1.1 license as far as possible).  
Luckily, most of this is in the config files which will probably never be 
used in the modular trees, but some of it isn't.

>and that moving to 
>6.7.0 is pointless and a waste of time.

Yeah; but I was also worried about, as I said:
>Also, the modular trees are likely to merge
> stuff from the monolithic tree, so it seemed important to clear this stuff
>up. 

In fact, some of the modular trees at freedesktop.org  have already merged 
from 6.7.0, including code merged from XFree86 4.4 in the 'questionable' list 
and code from the X-Oz commit.

This means that the modular trees have to be audited for such code before 
being used in Debian, which is annoying.

Potential future licensing issues with X.org (code merged from XFree86)

[Nathanael Nerode]

I started thinking about whether it's reasonable to
switch to the X.org tree for a future Debian release, before all the
modular trees are ready.  Also, the modular trees are likely to merge
stuff from the monolithic tree, so it seemed important to clear this stuff up.

Unfortunately, X.org merged from XFree86 4.4.0 before the release
of X11R6.7.0.  Meaning potential license issues with code coming from the
X.org tree.  :-P

This was with the following commits:
 18. Merged in XFree86 code up to 4.4.0 including changes to files that
 had a changed license. There was only one change which happened to
 be from me (Egbert Eich).
  23.  Merged with XFree86 4.4.0. Added changes that went into infected
   files. Reverted darwin/bundle/**/Credits.rtf to XFree86 versions
   to avoid future conflicts on ASCII but not humal readable files.
   (There should probably be separate CreditsXorg.rtf files)
   (Egbert Eich).

I have made a detailed summary (below) of the differences between Branden's
'sanitized' tree and the version merged into the X.org trunk (4.4.0).
If you don't care about that, stop reading now.  :-)

I did a diff -qr between the two trees, with
  -I '\$XFree86.*\$' \
  -I '\$Id.*\$' \
  -I '\$Date.*\$' \
  -I '\$Header.*\$' \
  -I '\$Source.*\$' \
in order to ignore bogus differences due to CVS expandos.

Then I tried to track down the origins of each commit in the XFree86 CVS logs.
(For a few groups of files, I wore out and did not do so, but I can if it's
wanted by anyone.)

For many of these, particularly the David Dawes-authored ones, I assume they
will have to be kept out of Debian's X packages.

This would be most easily accomplished by getting them reverted
in the X.org tree and any modular trees drawing from it.

But it might have to be accomplished in much more tedious ways.  Anyway,
many of the changes seem entirely irrelevant to Debian, but they might show
up if the X.org tree is used without further thought.  :-P

Most of the non-Dawes changes simply require assurances that the authors
did not intend them to be under the XFree86 1.1/X-Oz licenses, which most
of them probably didn't.

Please feel free to forward this to any list which is appropriate.

Removed files (irrelevant to licensing problems):
=
xc/doc/hardcopy/test
xc/doc/specs/PEX5
xc/programs/Xserver/hw/xfree86/doc/Status
xc/programs/Xserver/hw/xfree86/drivers/i810/README
xc/programs/Xserver/hw/xfree86/etc/bindist/NetBSD-aout-ix86/var-list
xc/util/compress (directory)

Added files
===
xc/programs/Xserver/hw/xfree86/common/xf86AutoConfig.c
  The X-Oz commit.  Dawes/X-Oz.

xc/programs/Xserver/hw/xfree86/etc/bindist/Linux-amd64 (directory)
  Dawes/XFree86 1.1.  Yes, the entire directory.

xc/programs/Xserver/hw/xfree86/etc/bindist/NetBSD-ix86/lib-excl
  Not actually new (readded the version from Feb 27, 2000).
  So, OK.

xc/programs/Xserver/hw/xfree86/getconfig/Imakefile
xc/programs/Xserver/hw/xfree86/getconfig/cfg.sample
xc/programs/Xserver/hw/xfree86/getconfig/getconfig.pl
xc/programs/Xserver/hw/xfree86/getconfig/getconfig.sh
xc/programs/Xserver/hw/xfree86/getconfig/xfree86.cfg
  The X-Oz commit.  Dawes/X-Oz.

Modified files
==
xc/RELNOTES
  I'm unsure.  Is this autogenerated?

xc/config/cf/Imake.rules
  Revision 3.129, David Dawes
  Apparently only affects Speedo fonts

xc/config/cf/X11.tmpl
  Revisions 1.248, 1.249, David Dawes
  Apparently only affects Speedo fonts

xc/config/cf/apollo.cf
  Revision 1.2, David Dawes

xc/config/cf/os2def.db
  Revision 1.8, apparently by Frank Giessler, committed by Dawes

xc/fonts/scaled/Speedo/Imakefile
  Revisions 1.6 and 1.7, David Dawes

xc/lib/font/FreeType/ftfuncs.c
  Revision 1.45.
  Appears to be by Chisato Yamauchi, committed by Dawes

xc/lib/font/FreeType/ftfuncs.h
  Revision 1.19.
  Appears to be by Chisato Yamauchi, committed by Dawes

xc/lib/font/FreeType/xttcap.c
  Revision 1.2.  Bugfix and deletion of deprecated stuff.
  Appears to be by Chisato Yamauchi, committed by Dawes

xc/lib/font/fontfile/encparse.c
  Revision 1.21, by 'tsi'.
  Warning fix only (adds two casts); non-copyrightable?

xc/lib/freetype2/freetype-def.cpp
  Revision 1.7, committed by dawes.
  A one-line addition.
  Apparently written by Frank Giessler.  OS/2 specific.

xc/lib/xtrans/Xtranssock.c
  Revision 3.69, commited by dawes.
  A deletion.  Rather unlikely to be copyrightable.
  Apparently written by Frank Giessler.  OS/2 specific.

xc/programs/Xserver/Xext/dpms.c
  Revision 3.12.  One-line change by Egbert Eich.

xc/programs/Xserver/hw/darwin/bundle/Dutch.lproj/Credits.rtf
xc/programs/Xserver/hw/darwin/bundle/English.lproj/Credits.rtf
xc/programs/Xserver/hw/darwin/bundle/French.lproj/Credits.rtf
xc/programs/Xserver/hw/darwin/bundle/German.lproj/Credits.rtf
xc/programs/Xserver/hw/darwin/bundle/Japanese.lproj/Credits.rtf
xc/programs/Xserver/hw/darwin/bundle/Portuguese.lproj/Credits.rtf
xc/programs/Xserver/hw/darwin/bundle/Spanish.lproj/Credits.rtf
xc/program

Re: Bug#242865: The "moreinfo" for these drivers/binary executables

[Nathanael Nerode]

Branden Robinson wrote:

> tag 242865 - moreinfo
> thanks
> 
> On Fri, Apr 16, 2004 at 07:24:16PM -0400, Nathanael Nerode wrote:
>> This is the list of files known to be affected by this bug:
>> 
>> xc/programs/Xserver/hw/xfree86/drivers/mga/mga_ucodexch
>> xc/programs/Xserver/hw/xfree86/drivers/rendition/v10002dxcuc
>> xc/programs/Xserver/hw/xfree86/drivers/rendition/v20002dxcuc
>> xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/r128_ccexcc
>> xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon_cpxcc
>> xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/mga_ucode.h
> 
> I think you mean:
> 
> xc/programs/Xserver/hw/xfree86/drivers/mga/mga_ucode.h
> xc/programs/Xserver/hw/xfree86/drivers/rendition/v10002d.uc
> xc/programs/Xserver/hw/xfree86/drivers/rendition/v20002d.uc
> xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/r128_cce.c
> xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon_cp.c
> xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/mga_ucode.h
> 
> (global search and replace gone wrong?)
Yes!  Heh.  Thanks for figuring out what I meant.  :-)

> 
>> These files all contain binary executables (to run on graphics card
>> chips)
>> with no source code at all.  Therefore they fail the DFSG's requirements.
>> 
>> Luckily, none of these files are actually *used* in Debian's XFree86
>> build, so removing them from the .tar.gz of Debian's XFree86 source
>> should be an easy and trivial solution to this bug for sarge.
>> 
>> (Different copies of the same binaries are present and used in the kernel
>> packages, but those are being addressed elsewhere.)
>> 
>> I don't think, therefore, that this bug needs to be tagged "moreinfo" any
>> longer...
> 
> Agreed.  Thanks!
> 

-- 
There are none so blind as those who will not see.

Re: Outstanding ITP - gatos-drm-source

[Nathanael Nerode]

Michel Dänzer wrote:
>> > Also, are you aware of the bugs being filed about the non-free
>> > microcode in the DRM?
>> 
>> No, I'll look at that.  You mean DRM from DRI or from GATOS ?
> 
> Any flavour, the microcode is the same everywhere.

I've been trying to figure out who really holds the microcode copyright; I
suspect the DRI tree is inaccurate on this point (claiming that the ATI
microcode copyright is held by VALinux).  Because of this, I believe
there's no explicit permission to redistribute it, and I hope someone calls
ATI soon.  :-)

-- 
There are none so blind as those who will not see.

Bug#242865: The "moreinfo" for these drivers/binary executables

[Nathanael Nerode]

This is the list of files known to be affected by this bug:

xc/programs/Xserver/hw/xfree86/drivers/mga/mga_ucodexch
xc/programs/Xserver/hw/xfree86/drivers/rendition/v10002dxcuc
xc/programs/Xserver/hw/xfree86/drivers/rendition/v20002dxcuc
xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/r128_ccexcc
xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon_cpxcc
xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/mga_ucode.h

These files all contain binary executables (to run on graphics card chips) 
with no source code at all.  Therefore they fail the DFSG's requirements.

Luckily, none of these files are actually *used* in Debian's XFree86 build, so 
removing them from the .tar.gz of Debian's XFree86 source should be an easy 
and trivial solution to this bug for sarge.

(Different copies of the same binaries are present and used in the kernel 
packages, but those are being addressed elsewhere.)

I don't think, therefore, that this bug needs to be tagged "moreinfo" any 
longer...

Re: X11R6.7

[Nathanael Nerode]

Keith Packard wrote:

> Around 15 o'clock on Apr 13, Branden Robinson wrote:
> 
>> I think it might be easier to transition our developers and users if we
>> packaged the X.Org monolithic tree, adding stuff from modular tree in
>> parallel as it becomes available.
> 
> That depends to some degree on whether I manage to convince the X.org
> developers to take the time right now to transition the tree to a modular
> structure without making any code changes.
Yes, indeedy.

>  If so, then having Debian
> transition to the modular version of X11R6.7 might make more sense than
> moving to the monolithic version of 6.7 only to then repackage with the
> modular bits a short time later.
Ye!  We like it!

> The goal here is to leave the code completely unchanged and only modify
> the build and packaging systems.
That would rock

-- 
Make sure your vote will count.
http://www.verifiedvoting.org/

Re: Bug#242865: mga_ucode.h

[Nathanael Nerode]

Michel Dänzer wrote:

> On Sat, 2004-04-10 at 11:05, Nathanael Nerode wrote:
>> >./programs/Xserver/hw/xfree86/drivers/mga/mga_ucode.h
>> > * GLX Hardware Device Driver for Matrox G200/G400
>> 
>> This version appears to be unused (not referenced anywhere), and hence no
>> loss.
>> 
>> The 'used' version is:
>> ./programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/mga_ucode.h
>> Which of course would need to be removed as well.
>> 
>> Although Michael Daenzer may wish to comment -- is that file even used in
>^^^
> Ahem.
Sorry!

> 
>> Debian's configuration, given that these other two in the same directory
>> aren't?
>> >./programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/r128_cce.c
>> >./programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon_cp.c
> 
> No, the DRM code in the xfree86 source package isn't used. Of course,
> the DRM code _is_ used in the kernels, and apparently similar bugs are
> being filed against them. I wonder if users will like the DRI not
> working out of the box... I think the people behind this should be
> forced to hack graphics chip command processor microcode 'source code'.
> ;)
> 
> 

-- 
Make sure your vote will count.
http://www.verifiedvoting.org/

Bug#242865: mga_ucode.h

[Nathanael Nerode]

>./programs/Xserver/hw/xfree86/drivers/mga/mga_ucode.h
> * GLX Hardware Device Driver for Matrox G200/G400

This version appears to be unused (not referenced anywhere), and hence no 
loss.

The 'used' version is:
./programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/mga_ucode.h
Which of course would need to be removed as well.

Although Michael Daenzer may wish to comment -- is that file even used in 
Debian's configuration, given that these other two in the same directory 
aren't?
>./programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/r128_cce.c
>./programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon_cp.c

Bug#242865: Rendition microcode also no loss.

[Nathanael Nerode]

>./programs/Xserver/hw/xfree86/drivers/rendition/v10002d.uc
>./programs/Xserver/hw/xfree86/drivers/rendition/v20002d.uc

It appears that this driver can work in non-accelerated mode without the 
firmware.  Furthermore, it appears that in the default configuration, which 
is used in Debian, it *is* in non-accelerated mode and *doesn't* use the 
firmware.  (See the USE_ACCEL define in rendition/rendition.c.)

So, much like the two which Michael Daenzer mentioned, these are unused, and 
therefore no loss at all.

Re: xorg vs. xlibs/xserver/xapps?

[Nathanael Nerode]

Keith Packard wrote:

> Around 17 o'clock on Mar 27, Nathanael Nerode wrote:
> 
>> What are the differences between XOrg's monolithic tree and
>> freedesktop.org's modular trees?  Are they basically the same code apart
>> from the (large) configuration differences, or is one behind/ahead of the
>> other regarding drivers, core functionality, etc.?
> 
> There aren't any significant technical differences, and I'll be merging
> those across once the X.Org release is ready.
Good news.  :-)  Whee!


> The goal is to migrate development effort from the monolithic tree to the
> modular tree while preserving full compatibility.
Again, good news, and whee.  :-)

-- 
Make sure your vote will count.
http://www.verifiedvoting.org/

xorg vs. xlibs/xserver/xapps?

[Nathanael Nerode]

Daniel Stone wrote:

> On Thu, Mar 25, 2004 at 06:51:03PM +0300, Dan Korostelev wrote:
>>  Is there any plans to replace XFree86 with XOrg
>> (http://freedesktop.org/Software/xorg), which is actually a fork of
>> XFree 4.4 with free licence.
>> 
>> Sorry for my english. Bye.
> 
> No, but there are plans to replace it with freedesktop.org's modular
> xlibs/xserver/xapps trees, to make it far easier to maintain.

To switch to a technical question
What are the differences between XOrg's monolithic tree and
freedesktop.org's modular trees?  Are they basically the same code apart
from the (large) configuration differences, or is one behind/ahead of the
other regarding drivers, core functionality, etc.?

For instance, I know that XOrg has basically all the XFree86 4.4
functionality in it (they're advertising it).  I have no idea whether the
modular freedesktop.org trees have the same collection of code merged in
(or whether they intend to).  (I hope so.)  Any idea?

-- 
Make sure your vote will count.
http://www.verifiedvoting.org/

Re: Bug#237574: #237574 X cannot start under kernel 2.6.3

[Nathanael Nerode]

Peter Samuelson wrote:

>   [Michel Dänzer]
>> >so you get double mouse events with a
>> >Debian generated XF86Config-4 with the mouse device selected as
>> >/dev/psaux?
> 
> [Nathanael Nerode]
>> That's an interesting theory, but doesn't appear to be true -- I'm
>> certainly not getting double mouse events.
> 
> You would be if you had the rather common XF86Config-4 setup with two
> InputDevice sections, one with /dev/input/mice and the other with
> /dev/psaux.
Oh, I see.  :-)  No, I only had the one section.

-- 
Make sure your vote will count.
http://www.verifiedvoting.org/

Bug#237574: #237574 X cannot start under kernel 2.6.3

[Nathanael Nerode]

Michel Dänzer wrote:

On Sat, 2004-03-13 at 08:37, Nathanael Nerode wrote:




Mason Thomas wrote:



Since kernel 2.6.3 has recently become available to testing, I installed
it
and booted. The kernel was unable to startup gdm, and I also could not
"startx". The 2.4 kernels do not appear to have this problem. The kernel
log
complains about errors with XFree86, so that is why I am submitting it
under
this package.


lsmod, and make sure the 'psmouse' modules is listed.
If not, `modprobe psmouse` and try again.

It's not loaded by default in kernel 2.6 for unknown reasons.



Because /dev(/misc)/psaux is deprecated and merely a copy of
/dev/input/mice with 2.6 kernels,

It is?  Why isn't this loudly documented somewhere?  :-)


so you get double mouse events with a
Debian generated XF86Config-4 with the mouse device selected as
/dev/psaux?
That's an interesting theory, but doesn't appear to be true -- I'm 
certainly not getting double mouse events.

Re: Bug#237574: #237574 X cannot start under kernel 2.6.3

[Nathanael Nerode]

Mason Thomas wrote:

>>>Since kernel 2.6.3 has recently become available to testing, I installed
>>>it
>>>and booted. The kernel was unable to startup gdm, and I also could not
>>>"startx". The 2.4 kernels do not appear to have this problem. The kernel
>>>log
>>>complains about errors with XFree86, so that is why I am submitting it
>>>under
>>>this package.

lsmod, and make sure the 'psmouse' modules is listed.
If not, `modprobe psmouse` and try again.

It's not loaded by default in kernel 2.6 for unknown reasons.
Put a line in /etc/modules which just says 'psmouse' to load it on boot.

Perhaps this should be a FAQ?  (Better yet, perhaps the kernel should load
it by default?...)

-- 
Make sure your vote will count.
http://www.verifiedvoting.org/

Bug#237574: #237574 X cannot start under kernel 2.6.3

[Nathanael Nerode]

Mason Thomas wrote:

>>>Since kernel 2.6.3 has recently become available to testing, I installed
>>>it
>>>and booted. The kernel was unable to startup gdm, and I also could not
>>>"startx". The 2.4 kernels do not appear to have this problem. The kernel
>>>log
>>>complains about errors with XFree86, so that is why I am submitting it
>>>under
>>>this package.

lsmod, and make sure the 'psmouse' modules is listed.
If not, `modprobe psmouse` and try again.

It's not loaded by default in kernel 2.6 for unknown reasons.
Put a line in /etc/modules which just says 'psmouse'.

Perhaps this should be a FAQ?

Stupid build failures for XFree86 4.3.0-2

[Nathanael Nerode]

>From the i386 buildd log:
>The following packages have unmet dependencies:
>  groff: Depends: libxaw7 (> 4.1.0) but it is not going to be installed
> Depends: xlibs (> 4.1.0) but it is not going to be installed
>  libglide2-dev: Depends: libglide2 but it is not going to be installed
>  libglide3-dev: Depends: libglide3 but it is not going to be installed
>  libxcursor-dev: Depends: libxcursor1 (= 1.0.2-4) but it is not going to be 
> installed
>  Depends: xlibs-dev but it is not going to be installed
>  libxft-dev: Depends: libxft2 (= 2.1.2-5) but it is not going to be installed
>  Depends: xlibs-dev but it is not going to be installed
>  libxrender-dev: Depends: libxrender1 (= 0.8.3-5) but it is not going to be 
> installed
>  Depends: xlibs-dev but it is not going to be installed
>  Depends: render-dev but it is not going to be installed
>  tetex-bin: Depends: libxaw7 (> 4.1.0) but it is not going to be installed
> Depends: t1lib1 but it is not going to be installed
> Depends: xlibs (> 4.1.0) but it is not going to be installed

Gah?  All of these look bogus to a lesser or greater extent, but what needs
to be done about them?

-- 
Nathanael Nerode  
US citizens: if you're considering voting for Bush, look at these first:
http://www.misleader.org/  http://www.cbc.ca/news/background/arar/
http://www.house.gov/reform/min/politicsandscience/

Re: X Strike Force XFree86 SVN commit: rev 1003 - /

[Nathanael Nerode]

Branden wrote:
>Here's the new plan.
>
>svn cp trunk branches/4.3.0/sid-branched-properly
>
>[make this branch look like revision 50 of branches/4.3.0/sid]
>
>svn ci
>svn merge -r 50:HEAD branches/4.3.0/sid branches/4.3.0/sid-branched-properly
>svn ci
>svn rm branches/4.3.0/sid branches/4.3.0/sid-branched-properly
Um, after going to all that trouble to make sid-branched-properly, you don't 
want to just delete it, do you?  :-O

>svn ci
>
>Merge the branch back onto the trunk.

debian/patches: my forward-ports of three of the 'unmerged' patches

[Nathanael Nerode]

These are untested, but they *did* pass 'debian/rules patch-audit'.
(I used the 'orig' tarball from the current version in experimental, on the
assumption that that wasn't going to change.)

The forward-porting seemed relatively straightforward, so I figured I might
as well just do it.

070_fbdevhw_device_node_warnings.diff -- the former patch of the same name
064_remove_duplicate_XShm_prototype.diff -- the former 049
071_nonexecutable_malloced_mem.diff -- the former 067

-- 
Nathanael Nerode  
US citizens: if you're considering voting for Bush, look at these first:
http://www.misleader.org/  http://www.cbc.ca/news/background/arar/
http://www.house.gov/reform/min/politicsandscience/
$Id$

This patch by Branden Robinson.

When there aren't any /dev/fb* devices, issue a more generic error message
instead of one X_ERROR for each device file that we try to open.

Not submitted upstream yet.

diff -urN xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c 
xc.new/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c
--- xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c2004-02-07 
18:25:01.0 -0500
+++ xc.new/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c2004-02-07 
18:20:44.0 -0500
@@ -298,7 +298,10 @@
}
if (namep)
*namep = NULL;
+   xf86DrvMsg(-1, X_ERROR,
+  "Unable to find a valid framebuffer device\n");
return -1;
+
 }
 
 static int
$Id$

This patch by Branden Robinson.

Submitted upstream as #5656 (as a suggestion to revert a previous CVS
revision).

--- xc/include/extensions/XShm.h~   2003-02-28 16:18:10.0 -0500
+++ xc/include/extensions/XShm.h2003-02-28 16:18:32.0 -0500
@@ -79,12 +79,6 @@
 
 int XShmGetEventBase(
 #if NeedFunctionPrototypes
-Display*   /* dpy */
-#endif
-);
-
-int XShmGetEventBase(
-#if NeedFunctionPrototypes
 Display*   /* dpy */
 #endif
 );
$Id$

This patch fixes the assumption that data returned by malloc() is executable.
In upstream revision 1.43, the assumption was fixed for ia64 only.  
We understand it is Linus' position that programs that assume data to be
executable are broken, so we enable this code for all Linux platforms.

Original patch (before upstream applied its own version) was by David Mosberger.

diff -urN xc/programs/Xserver/hw/xfree86/loader/elfloader.c 
xc.new/programs/Xserver/hw/xfree86/loader/elfloader.c
--- xc/programs/Xserver/hw/xfree86/loader/elfloader.c   2004-02-07 
17:33:29.0 -0500
+++ xc.new/programs/Xserver/hw/xfree86/loader/elfloader.c   2004-02-07 
17:29:03.0 -0500
@@ -957,7 +957,7 @@
ErrorF( "ELFCreateGOT() Unable to reallocate memory\n" );
return FALSE;
}
-#   if defined(linux) && defined(__ia64__) || defined(__OpenBSD__)
+#   if defined(linux) || defined(__OpenBSD__)
{
unsigned long page_size = getpagesize();
unsigned long round;

debian/patches: 068_riscpc_ioport_fix.diff

[Nathanael Nerode]

This one is merged, contrary to the TODO.  It's been renumbered to 021 and
improved slightly.

-- 
Nathanael Nerode  
US citizens: if you're considering voting for Bush, look at these first:
http://www.misleader.org/  http://www.cbc.ca/news/background/arar/
http://www.house.gov/reform/min/politicsandscience/

Re: X Strike Force XFree86 SVN commit: rev 1003 - /

[Nathanael Nerode]

+[3 February] The patch audit mentioned in the TODO file 
for the 4.3.0-1 release has been completed,
+thanks to the invaluable assistance of Nathanael Nerode and David 
Nusinow.  Once the missing patches have been
+forward-ported, I will either release 4.3.0-0pre1v6 to experimental, or 
4.3.0-1 to unstable.  The deciding factor
+will be how much work it is to merge branches/4.3.0/sid onto 
the trunk in SVN.  (The
+problem is that the branch wasn't "properly" branched in the first place, 
but rather an import by Daniel Stone of
+work he had done outside revision control -- at the time he did it, the 
XSF SVN repository did not even exist.)  I
+don't want people to have to wait simply while I do repository 
housekeeping, so if it looks like this will take a
+long time, I will release 4.3.0-0pre1v6 to experimental to tide people 
over.

Basically, you just want branches/4.3.0/sid to "become" the trunk, right?  If 
you're not worrying about somehow trying to get the trunk history attached to 
the branch (and my advice is: don't, as it will mess up the *branch* 
history), then I believe there's a very straightforward, if moderately 
demented, way of doing this in SVN:

svn mv trunk branches/old-trunk
svn cp branches/4.3.0/sid trunk
svn commit

The wonders of versioned renames and moves.  :-)