no libGLU in xlibgl1 and no dri module for tdfx
I have a Voodoo3 graphics card and was trying out direct rendering, which worked with the 4.0.1 that I compiled myself. I installed the experimental 4.0.1 packages (phase1v6), and after figuring out the error with the X wrapper (the XF86_NONE problem), I got the server working. However, I stumbled upon two issues, one is libGLU is missing from xlibgl1, and the other is no support for tdfx_dri was compiled in. First, xlibgl1 which is supposed to replace Mesa. However, only libGL is provided by xlibgl1. Either xlibgl1 should include libGLU or the Mesa packages need to split off libGLU into a separate package. Secondly, no dri tdfx support is included in the packages. The tdfx support depends on glide3 libraries compiled with DRI support. I also tried to get dri support to work by copying the tdfx_dri.so and libglide3 from the 4.0.1 I had compiled previously. Direct rendering worked, but caused the X server to segfault randomly. This is the only error message reported, from the kernel after X dies: [drm:drm_release] *ERROR* Process 10842 dead, freeing lock for context 1 I would like to compile the X packages myself to add tdfx support in the meantime. Please let me know what I need to properly build the X packages, and where to find anything not already in debian/unstable (dpkg-shlibdeps?).
no libGLU in xlibgl1 and no dri module for tdfx
I have a Voodoo3 graphics card and was trying out direct rendering, which worked with the 4.0.1 that I compiled myself. I installed the experimental 4.0.1 packages (phase1v6), and after figuring out the error with the X wrapper (the XF86_NONE problem), I got the server working. However, I stumbled upon two issues, one is libGLU is missing from xlibgl1, and the other is no support for tdfx_dri was compiled in. First, xlibgl1 which is supposed to replace Mesa. However, only libGL is provided by xlibgl1. Either xlibgl1 should include libGLU or the Mesa packages need to split off libGLU into a separate package. Secondly, no dri tdfx support is included in the packages. The tdfx support depends on glide3 libraries compiled with DRI support. I also tried to get dri support to work by copying the tdfx_dri.so and libglide3 from the 4.0.1 I had compiled previously. Direct rendering worked, but caused the X server to segfault randomly. This is the only error message reported, from the kernel after X dies: [drm:drm_release] *ERROR* Process 10842 dead, freeing lock for context 1 I would like to compile the X packages myself to add tdfx support in the meantime. Please let me know what I need to properly build the X packages, and where to find anything not already in debian/unstable (dpkg-shlibdeps?). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 and app-defaults
On Fri, Aug 04, 2000 at 06:20:08AM -0400, Thomas Bushnell, BSG wrote: > > I tried to get Xt to look in both directories, but several different > > attempts failed. > > It shouldn't be that hard to open one pathname and if you get ENOENT, > to try opening the other insteadthat might be a useful > compatibility feature to make work. (Though I agree that it's not > nearly as crucial as some apparently think.) This shouldn't be necessary, since a colon-separated search path is used. For some reason, just prepending /etc/X11/app-defaults didn't work. -- G. Branden Robinson | Debian GNU/Linux|It tastes good. [EMAIL PROTECTED] |-- Bill Clinton http://www.debian.org/~branden/ | pgpxN0aX8KkAB.pgp Description: PGP signature
Re: XFree86 4.0.1 and app-defaults
On Fri, Aug 04, 2000 at 06:20:08AM -0400, Thomas Bushnell, BSG wrote: > > I tried to get Xt to look in both directories, but several different > > attempts failed. > > It shouldn't be that hard to open one pathname and if you get ENOENT, > to try opening the other insteadthat might be a useful > compatibility feature to make work. (Though I agree that it's not > nearly as crucial as some apparently think.) This shouldn't be necessary, since a colon-separated search path is used. For some reason, just prepending /etc/X11/app-defaults didn't work. -- G. Branden Robinson | Debian GNU/Linux|It tastes good. [EMAIL PROTECTED] |-- Bill Clinton http://www.debian.org/~branden/ | PGP signature
Re: XFree86 4.0.1 and app-defaults
Branden Robinson <[EMAIL PROTECTED]> writes: > Whether app-defaults files can be regarded as configuration files or not is > an arbitrary decision. By moving them to /etc/X11 in the default > configuration, XFree86 has indicated their opinion. I see no reason to > differ with them. In my soon-to-be-over job with Athena at MIT I can confirm that we frequently have had great need to change app-defaults files for various reasons, and it has been a difficulty that they are not config files in Red Hat's XFree86 (Red Hat is our supported Linux platform on Athena). So FWIW, I think XFree86 made the right decision, which is another reason not to differ with them. ;) > I tried to get Xt to look in both directories, but several different > attempts failed. It shouldn't be that hard to open one pathname and if you get ENOENT, to try opening the other insteadthat might be a useful compatibility feature to make work. (Though I agree that it's not nearly as crucial as some apparently think.) Thomas
Re: XFree86 4.0.1 and app-defaults
On Tue, Aug 01, 2000 at 11:19:17PM +0200, Remco Blaakmeer wrote: > 1. It is my understanding that app-defaults files are not configuration >files, they are just default settings stored outside the binary. >Therefore, a sysadmin can be expected not to modify them. On the contrary, they can. It is, for instance, useful to configure the backspace and delete keys in accordance with the Debian Keyboard Policy on xterm's app-defaults file, but not in X resources, so that these settings get overridden on a per-session basis by the user's X resource settings (he may be running an X session on a remote machine with backwards mappings). Whether app-defaults files can be regarded as configuration files or not is an arbitrary decision. By moving them to /etc/X11 in the default configuration, XFree86 has indicated their opinion. I see no reason to differ with them. > 2. Files in /etc/X11/app-defaults/ will be modified by (ignorant?) >sysadmins. They will get mad when they discover their local >modifications have been thrown away without warning in an upgrade. No, they won't. I'm registering them as conffiles and when I write some new policy for this (which will have to supersede the policy ratified 8 months ago but only JUST released in the policy manual *sigh*) I will encourage other maintainers to do the same. > Because of point 1, it is my opinion that app-defaults files should never > be conffiles, no matter where they are located. Combine points 1 and 2, > and I think app-defaults file should continue to reside in > /usr/X11R6/lib/X11/app-defaults/. I disagree. > If you say I am wrong on point 1, please say so because that would make my > whole argument invalid. If point 1 has been right up until now and you > want to change it for XFree86 4, there is yet another issue: > > "Older" X clients (built before the necessary changes in Policy[2]) will > try to put their app-defaults files in /usr/X11R6/lib/X11/app-defaults/ > (like they should). Since this will be a symlink, the files will end up in > /etc/X11/app-defaults/. But they aren't conffiles and this conflicts with > the rule that every file under /etc must be a configuration file. > > Branden, where do you stand on this? Have you thought about this? I'm not forcing a migration. I changed my mind about that part. Instead, I changed the Xt library to look in /etc/X11/app-defaults. What this means is that programs using the new policy will work, and the old X clients won't. I tried to get Xt to look in both directories, but several different attempts failed. > Please tell me if I am totally wrong here. I am not an X developer, nor am > I even a Debian developer. I'm just a happy user and have been for some > years now. Packages that ship app-defaults will need to move them to /etc/X11/app-defaults when they build against xlib6g >> 4.0. -- G. Branden Robinson |America is at that awkward stage. It's Debian GNU/Linux|too late to work within the system, but [EMAIL PROTECTED] |too early to shoot the bastards. http://www.debian.org/~branden/ |--Claire Wolfe pgpf5xTFcUMgy.pgp Description: PGP signature
Re: XFree86 4.0.1 and app-defaults
On Tue, Aug 01, 2000 at 10:12:27AM +0200, Sven LUTHER wrote: > Why don't you just tell that XF4 will recognize > etc/X11/XF86Config-4 before etc/X11/XF86Config ? it would have informed me of > my error in far less words. But it would not have reinforced the desirable behavior of Reading The F'ing Manual. > > How about learning to distinguish between servers and clients? > > Because you maintain a package that is composed of the server, some clients > and the lib, and all get installed at the same time upstream ? Gosh, that's an excellent reason. Because distinct components are shipped together, they should be regarded as indistinguishable. > I do know how the Xfree system works, and know the difference between the > client and the server and the lib, maybe i am not as familiar as yourself with > all the small details. I don't have a command of many small details at all. I have a competent grasp of some very basic fundamentals. > That said, it is strange to me that you accuse me of acuusing you of being > incompetent, while you are accusing me of the exact same thing. I don't accuse you of any such thing; I think your words speak for themselves. > But then i know that since my attempt to get a working xfree package for ppc > in january 99, you don't like me ... Despite your best efforts to argue with me instead of contributing meaninfully, we have had working XFree86 .debs for PowerPC for quite a while. > Ok, but upstream needs to handle more legacy stuff than we, don't they ? I don't think this is the case, or even obvious one way or the other. Let's worry about the existing, concrete problems rather than hypotheticals. > Well, i inform you of what i noticed when i did compile XF4 from upstream > source, but you tell me it is uninterresting. Compiling your own XFree86 binaries is no substitute for testing the packages I have put together. > And you don't asked me to test your XF4 debian packages, you don't want to, > you don't even informed me that they existed, how can you expect that kind of > report from me ? I made an announcement to the debian-x mailing list. You have a recurring theme in your career as a Debian developer of expecting people to bring things to your attention. Our mailing lists are opt-in resources. You want to know about it, you've got to sign up. > That said, you do know that lot of stuff is configured in the config/cf files, No, really? In 2.5 years of packaging XFree86 somehow this fundamental issue escaped my attention[1]. > isn't it, are you aware of the _don't install outside of $ProjectRoot_ flag > for example ? I was aware of it, and we don't want it set. We *want* things in /etc/X11. > Ok, i will give more precise in my reports in the future, and i hope that you > will be less agressive, insulting and arrogant in your replies. If you don't succeed in the former, I doubt I will succeed in the latter. I do expect you to, for instance, read the manpages from time to time. > Not that you don't know how, as shown in your recent smooth and honeyy > report about the lucidux fonts on the xfree mailing list. I'm courteous to people deserving of courtesy. That is the default state with which I regard unknown people. But I don't forget you simply because you refrain from pestering me for a few weeks. > That said, why don't you just ship them in non-free ? I feel no compulsion to support non-free software with my unpaid volunteer effort. (Nor with my paid labor at Progeny, which is a Free Software company. If imurdock asks me to do so I will, but I don't think he will. I have already brought the non-free fonts to his attention.) > I know you don't like non-free, but that is what non-free is for, and > would stop Richard Wackerbart's argument immediately. We probably shouldn't discuss the contents of a private mailing list (xfree86-devel) on public ones. -- G. Branden Robinson | A celibate clergy is an especially good Debian GNU/Linux| idea, because it tends to suppress any [EMAIL PROTECTED] | hereditary propensity toward fanaticism. http://www.debian.org/~branden/ | -- Carl Sagan pgpcbvNt3jqzA.pgp Description: PGP signature
Re: XFree86 4.0.1 and app-defaults
Branden Robinson <[EMAIL PROTECTED]> writes: > Whether app-defaults files can be regarded as configuration files or not is > an arbitrary decision. By moving them to /etc/X11 in the default > configuration, XFree86 has indicated their opinion. I see no reason to > differ with them. In my soon-to-be-over job with Athena at MIT I can confirm that we frequently have had great need to change app-defaults files for various reasons, and it has been a difficulty that they are not config files in Red Hat's XFree86 (Red Hat is our supported Linux platform on Athena). So FWIW, I think XFree86 made the right decision, which is another reason not to differ with them. ;) > I tried to get Xt to look in both directories, but several different > attempts failed. It shouldn't be that hard to open one pathname and if you get ENOENT, to try opening the other insteadthat might be a useful compatibility feature to make work. (Though I agree that it's not nearly as crucial as some apparently think.) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 and app-defaults
On Tue, Aug 01, 2000 at 11:19:17PM +0200, Remco Blaakmeer wrote: > 1. It is my understanding that app-defaults files are not configuration >files, they are just default settings stored outside the binary. >Therefore, a sysadmin can be expected not to modify them. On the contrary, they can. It is, for instance, useful to configure the backspace and delete keys in accordance with the Debian Keyboard Policy on xterm's app-defaults file, but not in X resources, so that these settings get overridden on a per-session basis by the user's X resource settings (he may be running an X session on a remote machine with backwards mappings). Whether app-defaults files can be regarded as configuration files or not is an arbitrary decision. By moving them to /etc/X11 in the default configuration, XFree86 has indicated their opinion. I see no reason to differ with them. > 2. Files in /etc/X11/app-defaults/ will be modified by (ignorant?) >sysadmins. They will get mad when they discover their local >modifications have been thrown away without warning in an upgrade. No, they won't. I'm registering them as conffiles and when I write some new policy for this (which will have to supersede the policy ratified 8 months ago but only JUST released in the policy manual *sigh*) I will encourage other maintainers to do the same. > Because of point 1, it is my opinion that app-defaults files should never > be conffiles, no matter where they are located. Combine points 1 and 2, > and I think app-defaults file should continue to reside in > /usr/X11R6/lib/X11/app-defaults/. I disagree. > If you say I am wrong on point 1, please say so because that would make my > whole argument invalid. If point 1 has been right up until now and you > want to change it for XFree86 4, there is yet another issue: > > "Older" X clients (built before the necessary changes in Policy[2]) will > try to put their app-defaults files in /usr/X11R6/lib/X11/app-defaults/ > (like they should). Since this will be a symlink, the files will end up in > /etc/X11/app-defaults/. But they aren't conffiles and this conflicts with > the rule that every file under /etc must be a configuration file. > > Branden, where do you stand on this? Have you thought about this? I'm not forcing a migration. I changed my mind about that part. Instead, I changed the Xt library to look in /etc/X11/app-defaults. What this means is that programs using the new policy will work, and the old X clients won't. I tried to get Xt to look in both directories, but several different attempts failed. > Please tell me if I am totally wrong here. I am not an X developer, nor am > I even a Debian developer. I'm just a happy user and have been for some > years now. Packages that ship app-defaults will need to move them to /etc/X11/app-defaults when they build against xlib6g >> 4.0. -- G. Branden Robinson |America is at that awkward stage. It's Debian GNU/Linux|too late to work within the system, but [EMAIL PROTECTED] |too early to shoot the bastards. http://www.debian.org/~branden/ |--Claire Wolfe PGP signature
Re: XFree86 4.0.1 and app-defaults
On Tue, Aug 01, 2000 at 10:12:27AM +0200, Sven LUTHER wrote: > Why don't you just tell that XF4 will recognize > etc/X11/XF86Config-4 before etc/X11/XF86Config ? it would have informed me of > my error in far less words. But it would not have reinforced the desirable behavior of Reading The F'ing Manual. > > How about learning to distinguish between servers and clients? > > Because you maintain a package that is composed of the server, some clients > and the lib, and all get installed at the same time upstream ? Gosh, that's an excellent reason. Because distinct components are shipped together, they should be regarded as indistinguishable. > I do know how the Xfree system works, and know the difference between the > client and the server and the lib, maybe i am not as familiar as yourself with > all the small details. I don't have a command of many small details at all. I have a competent grasp of some very basic fundamentals. > That said, it is strange to me that you accuse me of acuusing you of being > incompetent, while you are accusing me of the exact same thing. I don't accuse you of any such thing; I think your words speak for themselves. > But then i know that since my attempt to get a working xfree package for ppc > in january 99, you don't like me ... Despite your best efforts to argue with me instead of contributing meaninfully, we have had working XFree86 .debs for PowerPC for quite a while. > Ok, but upstream needs to handle more legacy stuff than we, don't they ? I don't think this is the case, or even obvious one way or the other. Let's worry about the existing, concrete problems rather than hypotheticals. > Well, i inform you of what i noticed when i did compile XF4 from upstream > source, but you tell me it is uninterresting. Compiling your own XFree86 binaries is no substitute for testing the packages I have put together. > And you don't asked me to test your XF4 debian packages, you don't want to, > you don't even informed me that they existed, how can you expect that kind of > report from me ? I made an announcement to the debian-x mailing list. You have a recurring theme in your career as a Debian developer of expecting people to bring things to your attention. Our mailing lists are opt-in resources. You want to know about it, you've got to sign up. > That said, you do know that lot of stuff is configured in the config/cf files, No, really? In 2.5 years of packaging XFree86 somehow this fundamental issue escaped my attention[1]. > isn't it, are you aware of the _don't install outside of $ProjectRoot_ flag > for example ? I was aware of it, and we don't want it set. We *want* things in /etc/X11. > Ok, i will give more precise in my reports in the future, and i hope that you > will be less agressive, insulting and arrogant in your replies. If you don't succeed in the former, I doubt I will succeed in the latter. I do expect you to, for instance, read the manpages from time to time. > Not that you don't know how, as shown in your recent smooth and honeyy > report about the lucidux fonts on the xfree mailing list. I'm courteous to people deserving of courtesy. That is the default state with which I regard unknown people. But I don't forget you simply because you refrain from pestering me for a few weeks. > That said, why don't you just ship them in non-free ? I feel no compulsion to support non-free software with my unpaid volunteer effort. (Nor with my paid labor at Progeny, which is a Free Software company. If imurdock asks me to do so I will, but I don't think he will. I have already brought the non-free fonts to his attention.) > I know you don't like non-free, but that is what non-free is for, and > would stop Richard Wackerbart's argument immediately. We probably shouldn't discuss the contents of a private mailing list (xfree86-devel) on public ones. -- G. Branden Robinson | A celibate clergy is an especially good Debian GNU/Linux| idea, because it tends to suppress any [EMAIL PROTECTED] | hereditary propensity toward fanaticism. http://www.debian.org/~branden/ | -- Carl Sagan PGP signature
