[I am not subscribed to debian-user; please be sure the debian-x mailing
list is included in your follow-ups if you want me to see them. Please
also do not keep Joey in your To/CC headers unless you really want to
communicate privately with him.]
[Joey, I am CCing you as a heads-up. I don't know of a role address for
Stable Release Manager.]
Hi folks,
It's your friendly neighborhood X Strike Force lunatic with a request for
some feedback from woody users.
As some of you know, the most recent security update of XFree86 for woody,
xfree86 4.1.0-16woody5[1], featured fixes for many potential security problems
in the XPM library.
Unfortunately, the extensive changes made in this security release (due to
a security audit of XPM), caused a regression in functionality, such that
applications which use XPM to read and write arbitrary file specifications
can fail. This has been recently seen in, for example, the GIMP[2].
This inadvertent regression in functionality -- in my opinion -- calls for a
stable-update to the xfree86 packages to restore the functionality that was
lost. To that end, I have begun preparing xfree86 4.1.0-16woody6 in the X
Strike Force Subversion repository[3].
However, the controlling opinion regarding stable-updates is that of the
Stable Release Manager, Joey Schulze. His rules for determining what is
permissible as a stable-update are described at his website[4].
It does occur to me that, given this opportunity for a stable update to
XFree86, some other long-standing issues with the version of XFree86 in
woody can be resolved. Some, like the debconf default for "UseFBDev", are
consistently problematic for users. They cause the users grief because the
X server won't start, and they cause me grief because people complain about
a known fixed bug, and I can't just tell everyone to upgrade to unstable.
I therefore would like to solicit your opinions on which bugfixes should be
applied. Let me start off with a list of bugs that were fixed way back in
4.1.0-17, which was uploaded too late to make it into woody:
xfree86 (4.1.0-17) unstable; urgency=low
* patch #069: set the r128 driver's pitch increment to 8 * 32 instead of 8 *
64 bytes, since we know that a pitch of 800 bytes works on, for instance,
ATI Rage 128 LF-based clamshell iBooks; thanks to Michel Dänzer for his
help identifying the problem
[The above makes Debian woody's XFree86 X server needlessly unusable on
several models of laptop.]
* patch #070: patch from Michel Dänzer so that the fbdevhw layer doesn't
fail silently when no framebuffer device (e.g., /dev/fb0) can be found, or
doesn't respond to ioctl()s
[The above makes it much easier to troubleshoot X server failures,
especially when UseFBDev is set and should not be.]
[...]
* debian/local/xserver-wrapper.c:
- *sigh* Ben Collins changed our FROZEN C library back to pre-SuSv2 nice()
semantics, so rewrote the nice() error handing
[The above stops the X server wrapper from howling in a way that scares
users, *every damn time the X server starts*.]
- correct limits on legal nice values from -20 <= x <= 20 to
-20 <= x <= 19
[The above fixes bad data validation. It's probably not essential, but I'd
rather have the X wrapper scold the user for putting in a bad nice value
than have the C library screech about it.]
* debian/xserver-xfree86.config:
[...]
- when testing for fbcon, actually cat /proc/fb if it exists; it's only in
use if a string is returned
[The above fixes a broken default that keeps the X server from working with
the default configuration for many, many x86 users.]
- do not explicitly load the "dri" module on the sparc architecture if the
sunffb driver is being used, because of an apparent upstream bug in the
module loader (thanks, Ben Collins)
[The above fixes X server startup failures for SPARC users using the sunffb
driver.]
-- Branden Robinson <branden@debian.org> Fri, 24 May 2002 01:26:13 -0500
My question is this:
Are there any other changes that should be seriously considered for this
stable update? I'm particularly interested in feedback from people who
follow the debian-user list closely, and have seen certain woody XFree86
problems crop up time and time again. Feel free to cast your vote for any
of the above, or nominate your own bugfix.
Note that several types of changes have to be ruled out, despite how
popular I know some of them will be:
* updating XFree86 to a newer upstream version;
* updating the X packages to X.Org X11R6.[78]
* anything much larger than a one-line change to the upstream source
code
* any change which doesn't get tested and signed off on as working by at
least 3 people whose attestations can be trusted (I can be one of the
three for changes that don't require specific hardware to test)
* any bugfix that hasn't been written yet (there may be exceptions to this,
but you'd have to convince me first, and then I'll have to convince Joey
-- so your best bet is to come up with a patch, and it had better be
pretty compelling)
Also note that the Stable Release Manager, can veto any change he wants.
It's the prerogative he enjoys for being the sole Stable Release Manager,
which is an even more thankless task than maintaining XFree86, I am sure.
Even the modest sorts of changes I am proposing really push the envelope of
what I think is permissible under Debian's Stable Release update policy, so
if you want to talk about changes I've explicitly excluded above, please do
so in another thread.
I'd like to open a comment/discussion period lasting a couple of weeks. I
may close it early if there is insufficient interest, or under extenuating
circumstances (e.g., Joey tells me none of the above changes is permissible
under any circumstance).
I thank you in advance for your feedback.
[1] http://www.debian.org/security/2004/dsa-607
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286164
[3] svn://necrotic.deadbeast.net/xfree86/branches/4.1.0/woody-proposed-updates
[4] http://people.debian.org/~joey/3.0r5/
--
G. Branden Robinson | It's not a matter of alienating
Debian GNU/Linux | authors. They have every right to
branden@debian.org | license their software however we
http://people.debian.org/~branden/ | like. -- Craig Sanders
Attachment:
signature.asc
Description: Digital signature