Re: X 4.0.1 package requests.
Hope you don't mind if I CC my reply to the Debian X mailing list. On Thu, Sep 21, 2000 at 12:28:54AM -0700, Terence Ripperda wrote: I'm from NVIDIA, working on our 2d/3d drivers. Now that there are XFree86 4.0.1 packages in development, I'm looking at getting some .deb packages together for our drivers. I was looking at what you had so far for xfree86 and mesa/glx. I had a couple of requests: libGLU - will you be providing the libGLU library as part of the xlibmesa package, or seperately. It seems like it would be better for libGLU to be seperate from libGL, sort of like libglut is, since it's not really dependent on a specific version of libGL (or it shouldn't be). It is my intention to defer to the SGI OpenGL Linux ABI standard. That says that two shared libraries should be provided: libGL.so.1 and libGLU.so.1; that XFree86 currently builds the former but not the latter is an issue that they are working to rectify. Once they have done so, I will be shipping libGLU in the "xlibmesa3" library (and its headers and static vesion in "xlibmesa3-dev"). There is not yet official Debian policy on this matter, but I'm starting to realize we need one. I think Debian should follow the existing standard as drafted by SGI; any additional shared libraries not covered by that ABI should be shipped in separate Debian packages, so that all ABI-compliant implementations can Provide: the virtual package "libgl1". Brian Paul advised me to ship libOSMesa with xlibmesa, but in light of the fact that some GL implementations might not have that, I'm going to deviate just a little bit from his advice. I will be moving this library back out into an "xlibosmesa" package. libglx.a libGLcore.a - these files are in fact specific to the version of libGL used, but so far every package has them included with the base X modules. This is probably due to the modules being X modules and distributed with X, but functionally they are part of xlibmesa providing opengl functionality, and aren't very useful seperately. It would be a beautiful thing if you could move them into the xlibmesa package. I'll have to check with what the ABI says, but Debian Policy says that static libraries are shipped in "development" (i.e., "libfoo-dev") packages. Our driver will install libglx.so and libGLcore.so, which don't conflict with the libglx.a and libGLcore.a files in the filesystem namespace, but do conflict in the X module namespace. When loading a "glx" module, X will pick up libglx.a before libglx.so. So far, with RPM binaries, we're forced to rename those libraries from another package. It would be much easier on everyone involved if we could just conflict/replace all other libgl1 providers, and not have to worry beyond about conflicts beyond that. You can provide an absolute path to a module name as an argument to the Load command in the Modules section of the XF86Config file. I think this is preferable. There are underhanded things that your package could do to get the XFree86 modules out of the way, but let's see if we can negotiate something more friendly, first. :) The second thing (libglx.a/libGLcore.a) is infinitely more important than the first (libGLU), and it would be wonderful if we can work this out. I think we can. Do you like the absolute path idea? E.g.: Section "Module" Load"/usr/X11R6/lib/modules/libglx.so" EndSection Heck, it might be an even better idea to put the module in a place specific to the package, for instance: Section "Module" Load"/usr/lib/nvidia-driver/libglx.so" EndSection In fact, first analysis leads me to believe that reserving the XFree86 modules directory for modules shipped by XFree86 might be a good idea. Completely eliminates the possibility of namespace collision in the filesystem. Let me know what you think (that goes for the folks on debian-x as well). -- G. Branden Robinson| Never underestimate the power of human Debian GNU/Linux | stupidity. [EMAIL PROTECTED] | -- Robert Heinlein http://deadbeast.net/~branden/ | PGP signature
Re: sessreg in /etc/X11/xdm/Xstartup
On Thu, Sep 21, 2000 at 05:23:19PM +0200, Hervé Eychenne wrote: I'm in touch with Guillaume Morin [EMAIL PROTECTED] in order to package one of my application for Debian, called ulog. FYI, it intends to be the distributed equivalent of utmp/wtmp for X-window. Just FYI, the proper name is the "X Window System". Simply "X" can be used for short. So I'll have to add an entry to /etc/X11/xdm/xdm.options, called "use-ulog". As the xdm package maintainer, I suppose I have to ask you if you would mind adding this entry in you package and what is the exact procedure. I'm not sure it is necessary to add options to xdm.options to accomplish what you have in mind. I need to know nore about ulog first. Please consider describing it to the debian-devel mailing list. To the clean way to do things is to add an entry similar to the one in /etc/X11/xdm/Xstartup: # insert a utmp entry for the session if grep -qs ^use-sessreg /etc/X11/xdm/xdm.options; then exec sessreg -a -l $DISPLAY -u /var/run/utmp -x /etc/X11/xdm/Xservers $USER # NOTREACHED fi But why did you put an exec ? It prevents from simply adding my stuff before the "exit 0"... Does sessreg _have_ to be the last action done by this file, or is it just an optimisation ? I added the exec in response to an old, old bug report (#20941) which has now expired from the bug database. Sorry, I don't remember the rationale. I seem to remember it had something to with process ID's, but I'm pretty foggy after all this time; I made this change about 2.5 years ago. -- G. Branden Robinson|Reality is what refuses to go away when Debian GNU/Linux |I stop believing in it. [EMAIL PROTECTED] |-- Philip K. Dick http://deadbeast.net/~branden/ | PGP signature
Re: X 4.0.1 package requests.
* Branden Robinson [EMAIL PROTECTED] [000922 00:00]: In fact, first analysis leads me to believe that reserving the XFree86 modules directory for modules shipped by XFree86 might be a good idea. Completely eliminates the possibility of namespace collision in the filesystem. Branden, I think I agree with reserving the XFree86 lib/modules directory for official xf86 modules. I currently use the matrox provided mga_drv.o, and until a nice debian-x reader suggested dpkg-divert, I had been recopying the matrox driver over the xf86 driver. It worked, but was not optimal. Now that I know I can give XF86Config absolute pathnames, I think I will undo the diversion and use absolute paths; it seems much easier. :) Although, one thing to consider: would the alternatives system better solve the problem? (Keeping in mind that I know practically nothing of how alternatives works, only that it exists. :) Either way, replacing the /usr/X11R6/lib/modules/drivers/mga_drv.o file each time I upgrade something or other is getting old; a standard way of dealing with this would be nice, especially since those that don't know about the absolute paths (such as myself until tonight :) would get a big hint about it just by reading their XF86Config file. :) Thanks Branden; I am much enjoying my Xf86 4.0. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
X suddenly exits. Segv???
Package: xserver-xfree86 Version: 4.0.1-0phase2v7 Twice I've had X suddenly exit on me. Both times, iirc, it was when I pushed the "X" button to close a Mozilla frame via the WM. I don't know if it's a segv or what; it just suddenly snicks out, then `gdm' restarts. Once it was this version, another time before it was the previous (?) phase 2 binary. Has this happened to anyone else? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X suddenly exits. Segv???
On 22 Sep 2000, Karl M. Hegbloom wrote: Package: xserver-xfree86 Version: 4.0.1-0phase2v7 Twice I've had X suddenly exit on me. Both times, iirc, it was when I pushed the "X" button to close a Mozilla frame via the WM. I don't know if it's a segv or what; it just suddenly snicks out, then `gdm' restarts. Once it was this version, another time before it was the previous (?) phase 2 binary. Has this happened to anyone else? As I have stated earlier here, something similar has happened to me. However, I traced the problem back to an error in the gnome-name-server that exited with an error and then crashed X. Check your logs if this isn't the case for you too. //Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X totally freezes
On Fri, Sep 22, 2000 at 11:53:45AM +0100, Dave wrote: I've put the version 7 betas onto my woody box (Cyrix 166+, 96Mb RAM and a Mystique 2Mb card) and since then X crashes at reasonably unexpected times, freezing the whole machine so that even Alt-SysRq can't sync the disks or reboot - although a SAK does something before total destrucion sets in (not recoverable though). Needless to say, XFree 3.3 didn't do anything like that. There don't appear to be any logs of what happened, but this may be because the disks don't sync before I have to manually hard boot the system. I suspect this is an X problem rather than a Debian X one, but thought I'd write to the list just in case someone has any idea what's up. Hm... happened to me a couple of times too. My screen becomes black, with just a little of some screen garbage in the lower right corner. I originally blamed 2.4.0.9.4 kernel, and if not that, then NVIDIA non-free drivers maybe conflicting with latest X cvs changes, but since you've reported it, I started to doubt in X itself. I'm using phase2v5 by the way. Vedran Rodic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X totally freezes
On Fri, Sep 22, 2000 at 11:53:45AM +0100, Dave wrote: I've put the version 7 betas onto my woody box (Cyrix 166+, 96Mb RAM and a Mystique 2Mb card) and since then X crashes at reasonably unexpected times, freezing the whole machine so that even Alt-SysRq can't sync the disks or reboot - although a SAK does something before total destrucion sets in (not recoverable though). Needless to say, XFree 3.3 didn't do anything like that. There don't appear to be any logs of what happened, but this may be because the disks don't sync before I have to manually hard boot the system. I suspect this is an X problem rather than a Debian X one, but thought I'd write to the list just in case someone has any idea what's up. Hm... happened to me a couple of times too. My screen becomes black, with just a little of some screen garbage in the lower right corner. I originally blamed 2.4.0.9.4 kernel, and if not that, then NVIDIA non-free drivers maybe conflicting with latest X cvs changes, but since you've reported it, I started to doubt in X itself. I'm using phase2v5 by the way. Vedran Rodic Hi, im experiancing similar problems, my machine is a 2x500 celeron 192Mb ram and a dimod viper 770 ultra (TNT2 Ultra). I had no problems with the Xfree drivers, the nvidia driver however hangs my machine pretty bad, the screen stop getting signal and the box stop sespond to ping. I had the exacly same problem erlier when i compiled "Video mode selection support" in my kernel. 2.2.16 i think that was. I havent compiled in APM since its at SMP system and i disabled all power manegment in my bios (its a Abit bp6 mobo). Anyone have a theory on this. could it have something to do whith agp drivers or something? I havent done any agp configuring in the kernel. /Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Niggly little bug
I'm not sure whether it's worth mentioning but I found a *small* bug in building the packages. I'm not sure whether something should be done in the Makefile or if it's common practice that I wasn't aware of. Regardless, this is the situation: Some languages have different sort orderings. If the package is being built outside of LANG=C and the sort ordering is different (say, capitals don't come first) then the test of comparing MANIFEST lists fails. Now, whether LANG=C should be set in the Makefile or if building a package when LANG!=C is incredibly stupid, I don't know. I just thought it should be mentioned. -- shaky caller PGP signature
Re: X suddenly exits. Segv???
At 03:14 AM 9/22/00 -0700, Karl M. Hegbloom wrote: Package: xserver-xfree86 Version: 4.0.1-0phase2v7 Twice I've had X suddenly exit on me. Both times, iirc, it was when I pushed the "X" button to close a Mozilla frame via the WM. I don't know if it's a segv or what; it just suddenly snicks out, then `gdm' restarts. Once it was this version, another time before it was the previous (?) phase 2 binary. Has this happened to anyone else? I think that has happened to me once, but three or four times I have waken up to find that my X session has reset in the middle of the night (I tend to stay logged in for days/weeks at a time). The last two times that has happened coincided with network outages (cable modem reset the first time, router[1] turned off and disassembled last night) This morning, I woke up to find that Enlightenment now believes that my X server no longer has XSHM support. I don't know which version of the X packages I'm running, I upgraded last night. Also, it seems like DPMS works with xdm, but not with Enlightenment. I'm using the stock Matrox G400 driver. Any ideas with these issues? [1] our router is an old PowerMac, used because it was the spare computer in the house -- and therefore less expensive than building a dedicated Debian box. As it is, for 5 machines, we have 4 networks, 4+ operating systems, 4 dedicated hubs/bridges/translators, etc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Niggly little bug
[Followups set to -devel, please respect] Ashley brought this up on debian-x: On Fri, Sep 22, 2000 at 07:58:11AM -0500, Ashley Clark wrote: I'm not sure whether it's worth mentioning but I found a *small* bug in building the packages. I'm not sure whether something should be done in the Makefile or if it's common practice that I wasn't aware of. Regardless, this is the situation: Some languages have different sort orderings. If the package is being built outside of LANG=C and the sort ordering is different (say, capitals don't come first) then the test of comparing MANIFEST lists fails. Now, whether LANG=C should be set in the Makefile or if building a package when LANG!=C is incredibly stupid, I don't know. I just thought it should be mentioned. Do we have a policy on this? I've had a quick scan through the packaging manual, and I can't see it. My gut feeling is that maybe package builds should be run with LANG=C, since to try to get them running in any locale requires some quite complex testing from the maintainer (e.g. the issue above would have been hard to spot). Jules -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Any ETA to 4.0.2?
Anyone know what is happening with 4.0.2, which I think I saw on the xfree86 site as coming out in Sept or Oct. If this comes out, what are the plans with respect to these debs, Branden? Stay with 4.0.1c, or jump straight to 4.0.2? -- James Bromberger james_AT_bromberger.com www.rcpt.to/~james IT, Pelican Manufacturing - www.pelicanmanufacturing.com.au Snr Web Systems Admin, JDV - www.jdv.com * www.hartleypoynton.com.au Remainder moved to http://www.rcpt.to/~james/james/sig.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
XtVaGetValues weirdness
This isn't an XF4 specific problem, but I noticed it after upgrading and getting rid of Xaw3d. I have some Xt code which sets a value like this: XtVaSetValues(button, userData, w, NULL); and pulls it out later with XtVaGetValues(kids[i], userData, foo, NULL); Using xaw3d this worked fine, but with regular Xaw (from either 3.3.6 or 4.01) it fails, putting 0 in foo. Am I doing something wrong here that Xaw3d didn't check for? -- There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)
Re: libGLcore.a, libglx.a conflict with nvidia non-free drivers
Vedran Rodic [EMAIL PROTECTED] writes: I think that files in subject (located in /usr/X11R6/lib/modules/extensions) should be a part of xlibmesa3 package, since libGLcore.a is clearly mesa specific, I'm not sure about libglx.a. libGLcore.a provides hooks for the X server, that is, it is part of the xserver package (at any rate, it could be a xserver-glx-ext, but not part of xlibwhatever provides gl now). NVIDIA has its own GLX extension, but you can rename the file (say, libglx-nv.a) and change the appropriate line in your XF86Config-4 file. Marcelo
[seth@eazel.com: GLU vs accelerated GL conflicts (XF4.0.1 package problem)]
I feel like Bill Murray in _Ground Hog Day_, forced to live the same day over and over again... - Forwarded message from Seth Nickell [EMAIL PROTECTED] - From: Seth Nickell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: GLU vs accelerated GL conflicts (XF4.0.1 package problem) Date: Wed, 20 Sep 2000 22:24:38 -0700 Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-test8 i686) X-Accept-Language: en There currently exists a functional conflict between libmesag3 (the standard Mesa distribution for debian) and xlibmesa3 (as included with your XF4 packages). While xlibmesa3 is necessary to use accelerated rendering, the majority of OpenGL applications require the prescence of libGLU. Unfortunately since libmesag3 and xlibmesa3 are marked as conflicting, I must hand patch every time I do an apt-get (which isn't bad, but not quite preferable). One solution would be to provide a seperate xlibglu package, or something of that nature for people who wish to have them seperate in order to have both. -Seth - End forwarded message - -- G. Branden Robinson| Debian GNU/Linux |If encryption is outlawed, only outlaws [EMAIL PROTECTED] |will @goH7OjBd7*dnfk=q4fDj]Kz?. http://deadbeast.net/~branden/ | pgpFTQIPWd49m.pgp Description: PGP signature
Re: X 4.0.1 package requests.
Hope you don't mind if I CC my reply to the Debian X mailing list. On Thu, Sep 21, 2000 at 12:28:54AM -0700, Terence Ripperda wrote: I'm from NVIDIA, working on our 2d/3d drivers. Now that there are XFree86 4.0.1 packages in development, I'm looking at getting some .deb packages together for our drivers. I was looking at what you had so far for xfree86 and mesa/glx. I had a couple of requests: libGLU - will you be providing the libGLU library as part of the xlibmesa package, or seperately. It seems like it would be better for libGLU to be seperate from libGL, sort of like libglut is, since it's not really dependent on a specific version of libGL (or it shouldn't be). It is my intention to defer to the SGI OpenGL Linux ABI standard. That says that two shared libraries should be provided: libGL.so.1 and libGLU.so.1; that XFree86 currently builds the former but not the latter is an issue that they are working to rectify. Once they have done so, I will be shipping libGLU in the xlibmesa3 library (and its headers and static vesion in xlibmesa3-dev). There is not yet official Debian policy on this matter, but I'm starting to realize we need one. I think Debian should follow the existing standard as drafted by SGI; any additional shared libraries not covered by that ABI should be shipped in separate Debian packages, so that all ABI-compliant implementations can Provide: the virtual package libgl1. Brian Paul advised me to ship libOSMesa with xlibmesa, but in light of the fact that some GL implementations might not have that, I'm going to deviate just a little bit from his advice. I will be moving this library back out into an xlibosmesa package. libglx.a libGLcore.a - these files are in fact specific to the version of libGL used, but so far every package has them included with the base X modules. This is probably due to the modules being X modules and distributed with X, but functionally they are part of xlibmesa providing opengl functionality, and aren't very useful seperately. It would be a beautiful thing if you could move them into the xlibmesa package. I'll have to check with what the ABI says, but Debian Policy says that static libraries are shipped in development (i.e., libfoo-dev) packages. Our driver will install libglx.so and libGLcore.so, which don't conflict with the libglx.a and libGLcore.a files in the filesystem namespace, but do conflict in the X module namespace. When loading a glx module, X will pick up libglx.a before libglx.so. So far, with RPM binaries, we're forced to rename those libraries from another package. It would be much easier on everyone involved if we could just conflict/replace all other libgl1 providers, and not have to worry beyond about conflicts beyond that. You can provide an absolute path to a module name as an argument to the Load command in the Modules section of the XF86Config file. I think this is preferable. There are underhanded things that your package could do to get the XFree86 modules out of the way, but let's see if we can negotiate something more friendly, first. :) The second thing (libglx.a/libGLcore.a) is infinitely more important than the first (libGLU), and it would be wonderful if we can work this out. I think we can. Do you like the absolute path idea? E.g.: Section Module Load/usr/X11R6/lib/modules/libglx.so EndSection Heck, it might be an even better idea to put the module in a place specific to the package, for instance: Section Module Load/usr/lib/nvidia-driver/libglx.so EndSection In fact, first analysis leads me to believe that reserving the XFree86 modules directory for modules shipped by XFree86 might be a good idea. Completely eliminates the possibility of namespace collision in the filesystem. Let me know what you think (that goes for the folks on debian-x as well). -- G. Branden Robinson| Never underestimate the power of human Debian GNU/Linux | stupidity. [EMAIL PROTECTED] | -- Robert Heinlein http://deadbeast.net/~branden/ | pgpwxgjgEoIci.pgp Description: PGP signature
Re: sessreg in /etc/X11/xdm/Xstartup
On Thu, Sep 21, 2000 at 05:23:19PM +0200, Hervé Eychenne wrote: I'm in touch with Guillaume Morin [EMAIL PROTECTED] in order to package one of my application for Debian, called ulog. FYI, it intends to be the distributed equivalent of utmp/wtmp for X-window. Just FYI, the proper name is the X Window System. Simply X can be used for short. So I'll have to add an entry to /etc/X11/xdm/xdm.options, called use-ulog. As the xdm package maintainer, I suppose I have to ask you if you would mind adding this entry in you package and what is the exact procedure. I'm not sure it is necessary to add options to xdm.options to accomplish what you have in mind. I need to know nore about ulog first. Please consider describing it to the debian-devel mailing list. To the clean way to do things is to add an entry similar to the one in /etc/X11/xdm/Xstartup: # insert a utmp entry for the session if grep -qs ^use-sessreg /etc/X11/xdm/xdm.options; then exec sessreg -a -l $DISPLAY -u /var/run/utmp -x /etc/X11/xdm/Xservers $USER # NOTREACHED fi But why did you put an exec ? It prevents from simply adding my stuff before the exit 0... Does sessreg _have_ to be the last action done by this file, or is it just an optimisation ? I added the exec in response to an old, old bug report (#20941) which has now expired from the bug database. Sorry, I don't remember the rationale. I seem to remember it had something to with process ID's, but I'm pretty foggy after all this time; I made this change about 2.5 years ago. -- G. Branden Robinson|Reality is what refuses to go away when Debian GNU/Linux |I stop believing in it. [EMAIL PROTECTED] |-- Philip K. Dick http://deadbeast.net/~branden/ | pgpILFZGGbmG4.pgp Description: PGP signature
Re: X 4.0.1 package requests.
* Branden Robinson [EMAIL PROTECTED] [000922 00:00]: In fact, first analysis leads me to believe that reserving the XFree86 modules directory for modules shipped by XFree86 might be a good idea. Completely eliminates the possibility of namespace collision in the filesystem. Branden, I think I agree with reserving the XFree86 lib/modules directory for official xf86 modules. I currently use the matrox provided mga_drv.o, and until a nice debian-x reader suggested dpkg-divert, I had been recopying the matrox driver over the xf86 driver. It worked, but was not optimal. Now that I know I can give XF86Config absolute pathnames, I think I will undo the diversion and use absolute paths; it seems much easier. :) Although, one thing to consider: would the alternatives system better solve the problem? (Keeping in mind that I know practically nothing of how alternatives works, only that it exists. :) Either way, replacing the /usr/X11R6/lib/modules/drivers/mga_drv.o file each time I upgrade something or other is getting old; a standard way of dealing with this would be nice, especially since those that don't know about the absolute paths (such as myself until tonight :) would get a big hint about it just by reading their XF86Config file. :) Thanks Branden; I am much enjoying my Xf86 4.0. :)
Re: X 4.0.1 package requests.
On Fri, Sep 22, 2000 at 01:52:12AM -0500, Branden Robinson wrote: Hope you don't mind if I CC my reply to the Debian X mailing list. On Thu, Sep 21, 2000 at 12:28:54AM -0700, Terence Ripperda wrote: I'm from NVIDIA, working on our 2d/3d drivers. Now that there are XFree86 4.0.1 packages in development, I'm looking at getting some .deb packages together for our drivers. I was looking at what you had so far for xfree86 and mesa/glx. I had a couple of requests: libGLU - will you be providing the libGLU library as part of the xlibmesa package, or seperately. It seems like it would be better for libGLU to be seperate from libGL, sort of like libglut is, since it's not really dependent on a specific version of libGL (or it shouldn't be). It is my intention to defer to the SGI OpenGL Linux ABI standard. That says that two shared libraries should be provided: libGL.so.1 and libGLU.so.1; that XFree86 currently builds the former but not the latter is an issue that they are working to rectify. Once they have done so, I will be shipping libGLU in the xlibmesa3 library (and its headers and static vesion in xlibmesa3-dev). There is not yet official Debian policy on this matter, but I'm starting to realize we need one. I think Debian should follow the existing standard as drafted by SGI; any additional shared libraries not covered by that ABI should be shipped in separate Debian packages, so that all ABI-compliant implementations can Provide: the virtual package libgl1. Brian Paul advised me to ship libOSMesa with xlibmesa, but in light of the fact that some GL implementations might not have that, I'm going to deviate just a little bit from his advice. I will be moving this library back out into an xlibosmesa package. what about the libGLw libraries, i take it Brian Paul also wants them to be included in the Xfree gl libs. About non-free driver implementation, i guess a divert or something such would be nicest, isn't it. it would depend on the appropriate xfree packages (xlibmesa for the GL files, xserver-xfree86 for the driver) and divert the xfree provided GL libraries and driver, and also the kernel module, if there is one. How many non-free drivers packages are there, and who is willing to package them ? I know of drivers from NVIDIA, as well as matrox, but the later are being folded back into Xfree. There is ATI also, i guess. Friendly, Sven LUTHER
Any ETA to 4.0.2?
Anyone know what is happening with 4.0.2, which I think I saw on the xfree86 site as coming out in Sept or Oct. If this comes out, what are the plans with respect to these debs, Branden? Stay with 4.0.1c, or jump straight to 4.0.2? -- James Bromberger james_AT_bromberger.com www.rcpt.to/~james IT, Pelican Manufacturing - www.pelicanmanufacturing.com.au Snr Web Systems Admin, JDV - www.jdv.com * www.hartleypoynton.com.au Remainder moved to http://www.rcpt.to/~james/james/sig.html
DPMS in r128?
DPMS used to not work in `xserver-rage128', and at first not in `xserver-svga' either. At some point, a patch was applied to `xserver-svga' that caused DPMS to begin working. With `xserver-xfree86' and the `r128' driver, I again have no DPMS. I'd sure like the montitor to shut off when I'm not using it. Is there a discrete patch already created that can fix this? If not, how difficult do you think it will be for me to try and create a patch for you? Is it as simple as pasting a function from one file to another, or will it require more intimate knowledge of the internals? Without having ever looked at the X sources, can it be done in an afternoon, or should I just wait for yous to get to it? Branden, I'm aware that you are hard at work each day patching up XFree86-4.0.1 for us. Take your time and do it right; this note is just a ToDo item, not a screaming demand for service. -- Karl M. Hegbloom [EMAIL PROTECTED]
X suddenly exits. Segv???
Package: xserver-xfree86 Version: 4.0.1-0phase2v7 Twice I've had X suddenly exit on me. Both times, iirc, it was when I pushed the X button to close a Mozilla frame via the WM. I don't know if it's a segv or what; it just suddenly snicks out, then `gdm' restarts. Once it was this version, another time before it was the previous (?) phase 2 binary. Has this happened to anyone else?
Re: X suddenly exits. Segv???
On 22 Sep 2000, Karl M. Hegbloom wrote: Package: xserver-xfree86 Version: 4.0.1-0phase2v7 Twice I've had X suddenly exit on me. Both times, iirc, it was when I pushed the X button to close a Mozilla frame via the WM. I don't know if it's a segv or what; it just suddenly snicks out, then `gdm' restarts. Once it was this version, another time before it was the previous (?) phase 2 binary. Has this happened to anyone else? As I have stated earlier here, something similar has happened to me. However, I traced the problem back to an error in the gnome-name-server that exited with an error and then crashed X. Check your logs if this isn't the case for you too. //Anders
X totally freezes
I've put the version 7 betas onto my woody box (Cyrix 166+, 96Mb RAM and a Mystique 2Mb card) and since then X crashes at reasonably unexpected times, freezing the whole machine so that even Alt-SysRq can't sync the disks or reboot - although a SAK does something before total destrucion sets in (not recoverable though). Needless to say, XFree 3.3 didn't do anything like that. There don't appear to be any logs of what happened, but this may be because the disks don't sync before I have to manually hard boot the system. I suspect this is an X problem rather than a Debian X one, but thought I'd write to the list just in case someone has any idea what's up. Thanks for any responses, -Dave
Re: X totally freezes
On Fri, Sep 22, 2000 at 11:53:45AM +0100, Dave wrote: I've put the version 7 betas onto my woody box (Cyrix 166+, 96Mb RAM and a Mystique 2Mb card) and since then X crashes at reasonably unexpected times, freezing the whole machine so that even Alt-SysRq can't sync the disks or reboot - although a SAK does something before total destrucion sets in (not recoverable though). Needless to say, XFree 3.3 didn't do anything like that. There don't appear to be any logs of what happened, but this may be because the disks don't sync before I have to manually hard boot the system. I suspect this is an X problem rather than a Debian X one, but thought I'd write to the list just in case someone has any idea what's up. Hm... happened to me a couple of times too. My screen becomes black, with just a little of some screen garbage in the lower right corner. I originally blamed 2.4.0.9.4 kernel, and if not that, then NVIDIA non-free drivers maybe conflicting with latest X cvs changes, but since you've reported it, I started to doubt in X itself. I'm using phase2v5 by the way. Vedran Rodic
Re: X totally freezes
On Fri, Sep 22, 2000 at 11:53:45AM +0100, Dave wrote: I've put the version 7 betas onto my woody box (Cyrix 166+, 96Mb RAM and a Mystique 2Mb card) and since then X crashes at reasonably unexpected times, freezing the whole machine so that even Alt-SysRq can't sync the disks or reboot - although a SAK does something before total destrucion sets in (not recoverable though). Needless to say, XFree 3.3 didn't do anything like that. There don't appear to be any logs of what happened, but this may be because the disks don't sync before I have to manually hard boot the system. I suspect this is an X problem rather than a Debian X one, but thought I'd write to the list just in case someone has any idea what's up. Hm... happened to me a couple of times too. My screen becomes black, with just a little of some screen garbage in the lower right corner. I originally blamed 2.4.0.9.4 kernel, and if not that, then NVIDIA non-free drivers maybe conflicting with latest X cvs changes, but since you've reported it, I started to doubt in X itself. I'm using phase2v5 by the way. Vedran Rodic Hi, im experiancing similar problems, my machine is a 2x500 celeron 192Mb ram and a dimod viper 770 ultra (TNT2 Ultra). I had no problems with the Xfree drivers, the nvidia driver however hangs my machine pretty bad, the screen stop getting signal and the box stop sespond to ping. I had the exacly same problem erlier when i compiled Video mode selection support in my kernel. 2.2.16 i think that was. I havent compiled in APM since its at SMP system and i disabled all power manegment in my bios (its a Abit bp6 mobo). Anyone have a theory on this. could it have something to do whith agp drivers or something? I havent done any agp configuring in the kernel. /Andreas
Niggly little bug
I'm not sure whether it's worth mentioning but I found a *small* bug in building the packages. I'm not sure whether something should be done in the Makefile or if it's common practice that I wasn't aware of. Regardless, this is the situation: Some languages have different sort orderings. If the package is being built outside of LANG=C and the sort ordering is different (say, capitals don't come first) then the test of comparing MANIFEST lists fails. Now, whether LANG=C should be set in the Makefile or if building a package when LANG!=C is incredibly stupid, I don't know. I just thought it should be mentioned. -- shaky caller pgpQl1Xyk7tk0.pgp Description: PGP signature
Re: X suddenly exits. Segv???
At 03:14 AM 9/22/00 -0700, Karl M. Hegbloom wrote: Package: xserver-xfree86 Version: 4.0.1-0phase2v7 Twice I've had X suddenly exit on me. Both times, iirc, it was when I pushed the X button to close a Mozilla frame via the WM. I don't know if it's a segv or what; it just suddenly snicks out, then `gdm' restarts. Once it was this version, another time before it was the previous (?) phase 2 binary. Has this happened to anyone else? I think that has happened to me once, but three or four times I have waken up to find that my X session has reset in the middle of the night (I tend to stay logged in for days/weeks at a time). The last two times that has happened coincided with network outages (cable modem reset the first time, router[1] turned off and disassembled last night) This morning, I woke up to find that Enlightenment now believes that my X server no longer has XSHM support. I don't know which version of the X packages I'm running, I upgraded last night. Also, it seems like DPMS works with xdm, but not with Enlightenment. I'm using the stock Matrox G400 driver. Any ideas with these issues? [1] our router is an old PowerMac, used because it was the spare computer in the house -- and therefore less expensive than building a dedicated Debian box. As it is, for 5 machines, we have 4 networks, 4+ operating systems, 4 dedicated hubs/bridges/translators, etc.
Re: Niggly little bug
[Followups set to -devel, please respect] Ashley brought this up on debian-x: On Fri, Sep 22, 2000 at 07:58:11AM -0500, Ashley Clark wrote: I'm not sure whether it's worth mentioning but I found a *small* bug in building the packages. I'm not sure whether something should be done in the Makefile or if it's common practice that I wasn't aware of. Regardless, this is the situation: Some languages have different sort orderings. If the package is being built outside of LANG=C and the sort ordering is different (say, capitals don't come first) then the test of comparing MANIFEST lists fails. Now, whether LANG=C should be set in the Makefile or if building a package when LANG!=C is incredibly stupid, I don't know. I just thought it should be mentioned. Do we have a policy on this? I've had a quick scan through the packaging manual, and I can't see it. My gut feeling is that maybe package builds should be run with LANG=C, since to try to get them running in any locale requires some quite complex testing from the maintainer (e.g. the issue above would have been hard to spot). Jules
Re: X suddenly exits. Segv???
* Karl M. Hegbloom [EMAIL PROTECTED] [000922 03:12]: Package: xserver-xfree86 Version: 4.0.1-0phase2v7 Twice I've had X suddenly exit on me. Both times, iirc, it was when I pushed the X button to close a Mozilla frame via the WM. I don't know if it's a segv or what; it just suddenly snicks out, then `gdm' restarts. Once it was this version, another time before it was the previous (?) phase 2 binary. I too have seen this, or something similar. Running a dual-monitor g400 max with the matrox supplied driver, I have had my X exit quite quickly and without warning. Once was when mozilla was open (as well as a gnome terminal or two) and another time seemed to be very closely tied with mozilla -- it happened when I clicked a link in mozilla. I do not run gdm. (And frankly, I confused your reference of gdm with gdb every time I read your email... :) I think I have seen it both with phase 1 and phase 2 .debs, but I am not certain that it did happen with phase 1. I wish I had had the wisdom to make a copy of the server output at that point... :) I do think that one of the xfree86 mailling lists would be the better forum though; I get the impression debian-x is primarily for feedback about the X experience specific to debian. (I too am guilty for using it for other purposes.. :)
Mesa Problem?
Package: xlibmesa3 Version: 4.0.1-0phase2v8 I'm using linux 2.4.0-test8 with DRI support and the r128 module(for my Rage 128 card). Whenever I run any Mesa based applications, they flicker constantly and improperly render certain parts of the screen. A good example of this behavior can be seen by running any of the xlock GL hacks. Branden, I know that these packages aren't for general use, and that this problem probably falls somewhere in the low priority section. I also understand that you're very busy, so I don't expect this to be fixed right away. -- Travis Whitton [EMAIL PROTECTED]
Re: X suddenly exits. Segv???
[EMAIL PROTECTED] (Karl M. Hegbloom) writes: Package: xserver-xfree86 Version: 4.0.1-0phase2v7 Twice I've had X suddenly exit on me. Both times, iirc, it was when I pushed the X button to close a Mozilla frame via the WM. I don't know if it's a segv or what; it just suddenly snicks out, then `gdm' restarts. Once it was this version, another time before it was the previous (?) phase 2 binary. Has this happened to anyone else? I haven't seen this recently. One thing you may want to do to check, if you haven't yet, is to put something other than the window manager as the last entry in the xsession/xinitrc, so it'll be obvious whether the thing dying is the window manager or the X server itself. Also, is there any information in /var/log/XFree86.log? - M -- Mark Monty Montague | [EMAIL PROTECTED] | I don't do Windows(tm) I'm dubious about any company whose assets can be destroyed by rm -rf URL:http://www.gg.caltech.edu/~monty/monty.shtml X-PGP-Fingerprint: E4 EA 6D B1 82 46 DB A1 B0 FF 60 B9 F9 5D 5C F7
Re: Blackbox is crashing on phase 7 of X
On Tue, Sep 19, 2000 at 03:50:49PM -0500, David Starner wrote: On Tue, Sep 19, 2000 at 04:38:03PM -0400, Decklin Foster wrote: David Starner writes: snprintf(-Misc-Fixed-Medium-R-SemiCondens..., 226, %s,-*-*-%s-%s-*-*-%d-*-*-*-*-*-*..., -Misc-Fixed-Medium-R-SemiCondens..., Medium, R, 13) = 130 Ah, ok. Are you able to get the font list at all? (worst case, use something that doesn't allocate a font as your session and DISPLAY=:0 xlsfonts on the console...) Or put xlsfonts file in your .xsession file. I can get the list, it looks right, sawfish and netscape and xterm run just fine. Sigh. LC_ALL=C blackbox seems to fix it. I've filed a bug on blackbox for this. Sorry guys. -- David Starner - [EMAIL PROTECTED] http/ftp: dvdeug.dhis.org And crawling, on the planet's face, some insects called the human race. Lost in space, lost in time, and meaning. -- RHPS
