Re: Start preparing xfree86 4.3.0.dfsg.1-2
On Thu, Apr 29, 2004 at 11:01:57AM +0200, Thomas Winischhofer wrote: > > Fabio Massimo Di Nitto wrote: > > * Grab SiS driver from HEAD per Thomas Winischhofer. > > Please don't grab it from the XFree86 CVS but my website instead. You mean this, right?: http://www.winischhofer.net/sis/sis_drv_src_040504-1.tar.gz > For various reasons I don't commit to the XFree86 CVS too often these > days, and the driver on my website is far more advanced than the one > in the XFree86 CVS as it - last but least - has been lab-tested by SiS > themselves for the new chipsets (661/741/760). Excellent! > The current driver also fixes Bugs #246087 and #245249. Wonderful! Thanks! -- G. Branden Robinson| There's nothing an agnostic can't Debian GNU/Linux | do if he doesn't know whether he [EMAIL PROTECTED] | believes in it or not. http://people.debian.org/~branden/ | -- Graham Chapman signature.asc Description: Digital signature
Re: Start preparing xfree86 4.3.0.dfsg.1-2
On Mon, 3 May 2004, Branden Robinson wrote: > Thanks; I have added this patch to the TODO; it's Fabio's call as to > whether it becomes a must-have fix for -2, but I suspect it should. > > To devolve into a parlance I've seen elsewhere (such as on Subversion's > development list) Fabio, please count me as voting +1 on adding this to > the TODO for -2. +1 ;) Fabio -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Re: Start preparing xfree86 4.3.0.dfsg.1-2
Hi Thomas, On Tue, 4 May 2004, Thomas Winischhofer wrote: > Fabio Massimo Di Nitto wrote: > > On Thu, 29 Apr 2004, Thomas Winischhofer wrote: > > > > > >>Fabio Massimo Di Nitto wrote: > >> > * Grab SiS driver from HEAD per Thomas Winischhofer. > >> > >>Please don't grab it from the XFree86 CVS but my website instead. For > >>various reasons I don't commit to the XFree86 CVS too often these days, > >>and the driver on my website is far more advanced than the one in the > >>XFree86 CVS as it - last but least - has been lab-tested by SiS > >>themselves for the new chipsets (661/741/760). > >> > >>The current driver also fixes Bugs #246087 and #245249. > > > > > > Thanks a lot for the information! > > > > Fabio > > > > Fabio, to save you some trouble: Do NOT use the Imakefile and Makefile > than come with my source archive. These are for 4.1 and 4.2 only (as I > added some files in the meantime a few years ago). The original > Imakefile from 4.3 does nicely, and the Makefile can be deleted (as it > will be created anyway). All other files (*.c, *.h, *.man) apply. > (Although I must confess that the .man has been missing until today) Once again i can only thank you for the information. I am CC'ing debian-x so the guy that will merge your code will know what to do. Thanks Fabio -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Re: Start preparing xfree86 4.3.0.dfsg.1-2
On Mon, 2004-05-03 at 19:50, Branden Robinson wrote: > On Fri, Apr 30, 2004 at 08:41:13PM +0200, Michel Dänzer wrote: > > > > http://penguinppc.org/~daenzer/DRI/applied/radeon-accelinit.diff is the > > radeon fix. [...] > Michel, this fixes the following, right? > > (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 > (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 > (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 > (EE) RADEON(0): GetBuffer timed out, resetting engine... Yes. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: Start preparing xfree86 4.3.0.dfsg.1-2
On Fri, Apr 30, 2004 at 08:41:13PM +0200, Michel Dänzer wrote: > On Fri, 2004-04-30 at 18:48, Fabio Massimo Di Nitto wrote: > > On Fri, 30 Apr 2004, Michel Dnzer wrote: > > > Let me point out again that there is actually a bug in the > > > xserver-xfree86 r128 and radeon drivers: they don't deal gracefully with > > > the DRI initialisation failing late in the game. However, IMHO it's the > > > responsibility of the people who want to remove the firmware from the > > > kernel packages to fix this, as this bug is very unlikely to trigger > > > otherwise (basically takes a buggy DRM). > > > > Yes I understand that. Would that bug shows up again in other situations > > other than this one? I read in another message that you can dig out a > > patch for this problem. Would you mind to post it here? > > http://penguinppc.org/~daenzer/DRI/applied/radeon-accelinit.diff is the > radeon fix. Thanks; I have added this patch to the TODO; it's Fabio's call as to whether it becomes a must-have fix for -2, but I suspect it should. To devolve into a parlance I've seen elsewhere (such as on Subversion's development list) Fabio, please count me as voting +1 on adding this to the TODO for -2. Michel, this fixes the following, right? (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... [repeat until /var fills up] Just making sure I understand the problem, symptoms, and solution correctly. -- G. Branden Robinson|If you wish to strive for peace of Debian GNU/Linux |soul, then believe; if you wish to [EMAIL PROTECTED] |be a devotee of truth, then http://people.debian.org/~branden/ |inquire. -- Friedrich Nietzsche signature.asc Description: Digital signature
Re: Start preparing xfree86 4.3.0.dfsg.1-2
On Fri, 2004-04-30 at 18:48, Fabio Massimo Di Nitto wrote: > On Fri, 30 Apr 2004, Michel Dnzer wrote: > > > On Fri, 2004-04-30 at 17:16, Fabio Massimo Di Nitto wrote: > > > > > > The ATI/radeon problem has been fixed by Herbert already in the new kernel > > > upload -4. > > > > Let me point out again that there is actually a bug in the > > xserver-xfree86 r128 and radeon drivers: they don't deal gracefully with > > the DRI initialisation failing late in the game. However, IMHO it's the > > responsibility of the people who want to remove the firmware from the > > kernel packages to fix this, as this bug is very unlikely to trigger > > otherwise (basically takes a buggy DRM). > > Yes I understand that. Would that bug shows up again in other situations > other than this one? I read in another message that you can dig out a > patch for this problem. Would you mind to post it here? http://penguinppc.org/~daenzer/DRI/applied/radeon-accelinit.diff is the radeon fix. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: Start preparing xfree86 4.3.0.dfsg.1-2
On Fri, 30 Apr 2004, Michel D�nzer wrote: > On Fri, 2004-04-30 at 17:16, Fabio Massimo Di Nitto wrote: > > > > The ATI/radeon problem has been fixed by Herbert already in the new kernel > > upload -4. > > Let me point out again that there is actually a bug in the > xserver-xfree86 r128 and radeon drivers: they don't deal gracefully with > the DRI initialisation failing late in the game. However, IMHO it's the > responsibility of the people who want to remove the firmware from the > kernel packages to fix this, as this bug is very unlikely to trigger > otherwise (basically takes a buggy DRM). Yes I understand that. Would that bug shows up again in other situations other than this one? I read in another message that you can dig out a patch for this problem. Would you mind to post it here? Thanks Fabio -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Re: Start preparing xfree86 4.3.0.dfsg.1-2
On Fri, 2004-04-30 at 17:16, Fabio Massimo Di Nitto wrote: > > The ATI/radeon problem has been fixed by Herbert already in the new kernel > upload -4. Let me point out again that there is actually a bug in the xserver-xfree86 r128 and radeon drivers: they don't deal gracefully with the DRI initialisation failing late in the game. However, IMHO it's the responsibility of the people who want to remove the firmware from the kernel packages to fix this, as this bug is very unlikely to trigger otherwise (basically takes a buggy DRM). -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: Start preparing xfree86 4.3.0.dfsg.1-2
On Fri, 30 Apr 2004, Branden Robinson wrote:
> 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.
Well thanks also to all your work in cleaning up my logs and errors here
and there ;)
> > >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 <---
The ATI/radeon problem has been fixed by Herbert already in the new kernel
upload -4. We need to investigate the mga driver to verify who needs to
work on it.
> 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.
The one i saw was still to 4.3.0-7, but i went trough it very very fast.
> > * 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]
agreed. more we stay away from the licence mess better is.
> > * 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.
Sure. Mine is just a list. We will do as much as we can. Also removing or
postponing items if required.
More generally, I would like that people read my messages as a direction
to go, but not a strict rule to follow.
> > 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.
Do you have a branch for it? or only a local copy?
> 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.
agreed.. as above ;)
Thanks
Fabio
--
fajita: step one
Whatever the problem, step one is always to look in the error log.
fajita: step two
When in danger or in doubt, step two is to scream and shout.
Re: Start preparing xfree86 4.3.0.dfsg.1-2
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 spea
Re: Start preparing xfree86 4.3.0.dfsg.1-2
Around 11 o'clock on Apr 29, Thomas Winischhofer wrote: > Please don't grab it from the XFree86 CVS but my website instead. For > various reasons I don't commit to the XFree86 CVS too often these days, > and the driver on my website is far more advanced than the one in the > XFree86 CVS as it - last but least - has been lab-tested by SiS > themselves for the new chipsets (661/741/760). Please let me know if you'd like to use freedesktop.org in any way to help with this project. -keith pgpOVj3z8utrC.pgp Description: PGP signature
Re: Start preparing xfree86 4.3.0.dfsg.1-2
On Thu, 29 Apr 2004, Thomas Winischhofer wrote: > > Fabio Massimo Di Nitto wrote: > > * Grab SiS driver from HEAD per Thomas Winischhofer. > > Please don't grab it from the XFree86 CVS but my website instead. For > various reasons I don't commit to the XFree86 CVS too often these days, > and the driver on my website is far more advanced than the one in the > XFree86 CVS as it - last but least - has been lab-tested by SiS > themselves for the new chipsets (661/741/760). > > The current driver also fixes Bugs #246087 and #245249. Thanks a lot for the information! Fabio -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Re: Start preparing xfree86 4.3.0.dfsg.1-2
Fabio Massimo Di Nitto wrote: > * Grab SiS driver from HEAD per Thomas Winischhofer. Please don't grab it from the XFree86 CVS but my website instead. For various reasons I don't commit to the XFree86 CVS too often these days, and the driver on my website is far more advanced than the one in the XFree86 CVS as it - last but least - has been lab-tested by SiS themselves for the new chipsets (661/741/760). The current driver also fixes Bugs #246087 and #245249. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org
