On Thu, Apr 29, 2004 at 07:56:06AM +0200, Fabio Massimo Di Nitto wrote: > Hi all, > a few hours ago 4.3.0.dfsg.1-1 has been uploaded and it will hit > the mirrors within tomorrow.
Hats off, Fabio! You have my deepest thanks for handling this
responsibility, and handling it well.
> So far Branden has already commited to trunk a fix for #242485 and it is
> perfectly fine with me.
Okay.
> >From the TODO list, I think we should proceed in the following order of
> priorities:
>
> - ---> subliminal message: fix whatever I broke with 4.3.0.dfsg.1-1 <---
There are some reports trickling in that the damn kernel 2.6 "This is a
bug in XFree86. This is a bug in XFree86. This is a bug in XFree86.
This is a bug in XFree86." problem isn't truly resolved.
We'll have to wait and see how that develops. Not your fault in any
case.
> * #240889: add AMD64 support
> patch seems ok.
Yeah, the Great Biarch Debate is no reason for us to delay AMD64 support
any further.
[snip items I agree with and which do not require comment]
> * Grab SiS driver from HEAD per Thomas Winischhofer.
As noted on this list, we'll pull from Thomas's website instead. I've
updated the TODO already.
> * steal {U,}XTerm* app-defaults updates from HEAD and resync patches
I think I will pull from Thomas (Dickey's) releases instead. With
XFree86 (implicitly) slapping their new license on all the Imakefiles, I
don't feel like messing with upstream CVS.
[snip items I agree with and which do not require comment]
> * 006_dont_ref_rman.man.diff: different fix exists upstream; steal it
> from HEAD
>
> * 013_xkb_symbols_euro_support.diff: different fix exists upstream;
> steal it from HEAD
We should grab fixes from XFree86 CVS only if:
1) They predate the relicensing on 2004-02-13; and
2) They predate the addition of X-Oz copyrighted code on affected files.
That means that for some files, the clock stops on 2003-10-07. Those
files are:
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/xf86AutoConfig.c
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/drivers/vesa/vesa.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
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
> * Fix upstream install rule that prevents Xcursor themes from being
> installed on s390. As I understand it, this is client-side stuff and
> there's not really any reason it shouldn't be made available on the s390
> architecture.
>
> * Fix other gratuitous differences between s390 debehlper files and the
> generic ones by fixing upstream Imakeage to not turn extra stuff off when
> the XFree86 X server is not being built (like xmodmap.std). It ships
> libXxf86vm.a but not the corresponding manpages.
Be warned; I know my way around Imake fairly well by now (though I'm hardly an
expert), but the above could be time consuming. I think we should be
prepared to defer these in favor either of other fixes or just getting
the release out the door.
> * more cosmetic/lintian cleanup if there will be time for it.
Yeah, I should add this to the "ongoing work" items in the TODO.
> For this release, other than the 4 bug fixes, we will work mainly on
> resync and cleanup. If -1 and -2 will not show big problems we might want
> to consider slightly bigger changes for -3, like the rewrite
> xserver-xfree86 debconfage. Time will tell.
Yeah, I'm not quite ready for a commit of the stuff I've got in my
working copy.
> Again as -1 this release will have only one major/risky change applying
> the via patch from Adam Conrad.
Right.
> Without repeating Branden and myself on each entry, be sure that licences
> are ok when pulling stuff from cvs HEAD.
See above. As I feared, David Dawes has not replied to my request for a
clarification on what the heck is going on with this "implicit relicense
even if neither the file nor the commit message say so" business, so I
think that everything failing the criteria I outlined above needs to be
regarded as poisonous.
If anyone feels differently -- about the license business or anything
else -- please speak up! This is the thread for deciding what -2 will
look like, so put your "-2" cents in. :)
--
G. Branden Robinson | I just wanted to see what it looked
Debian GNU/Linux | like in a spotlight.
[EMAIL PROTECTED] | -- Jim Morrison
http://people.debian.org/~branden/ |
signature.asc
Description: Digital signature
