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
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 -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita 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, 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 -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita 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, 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 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, 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
--
user fajita: step one
fajita Whatever the problem, step one is always to look in the error log.
user fajita: step two
fajita 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, 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 -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita 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 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
Start preparing xfree86 4.3.0.dfsg.1-2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
a few hours ago 4.3.0.dfsg.1-1 has been uploaded and it will hit
the mirrors within tomorrow.
It is already time to start working on the next release.
So far Branden has already commited to trunk a fix for #242485 and it is
perfectly fine with me.
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 ---
* #240889: add AMD64 support
patch seems ok.
* #240581: xserver-xfree86: [ati/radeon] support ForceMinDotClock option
patch is already upstream.
* #245044: xdm: cannot resolve hostnames from Xaccess Indirect lines.
url to the fix is in the BTS.
* Apply Adam Conrad's VIA driver patch (on debian-x).
patch doesn't look extremely intrusive (since it stores almost everything
in via/).
* Grab SiS driver from HEAD per Thomas Winischhofer.
* steal {U,}XTerm* app-defaults updates from HEAD and resync patches
* move patch in 009_use_xf86config-4_in_xf86config.diff to
911_debian_XF86Config_to_XF86Config-4.diff
* 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
* 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.
* more cosmetic/lintian cleanup if there will be time for it.
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.
Again as -1 this release will have only one major/risky change applying
the via patch from Adam Conrad.
Without repeating Branden and myself on each entry, be sure that licences
are ok when pulling stuff from cvs HEAD.
Thanks
Fabio
- --
user fajita: step one
fajita Whatever the problem, step one is always to look in the error log.
user fajita: step two
fajita When in danger or in doubt, step two is to scream and shout.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAkJj6hCzbekR3nhgRApFmAKCZYDNmlKCVSmCKWLIlH8Do4K3CKwCbBp9h
V8rfRl5haf8WPByeAH1AYvg=
=YggD
-END PGP SIGNATURE-
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
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 -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
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
