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
Re: XFree86 4.0.1 and app-defaults
Can I ask a question ? In <[EMAIL PROTECTED]>, on Thu, 27 Jul 2000 00:21:54 -0500, Branden Robinson <[EMAIL PROTECTED]> wrote: > It has to do with app-defaults files. Current Debian policy says these > can't be conffiles, so they go in /usr/X11R6/lib/X11/app-defaults. > > Well, upstream has changed things, and it putting them in > /etc/X11/app-defaults. Rather than buck this trend, I think we should roll > with it. I have not checked the 4.0.1 source tree yet, so please let me know if this has been solved. There are some "app-defaults" directory specific to Languages. My package of xcalendar-i18n has two separate resource settings for ja_JP.ujis and ko_KR.eucKR as well as the main app-defaults. $ dpkg -L xcalendar-i18n|grep app-defaults /usr/X11R6/lib/X11/app-defaults /usr/X11R6/lib/X11/app-defaults/XCalendar /usr/X11R6/lib/X11/ja_JP.ujis/app-defaults /usr/X11R6/lib/X11/ja_JP.ujis/app-defaults/XCalendar /usr/X11R6/lib/X11/ko_KR.eucKR/app-defaults /usr/X11R6/lib/X11/ko_KR.eucKR/app-defaults/XCalendar as specified as By default the imake variable ProjectRoot is /usr/X11R6.4 and XFILESEARCHPATH has these components: $ProjectRoot/lib/X11/%L/%T/%N%C%S $ProjectRoot/lib/X11/%l/%T/%N%C%S $ProjectRoot/lib/X11/%T/%N%C%S $ProjectRoot/lib/X11/%L/%T/%N%S $ProjectRoot/lib/X11/%l/%T/%N%S $ProjectRoot/lib/X11/%T/%N%S in xc/RELNOTES.TXT. These files are used to select the strings for menus and labels which are shown in the native language for Japanese and Korean in addition with the default English messages. > We all know there is a "root" XFree86 package that all other X Window > System packages depend on, and that is xfree86-common. In the preinst of > this package will be something like the following logic: > > if [ ! -L /usr/X11R6/lib/X11/app-defaults ]; then > # uh oh, we need to move this > mv /usr/X11R6/lib/X11/app-defaults /usr/X11R6/lib/X11/app-defaults.MOVING > ln -s /etc/X11/app-defaults /usr/X11R6/lib/X11/app-defaults > mv /usr/X11R6/lib/X11/app-defaults.MOVING/* /etc/X11/app-defaults > rmdir /usr/X11R6/lib/X11/app-defaults.MOVING > fi Can this handle the directories /usr/X11R6/lib/X11/$LOCALE/app-defaults ? As fas as I know, xfig also has the specific app-defaults for ja_JP.ujis and ko_KR.eucKR. Thanks. -- Taketoshi Sano: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>
Re: XFree86 4.0.1 and app-defaults
Can I ask a question ? In <[EMAIL PROTECTED]>, on Thu, 27 Jul 2000 00:21:54 -0500, Branden Robinson <[EMAIL PROTECTED]> wrote: > It has to do with app-defaults files. Current Debian policy says these > can't be conffiles, so they go in /usr/X11R6/lib/X11/app-defaults. > > Well, upstream has changed things, and it putting them in > /etc/X11/app-defaults. Rather than buck this trend, I think we should roll > with it. I have not checked the 4.0.1 source tree yet, so please let me know if this has been solved. There are some "app-defaults" directory specific to Languages. My package of xcalendar-i18n has two separate resource settings for ja_JP.ujis and ko_KR.eucKR as well as the main app-defaults. $ dpkg -L xcalendar-i18n|grep app-defaults /usr/X11R6/lib/X11/app-defaults /usr/X11R6/lib/X11/app-defaults/XCalendar /usr/X11R6/lib/X11/ja_JP.ujis/app-defaults /usr/X11R6/lib/X11/ja_JP.ujis/app-defaults/XCalendar /usr/X11R6/lib/X11/ko_KR.eucKR/app-defaults /usr/X11R6/lib/X11/ko_KR.eucKR/app-defaults/XCalendar as specified as By default the imake variable ProjectRoot is /usr/X11R6.4 and XFILESEARCHPATH has these components: $ProjectRoot/lib/X11/%L/%T/%N%C%S $ProjectRoot/lib/X11/%l/%T/%N%C%S $ProjectRoot/lib/X11/%T/%N%C%S $ProjectRoot/lib/X11/%L/%T/%N%S $ProjectRoot/lib/X11/%l/%T/%N%S $ProjectRoot/lib/X11/%T/%N%S in xc/RELNOTES.TXT. These files are used to select the strings for menus and labels which are shown in the native language for Japanese and Korean in addition with the default English messages. > We all know there is a "root" XFree86 package that all other X Window > System packages depend on, and that is xfree86-common. In the preinst of > this package will be something like the following logic: > > if [ ! -L /usr/X11R6/lib/X11/app-defaults ]; then > # uh oh, we need to move this > mv /usr/X11R6/lib/X11/app-defaults /usr/X11R6/lib/X11/app-defaults.MOVING > ln -s /etc/X11/app-defaults /usr/X11R6/lib/X11/app-defaults > mv /usr/X11R6/lib/X11/app-defaults.MOVING/* /etc/X11/app-defaults > rmdir /usr/X11R6/lib/X11/app-defaults.MOVING > fi Can this handle the directories /usr/X11R6/lib/X11/$LOCALE/app-defaults ? As fas as I know, xfig also has the specific app-defaults for ja_JP.ujis and ko_KR.eucKR. Thanks. -- Taketoshi Sano: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 and app-defaults
On Thu, 27 Jul 2000, Branden Robinson wrote: > On Thu, Jul 27, 2000 at 04:15:59AM -0700, Joey Hess wrote: [...] > > So, why not hack X[2]? Make the library look in /etc/X11/app-defaults, then > > in the old location. Make policy that states that packages depending on the > > X 4 version of that library should use /etc/X11/app-defaults. Such a > > package would break if it were installed onto a system with an older > > xlib, but the dependancy will prevent that. Upgrades and downgrades will > > work without any messy difficulties. You can remove the xlib hack in a > > release or two. > > I was hoping to avoid this, but developing consensus on -policy seems to be > that I should do this. Sigh. I just read the discussion and I am still having a problems with the proposed solutions. Since I installed buzz for the first time, I have gotten the impression that every file under /etc is a configuration file[1] and local modifications will be preserved on upgrades. Let's read that again: "Every file under /etc is a configuration file and local modifications will be preserved on upgrades." This may or may not be written down in Debian Policy, I haven't checked. But I surely depend on it in Debian. It raises some points in this case, though. 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. 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. 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/. 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? 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. Remco [1] Note the difference between "configuration file" and "conffile". [2] This includes, of course, every X client in potato. -- rd1936: 10:25pm up 19 days, 20:15, 8 users, load average: 1.44, 1.31, 1.23
Re: XFree86 4.0.1 and app-defaults
On Thu, 27 Jul 2000, Branden Robinson wrote: > On Thu, Jul 27, 2000 at 04:15:59AM -0700, Joey Hess wrote: [...] > > So, why not hack X[2]? Make the library look in /etc/X11/app-defaults, then > > in the old location. Make policy that states that packages depending on the > > X 4 version of that library should use /etc/X11/app-defaults. Such a > > package would break if it were installed onto a system with an older > > xlib, but the dependancy will prevent that. Upgrades and downgrades will > > work without any messy difficulties. You can remove the xlib hack in a > > release or two. > > I was hoping to avoid this, but developing consensus on -policy seems to be > that I should do this. Sigh. I just read the discussion and I am still having a problems with the proposed solutions. Since I installed buzz for the first time, I have gotten the impression that every file under /etc is a configuration file[1] and local modifications will be preserved on upgrades. Let's read that again: "Every file under /etc is a configuration file and local modifications will be preserved on upgrades." This may or may not be written down in Debian Policy, I haven't checked. But I surely depend on it in Debian. It raises some points in this case, though. 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. 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. 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/. 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? 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. Remco [1] Note the difference between "configuration file" and "conffile". [2] This includes, of course, every X client in potato. -- rd1936: 10:25pm up 19 days, 20:15, 8 users, load average: 1.44, 1.31, 1.23 -- 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, Jul 28, 2000 at 09:07:45PM +0200, Marcelo E. Magallon wrote: > >> Sven LUTHER <[EMAIL PROTECTED]> writes: > > > > The XF86Config file is not a conffile. Read the XF86Config 4.x manpage, > > > and you'll see there is no conflict. > > > Well if i install the 3.3.6 X server, it will read its configuration > > file from /etc/X11/XF86Config, and the 4.0.1 X server will read his > > from the exact same location. And The XF86Config format is _NOT_ the > > same for both versions. Thus you run into problems if you want ot > > have XF4.0.1 and XF3.3.6 installed in the same time. > > Please DO read the manpage. There is NO conflict (it will become clear > IFF you read the manpage). Last weekend I was testing a rather bad > scenario (all sorts of mixing of clients, servers and libraries) and as > far as I could see, everything works -- except, of course, stuff using > features only found in XFree86 4.0. Yes, i did read it now, ... that is what comes from reading stuff in the various stages of developpment, they change all the time :((( > > Ok, but you will be packaging the X server + the X libraries + all > > the standard X apps that come with it (well twm, xterm and such). I > > see i need to be much more precise with my postings to you, so > > therfor i will name this whole stuff the "X stuff", so there is no > > confusion. > > ROTFL! (It was a joke, wasn't it?) Well in part, what i don't understand is why branden keeps yelling on me that i don't understand the difference between server and client, when the xf4 debian packages include both, and thus both (and the libraries) have to be thought of when doing the packaging ? > > Now imagine i have the 3.3.6 server installed (which don't know about > > the new location of the app-default stuff you spoke about in your > > mail) > > Read chapters 2 and 10 (IIRC) of the documentation shipped with XFree86 > 4.0. app-defaults are not server side. But when you install the 3.3.6 server, it will pull in the 3.3.6 xfree86-common, which will not have the symlink installed. Now you install an 4.0.1 app, and it could install app-defaults into /etc/X11/app-defaults. Now you have two situation : 1) only the app will ever be reading it's app-defaults, and thus we have no problem whatsoever, the symlink is not really needed, apart from giving the user a uniform location to change his app-defaults. 2) There is some other tool that modify/read the app-defaults, and thus this tool needs be aware of the location of it. Again, it could be looking in both places and do the job for us, no symlink needed. That said, does such a tool exist ? and more importantly, since upstream ships with a symlink, just let's put it in place, the important thing is that no debian package should install its app-default in the wrong location. Friendly, Sven LUTHER
Re: XFree86 4.0.1 and app-defaults
On Fri, Jul 28, 2000 at 10:00:04AM -0500, Branden Robinson wrote: > On Fri, Jul 28, 2000 at 11:49:27AM +0200, Sven LUTHER wrote: > > On Thu, Jul 27, 2000 at 10:50:49AM -0500, Branden Robinson wrote: > > Well if i install the 3.3.6 X server, it will read its configuration file > > from > > /etc/X11/XF86Config, and the 4.0.1 X server will read his from the exact > > same > > location. And The XF86Config format is _NOT_ the same for both versions. > > Thus > > you run into problems if you want ot have XF4.0.1 and XF3.3.6 installed in > > the > > same time. > > > > ... huh, forgot, you don't plan to allow this kind of things, isn't it ? > > You *still* quite obviously have not read the manpage for the 4.x version > of XF86Config. Since you have decided to accuse me of incompetence, I'll > just leave you in ignorance on this point. Ok, did read the man page now, ... You were right, 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. > > Ok, but you will be packaging the X server + the X libraries + all the > > standard X apps that come with it (well twm, xterm and such). I see i need > > to > > be much more precise with my postings to you, so therfor i will name this > > whole stuff the "X stuff", so there is no confusion. > > 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 ? > > I do driver work, no need to be very much aware of lot of stuff which you > > have > > a much better grasp of, > > On the contrary, I think you do need to get a handle on how the rest of the > X Window System works, at least in broad principles. Not knowing these > things will impede your communication with other XFree86 developers. ... 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. That said, is it true that for the work i do, it is more important to knew the graphics ship registers and how a graphic chip works than the much more high level stuff. 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. But then i know that since my attempt to get a working xfree package for ppc in january 99, you don't like me ... > > That said, we are speaking about X apps, well at least some of them are > > maintained by you (x11/xterm and co). Or do you plan to keep the symlink > > magic > > in place forever ? > > Upstream ships a symlink. Ultimately I'd like to see us do so as well. Ok, but upstream needs to handle more legacy stuff than we, don't they ? Anyway, lets just do it. > > Now imagine i have the 3.3.6 server installed (which don't know about the > > new > > location of the app-default stuff you spoke about in your mail) and install > > apps that where compiled for the new 4.0.1 scheme of things. What will > > happen > > if your 4.0.1 xterm installs its app-default files in the /etc location and > > while the 3.3.6 xfree86-common didn't create the symlink ? > > Apparently you didn't read my initial mail in this thread, or you have just > as much trouble grasping Debian package dependencies as you do the > distinction between X servers and X clients. I guess these are not things > you feel you need to know --- maybe you should just just start calling them > "Debian stuff"? > > X clients compiled against the 4.x libraries will depend on xlib6g 4.x. > xlib6g 4.x will depend on xfree86-common 4.x. Therefore, X clients > compiled against the 4.x libraries will not be present on systems with > xfree86-common 3.3.6. Sure, that's what i forgot. > > And i have been running XF4 since a long time already (well since before > > it was called 3.9.x). I can tell you what has gone bad in any terms you > > will need. But then if you are not interrested, just do the work > > yourself, i will wait for the packages to be released, but then don't > > complain you have no time to do the work, if you don't accept help from > > people > > Incoherent "help" from you is less valuable than knowledgeable, or simply > informative help from others. Just to name names, Joey Hess, Brendan > O'Dea, and Marcelo Magallon all provided quite helpful feedback on my > preliminary 4.0.1 .debs. In large portion, they simply provided > typescripts of their installation commands and the output they generated. > (Joey Hess gets the purple heard for grepping the sources to find out what > Xt function reads app-defaults, though. But as it turns out, I have to > edit something in config/cf to do what we want, and not lib/Xt. Ah, the > Byzantine joys of X.) Well, i inform you of what i noticed when i did compile XF4 from upstream source, but you tell me it is uninterresting. And y
Re: XFree86 4.0.1 and app-defaults
On Fri, Jul 28, 2000 at 09:07:45PM +0200, Marcelo E. Magallon wrote: > >> Sven LUTHER <[EMAIL PROTECTED]> writes: > > > > The XF86Config file is not a conffile. Read the XF86Config 4.x manpage, > > > and you'll see there is no conflict. > > > Well if i install the 3.3.6 X server, it will read its configuration > > file from /etc/X11/XF86Config, and the 4.0.1 X server will read his > > from the exact same location. And The XF86Config format is _NOT_ the > > same for both versions. Thus you run into problems if you want ot > > have XF4.0.1 and XF3.3.6 installed in the same time. > > Please DO read the manpage. There is NO conflict (it will become clear > IFF you read the manpage). Last weekend I was testing a rather bad > scenario (all sorts of mixing of clients, servers and libraries) and as > far as I could see, everything works -- except, of course, stuff using > features only found in XFree86 4.0. Yes, i did read it now, ... that is what comes from reading stuff in the various stages of developpment, they change all the time :((( > > Ok, but you will be packaging the X server + the X libraries + all > > the standard X apps that come with it (well twm, xterm and such). I > > see i need to be much more precise with my postings to you, so > > therfor i will name this whole stuff the "X stuff", so there is no > > confusion. > > ROTFL! (It was a joke, wasn't it?) Well in part, what i don't understand is why branden keeps yelling on me that i don't understand the difference between server and client, when the xf4 debian packages include both, and thus both (and the libraries) have to be thought of when doing the packaging ? > > Now imagine i have the 3.3.6 server installed (which don't know about > > the new location of the app-default stuff you spoke about in your > > mail) > > Read chapters 2 and 10 (IIRC) of the documentation shipped with XFree86 > 4.0. app-defaults are not server side. But when you install the 3.3.6 server, it will pull in the 3.3.6 xfree86-common, which will not have the symlink installed. Now you install an 4.0.1 app, and it could install app-defaults into /etc/X11/app-defaults. Now you have two situation : 1) only the app will ever be reading it's app-defaults, and thus we have no problem whatsoever, the symlink is not really needed, apart from giving the user a uniform location to change his app-defaults. 2) There is some other tool that modify/read the app-defaults, and thus this tool needs be aware of the location of it. Again, it could be looking in both places and do the job for us, no symlink needed. That said, does such a tool exist ? and more importantly, since upstream ships with a symlink, just let's put it in place, the important thing is that no debian package should install its app-default in the wrong location. Friendly, Sven LUTHER -- 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, Jul 28, 2000 at 10:00:04AM -0500, Branden Robinson wrote: > On Fri, Jul 28, 2000 at 11:49:27AM +0200, Sven LUTHER wrote: > > On Thu, Jul 27, 2000 at 10:50:49AM -0500, Branden Robinson wrote: > > Well if i install the 3.3.6 X server, it will read its configuration file from > > /etc/X11/XF86Config, and the 4.0.1 X server will read his from the exact same > > location. And The XF86Config format is _NOT_ the same for both versions. Thus > > you run into problems if you want ot have XF4.0.1 and XF3.3.6 installed in the > > same time. > > > > ... huh, forgot, you don't plan to allow this kind of things, isn't it ? > > You *still* quite obviously have not read the manpage for the 4.x version > of XF86Config. Since you have decided to accuse me of incompetence, I'll > just leave you in ignorance on this point. Ok, did read the man page now, ... You were right, 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. > > Ok, but you will be packaging the X server + the X libraries + all the > > standard X apps that come with it (well twm, xterm and such). I see i need to > > be much more precise with my postings to you, so therfor i will name this > > whole stuff the "X stuff", so there is no confusion. > > 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 ? > > I do driver work, no need to be very much aware of lot of stuff which you have > > a much better grasp of, > > On the contrary, I think you do need to get a handle on how the rest of the > X Window System works, at least in broad principles. Not knowing these > things will impede your communication with other XFree86 developers. ... 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. That said, is it true that for the work i do, it is more important to knew the graphics ship registers and how a graphic chip works than the much more high level stuff. 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. But then i know that since my attempt to get a working xfree package for ppc in january 99, you don't like me ... > > That said, we are speaking about X apps, well at least some of them are > > maintained by you (x11/xterm and co). Or do you plan to keep the symlink magic > > in place forever ? > > Upstream ships a symlink. Ultimately I'd like to see us do so as well. Ok, but upstream needs to handle more legacy stuff than we, don't they ? Anyway, lets just do it. > > Now imagine i have the 3.3.6 server installed (which don't know about the new > > location of the app-default stuff you spoke about in your mail) and install > > apps that where compiled for the new 4.0.1 scheme of things. What will happen > > if your 4.0.1 xterm installs its app-default files in the /etc location and > > while the 3.3.6 xfree86-common didn't create the symlink ? > > Apparently you didn't read my initial mail in this thread, or you have just > as much trouble grasping Debian package dependencies as you do the > distinction between X servers and X clients. I guess these are not things > you feel you need to know --- maybe you should just just start calling them > "Debian stuff"? > > X clients compiled against the 4.x libraries will depend on xlib6g 4.x. > xlib6g 4.x will depend on xfree86-common 4.x. Therefore, X clients > compiled against the 4.x libraries will not be present on systems with > xfree86-common 3.3.6. Sure, that's what i forgot. > > And i have been running XF4 since a long time already (well since before > > it was called 3.9.x). I can tell you what has gone bad in any terms you > > will need. But then if you are not interrested, just do the work > > yourself, i will wait for the packages to be released, but then don't > > complain you have no time to do the work, if you don't accept help from > > people > > Incoherent "help" from you is less valuable than knowledgeable, or simply > informative help from others. Just to name names, Joey Hess, Brendan > O'Dea, and Marcelo Magallon all provided quite helpful feedback on my > preliminary 4.0.1 .debs. In large portion, they simply provided > typescripts of their installation commands and the output they generated. > (Joey Hess gets the purple heard for grepping the sources to find out what > Xt function reads app-defaults, though. But as it turns out, I have to > edit something in config/cf to do what we want, and not lib/Xt. Ah, the > Byzantine joys of X.) Well, i inform you of what i noticed when i did compile XF4 from upstream source, but you tell me it is uninterresting. And you don't asked me to test your XF4 debian pa
Re: XFree86 4.0.1 and app-defaults
On Fri, Jul 28, 2000 at 01:55:15PM -0500, Derek J Witt wrote: > I just upgraded to XF 4.0.1 via the tarballs. I found out that X is more > unstable than XF 4.0.0. The s3virge server just locks up my system faster > than 4.0.0 did. I tried disabling gpm, all font servers to no avail. The best thing for you to do is submit a bug report to XFree86 using this file: xc/programs/Xserver/hw/xfree86/doc/BugReport That's in the source distribution. I'm sure their binary tarballs put it somewhere. -- G. Branden Robinson |I am sorry, but what you have mistaken Debian GNU/Linux|for malicious intent is nothing more [EMAIL PROTECTED] |than sheer incompetence! http://www.debian.org/~branden/ |-- J. L. Rizzo II pgpFhFCS2OjmD.pgp Description: PGP signature
Re: XFree86 4.0.1 and app-defaults
On Fri, Jul 28, 2000 at 01:55:15PM -0500, Derek J Witt wrote: > I just upgraded to XF 4.0.1 via the tarballs. I found out that X is more > unstable than XF 4.0.0. The s3virge server just locks up my system faster > than 4.0.0 did. I tried disabling gpm, all font servers to no avail. The best thing for you to do is submit a bug report to XFree86 using this file: xc/programs/Xserver/hw/xfree86/doc/BugReport That's in the source distribution. I'm sure their binary tarballs put it somewhere. -- G. Branden Robinson |I am sorry, but what you have mistaken Debian GNU/Linux|for malicious intent is nothing more [EMAIL PROTECTED] |than sheer incompetence! http://www.debian.org/~branden/ |-- J. L. Rizzo II PGP signature
Re: XFree86 4.0.1 and app-defaults
>> Sven LUTHER <[EMAIL PROTECTED]> writes: > When i build XF4, i install it into /usr/X11R6.4, and patch it so > that it uses /etc/X11/XF86Config.4 instead of /etc/X11/XF86Config.4. Interesting... you patched it to do ALMOST EXACTLY WHAT IT DOES PER DEFAULT. Please go /read/ the manpages. Marcelo
Re: XFree86 4.0.1 and app-defaults
>> Sven LUTHER <[EMAIL PROTECTED]> writes: > > The XF86Config file is not a conffile. Read the XF86Config 4.x manpage, > > and you'll see there is no conflict. > Well if i install the 3.3.6 X server, it will read its configuration > file from /etc/X11/XF86Config, and the 4.0.1 X server will read his > from the exact same location. And The XF86Config format is _NOT_ the > same for both versions. Thus you run into problems if you want ot > have XF4.0.1 and XF3.3.6 installed in the same time. Please DO read the manpage. There is NO conflict (it will become clear IFF you read the manpage). Last weekend I was testing a rather bad scenario (all sorts of mixing of clients, servers and libraries) and as far as I could see, everything works -- except, of course, stuff using features only found in XFree86 4.0. > Ok, but you will be packaging the X server + the X libraries + all > the standard X apps that come with it (well twm, xterm and such). I > see i need to be much more precise with my postings to you, so > therfor i will name this whole stuff the "X stuff", so there is no > confusion. ROTFL! (It was a joke, wasn't it?) > Now imagine i have the 3.3.6 server installed (which don't know about > the new location of the app-default stuff you spoke about in your > mail) Read chapters 2 and 10 (IIRC) of the documentation shipped with XFree86 4.0. app-defaults are not server side. Marcelo
Re: XFree86 4.0.1 and app-defaults
I just upgraded to XF 4.0.1 via the tarballs. I found out that X is more unstable than XF 4.0.0. The s3virge server just locks up my system faster than 4.0.0 did. I tried disabling gpm, all font servers to no avail. The only stability I've gotten from XFree86 (3.x and 4.0.x in general) is by using fbdev with VESA FB. While this is very stable for me, it's non-accelerated. This does hamper some things; I can't play some games like Q3A and Unreal Tournament (Not that really matters ;-) It seems that my box locks up mostly when xterm scrolls up or other changes content (scrolling and clearing window seem to be the culprits). I also had my box lock up when my screen changes content (e.g. moving windows or when other windows' content change). I am using a S3 Virge/GX2 with 4 MB VRAM (Diamond Stealth 3D 4000). This is an AGP card. I don't think it's a AGPx2. I tried adjusting the aparture size in my bios. I tried using from 0 upto 32Mb to no avail. It seems that 16Mb is perhaps the most stable. I also tried disabling all ROM shadowing in my bios. That seems to help some. I am still shadowing my video bios. I don't know if that affects it. I could also try disabling IRQ10 (making the video card not using IRQ's). BTW, I'm using a Tyan AT-100 bios dated 23 September 1999. I have 32Mb ram, K6-2/350. I am currently using 2.4.0-test4. I am at woody. I know i'm using at least libc 2.1.2 or so. If anyone would have any thoughts on this would be appreciated. ** Derek J Witt ** * Email: mailto:[EMAIL PROTECTED] * * Home Page: http://www.flinthills.com/~djw/ * *** "...and on the eighth day, God met Bill Gates." - Unknown **
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 11:09:03AM -0500, Branden Robinson wrote: > Everyone except Christian Steigies did not see that. It was your > imagination. Go away. I'll append the last lines of the log, maybe its just mc68000 missing here ? #elif defined(__powerpc__) || defined(__sparc__) || defined(__mips__) I'll try to hack that in and rebuild. (Note its really mc68000 and not __m68k__, __mc68000__ or similar). It should help compiling this step, I have no idea how much use that is... Branden, if you want the full log, gzipped its 300k. Christian [...] rm -f lnxResource.o gcc -c -O2 -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -I../../../../../../programs/Xserver/hw/xfree86/common -I../../../../../../programs/Xserver/hw/xfree86/os-support -I. -I../../../../../../programs/Xserver/include -I../../../../../../exports/include/X11 -I../../../../../../include/extensions -I../../../../../.. -I../../../../../../exports/include -Dlinux -D__mc68000__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -I/usr/src/linux/include -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPANORAMIX -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DSMART_SCHEDULE -DX_BYTE_ORDER=X_BIG_ENDIAN -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO-DUSESTDRES -DHAVE_SYSV_IPC lnxResource.c lnxResource.c:211: #error : Put your platform dependent code here!! make[8]: *** [lnxResource.o] Error 1 make[8]: Leaving directory `/build/source/xfree4.0/xfree86-1-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/os-support/linux' make[7]: *** [linux] Error 2 [...] make: *** [debian/stampdir/build] Error 2 ** Build finished at 2728-1432 FAILED [dpkg-buildpackage died] -- ** Finished at 2728-1433 Build needed 14:38:57, 423648k disk space
Re: XFree86 4.0.1 and app-defaults
>> Sven LUTHER <[EMAIL PROTECTED]> writes: > When i build XF4, i install it into /usr/X11R6.4, and patch it so > that it uses /etc/X11/XF86Config.4 instead of /etc/X11/XF86Config.4. Interesting... you patched it to do ALMOST EXACTLY WHAT IT DOES PER DEFAULT. Please go /read/ the manpages. Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 and app-defaults
>> Sven LUTHER <[EMAIL PROTECTED]> writes: > > The XF86Config file is not a conffile. Read the XF86Config 4.x manpage, > > and you'll see there is no conflict. > Well if i install the 3.3.6 X server, it will read its configuration > file from /etc/X11/XF86Config, and the 4.0.1 X server will read his > from the exact same location. And The XF86Config format is _NOT_ the > same for both versions. Thus you run into problems if you want ot > have XF4.0.1 and XF3.3.6 installed in the same time. Please DO read the manpage. There is NO conflict (it will become clear IFF you read the manpage). Last weekend I was testing a rather bad scenario (all sorts of mixing of clients, servers and libraries) and as far as I could see, everything works -- except, of course, stuff using features only found in XFree86 4.0. > Ok, but you will be packaging the X server + the X libraries + all > the standard X apps that come with it (well twm, xterm and such). I > see i need to be much more precise with my postings to you, so > therfor i will name this whole stuff the "X stuff", so there is no > confusion. ROTFL! (It was a joke, wasn't it?) > Now imagine i have the 3.3.6 server installed (which don't know about > the new location of the app-default stuff you spoke about in your > mail) Read chapters 2 and 10 (IIRC) of the documentation shipped with XFree86 4.0. app-defaults are not server side. Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 and app-defaults
I just upgraded to XF 4.0.1 via the tarballs. I found out that X is more unstable than XF 4.0.0. The s3virge server just locks up my system faster than 4.0.0 did. I tried disabling gpm, all font servers to no avail. The only stability I've gotten from XFree86 (3.x and 4.0.x in general) is by using fbdev with VESA FB. While this is very stable for me, it's non-accelerated. This does hamper some things; I can't play some games like Q3A and Unreal Tournament (Not that really matters ;-) It seems that my box locks up mostly when xterm scrolls up or other changes content (scrolling and clearing window seem to be the culprits). I also had my box lock up when my screen changes content (e.g. moving windows or when other windows' content change). I am using a S3 Virge/GX2 with 4 MB VRAM (Diamond Stealth 3D 4000). This is an AGP card. I don't think it's a AGPx2. I tried adjusting the aparture size in my bios. I tried using from 0 upto 32Mb to no avail. It seems that 16Mb is perhaps the most stable. I also tried disabling all ROM shadowing in my bios. That seems to help some. I am still shadowing my video bios. I don't know if that affects it. I could also try disabling IRQ10 (making the video card not using IRQ's). BTW, I'm using a Tyan AT-100 bios dated 23 September 1999. I have 32Mb ram, K6-2/350. I am currently using 2.4.0-test4. I am at woody. I know i'm using at least libc 2.1.2 or so. If anyone would have any thoughts on this would be appreciated. ** Derek J Witt ** * Email: mailto:[EMAIL PROTECTED] * * Home Page: http://www.flinthills.com/~djw/ * *** "...and on the eighth day, God met Bill Gates." - Unknown ** -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 11:09:03AM -0500, Branden Robinson wrote: > Everyone except Christian Steigies did not see that. It was your > imagination. Go away. I'll append the last lines of the log, maybe its just mc68000 missing here ? #elif defined(__powerpc__) || defined(__sparc__) || defined(__mips__) I'll try to hack that in and rebuild. (Note its really mc68000 and not __m68k__, __mc68000__ or similar). It should help compiling this step, I have no idea how much use that is... Branden, if you want the full log, gzipped its 300k. Christian [...] rm -f lnxResource.o gcc -c -O2 -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -I../../../../../../programs/Xserver/hw/xfree86/common -I../../../../../../programs/Xserver/hw/xfree86/os-support -I. -I../../../../../../programs/Xserver/include -I../../../../../../exports/include/X11 -I../../../../../../include/extensions -I../../../../../.. -I../../../../../../exports/include -Dlinux -D__mc68000__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -I/usr/src/linux/include -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPANORAMIX -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DSMART_SCHEDULE -DX_BYTE_ORDER=X_BIG_ENDIAN -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO-DUSESTDRES -DHAVE_SYSV_IPC lnxResource.c lnxResource.c:211: #error : Put your platform dependent code here!! make[8]: *** [lnxResource.o] Error 1 make[8]: Leaving directory `/build/source/xfree4.0/xfree86-1-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/os-support/linux' make[7]: *** [linux] Error 2 [...] make: *** [debian/stampdir/build] Error 2 ** Build finished at 2728-1432 FAILED [dpkg-buildpackage died] -- ** Finished at 2728-1433 Build needed 14:38:57, 423648k disk space -- 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, Jul 28, 2000 at 12:09:59PM +0200, Sven LUTHER wrote: > When i build XF4, i install it into /usr/X11R6.4, and patch it so that it uses > /etc/X11/XF86Config.4 instead of /etc/X11/XF86Config.4. ^^ Interesting distinction there. [...] > Why don't use a similar trick with the debian package, at least during the > phase where the xf4 debian package are still flagged _dangerous_ this way you > can test it, and not jeopardize your debian XF3.x install ? Because it doesn't achieve what I need. The point is not to get some kludge on people's systems. The point is to find out what DOES break, what DOES get overwritten, what package conflicts need to be declared so that our users *CAN UPGRADE* from 3.3.6 and not end up with two entire installations of the X Window System. For instance, your approach would not have revealed the app-defaults problem. It would simply have postponed the frustration of discovering it. My approach front-loads the problems, so that we actually have real Debian packages available for people sooner. A Debian package is not a .tar.gz file. Debian packages are upgradeable in place. If people just want 4.0.1 on their system ASAP, they are free to download the binary tarfiles from XFree86, or compile it from source themselves. > diff -u xc.orig/config/cf/xfree86.cf xc/config/cf/xfree86.cf > --- xc.orig/config/cf/xfree86.cf Mon Apr 10 18:35:34 2000 > +++ xc/config/cf/xfree86.cf Mon Apr 10 19:42:31 2000 > @@ -21,7 +21,7 @@ > */ > > #ifndef XConfigFile > -#define XConfigFile XF86Config > +#define XConfigFile XF86Config.4 > #endif > #ifndef XConfigDir > #define XConfigDir $(LIBDIR) This change is not necessary; please review XF86Config(5). -- G. Branden Robinson |The only way to get rid of a temptation Debian GNU/Linux|is to yield to it. [EMAIL PROTECTED] |-- Oscar Wilde http://www.debian.org/~branden/ | pgp4zFT47PEjZ.pgp Description: PGP signature
Re: XFree86 4.0.1 and app-defaults
On Fri, Jul 28, 2000 at 11:49:27AM +0200, Sven LUTHER wrote: > On Thu, Jul 27, 2000 at 10:50:49AM -0500, Branden Robinson wrote: > Well if i install the 3.3.6 X server, it will read its configuration file from > /etc/X11/XF86Config, and the 4.0.1 X server will read his from the exact same > location. And The XF86Config format is _NOT_ the same for both versions. Thus > you run into problems if you want ot have XF4.0.1 and XF3.3.6 installed in the > same time. > > ... huh, forgot, you don't plan to allow this kind of things, isn't it ? You *still* quite obviously have not read the manpage for the 4.x version of XF86Config. Since you have decided to accuse me of incompetence, I'll just leave you in ignorance on this point. > Ok, but you will be packaging the X server + the X libraries + all the > standard X apps that come with it (well twm, xterm and such). I see i need to > be much more precise with my postings to you, so therfor i will name this > whole stuff the "X stuff", so there is no confusion. How about learning to distinguish between servers and clients? > I do driver work, no need to be very much aware of lot of stuff which you have > a much better grasp of, On the contrary, I think you do need to get a handle on how the rest of the X Window System works, at least in broad principles. Not knowing these things will impede your communication with other XFree86 developers. > That said, we are speaking about X apps, well at least some of them are > maintained by you (x11/xterm and co). Or do you plan to keep the symlink magic > in place forever ? Upstream ships a symlink. Ultimately I'd like to see us do so as well. > Now imagine i have the 3.3.6 server installed (which don't know about the new > location of the app-default stuff you spoke about in your mail) and install > apps that where compiled for the new 4.0.1 scheme of things. What will happen > if your 4.0.1 xterm installs its app-default files in the /etc location and > while the 3.3.6 xfree86-common didn't create the symlink ? Apparently you didn't read my initial mail in this thread, or you have just as much trouble grasping Debian package dependencies as you do the distinction between X servers and X clients. I guess these are not things you feel you need to know --- maybe you should just just start calling them "Debian stuff"? X clients compiled against the 4.x libraries will depend on xlib6g 4.x. xlib6g 4.x will depend on xfree86-common 4.x. Therefore, X clients compiled against the 4.x libraries will not be present on systems with xfree86-common 3.3.6. > But then maybe i am being stupid, the app-default is only ever used by the app > that installed it (in this case xterm ?). So i guess there are no conflicts, > ... Well, that's what I told you; given that you claim disinterest in understanding these things yourself, you might as well just start taking my word for it. > > Well, there are lots of possible ways things can go wrong. What you > > describe doesn't sound like a server problem to me. > > No, but it is an "X stuff" problem, ... I expect more intelligent problem reports from fellow Debian and XFree86 developers. You are both. Therefore I expect a little more initiative from you. Heck, there are users of my packages who are *neither* Debian nor XFree86 developers, and submit far more informative problem reports than you do. You do little more than describe some vague set of circumstances and proclaim "it's broken". > How come on, don't threat me as stupid, just because i was a bit unprecise in > my mail, i understand perfectly well the difference between the server, the > client and the libraries. Then why would you have any reason to believe the X server would read app-defaults files directly? The X server doesn't even read X *resources* from files, though it does store them. > And i have been running XF4 since a long time already (well since before > it was called 3.9.x). I can tell you what has gone bad in any terms you > will need. But then if you are not interrested, just do the work > yourself, i will wait for the packages to be released, but then don't > complain you have no time to do the work, if you don't accept help from > people Incoherent "help" from you is less valuable than knowledgeable, or simply informative help from others. Just to name names, Joey Hess, Brendan O'Dea, and Marcelo Magallon all provided quite helpful feedback on my preliminary 4.0.1 .debs. In large portion, they simply provided typescripts of their installation commands and the output they generated. (Joey Hess gets the purple heard for grepping the sources to find out what Xt function reads app-defaults, though. But as it turns out, I have to edit something in config/cf to do what we want, and not lib/Xt. Ah, the Byzantine joys of X.) If you can learn to communicate your problems better, I will appreciate feedback from you. If not, it will be worthless to me, and you'll only see your problems get fixed because
Re: XFree86 4.0.1 and app-defaults
On Fri, Jul 28, 2000 at 12:09:59PM +0200, Sven LUTHER wrote: > When i build XF4, i install it into /usr/X11R6.4, and patch it so that it uses > /etc/X11/XF86Config.4 instead of /etc/X11/XF86Config.4. ^^ Interesting distinction there. [...] > Why don't use a similar trick with the debian package, at least during the > phase where the xf4 debian package are still flagged _dangerous_ this way you > can test it, and not jeopardize your debian XF3.x install ? Because it doesn't achieve what I need. The point is not to get some kludge on people's systems. The point is to find out what DOES break, what DOES get overwritten, what package conflicts need to be declared so that our users *CAN UPGRADE* from 3.3.6 and not end up with two entire installations of the X Window System. For instance, your approach would not have revealed the app-defaults problem. It would simply have postponed the frustration of discovering it. My approach front-loads the problems, so that we actually have real Debian packages available for people sooner. A Debian package is not a .tar.gz file. Debian packages are upgradeable in place. If people just want 4.0.1 on their system ASAP, they are free to download the binary tarfiles from XFree86, or compile it from source themselves. > diff -u xc.orig/config/cf/xfree86.cf xc/config/cf/xfree86.cf > --- xc.orig/config/cf/xfree86.cf Mon Apr 10 18:35:34 2000 > +++ xc/config/cf/xfree86.cf Mon Apr 10 19:42:31 2000 > @@ -21,7 +21,7 @@ > */ > > #ifndef XConfigFile > -#define XConfigFile XF86Config > +#define XConfigFile XF86Config.4 > #endif > #ifndef XConfigDir > #define XConfigDir $(LIBDIR) This change is not necessary; please review XF86Config(5). -- G. Branden Robinson |The only way to get rid of a temptation Debian GNU/Linux|is to yield to it. [EMAIL PROTECTED] |-- Oscar Wilde http://www.debian.org/~branden/ | PGP signature
Re: XFree86 4.0.1 and app-defaults
On Fri, Jul 28, 2000 at 11:49:27AM +0200, Sven LUTHER wrote: > On Thu, Jul 27, 2000 at 10:50:49AM -0500, Branden Robinson wrote: > Well if i install the 3.3.6 X server, it will read its configuration file from > /etc/X11/XF86Config, and the 4.0.1 X server will read his from the exact same > location. And The XF86Config format is _NOT_ the same for both versions. Thus > you run into problems if you want ot have XF4.0.1 and XF3.3.6 installed in the > same time. > > ... huh, forgot, you don't plan to allow this kind of things, isn't it ? You *still* quite obviously have not read the manpage for the 4.x version of XF86Config. Since you have decided to accuse me of incompetence, I'll just leave you in ignorance on this point. > Ok, but you will be packaging the X server + the X libraries + all the > standard X apps that come with it (well twm, xterm and such). I see i need to > be much more precise with my postings to you, so therfor i will name this > whole stuff the "X stuff", so there is no confusion. How about learning to distinguish between servers and clients? > I do driver work, no need to be very much aware of lot of stuff which you have > a much better grasp of, On the contrary, I think you do need to get a handle on how the rest of the X Window System works, at least in broad principles. Not knowing these things will impede your communication with other XFree86 developers. > That said, we are speaking about X apps, well at least some of them are > maintained by you (x11/xterm and co). Or do you plan to keep the symlink magic > in place forever ? Upstream ships a symlink. Ultimately I'd like to see us do so as well. > Now imagine i have the 3.3.6 server installed (which don't know about the new > location of the app-default stuff you spoke about in your mail) and install > apps that where compiled for the new 4.0.1 scheme of things. What will happen > if your 4.0.1 xterm installs its app-default files in the /etc location and > while the 3.3.6 xfree86-common didn't create the symlink ? Apparently you didn't read my initial mail in this thread, or you have just as much trouble grasping Debian package dependencies as you do the distinction between X servers and X clients. I guess these are not things you feel you need to know --- maybe you should just just start calling them "Debian stuff"? X clients compiled against the 4.x libraries will depend on xlib6g 4.x. xlib6g 4.x will depend on xfree86-common 4.x. Therefore, X clients compiled against the 4.x libraries will not be present on systems with xfree86-common 3.3.6. > But then maybe i am being stupid, the app-default is only ever used by the app > that installed it (in this case xterm ?). So i guess there are no conflicts, > ... Well, that's what I told you; given that you claim disinterest in understanding these things yourself, you might as well just start taking my word for it. > > Well, there are lots of possible ways things can go wrong. What you > > describe doesn't sound like a server problem to me. > > No, but it is an "X stuff" problem, ... I expect more intelligent problem reports from fellow Debian and XFree86 developers. You are both. Therefore I expect a little more initiative from you. Heck, there are users of my packages who are *neither* Debian nor XFree86 developers, and submit far more informative problem reports than you do. You do little more than describe some vague set of circumstances and proclaim "it's broken". > How come on, don't threat me as stupid, just because i was a bit unprecise in > my mail, i understand perfectly well the difference between the server, the > client and the libraries. Then why would you have any reason to believe the X server would read app-defaults files directly? The X server doesn't even read X *resources* from files, though it does store them. > And i have been running XF4 since a long time already (well since before > it was called 3.9.x). I can tell you what has gone bad in any terms you > will need. But then if you are not interrested, just do the work > yourself, i will wait for the packages to be released, but then don't > complain you have no time to do the work, if you don't accept help from > people Incoherent "help" from you is less valuable than knowledgeable, or simply informative help from others. Just to name names, Joey Hess, Brendan O'Dea, and Marcelo Magallon all provided quite helpful feedback on my preliminary 4.0.1 .debs. In large portion, they simply provided typescripts of their installation commands and the output they generated. (Joey Hess gets the purple heard for grepping the sources to find out what Xt function reads app-defaults, though. But as it turns out, I have to edit something in config/cf to do what we want, and not lib/Xt. Ah, the Byzantine joys of X.) If you can learn to communicate your problems better, I will appreciate feedback from you. If not, it will be worthless to me, and you'll only see your problems get fixed because
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 11:09:03AM -0500, Branden Robinson wrote: > On Thu, Jul 27, 2000 at 01:32:32PM +0200, Christian T. Steigies wrote: > > Are source packages available? > > I'm probably going to regret posting this URL, especially since I'll have > v3 -- which I *was* going to make public -- ready today, but... > > http://deadbeast.net/~branden/DANGER_WILL_ROBINSON/ > Branden, ... When i build XF4, i install it into /usr/X11R6.4, and patch it so that it uses /etc/X11/XF86Config.4 instead of /etc/X11/XF86Config.4. This as worked nicely to have both 3.3.6 and 4.x installed at the same time on my boxes. Sure after that i have to modify /etc/ld.so.conf so it looks into /usr/X11R6.4/lib and modify the path accordyingly. or use the appropriate shell variables to do the same stuff. Why don't use a similar trick with the debian package, at least during the phase where the xf4 debian package are still flagged _dangerous_ this way you can test it, and not jeopardize your debian XF3.x install ? Here is the (rather smallish) patch to do this. If you like i could provide a small shell script to switch between both server ? Friendly, Sven LUTHER diff -u xc.orig/config/cf/site.def xc/config/cf/site.def --- xc.orig/config/cf/site.def Mon Apr 10 18:35:34 2000 +++ xc/config/cf/site.def Mon Apr 10 19:42:15 2000 @@ -84,7 +84,7 @@ #ifdef AfterVendorCF #ifndef ProjectRoot -#define ProjectRoot /usr/X11R6 +#define ProjectRoot /usr/X11R6.4 #endif /* diff -u xc.orig/config/cf/xfree86.cf xc/config/cf/xfree86.cf --- xc.orig/config/cf/xfree86.cfMon Apr 10 18:35:34 2000 +++ xc/config/cf/xfree86.cf Mon Apr 10 19:42:31 2000 @@ -21,7 +21,7 @@ */ #ifndef XConfigFile -#define XConfigFileXF86Config +#define XConfigFileXF86Config.4 #endif #ifndef XConfigDir #define XConfigDir $(LIBDIR)
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 01:32:32PM +0200, Christian T. Steigies wrote: > On Thu, Jul 27, 2000 at 12:57:10PM +0200, Sven LUTHER wrote: > > I remember running XF4 on top of amifb way back in the 3.9.16 days, i > > suppose > > this will work nicely on m68k also, if you can build the kernel. > amifb is not the only fb available for m68k. It might work for me, but I can > not see it, since my ami mon has gone bust. Will you donate me an old mon, > or better a flickerfixer so I can test that? Huh, ... what is the problem with using the vga mode on amifb, sure you will need a connector converter, but it works fine. I have been usning a 30Khz+ monitor since the longest time on my amiga. > AFAIK amifb is the _only_ fb for m68k which is working in X4.0, or maybe > there is one more. Youre the xfree developer, not me. Ill try to improve the > kernel driver for my virge, but I will not work on xfree drivers in the > foreseable future. Well, there is pm2fb, but you will need a powerup board for it so most probably you will be running apus and not m68k. But then i think some cyberstorm boards accepted pm2 cybervision cards. That said, are you saying that the fbdevhw stuff will not run on your virge fb ? Did you test it before saying that, i see no major reason why it should not work (sure, it is unaccelerated, but then ...) > > > Fine, but what if the 4.0 libraries can not be built on m68k (I would not > > > wonder if), will the 3.3.6 libaries be still around for us? > > > > Did you try it ? > Are source packages available? > That was not my question, I do not intend to build anything now, I was just > asking a technical question. Again: will xfree 3.3.6 and 4.0 be able to > exist simultaneously in the archive? X4.0 would need to have a new package > name then I think. This is the plan, right? I only want a confirmation for > that... if not, we might declare the m68k port dead for woody. > > > How long do you think i would need to build XF4 on a 25MHz 68040 ? > No idea, are source packages available? Oh, I said that before, all I can > say is, xfree 3.3.6 takes about 24h on [EMAIL PROTECTED], 4.0 will be about > half the > time, since IIRC libc5 packages will be dropped. No idea what else wil be > built to make it use more time... So it will take days on my box, maybe i could try it out, but it would be bests if someone with a faster processor did do it. Well, for response to the kind of porblem you are asking you just need to compile the upstream XF4.0.1 tarball, no need of debian packaging to find this out. > > mach64 should be supported under XF4, or will soonely, i think, anyway, you > > could always run the fbdev Xserver without accels. > I could also run in VGA mode or buy a new graphics card. But again, that was > not my question... Ok, but until someone tries a compile, we will not have a definitive answer on this, and most possibly no fix to any problem that will come up. Friendly, Svne LUTHER
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 10:50:49AM -0500, Branden Robinson wrote: > On Thu, Jul 27, 2000 at 10:27:55AM +0200, Sven LUTHER wrote: > > Ok, about the X server, but will we maintain two sets of libraries also, or > > go > > with the 4.0.1 ones ? > > Just the 4.0.1 ones. > > > Also how did you solve the XF86Config conflict ? since 4.x a,d 3.x > > XF86Config > > files are not compatible. > > The XF86Config file is not a conffile. Read the XF86Config 4.x manpage, > and you'll see there is no conflict. Well if i install the 3.3.6 X server, it will read its configuration file from /etc/X11/XF86Config, and the 4.0.1 X server will read his from the exact same location. And The XF86Config format is _NOT_ the same for both versions. Thus you run into problems if you want ot have XF4.0.1 and XF3.3.6 installed in the same time. ... huh, forgot, you don't plan to allow this kind of things, isn't it ? > > Sure, ... bad wording perhaps, but i did think more about changing > > app-default > > location and other similar stuff, since in the long run, the apps should > > install it in the new location, you will have to fix the 3.3.6 server to use > > the new location, > > Uh. Remember, the X Window System is network-transparent. The X server > itself does not read or deal with app-defaults files in any way. Ok, but you will be packaging the X server + the X libraries + all the standard X apps that come with it (well twm, xterm and such). I see i need to be much more precise with my postings to you, so therfor i will name this whole stuff the "X stuff", so there is no confusion. > What exactly do you do as a developer for XFree86, again? You seem to have > difficulty with a few really fundamental concepts of its operation. I do driver work, no need to be very much aware of lot of stuff which you have a much better grasp of, just hardware docs and other such things. And i don't do it since a very long time (Well i am developper since 1 and half year only, but didn't work on X all the time since then (well i burnt the graphic card i wanted to do driver work for and it took a long time in being replaced) That said, we are speaking about X apps, well at least some of them are maintained by you (x11/xterm and co). Or do you plan to keep the symlink magic in place forever ? Now imagine i have the 3.3.6 server installed (which don't know about the new location of the app-default stuff you spoke about in your mail) and install apps that where compiled for the new 4.0.1 scheme of things. What will happen if your 4.0.1 xterm installs its app-default files in the /etc location and while the 3.3.6 xfree86-common didn't create the symlink ? > > that is the 3.3.6 xfree-common should do the same trick as > > the 4.0.1 one ? > > That is not necessary. But then maybe i am being stupid, the app-default is only ever used by the app that installed it (in this case xterm ?). So i guess there are no conflicts, ... > > I thought 4.0.1 moved to X11R6.4, did only 1 library change version number > > when going from X11R6.3 to X11R6.4 ? > > Looks that way. > > > I confirm, i run most X clients on a hand installed 4.0.1+ server, without > > major problems. Like said the only problems encountered where with the xterm > > color stuff when i didn't do a full XF4 install and some keymap problems > > (well > > surely because default 4.x XF86Config came with a japanese keyboard > > configuration, and i didn't spot it :((() > > Well, there are lots of possible ways things can go wrong. What you > describe doesn't sound like a server problem to me. No, but it is an "X stuff" problem, ... > > where can i get your brand new XF4 packages ? i would like to download them > > tommorow, build and try them out in my offline home box, and then report > > back > > to you about it. > > Well, before you do that, please read /usr/doc/xfree86-common/FAQ.gz and > get your head around the differences between the X server, X clients, and X > libraries; your mails are not telling me you have them quite figured out, > and I need testers who can do better than say "it's broken", but who can > make a reasonable guess as to why. To do that, you have to understand a > little bit about how X works. How come on, don't threat me as stupid, just because i was a bit unprecise in my mail, i understand perfectly well the difference between the server, the client and the libraries. And i have been running XF4 since a long time already (well since before it was called 3.9.x). I can tell you what has gone bad in any terms you will need. But then if you are not interrested, just do the work yourself, i will wait for the packages to be released, but then don't complain you have no time to do the work, if you don't accept help from people ... Friendly, Sven LUTHER > > -- > G. Branden Robinson |Communism is just one step on the long > Debian GNU/Linux|road from capitalism to capitalism. > [EMAIL PROTECTED] |--
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 11:09:03AM -0500, Branden Robinson wrote: > On Thu, Jul 27, 2000 at 01:32:32PM +0200, Christian T. Steigies wrote: > > Are source packages available? > > I'm probably going to regret posting this URL, especially since I'll have > v3 -- which I *was* going to make public -- ready today, but... > > http://deadbeast.net/~branden/DANGER_WILL_ROBINSON/ > Branden, ... When i build XF4, i install it into /usr/X11R6.4, and patch it so that it uses /etc/X11/XF86Config.4 instead of /etc/X11/XF86Config.4. This as worked nicely to have both 3.3.6 and 4.x installed at the same time on my boxes. Sure after that i have to modify /etc/ld.so.conf so it looks into /usr/X11R6.4/lib and modify the path accordyingly. or use the appropriate shell variables to do the same stuff. Why don't use a similar trick with the debian package, at least during the phase where the xf4 debian package are still flagged _dangerous_ this way you can test it, and not jeopardize your debian XF3.x install ? Here is the (rather smallish) patch to do this. If you like i could provide a small shell script to switch between both server ? Friendly, Sven LUTHER diff -u xc.orig/config/cf/site.def xc/config/cf/site.def --- xc.orig/config/cf/site.def Mon Apr 10 18:35:34 2000 +++ xc/config/cf/site.def Mon Apr 10 19:42:15 2000 @@ -84,7 +84,7 @@ #ifdef AfterVendorCF #ifndef ProjectRoot -#define ProjectRoot /usr/X11R6 +#define ProjectRoot /usr/X11R6.4 #endif /* diff -u xc.orig/config/cf/xfree86.cf xc/config/cf/xfree86.cf --- xc.orig/config/cf/xfree86.cfMon Apr 10 18:35:34 2000 +++ xc/config/cf/xfree86.cf Mon Apr 10 19:42:31 2000 @@ -21,7 +21,7 @@ */ #ifndef XConfigFile -#define XConfigFileXF86Config +#define XConfigFileXF86Config.4 #endif #ifndef XConfigDir #define XConfigDir $(LIBDIR)
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 01:32:32PM +0200, Christian T. Steigies wrote: > On Thu, Jul 27, 2000 at 12:57:10PM +0200, Sven LUTHER wrote: > > I remember running XF4 on top of amifb way back in the 3.9.16 days, i suppose > > this will work nicely on m68k also, if you can build the kernel. > amifb is not the only fb available for m68k. It might work for me, but I can > not see it, since my ami mon has gone bust. Will you donate me an old mon, > or better a flickerfixer so I can test that? Huh, ... what is the problem with using the vga mode on amifb, sure you will need a connector converter, but it works fine. I have been usning a 30Khz+ monitor since the longest time on my amiga. > AFAIK amifb is the _only_ fb for m68k which is working in X4.0, or maybe > there is one more. Youre the xfree developer, not me. Ill try to improve the > kernel driver for my virge, but I will not work on xfree drivers in the > foreseable future. Well, there is pm2fb, but you will need a powerup board for it so most probably you will be running apus and not m68k. But then i think some cyberstorm boards accepted pm2 cybervision cards. That said, are you saying that the fbdevhw stuff will not run on your virge fb ? Did you test it before saying that, i see no major reason why it should not work (sure, it is unaccelerated, but then ...) > > > Fine, but what if the 4.0 libraries can not be built on m68k (I would not > > > wonder if), will the 3.3.6 libaries be still around for us? > > > > Did you try it ? > Are source packages available? > That was not my question, I do not intend to build anything now, I was just > asking a technical question. Again: will xfree 3.3.6 and 4.0 be able to > exist simultaneously in the archive? X4.0 would need to have a new package > name then I think. This is the plan, right? I only want a confirmation for > that... if not, we might declare the m68k port dead for woody. > > > How long do you think i would need to build XF4 on a 25MHz 68040 ? > No idea, are source packages available? Oh, I said that before, all I can > say is, xfree 3.3.6 takes about 24h on 060@50, 4.0 will be about half the > time, since IIRC libc5 packages will be dropped. No idea what else wil be > built to make it use more time... So it will take days on my box, maybe i could try it out, but it would be bests if someone with a faster processor did do it. Well, for response to the kind of porblem you are asking you just need to compile the upstream XF4.0.1 tarball, no need of debian packaging to find this out. > > mach64 should be supported under XF4, or will soonely, i think, anyway, you > > could always run the fbdev Xserver without accels. > I could also run in VGA mode or buy a new graphics card. But again, that was > not my question... Ok, but until someone tries a compile, we will not have a definitive answer on this, and most possibly no fix to any problem that will come up. Friendly, Svne LUTHER -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 10:50:49AM -0500, Branden Robinson wrote: > On Thu, Jul 27, 2000 at 10:27:55AM +0200, Sven LUTHER wrote: > > Ok, about the X server, but will we maintain two sets of libraries also, or go > > with the 4.0.1 ones ? > > Just the 4.0.1 ones. > > > Also how did you solve the XF86Config conflict ? since 4.x a,d 3.x XF86Config > > files are not compatible. > > The XF86Config file is not a conffile. Read the XF86Config 4.x manpage, > and you'll see there is no conflict. Well if i install the 3.3.6 X server, it will read its configuration file from /etc/X11/XF86Config, and the 4.0.1 X server will read his from the exact same location. And The XF86Config format is _NOT_ the same for both versions. Thus you run into problems if you want ot have XF4.0.1 and XF3.3.6 installed in the same time. ... huh, forgot, you don't plan to allow this kind of things, isn't it ? > > Sure, ... bad wording perhaps, but i did think more about changing app-default > > location and other similar stuff, since in the long run, the apps should > > install it in the new location, you will have to fix the 3.3.6 server to use > > the new location, > > Uh. Remember, the X Window System is network-transparent. The X server > itself does not read or deal with app-defaults files in any way. Ok, but you will be packaging the X server + the X libraries + all the standard X apps that come with it (well twm, xterm and such). I see i need to be much more precise with my postings to you, so therfor i will name this whole stuff the "X stuff", so there is no confusion. > What exactly do you do as a developer for XFree86, again? You seem to have > difficulty with a few really fundamental concepts of its operation. I do driver work, no need to be very much aware of lot of stuff which you have a much better grasp of, just hardware docs and other such things. And i don't do it since a very long time (Well i am developper since 1 and half year only, but didn't work on X all the time since then (well i burnt the graphic card i wanted to do driver work for and it took a long time in being replaced) That said, we are speaking about X apps, well at least some of them are maintained by you (x11/xterm and co). Or do you plan to keep the symlink magic in place forever ? Now imagine i have the 3.3.6 server installed (which don't know about the new location of the app-default stuff you spoke about in your mail) and install apps that where compiled for the new 4.0.1 scheme of things. What will happen if your 4.0.1 xterm installs its app-default files in the /etc location and while the 3.3.6 xfree86-common didn't create the symlink ? > > that is the 3.3.6 xfree-common should do the same trick as > > the 4.0.1 one ? > > That is not necessary. But then maybe i am being stupid, the app-default is only ever used by the app that installed it (in this case xterm ?). So i guess there are no conflicts, ... > > I thought 4.0.1 moved to X11R6.4, did only 1 library change version number > > when going from X11R6.3 to X11R6.4 ? > > Looks that way. > > > I confirm, i run most X clients on a hand installed 4.0.1+ server, without > > major problems. Like said the only problems encountered where with the xterm > > color stuff when i didn't do a full XF4 install and some keymap problems (well > > surely because default 4.x XF86Config came with a japanese keyboard > > configuration, and i didn't spot it :((() > > Well, there are lots of possible ways things can go wrong. What you > describe doesn't sound like a server problem to me. No, but it is an "X stuff" problem, ... > > where can i get your brand new XF4 packages ? i would like to download them > > tommorow, build and try them out in my offline home box, and then report back > > to you about it. > > Well, before you do that, please read /usr/doc/xfree86-common/FAQ.gz and > get your head around the differences between the X server, X clients, and X > libraries; your mails are not telling me you have them quite figured out, > and I need testers who can do better than say "it's broken", but who can > make a reasonable guess as to why. To do that, you have to understand a > little bit about how X works. How come on, don't threat me as stupid, just because i was a bit unprecise in my mail, i understand perfectly well the difference between the server, the client and the libraries. And i have been running XF4 since a long time already (well since before it was called 3.9.x). I can tell you what has gone bad in any terms you will need. But then if you are not interrested, just do the work yourself, i will wait for the packages to be released, but then don't complain you have no time to do the work, if you don't accept help from people ... Friendly, Sven LUTHER > > -- > G. Branden Robinson |Communism is just one step on the long > Debian GNU/Linux|road from capitalism to capitalism. > [EMAIL PROTECTED] |-- Russian saying > http:/
Re: XFree86 4.0.1 and app-defaults
Please don't CC me on list mails. On Thu, Jul 27, 2000 at 11:54:09AM -0700, Sean 'Shaleh' Perry wrote: > > I was hoping to avoid this, but developing consensus on -policy seems to be > > that I should do this. Sigh. > > > >> [1] Verified, that is lib/Xt/Initialize.c, XtScreenDatabase() > > > > I'm not sure it's not the only one. It's not just Xt-using apps that read > > app-defaults, IIRC. I think the Xrm* functions may deal with it as well. > > I'll check this out. > > > >> [2] And yeah I looked at the code and it looks doable. Insert a check for > >> a file in the old directory around line 534 of the file in [1]. > > > > Indeed, I believe this is an Xrm issue, not necessarily a Xt one. Turns out that app-defaults is just an Xt convention. This further underscores the distinction between app-defaults and X resources, which most people think are the same thing. :) In a nutshell, app-defaults are a way of storing default information about the program external to its binary. They are strictly client-side, whereas X resources are stored within the server. > Hacking X to do this seems bad. Why did upstream not have a similar redundant > search path? Don't know. -- G. Branden Robinson|When dogma enters the brain, all Debian GNU/Linux |intellectual activity ceases. [EMAIL PROTECTED] |-- Robert Anton Wilson http://deadbeast.net/~branden/ | pgprg5qhryCMk.pgp Description: PGP signature
Re: XFree86 4.0.1 and app-defaults
Please don't CC me on list mails. On Thu, Jul 27, 2000 at 11:54:09AM -0700, Sean 'Shaleh' Perry wrote: > > I was hoping to avoid this, but developing consensus on -policy seems to be > > that I should do this. Sigh. > > > >> [1] Verified, that is lib/Xt/Initialize.c, XtScreenDatabase() > > > > I'm not sure it's not the only one. It's not just Xt-using apps that read > > app-defaults, IIRC. I think the Xrm* functions may deal with it as well. > > I'll check this out. > > > >> [2] And yeah I looked at the code and it looks doable. Insert a check for > >> a file in the old directory around line 534 of the file in [1]. > > > > Indeed, I believe this is an Xrm issue, not necessarily a Xt one. Turns out that app-defaults is just an Xt convention. This further underscores the distinction between app-defaults and X resources, which most people think are the same thing. :) In a nutshell, app-defaults are a way of storing default information about the program external to its binary. They are strictly client-side, whereas X resources are stored within the server. > Hacking X to do this seems bad. Why did upstream not have a similar redundant > search path? Don't know. -- G. Branden Robinson|When dogma enters the brain, all Debian GNU/Linux |intellectual activity ceases. [EMAIL PROTECTED] |-- Robert Anton Wilson http://deadbeast.net/~branden/ | PGP signature
Re: XFree86 4.0.1 and app-defaults
Sean 'Shaleh' Perry wrote: > Indeed, I believe this is an Xrm issue, not necessarily a Xt one. Well the file I referenced is the only .c or .h file in all of X that contains the string '"app-defaults"'. > Hacking X to do this seems bad. Why did upstream not have a similar redundant > search path? Remember, upstream almost never thinks about backwards compatability and incremental upgrades the way we do. -- see shy jo
Re: XFree86 4.0.1 and app-defaults
Wichert Akkerman wrote: > Can't you play a trick with XUSERFILESEARCHPATH internally? That might > work (I'm assuming it has some built-in default value here). Actually, the search path's value comes from the Imakefile, where is is set via some imake function like this: SEARCHPATHDEFAULT = XFileSearchPathDefault However, I think it's used as a search path for more than just app-defaults files, so playing tricks with it directly may not be wise. -- see shy jo
Re: XFree86 4.0.1 and app-defaults
Sean 'Shaleh' Perry wrote: > Indeed, I believe this is an Xrm issue, not necessarily a Xt one. Well the file I referenced is the only .c or .h file in all of X that contains the string '"app-defaults"'. > Hacking X to do this seems bad. Why did upstream not have a similar redundant > search path? Remember, upstream almost never thinks about backwards compatability and incremental upgrades the way we do. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 and app-defaults
Wichert Akkerman wrote: > Can't you play a trick with XUSERFILESEARCHPATH internally? That might > work (I'm assuming it has some built-in default value here). Actually, the search path's value comes from the Imakefile, where is is set via some imake function like this: SEARCHPATHDEFAULT = XFileSearchPathDefault However, I think it's used as a search path for more than just app-defaults files, so playing tricks with it directly may not be wise. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 and app-defaults
> I was hoping to avoid this, but developing consensus on -policy seems to be > that I should do this. Sigh. > >> [1] Verified, that is lib/Xt/Initialize.c, XtScreenDatabase() > > I'm not sure it's not the only one. It's not just Xt-using apps that read > app-defaults, IIRC. I think the Xrm* functions may deal with it as well. > I'll check this out. > >> [2] And yeah I looked at the code and it looks doable. Insert a check for >> a file in the old directory around line 534 of the file in [1]. > Indeed, I believe this is an Xrm issue, not necessarily a Xt one. Hacking X to do this seems bad. Why did upstream not have a similar redundant search path?
Re: XFree86 4.0.1 and app-defaults
Previously Branden Robinson wrote: > On Thu, Jul 27, 2000 at 04:15:59AM -0700, Joey Hess wrote: > > So, why not hack X[2]? Make the library look in /etc/X11/app-defaults, then > > in the old location. Make policy that states that packages depending on the > > X 4 version of that library should use /etc/X11/app-defaults. Such a > > package would break if it were installed onto a system with an older > > xlib, but the dependancy will prevent that. Upgrades and downgrades will > > work without any messy difficulties. You can remove the xlib hack in a > > release or two. > > I was hoping to avoid this, but developing consensus on -policy seems to be > that I should do this. Sigh. Can't you play a trick with XUSERFILESEARCHPATH internally? That might work (I'm assuming it has some built-in default value here). Wichert. -- _ / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgp3dL38aByYz.pgp Description: PGP signature
Re: XFree86 4.0.1 and app-defaults
> I was hoping to avoid this, but developing consensus on -policy seems to be > that I should do this. Sigh. > >> [1] Verified, that is lib/Xt/Initialize.c, XtScreenDatabase() > > I'm not sure it's not the only one. It's not just Xt-using apps that read > app-defaults, IIRC. I think the Xrm* functions may deal with it as well. > I'll check this out. > >> [2] And yeah I looked at the code and it looks doable. Insert a check for >> a file in the old directory around line 534 of the file in [1]. > Indeed, I believe this is an Xrm issue, not necessarily a Xt one. Hacking X to do this seems bad. Why did upstream not have a similar redundant search path? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 02:47:25PM +0200, Marcelo E. Magallon wrote: > I'm two minds about this. Yes, the architecture of the new X server > is better. What I'm getting out of it is not. I have to sit down, > reread docs, and figure out why, but the 16 bpp mode suffers from > severe dithering on my hardware (G400). Yes, I've seen a big thread about this on xfree86-devel. It's being worked on. > The much promotioned OpenGL support is still in development, which is > the other reason I annoyed you so much about the .diff.gz -- I want to > persue automatic building out of cvs of the relevant stuff for Debian. > On that respect, utah-glx is still faster/easier to install/better > looking/whatever. Well, like I said, I have no intention to kill the 3.x servers in general for woody. What I *was* going to do was kill the server binaries or SVGA modules for all hardware that had at least unaccelerated support in 4.0. I could be persuaded to change my criteria. What servers and SVGA modules are built is a matter of editing one .cf file. -- G. Branden Robinson |"To be is to do" -- Plato Debian GNU/Linux|"To do is to be" -- Aristotle [EMAIL PROTECTED] |"Do be do be do" -- Sinatra http://www.debian.org/~branden/ | pgp1Ro20zCTeg.pgp Description: PGP signature
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 01:32:32PM +0200, Christian T. Steigies wrote: > Are source packages available? I'm probably going to regret posting this URL, especially since I'll have v3 -- which I *was* going to make public -- ready today, but... http://deadbeast.net/~branden/DANGER_WILL_ROBINSON/ Everyone except Christian Steigies did not see that. It was your imagination. Go away. > Again: will xfree 3.3.6 and 4.0 be able to exist simultaneously in the > archive? X4.0 would need to have a new package name then I think. This is > the plan, right? I only want a confirmation for that... if not, we might > declare the m68k port dead for woody. I wasn't planning on letting them exist simultaneously, except for the servers, which should address the m68k hardware issues. I do *not* want the m68k port to be declared dead; certainly not because of XFree86. -- G. Branden Robinson | Men use thought only to justify their Debian GNU/Linux| wrong doings, and speech only to conceal [EMAIL PROTECTED] | their thoughts. http://www.debian.org/~branden/ | -- Voltaire pgpPmInYaRtCt.pgp Description: PGP signature
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 10:59:11AM +0200, Christian T. Steigies wrote: > Ok, I am not an xfree86 developer, I have to ask the m68k question. AFAIK > the xfree drivers for m68k are by far not ready, or only a handful yet. With > this we (m68k) could install xfree4.0 libraries and run the 3.3.6 servers? Yes. > Fine, but what if the 4.0 libraries can not be built on m68k (I would not > wonder if), will the 3.3.6 libaries be still around for us? No, but if they don't build on Amiga I'm going to have to bust ass to port them. Guess it will be time to phone up this company I have in mind and plead for an Amiga 4000T. > Will the complete packages of 3.3.6 and 4.0+ exist in parallel, for those > with m68k and other not so recent hardware (like my mach64)? Might not be > necessary, but I have a better feeling, if I ran all packages from one > version. Well, at present I'm not planning to do this. Full 3.3.6 packages will of course exist in potato, however. Note that I am delegating maintainership of XFree86 3.x to Stephen R. Gore, who was masochistic enough to volunteer for this task. > Sorry if you answered that allready in your first message, but with my > historic view, I did not see a quick answer to that. I didn't answer it in my initial message in this thread, but it has been talked about before. A few weeks ago, though, maybe. -- G. Branden Robinson |A committee is a life form with six or Debian GNU/Linux|more legs and no brain. [EMAIL PROTECTED] |-- Robert Heinlein http://www.debian.org/~branden/ | pgpztrH1Y5d26.pgp Description: PGP signature
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 04:15:59AM -0700, Joey Hess wrote: > Hmm. What bogus information will dpkg have? [...] > I can only identify two problems: > > * dpkg -S /etc/X11/app-defaults/foo will fail. That's what I was thinking of. > * If some other package also contains an app-defaults file named foo, > but puts in in /etc/X11/app-defaults/foo, strange things could happen > if both packages are installed. Well, that's an ordinary package conflict. Two packages should not be shipping app-defaults files with the same name unless they conflict. > Note that both problems can happen even if we adopt your proposed policy > and everyone follows it to the letter, in the following situation: > > * I upgrade to woody, new X, and upgrade all the app-defaults-containing > packages. > * I then decide I like potato's version of one of those packages better, > and downgrade to it. Nothing prevents me from doing this after all. Hrm. Well, I was kinda hoping no one would do this. A little unrealistic, perhaps. > I also have a bit of an alternate idea, which goes like this. You > mention a few things: [...] > Ok, so all packages that have app-defaults files link to the X > libraries. I assume one of those libraries is responsible for reading > the app-defaults file[1]. And some horrible thing you haven't specified will > happen if an app cannot read its app-defaults file. Some programs, like the new xf86cfg, don't work at all (it just crashes back to the prompt). xterm staggers a bit but is usable. xcalc doesn't know how to place its widgets. If this breaks stuff even in other parts of the XFree86 distribution, I have pretty dire expectations about third-party clients. > So, why not hack X[2]? Make the library look in /etc/X11/app-defaults, then > in the old location. Make policy that states that packages depending on the > X 4 version of that library should use /etc/X11/app-defaults. Such a > package would break if it were installed onto a system with an older > xlib, but the dependancy will prevent that. Upgrades and downgrades will > work without any messy difficulties. You can remove the xlib hack in a > release or two. I was hoping to avoid this, but developing consensus on -policy seems to be that I should do this. Sigh. > [1] Verified, that is lib/Xt/Initialize.c, XtScreenDatabase() I'm not sure it's not the only one. It's not just Xt-using apps that read app-defaults, IIRC. I think the Xrm* functions may deal with it as well. I'll check this out. > [2] And yeah I looked at the code and it looks doable. Insert a check for > a file in the old directory around line 534 of the file in [1]. Thanks. -- G. Branden Robinson |You live and learn. Debian GNU/Linux|Or you don't live long. [EMAIL PROTECTED] |-- Robert Heinlein http://www.debian.org/~branden/ | pgpxZofpmVMWa.pgp Description: PGP signature
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 10:27:55AM +0200, Sven LUTHER wrote: > Ok, about the X server, but will we maintain two sets of libraries also, or go > with the 4.0.1 ones ? Just the 4.0.1 ones. > Also how did you solve the XF86Config conflict ? since 4.x a,d 3.x XF86Config > files are not compatible. The XF86Config file is not a conffile. Read the XF86Config 4.x manpage, and you'll see there is no conflict. > Sure, ... bad wording perhaps, but i did think more about changing app-default > location and other similar stuff, since in the long run, the apps should > install it in the new location, you will have to fix the 3.3.6 server to use > the new location, Uh. Remember, the X Window System is network-transparent. The X server itself does not read or deal with app-defaults files in any way. What exactly do you do as a developer for XFree86, again? You seem to have difficulty with a few really fundamental concepts of its operation. > that is the 3.3.6 xfree-common should do the same trick as > the 4.0.1 one ? That is not necessary. > I thought 4.0.1 moved to X11R6.4, did only 1 library change version number > when going from X11R6.3 to X11R6.4 ? Looks that way. > I confirm, i run most X clients on a hand installed 4.0.1+ server, without > major problems. Like said the only problems encountered where with the xterm > color stuff when i didn't do a full XF4 install and some keymap problems (well > surely because default 4.x XF86Config came with a japanese keyboard > configuration, and i didn't spot it :((() Well, there are lots of possible ways things can go wrong. What you describe doesn't sound like a server problem to me. > where can i get your brand new XF4 packages ? i would like to download them > tommorow, build and try them out in my offline home box, and then report back > to you about it. Well, before you do that, please read /usr/doc/xfree86-common/FAQ.gz and get your head around the differences between the X server, X clients, and X libraries; your mails are not telling me you have them quite figured out, and I need testers who can do better than say "it's broken", but who can make a reasonable guess as to why. To do that, you have to understand a little bit about how X works. -- G. Branden Robinson |Communism is just one step on the long Debian GNU/Linux|road from capitalism to capitalism. [EMAIL PROTECTED] |-- Russian saying http://www.debian.org/~branden/ | pgpsiSpusNy0h.pgp Description: PGP signature
Re: XFree86 4.0.1 and app-defaults
Previously Branden Robinson wrote: > On Thu, Jul 27, 2000 at 04:15:59AM -0700, Joey Hess wrote: > > So, why not hack X[2]? Make the library look in /etc/X11/app-defaults, then > > in the old location. Make policy that states that packages depending on the > > X 4 version of that library should use /etc/X11/app-defaults. Such a > > package would break if it were installed onto a system with an older > > xlib, but the dependancy will prevent that. Upgrades and downgrades will > > work without any messy difficulties. You can remove the xlib hack in a > > release or two. > > I was hoping to avoid this, but developing consensus on -policy seems to be > that I should do this. Sigh. Can't you play a trick with XUSERFILESEARCHPATH internally? That might work (I'm assuming it has some built-in default value here). Wichert. -- _ / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | PGP signature
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 02:47:25PM +0200, Marcelo E. Magallon wrote: > I'm two minds about this. Yes, the architecture of the new X server > is better. What I'm getting out of it is not. I have to sit down, > reread docs, and figure out why, but the 16 bpp mode suffers from > severe dithering on my hardware (G400). Yes, I've seen a big thread about this on xfree86-devel. It's being worked on. > The much promotioned OpenGL support is still in development, which is > the other reason I annoyed you so much about the .diff.gz -- I want to > persue automatic building out of cvs of the relevant stuff for Debian. > On that respect, utah-glx is still faster/easier to install/better > looking/whatever. Well, like I said, I have no intention to kill the 3.x servers in general for woody. What I *was* going to do was kill the server binaries or SVGA modules for all hardware that had at least unaccelerated support in 4.0. I could be persuaded to change my criteria. What servers and SVGA modules are built is a matter of editing one .cf file. -- G. Branden Robinson |"To be is to do" -- Plato Debian GNU/Linux|"To do is to be" -- Aristotle [EMAIL PROTECTED] |"Do be do be do" -- Sinatra http://www.debian.org/~branden/ | PGP signature
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 01:32:32PM +0200, Christian T. Steigies wrote: > Are source packages available? I'm probably going to regret posting this URL, especially since I'll have v3 -- which I *was* going to make public -- ready today, but... http://deadbeast.net/~branden/DANGER_WILL_ROBINSON/ Everyone except Christian Steigies did not see that. It was your imagination. Go away. > Again: will xfree 3.3.6 and 4.0 be able to exist simultaneously in the > archive? X4.0 would need to have a new package name then I think. This is > the plan, right? I only want a confirmation for that... if not, we might > declare the m68k port dead for woody. I wasn't planning on letting them exist simultaneously, except for the servers, which should address the m68k hardware issues. I do *not* want the m68k port to be declared dead; certainly not because of XFree86. -- G. Branden Robinson | Men use thought only to justify their Debian GNU/Linux| wrong doings, and speech only to conceal [EMAIL PROTECTED] | their thoughts. http://www.debian.org/~branden/ | -- Voltaire PGP signature
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 10:59:11AM +0200, Christian T. Steigies wrote: > Ok, I am not an xfree86 developer, I have to ask the m68k question. AFAIK > the xfree drivers for m68k are by far not ready, or only a handful yet. With > this we (m68k) could install xfree4.0 libraries and run the 3.3.6 servers? Yes. > Fine, but what if the 4.0 libraries can not be built on m68k (I would not > wonder if), will the 3.3.6 libaries be still around for us? No, but if they don't build on Amiga I'm going to have to bust ass to port them. Guess it will be time to phone up this company I have in mind and plead for an Amiga 4000T. > Will the complete packages of 3.3.6 and 4.0+ exist in parallel, for those > with m68k and other not so recent hardware (like my mach64)? Might not be > necessary, but I have a better feeling, if I ran all packages from one > version. Well, at present I'm not planning to do this. Full 3.3.6 packages will of course exist in potato, however. Note that I am delegating maintainership of XFree86 3.x to Stephen R. Gore, who was masochistic enough to volunteer for this task. > Sorry if you answered that allready in your first message, but with my > historic view, I did not see a quick answer to that. I didn't answer it in my initial message in this thread, but it has been talked about before. A few weeks ago, though, maybe. -- G. Branden Robinson |A committee is a life form with six or Debian GNU/Linux|more legs and no brain. [EMAIL PROTECTED] |-- Robert Heinlein http://www.debian.org/~branden/ | PGP signature
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 04:15:59AM -0700, Joey Hess wrote: > Hmm. What bogus information will dpkg have? [...] > I can only identify two problems: > > * dpkg -S /etc/X11/app-defaults/foo will fail. That's what I was thinking of. > * If some other package also contains an app-defaults file named foo, > but puts in in /etc/X11/app-defaults/foo, strange things could happen > if both packages are installed. Well, that's an ordinary package conflict. Two packages should not be shipping app-defaults files with the same name unless they conflict. > Note that both problems can happen even if we adopt your proposed policy > and everyone follows it to the letter, in the following situation: > > * I upgrade to woody, new X, and upgrade all the app-defaults-containing > packages. > * I then decide I like potato's version of one of those packages better, > and downgrade to it. Nothing prevents me from doing this after all. Hrm. Well, I was kinda hoping no one would do this. A little unrealistic, perhaps. > I also have a bit of an alternate idea, which goes like this. You > mention a few things: [...] > Ok, so all packages that have app-defaults files link to the X > libraries. I assume one of those libraries is responsible for reading > the app-defaults file[1]. And some horrible thing you haven't specified will > happen if an app cannot read its app-defaults file. Some programs, like the new xf86cfg, don't work at all (it just crashes back to the prompt). xterm staggers a bit but is usable. xcalc doesn't know how to place its widgets. If this breaks stuff even in other parts of the XFree86 distribution, I have pretty dire expectations about third-party clients. > So, why not hack X[2]? Make the library look in /etc/X11/app-defaults, then > in the old location. Make policy that states that packages depending on the > X 4 version of that library should use /etc/X11/app-defaults. Such a > package would break if it were installed onto a system with an older > xlib, but the dependancy will prevent that. Upgrades and downgrades will > work without any messy difficulties. You can remove the xlib hack in a > release or two. I was hoping to avoid this, but developing consensus on -policy seems to be that I should do this. Sigh. > [1] Verified, that is lib/Xt/Initialize.c, XtScreenDatabase() I'm not sure it's not the only one. It's not just Xt-using apps that read app-defaults, IIRC. I think the Xrm* functions may deal with it as well. I'll check this out. > [2] And yeah I looked at the code and it looks doable. Insert a check for > a file in the old directory around line 534 of the file in [1]. Thanks. -- G. Branden Robinson |You live and learn. Debian GNU/Linux|Or you don't live long. [EMAIL PROTECTED] |-- Robert Heinlein http://www.debian.org/~branden/ | PGP signature
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 10:27:55AM +0200, Sven LUTHER wrote: > Ok, about the X server, but will we maintain two sets of libraries also, or go > with the 4.0.1 ones ? Just the 4.0.1 ones. > Also how did you solve the XF86Config conflict ? since 4.x a,d 3.x XF86Config > files are not compatible. The XF86Config file is not a conffile. Read the XF86Config 4.x manpage, and you'll see there is no conflict. > Sure, ... bad wording perhaps, but i did think more about changing app-default > location and other similar stuff, since in the long run, the apps should > install it in the new location, you will have to fix the 3.3.6 server to use > the new location, Uh. Remember, the X Window System is network-transparent. The X server itself does not read or deal with app-defaults files in any way. What exactly do you do as a developer for XFree86, again? You seem to have difficulty with a few really fundamental concepts of its operation. > that is the 3.3.6 xfree-common should do the same trick as > the 4.0.1 one ? That is not necessary. > I thought 4.0.1 moved to X11R6.4, did only 1 library change version number > when going from X11R6.3 to X11R6.4 ? Looks that way. > I confirm, i run most X clients on a hand installed 4.0.1+ server, without > major problems. Like said the only problems encountered where with the xterm > color stuff when i didn't do a full XF4 install and some keymap problems (well > surely because default 4.x XF86Config came with a japanese keyboard > configuration, and i didn't spot it :((() Well, there are lots of possible ways things can go wrong. What you describe doesn't sound like a server problem to me. > where can i get your brand new XF4 packages ? i would like to download them > tommorow, build and try them out in my offline home box, and then report back > to you about it. Well, before you do that, please read /usr/doc/xfree86-common/FAQ.gz and get your head around the differences between the X server, X clients, and X libraries; your mails are not telling me you have them quite figured out, and I need testers who can do better than say "it's broken", but who can make a reasonable guess as to why. To do that, you have to understand a little bit about how X works. -- G. Branden Robinson |Communism is just one step on the long Debian GNU/Linux|road from capitalism to capitalism. [EMAIL PROTECTED] |-- Russian saying http://www.debian.org/~branden/ | PGP signature
Re: XFree86 4.0.1 and app-defaults
On Thu, 27 Jul 2000, Branden Robinson wrote: > It has to do with app-defaults files. Current Debian policy says > these can't be conffiles, so they go in > /usr/X11R6/lib/X11/app-defaults. > Well, upstream has changed things, and it putting them in > /etc/X11/app-defaults. Rather than buck this trend, I think we > should roll with it. Agreed. > What's worse is that /usr/X11R6/lib/X11/app-defaults is going to > need to become a symbolic link to /etc/X11/app-defaults, Here I don't agree. Why do we need a symlink, isn't it possible to keep both directories in parallel until the transition is complete? IIRC there are some environment variables (XAPPLRESDIR, XFILESEARCHPATH, XUSERFILESEARCHPATH,...) which tell the applications (and the xlib) where to look for app-defaults files. Isn't it possible to extend this mechanism in the xlib to search for an app-defaults file in /etc/X11/app-defaults first and if it doesn't find the file there, to search in /usr/X11R6/lib/X11/app-defaults? This technique would avoid the symlink trouble and would lead to a smooth migration. Except this lintian has to be extended to mark files in /usr/X11R6/lib/X11/app-defaults as errors and check whether /etc/X11/app-defaults/* are conffiles. Additionally the imake stuff should be adapted (I propose that XFree86 4.* already did so) to install app-defaults files in /etc/X11/app-defaults. So I don't see any need to move the app-defaults files of old packages and to create any symlinks. Okay, I see, that it is more work for you, because you have to implement this fallback mechanism into the xlib, but this way sounds much more solid to me than the symlink hack. Tscho Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * pgplpfvgOGYVf.pgp Description: PGP signature
Re: XFree86 4.0.1 and app-defaults
>> Branden Robinson <[EMAIL PROTECTED]> writes: [ regarding the status of the new Xserver ] > I expect it to be widely used, especially by people with recent hardware. I'm two minds about this. Yes, the architecture of the new X server is better. What I'm getting out of it is not. I have to sit down, reread docs, and figure out why, but the 16 bpp mode suffers from severe dithering on my hardware (G400). The much promotioned OpenGL support is still in development, which is the other reason I annoyed you so much about the .diff.gz -- I want to persue automatic building out of cvs of the relevant stuff for Debian. On that respect, utah-glx is still faster/easier to install/better looking/whatever. > Some of the 3.x series X servers will continue to be provided to support > hardware that 4.0 doesn't yet. And utah-glx (doesn't work with 4.0 servers) Thanks, Marcelo
Re: XFree86 4.0.1 and app-defaults
[ Talking about /usr/X11R6/lib/X11/app-defaults directory, which is planned to be a symlink to /etc/X11/app-defaults. ] > *HOWEVER*, dpkg's databases will contain bogus information about the > locations of files installed to that directory. So it is imperative that > these packages have new versions that will clean up the mess. Hmm. What bogus information will dpkg have? If my package foo installs an app-defaults file in the old directory now, after the directory is forcibly moved to /etc, dpkg will still think the file is /usr/X11R6/lib/X11/app-defaults/foo. dpkg follows symlinks, so even if I release a new version of my package that contravenes the proposed policy and still uses /usr/X11R6/lib/X11/app-defaults/foo, dpkg will replace that file without complaint. I can only identify two problems: * dpkg -S /etc/X11/app-defaults/foo will fail. * If some other package also contains an app-defaults file named foo, but puts in in /etc/X11/app-defaults/foo, strange things could happen if both packages are installed. Note that both problems can happen even if we adopt your proposed policy and everyone follows it to the letter, in the following situation: * I upgrade to woody, new X, and upgrade all the app-defaults-containing packages. * I then decide I like potato's version of one of those packages better, and downgrade to it. Nothing prevents me from doing this after all. I also have a bit of an alternate idea, which goes like this. You mention a few things: > Things will break spectacularly if that symlink doesn't exist. > + All packages that ship stuff in /usr/X11R6/lib/X11/app-defaults are X > clients. > + X clients depends on the X libraries. (Exceptions to this in the Debian > system do not exist in practice, unless we have any programs written in > Common Lisp and using CLX. I don't think we do.) Ok, so all packages that have app-defaults files link to the X libraries. I assume one of those libraries is responsible for reading the app-defaults file[1]. And some horrible thing you haven't specified will happen if an app cannot read its app-defaults file. So, why not hack X[2]? Make the library look in /etc/X11/app-defaults, then in the old location. Make policy that states that packages depending on the X 4 version of that library should use /etc/X11/app-defaults. Such a package would break if it were installed onto a system with an older xlib, but the dependancy will prevent that. Upgrades and downgrades will work without any messy difficulties. You can remove the xlib hack in a release or two. -- see shy jo [1] Verified, that is lib/Xt/Initialize.c, XtScreenDatabase() [2] And yeah I looked at the code and it looks doable. Insert a check for a file in the old directory around line 534 of the file in [1].
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 12:57:10PM +0200, Sven LUTHER wrote: > I remember running XF4 on top of amifb way back in the 3.9.16 days, i suppose > this will work nicely on m68k also, if you can build the kernel. amifb is not the only fb available for m68k. It might work for me, but I can not see it, since my ami mon has gone bust. Will you donate me an old mon, or better a flickerfixer so I can test that? AFAIK amifb is the _only_ fb for m68k which is working in X4.0, or maybe there is one more. Youre the xfree developer, not me. Ill try to improve the kernel driver for my virge, but I will not work on xfree drivers in the foreseable future. > > Fine, but what if the 4.0 libraries can not be built on m68k (I would not > > wonder if), will the 3.3.6 libaries be still around for us? > > Did you try it ? Are source packages available? That was not my question, I do not intend to build anything now, I was just asking a technical question. Again: will xfree 3.3.6 and 4.0 be able to exist simultaneously in the archive? X4.0 would need to have a new package name then I think. This is the plan, right? I only want a confirmation for that... if not, we might declare the m68k port dead for woody. > How long do you think i would need to build XF4 on a 25MHz 68040 ? No idea, are source packages available? Oh, I said that before, all I can say is, xfree 3.3.6 takes about 24h on [EMAIL PROTECTED], 4.0 will be about half the time, since IIRC libc5 packages will be dropped. No idea what else wil be built to make it use more time... > mach64 should be supported under XF4, or will soonely, i think, anyway, you > could always run the fbdev Xserver without accels. I could also run in VGA mode or buy a new graphics card. But again, that was not my question... Christian
Re: XFree86 4.0.1 and app-defaults
On Thu, 27 Jul 2000, Branden Robinson wrote: > It has to do with app-defaults files. Current Debian policy says > these can't be conffiles, so they go in > /usr/X11R6/lib/X11/app-defaults. > Well, upstream has changed things, and it putting them in > /etc/X11/app-defaults. Rather than buck this trend, I think we > should roll with it. Agreed. > What's worse is that /usr/X11R6/lib/X11/app-defaults is going to > need to become a symbolic link to /etc/X11/app-defaults, Here I don't agree. Why do we need a symlink, isn't it possible to keep both directories in parallel until the transition is complete? IIRC there are some environment variables (XAPPLRESDIR, XFILESEARCHPATH, XUSERFILESEARCHPATH,...) which tell the applications (and the xlib) where to look for app-defaults files. Isn't it possible to extend this mechanism in the xlib to search for an app-defaults file in /etc/X11/app-defaults first and if it doesn't find the file there, to search in /usr/X11R6/lib/X11/app-defaults? This technique would avoid the symlink trouble and would lead to a smooth migration. Except this lintian has to be extended to mark files in /usr/X11R6/lib/X11/app-defaults as errors and check whether /etc/X11/app-defaults/* are conffiles. Additionally the imake stuff should be adapted (I propose that XFree86 4.* already did so) to install app-defaults files in /etc/X11/app-defaults. So I don't see any need to move the app-defaults files of old packages and to create any symlinks. Okay, I see, that it is more work for you, because you have to implement this fallback mechanism into the xlib, but this way sounds much more solid to me than the symlink hack. Tscho Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP signature
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 10:59:11AM +0200, Christian T. Steigies wrote: > On Thu, Jul 27, 2000 at 03:00:04AM -0500, Branden Robinson wrote: > > On Thu, Jul 27, 2000 at 07:59:03AM +0200, Sven LUTHER wrote: > > > I think what you propose is a good solution. I suppose 4.0.1 will be > > > woody's > > > primary X server, will it not ? > > > > I expect it to be widely used, especially by people with recent hardware. > > > > Some of the 3.x series X servers will continue to be provided to support > > hardware that 4.0 doesn't yet. The package names and filenames names do > > not overlap, so /etc/X11/Xserver will continue to be used as we have for > > years. The 3.x servers should work fine with the 4.x series clients and > > libraries, though of course those servers are missing the features that are > > receiving so much attention in 4.0. That will include the enhanced font > > support; users of 3.x server may want to look into using the 4.x version of > > xfs. > Ok, I am not an xfree86 developer, I have to ask the m68k question. AFAIK > the xfree drivers for m68k are by far not ready, or only a handful yet. With > this we (m68k) could install xfree4.0 libraries and run the 3.3.6 servers? I remember running XF4 on top of amifb way back in the 3.9.16 days, i suppose this will work nicely on m68k also, if you can build the kernel. > Fine, but what if the 4.0 libraries can not be built on m68k (I would not > wonder if), will the 3.3.6 libaries be still around for us? Did you try it ? best guess would be to try it out, and report any problem so they can get fixed. I would do it but have no space on my apus box for a m68k system. maybe i will erase my apus system after the potato release and let the box build XF4 for me. How long do you think i would need to build XF4 on a 25MHz 68040 ? > Will the complete packages of 3.3.6 and 4.0+ exist in parallel, for those > with m68k and other not so recent hardware (like my mach64)? Might not be mach64 should be supported under XF4, or will soonely, i think, anyway, you could always run the fbdev Xserver without accels. Friendly, Sven LUTHER
Re: XFree86 4.0.1 and app-defaults
>> Branden Robinson <[EMAIL PROTECTED]> writes: [ regarding the status of the new Xserver ] > I expect it to be widely used, especially by people with recent hardware. I'm two minds about this. Yes, the architecture of the new X server is better. What I'm getting out of it is not. I have to sit down, reread docs, and figure out why, but the 16 bpp mode suffers from severe dithering on my hardware (G400). The much promotioned OpenGL support is still in development, which is the other reason I annoyed you so much about the .diff.gz -- I want to persue automatic building out of cvs of the relevant stuff for Debian. On that respect, utah-glx is still faster/easier to install/better looking/whatever. > Some of the 3.x series X servers will continue to be provided to support > hardware that 4.0 doesn't yet. And utah-glx (doesn't work with 4.0 servers) Thanks, Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 03:00:04AM -0500, Branden Robinson wrote: > On Thu, Jul 27, 2000 at 07:59:03AM +0200, Sven LUTHER wrote: > > I think what you propose is a good solution. I suppose 4.0.1 will be woody's > > primary X server, will it not ? > > I expect it to be widely used, especially by people with recent hardware. > > Some of the 3.x series X servers will continue to be provided to support > hardware that 4.0 doesn't yet. The package names and filenames names do > not overlap, so /etc/X11/Xserver will continue to be used as we have for > years. The 3.x servers should work fine with the 4.x series clients and > libraries, though of course those servers are missing the features that are > receiving so much attention in 4.0. That will include the enhanced font > support; users of 3.x server may want to look into using the 4.x version of > xfs. Ok, I am not an xfree86 developer, I have to ask the m68k question. AFAIK the xfree drivers for m68k are by far not ready, or only a handful yet. With this we (m68k) could install xfree4.0 libraries and run the 3.3.6 servers? Fine, but what if the 4.0 libraries can not be built on m68k (I would not wonder if), will the 3.3.6 libaries be still around for us? Will the complete packages of 3.3.6 and 4.0+ exist in parallel, for those with m68k and other not so recent hardware (like my mach64)? Might not be necessary, but I have a better feeling, if I ran all packages from one version. Sorry if you answered that allready in your first message, but with my historic view, I did not see a quick answer to that. Christian
Re: XFree86 4.0.1 and app-defaults
[ Talking about /usr/X11R6/lib/X11/app-defaults directory, which is planned to be a symlink to /etc/X11/app-defaults. ] > *HOWEVER*, dpkg's databases will contain bogus information about the > locations of files installed to that directory. So it is imperative that > these packages have new versions that will clean up the mess. Hmm. What bogus information will dpkg have? If my package foo installs an app-defaults file in the old directory now, after the directory is forcibly moved to /etc, dpkg will still think the file is /usr/X11R6/lib/X11/app-defaults/foo. dpkg follows symlinks, so even if I release a new version of my package that contravenes the proposed policy and still uses /usr/X11R6/lib/X11/app-defaults/foo, dpkg will replace that file without complaint. I can only identify two problems: * dpkg -S /etc/X11/app-defaults/foo will fail. * If some other package also contains an app-defaults file named foo, but puts in in /etc/X11/app-defaults/foo, strange things could happen if both packages are installed. Note that both problems can happen even if we adopt your proposed policy and everyone follows it to the letter, in the following situation: * I upgrade to woody, new X, and upgrade all the app-defaults-containing packages. * I then decide I like potato's version of one of those packages better, and downgrade to it. Nothing prevents me from doing this after all. I also have a bit of an alternate idea, which goes like this. You mention a few things: > Things will break spectacularly if that symlink doesn't exist. > + All packages that ship stuff in /usr/X11R6/lib/X11/app-defaults are X > clients. > + X clients depends on the X libraries. (Exceptions to this in the Debian > system do not exist in practice, unless we have any programs written in > Common Lisp and using CLX. I don't think we do.) Ok, so all packages that have app-defaults files link to the X libraries. I assume one of those libraries is responsible for reading the app-defaults file[1]. And some horrible thing you haven't specified will happen if an app cannot read its app-defaults file. So, why not hack X[2]? Make the library look in /etc/X11/app-defaults, then in the old location. Make policy that states that packages depending on the X 4 version of that library should use /etc/X11/app-defaults. Such a package would break if it were installed onto a system with an older xlib, but the dependancy will prevent that. Upgrades and downgrades will work without any messy difficulties. You can remove the xlib hack in a release or two. -- see shy jo [1] Verified, that is lib/Xt/Initialize.c, XtScreenDatabase() [2] And yeah I looked at the code and it looks doable. Insert a check for a file in the old directory around line 534 of the file in [1]. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 12:57:10PM +0200, Sven LUTHER wrote: > I remember running XF4 on top of amifb way back in the 3.9.16 days, i suppose > this will work nicely on m68k also, if you can build the kernel. amifb is not the only fb available for m68k. It might work for me, but I can not see it, since my ami mon has gone bust. Will you donate me an old mon, or better a flickerfixer so I can test that? AFAIK amifb is the _only_ fb for m68k which is working in X4.0, or maybe there is one more. Youre the xfree developer, not me. Ill try to improve the kernel driver for my virge, but I will not work on xfree drivers in the foreseable future. > > Fine, but what if the 4.0 libraries can not be built on m68k (I would not > > wonder if), will the 3.3.6 libaries be still around for us? > > Did you try it ? Are source packages available? That was not my question, I do not intend to build anything now, I was just asking a technical question. Again: will xfree 3.3.6 and 4.0 be able to exist simultaneously in the archive? X4.0 would need to have a new package name then I think. This is the plan, right? I only want a confirmation for that... if not, we might declare the m68k port dead for woody. > How long do you think i would need to build XF4 on a 25MHz 68040 ? No idea, are source packages available? Oh, I said that before, all I can say is, xfree 3.3.6 takes about 24h on 060@50, 4.0 will be about half the time, since IIRC libc5 packages will be dropped. No idea what else wil be built to make it use more time... > mach64 should be supported under XF4, or will soonely, i think, anyway, you > could always run the fbdev Xserver without accels. I could also run in VGA mode or buy a new graphics card. But again, that was not my question... Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 10:59:11AM +0200, Christian T. Steigies wrote: > On Thu, Jul 27, 2000 at 03:00:04AM -0500, Branden Robinson wrote: > > On Thu, Jul 27, 2000 at 07:59:03AM +0200, Sven LUTHER wrote: > > > I think what you propose is a good solution. I suppose 4.0.1 will be woody's > > > primary X server, will it not ? > > > > I expect it to be widely used, especially by people with recent hardware. > > > > Some of the 3.x series X servers will continue to be provided to support > > hardware that 4.0 doesn't yet. The package names and filenames names do > > not overlap, so /etc/X11/Xserver will continue to be used as we have for > > years. The 3.x servers should work fine with the 4.x series clients and > > libraries, though of course those servers are missing the features that are > > receiving so much attention in 4.0. That will include the enhanced font > > support; users of 3.x server may want to look into using the 4.x version of > > xfs. > Ok, I am not an xfree86 developer, I have to ask the m68k question. AFAIK > the xfree drivers for m68k are by far not ready, or only a handful yet. With > this we (m68k) could install xfree4.0 libraries and run the 3.3.6 servers? I remember running XF4 on top of amifb way back in the 3.9.16 days, i suppose this will work nicely on m68k also, if you can build the kernel. > Fine, but what if the 4.0 libraries can not be built on m68k (I would not > wonder if), will the 3.3.6 libaries be still around for us? Did you try it ? best guess would be to try it out, and report any problem so they can get fixed. I would do it but have no space on my apus box for a m68k system. maybe i will erase my apus system after the potato release and let the box build XF4 for me. How long do you think i would need to build XF4 on a 25MHz 68040 ? > Will the complete packages of 3.3.6 and 4.0+ exist in parallel, for those > with m68k and other not so recent hardware (like my mach64)? Might not be mach64 should be supported under XF4, or will soonely, i think, anyway, you could always run the fbdev Xserver without accels. Friendly, Sven LUTHER -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 03:00:04AM -0500, Branden Robinson wrote: > On Thu, Jul 27, 2000 at 07:59:03AM +0200, Sven LUTHER wrote: > > I think what you propose is a good solution. I suppose 4.0.1 will be woody's > > primary X server, will it not ? > > I expect it to be widely used, especially by people with recent hardware. > > Some of the 3.x series X servers will continue to be provided to support > hardware that 4.0 doesn't yet. The package names and filenames names do > not overlap, so /etc/X11/Xserver will continue to be used as we have for > years. The 3.x servers should work fine with the 4.x series clients and > libraries, though of course those servers are missing the features that are > receiving so much attention in 4.0. That will include the enhanced font > support; users of 3.x server may want to look into using the 4.x version of > xfs. Ok, I am not an xfree86 developer, I have to ask the m68k question. AFAIK the xfree drivers for m68k are by far not ready, or only a handful yet. With this we (m68k) could install xfree4.0 libraries and run the 3.3.6 servers? Fine, but what if the 4.0 libraries can not be built on m68k (I would not wonder if), will the 3.3.6 libaries be still around for us? Will the complete packages of 3.3.6 and 4.0+ exist in parallel, for those with m68k and other not so recent hardware (like my mach64)? Might not be necessary, but I have a better feeling, if I ran all packages from one version. Sorry if you answered that allready in your first message, but with my historic view, I did not see a quick answer to that. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 03:00:04AM -0500, Branden Robinson wrote: > On Thu, Jul 27, 2000 at 07:59:03AM +0200, Sven LUTHER wrote: > > I think what you propose is a good solution. I suppose 4.0.1 will be woody's > > primary X server, will it not ? > > I expect it to be widely used, especially by people with recent hardware. > > Some of the 3.x series X servers will continue to be provided to support > hardware that 4.0 doesn't yet. The package names and filenames names do > not overlap, so /etc/X11/Xserver will continue to be used as we have for > years. The 3.x servers should work fine with the 4.x series clients and > libraries, though of course those servers are missing the features that are > receiving so much attention in 4.0. That will include the enhanced font > support; users of 3.x server may want to look into using the 4.x version of > xfs. Ok, about the X server, but will we maintain two sets of libraries also, or go with the 4.0.1 ones ? Also how did you solve the XF86Config conflict ? since 4.x a,d 3.x XF86Config files are not compatible. > > or else each package will have to be compiled differently for XF3.3.6 and > > XF4.0.1. > > Uh, as an XFree86 developer I hope you'd recall that one doesn't compile X > clients against X servers. One compiles clients against the X libraries. > The xlib6g package will be provided by the XFree86 4.x source packages. > Furthermore, the wire protocol itself has not changed (it's still X Version > 11), so communications between the clients and servers will not change. Sure, ... bad wording perhaps, but i did think more about changing app-default location and other similar stuff, since in the long run, the apps should install it in the new location, you will have to fix the 3.3.6 server to use the new location,that is the 3.3.6 xfree-common should do the same trick as the 4.0.1 one ? > Two shared libraries increased their version numbers with XFree86 4.0; > libXext (a bundle of common protocol extensions), which moved from 6.3 to > 6.4; this is part and parcel of upstream's transition to X11R6.4 from > X11R6.3. > libXaw is now available in two versions; 6.1, which is the same version > as is presently available, and also a new 7.0 version which was written > by one of the XFree86 developers and, among other things, has a greatly > improved text widget, and is themeable. The Athena widget library has, > consequently, been split out of the xlib6g package. I thought 4.0.1 moved to X11R6.4, did only 1 library change version number when going from X11R6.3 to X11R6.4 ? > In any case, I reiterate that the variety of available servers should have > little or no impact on the clients. I do not know what has changed in > libXext, which of course has a server-side implementation, but the minor > version number increase does not imply to me an incompatible change. If > I'm wrong, I guess we'll find out soon enough. I confirm, i run most X clients on a hand installed 4.0.1+ server, without major problems. Like said the only problems encountered where with the xterm color stuff when i didn't do a full XF4 install and some keymap problems (well surely because default 4.x XF86Config came with a japanese keyboard configuration, and i didn't spot it :((() > > Also, please remeber to have lintian check about app-default stuff when you > > release the XF4 packages. > > Well, I don't maintain lintian, so I can only ask for such a thing. I know that, just fill the bug against lintian. but in my experience this kind of things take time, but mayeb since X is a major package, it will get included quicker. > > Best way to make all developper of package aware of the problem (well > > sure you could fill bugs to all package using app-defaults also, with a > > nice bug reporting script doing the job) ... > > I'll see what develops. :))) BTW, ... where can i get your brand new XF4 packages ? i would like to download them tommorow, build and try them out in my offline home box, and then report back to you about it. Friendly, Svne LUTHER
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 07:59:03AM +0200, Sven LUTHER wrote: > I think what you propose is a good solution. I suppose 4.0.1 will be woody's > primary X server, will it not ? I expect it to be widely used, especially by people with recent hardware. Some of the 3.x series X servers will continue to be provided to support hardware that 4.0 doesn't yet. The package names and filenames names do not overlap, so /etc/X11/Xserver will continue to be used as we have for years. The 3.x servers should work fine with the 4.x series clients and libraries, though of course those servers are missing the features that are receiving so much attention in 4.0. That will include the enhanced font support; users of 3.x server may want to look into using the 4.x version of xfs. > or else each package will have to be compiled differently for XF3.3.6 and > XF4.0.1. Uh, as an XFree86 developer I hope you'd recall that one doesn't compile X clients against X servers. One compiles clients against the X libraries. The xlib6g package will be provided by the XFree86 4.x source packages. Furthermore, the wire protocol itself has not changed (it's still X Version 11), so communications between the clients and servers will not change. Two shared libraries increased their version numbers with XFree86 4.0; libXext (a bundle of common protocol extensions), which moved from 6.3 to 6.4; this is part and parcel of upstream's transition to X11R6.4 from X11R6.3. libXaw is now available in two versions; 6.1, which is the same version as is presently available, and also a new 7.0 version which was written by one of the XFree86 developers and, among other things, has a greatly improved text widget, and is themeable. The Athena widget library has, consequently, been split out of the xlib6g package. In any case, I reiterate that the variety of available servers should have little or no impact on the clients. I do not know what has changed in libXext, which of course has a server-side implementation, but the minor version number increase does not imply to me an incompatible change. If I'm wrong, I guess we'll find out soon enough. > Also, please remeber to have lintian check about app-default stuff when you > release the XF4 packages. Well, I don't maintain lintian, so I can only ask for such a thing. > Best way to make all developper of package aware of the problem (well > sure you could fill bugs to all package using app-defaults also, with a > nice bug reporting script doing the job) ... I'll see what develops. -- G. Branden Robinson | If a man ate a pound of pasta and a Debian GNU/Linux| pound of antipasto, would they cancel [EMAIL PROTECTED] | out, leaving him still hungry? http://www.debian.org/~branden/ | -- Scott Adams pgp9kGOT6tFWY.pgp Description: PGP signature
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 03:00:04AM -0500, Branden Robinson wrote: > On Thu, Jul 27, 2000 at 07:59:03AM +0200, Sven LUTHER wrote: > > I think what you propose is a good solution. I suppose 4.0.1 will be woody's > > primary X server, will it not ? > > I expect it to be widely used, especially by people with recent hardware. > > Some of the 3.x series X servers will continue to be provided to support > hardware that 4.0 doesn't yet. The package names and filenames names do > not overlap, so /etc/X11/Xserver will continue to be used as we have for > years. The 3.x servers should work fine with the 4.x series clients and > libraries, though of course those servers are missing the features that are > receiving so much attention in 4.0. That will include the enhanced font > support; users of 3.x server may want to look into using the 4.x version of > xfs. Ok, about the X server, but will we maintain two sets of libraries also, or go with the 4.0.1 ones ? Also how did you solve the XF86Config conflict ? since 4.x a,d 3.x XF86Config files are not compatible. > > or else each package will have to be compiled differently for XF3.3.6 and > > XF4.0.1. > > Uh, as an XFree86 developer I hope you'd recall that one doesn't compile X > clients against X servers. One compiles clients against the X libraries. > The xlib6g package will be provided by the XFree86 4.x source packages. > Furthermore, the wire protocol itself has not changed (it's still X Version > 11), so communications between the clients and servers will not change. Sure, ... bad wording perhaps, but i did think more about changing app-default location and other similar stuff, since in the long run, the apps should install it in the new location, you will have to fix the 3.3.6 server to use the new location,that is the 3.3.6 xfree-common should do the same trick as the 4.0.1 one ? > Two shared libraries increased their version numbers with XFree86 4.0; > libXext (a bundle of common protocol extensions), which moved from 6.3 to > 6.4; this is part and parcel of upstream's transition to X11R6.4 from > X11R6.3. > libXaw is now available in two versions; 6.1, which is the same version > as is presently available, and also a new 7.0 version which was written > by one of the XFree86 developers and, among other things, has a greatly > improved text widget, and is themeable. The Athena widget library has, > consequently, been split out of the xlib6g package. I thought 4.0.1 moved to X11R6.4, did only 1 library change version number when going from X11R6.3 to X11R6.4 ? > In any case, I reiterate that the variety of available servers should have > little or no impact on the clients. I do not know what has changed in > libXext, which of course has a server-side implementation, but the minor > version number increase does not imply to me an incompatible change. If > I'm wrong, I guess we'll find out soon enough. I confirm, i run most X clients on a hand installed 4.0.1+ server, without major problems. Like said the only problems encountered where with the xterm color stuff when i didn't do a full XF4 install and some keymap problems (well surely because default 4.x XF86Config came with a japanese keyboard configuration, and i didn't spot it :((() > > Also, please remeber to have lintian check about app-default stuff when you > > release the XF4 packages. > > Well, I don't maintain lintian, so I can only ask for such a thing. I know that, just fill the bug against lintian. but in my experience this kind of things take time, but mayeb since X is a major package, it will get included quicker. > > Best way to make all developper of package aware of the problem (well > > sure you could fill bugs to all package using app-defaults also, with a > > nice bug reporting script doing the job) ... > > I'll see what develops. :))) BTW, ... where can i get your brand new XF4 packages ? i would like to download them tommorow, build and try them out in my offline home box, and then report back to you about it. Friendly, Svne LUTHER -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 07:59:03AM +0200, Sven LUTHER wrote: > I think what you propose is a good solution. I suppose 4.0.1 will be woody's > primary X server, will it not ? I expect it to be widely used, especially by people with recent hardware. Some of the 3.x series X servers will continue to be provided to support hardware that 4.0 doesn't yet. The package names and filenames names do not overlap, so /etc/X11/Xserver will continue to be used as we have for years. The 3.x servers should work fine with the 4.x series clients and libraries, though of course those servers are missing the features that are receiving so much attention in 4.0. That will include the enhanced font support; users of 3.x server may want to look into using the 4.x version of xfs. > or else each package will have to be compiled differently for XF3.3.6 and > XF4.0.1. Uh, as an XFree86 developer I hope you'd recall that one doesn't compile X clients against X servers. One compiles clients against the X libraries. The xlib6g package will be provided by the XFree86 4.x source packages. Furthermore, the wire protocol itself has not changed (it's still X Version 11), so communications between the clients and servers will not change. Two shared libraries increased their version numbers with XFree86 4.0; libXext (a bundle of common protocol extensions), which moved from 6.3 to 6.4; this is part and parcel of upstream's transition to X11R6.4 from X11R6.3. libXaw is now available in two versions; 6.1, which is the same version as is presently available, and also a new 7.0 version which was written by one of the XFree86 developers and, among other things, has a greatly improved text widget, and is themeable. The Athena widget library has, consequently, been split out of the xlib6g package. In any case, I reiterate that the variety of available servers should have little or no impact on the clients. I do not know what has changed in libXext, which of course has a server-side implementation, but the minor version number increase does not imply to me an incompatible change. If I'm wrong, I guess we'll find out soon enough. > Also, please remeber to have lintian check about app-default stuff when you > release the XF4 packages. Well, I don't maintain lintian, so I can only ask for such a thing. > Best way to make all developper of package aware of the problem (well > sure you could fill bugs to all package using app-defaults also, with a > nice bug reporting script doing the job) ... I'll see what develops. -- G. Branden Robinson | If a man ate a pound of pasta and a Debian GNU/Linux| pound of antipasto, would they cancel [EMAIL PROTECTED] | out, leaving him still hungry? http://www.debian.org/~branden/ | -- Scott Adams PGP signature
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 12:21:54AM -0500, Branden Robinson wrote: > Hi folks. > > As some of you know, highly unstable and experimental 4.0.1 .debs were > produced on Friday and made available to a few people for testing. These > things were way broken, but not as badly as I feared. I got some valuable > feedback, made some fixes, and am preparing for a real Phase 1 release as I > write this. > > But XFree86 4 has thickened the plot in a way I didn't foresee. > > It has to do with app-defaults files. Current Debian policy says these > can't be conffiles, so they go in /usr/X11R6/lib/X11/app-defaults. > > Well, upstream has changed things, and it putting them in > /etc/X11/app-defaults. Rather than buck this trend, I think we should roll > with it. > > However, this means changing Debian policy. That part's not hard. > (Unless the -policy group wants to prove me wrong on this point.) > > What's worse is that /usr/X11R6/lib/X11/app-defaults is going to need to > become a symbolic link to /etc/X11/app-defaults, and because dpkg does not > clobber directories by overwriting them with symlinks (rather, it just > fails to make the symlink), a *LOT* of packages are going to have to change > the way they do things. So, the current app-defaults policy is going to be > taken out back and shot. > > Things will break spectacularly if that symlink doesn't exist. So it HAS > to be there. So here's what I'm going to do. > > We all know there is a "root" XFree86 package that all other X Window > System packages depend on, and that is xfree86-common. In the preinst of > this package will be something like the following logic: > > if [ ! -L /usr/X11R6/lib/X11/app-defaults ]; then > # uh oh, we need to move this > mv /usr/X11R6/lib/X11/app-defaults /usr/X11R6/lib/X11/app-defaults.MOVING > ln -s /etc/X11/app-defaults /usr/X11R6/lib/X11/app-defaults > mv /usr/X11R6/lib/X11/app-defaults.MOVING/* /etc/X11/app-defaults > rmdir /usr/X11R6/lib/X11/app-defaults.MOVING > fi > > dpkg-divert doesn't make a lot of sense here because the files will be > resolvable using same path they were before --- AFTER the preinst has done > its work. Since only one preinst runs at a time, and this preinst handles > the whole migration, this is an atomic operation from the package system's > perspective. > > *HOWEVER*, dpkg's databases will contain bogus information about the > locations of files installed to that directory. So it is imperative that > these packages have new versions that will clean up the mess. > > All these new packages have to do is ship those app-defaults files in > /etc/X11/app-defaults instead. I suggest marking them as conffiles as > well, but this is ultimately up to the package maintainer's discretion. > > So here is what I suggest. Packages that currently ship app-defaults > files MUST, when they are built against xlib6g 4.0.1, implement this > transition. This will make everything as clean and neat as it can be > because: I think what you propose is a good solution. I suppose 4.0.1 will be woody's primary X server, will it not ? or else each package will have to be compiled differently for XF3.3.6 and XF4.0.1. Also, please remeber to have lintian check about app-default stuff when you release the XF4 packages. Best way to make all developper of package aware of the problem (well sure you could fill bugs to all package using app-defaults also, with a nice bug reporting script doing the job) ... Friendly, Svne LUTHER
Re: XFree86 4.0.1 and app-defaults
On Thu, Jul 27, 2000 at 12:21:54AM -0500, Branden Robinson wrote: > Hi folks. > > As some of you know, highly unstable and experimental 4.0.1 .debs were > produced on Friday and made available to a few people for testing. These > things were way broken, but not as badly as I feared. I got some valuable > feedback, made some fixes, and am preparing for a real Phase 1 release as I > write this. > > But XFree86 4 has thickened the plot in a way I didn't foresee. > > It has to do with app-defaults files. Current Debian policy says these > can't be conffiles, so they go in /usr/X11R6/lib/X11/app-defaults. > > Well, upstream has changed things, and it putting them in > /etc/X11/app-defaults. Rather than buck this trend, I think we should roll > with it. > > However, this means changing Debian policy. That part's not hard. > (Unless the -policy group wants to prove me wrong on this point.) > > What's worse is that /usr/X11R6/lib/X11/app-defaults is going to need to > become a symbolic link to /etc/X11/app-defaults, and because dpkg does not > clobber directories by overwriting them with symlinks (rather, it just > fails to make the symlink), a *LOT* of packages are going to have to change > the way they do things. So, the current app-defaults policy is going to be > taken out back and shot. > > Things will break spectacularly if that symlink doesn't exist. So it HAS > to be there. So here's what I'm going to do. > > We all know there is a "root" XFree86 package that all other X Window > System packages depend on, and that is xfree86-common. In the preinst of > this package will be something like the following logic: > > if [ ! -L /usr/X11R6/lib/X11/app-defaults ]; then > # uh oh, we need to move this > mv /usr/X11R6/lib/X11/app-defaults /usr/X11R6/lib/X11/app-defaults.MOVING > ln -s /etc/X11/app-defaults /usr/X11R6/lib/X11/app-defaults > mv /usr/X11R6/lib/X11/app-defaults.MOVING/* /etc/X11/app-defaults > rmdir /usr/X11R6/lib/X11/app-defaults.MOVING > fi > > dpkg-divert doesn't make a lot of sense here because the files will be > resolvable using same path they were before --- AFTER the preinst has done > its work. Since only one preinst runs at a time, and this preinst handles > the whole migration, this is an atomic operation from the package system's > perspective. > > *HOWEVER*, dpkg's databases will contain bogus information about the > locations of files installed to that directory. So it is imperative that > these packages have new versions that will clean up the mess. > > All these new packages have to do is ship those app-defaults files in > /etc/X11/app-defaults instead. I suggest marking them as conffiles as > well, but this is ultimately up to the package maintainer's discretion. > > So here is what I suggest. Packages that currently ship app-defaults > files MUST, when they are built against xlib6g 4.0.1, implement this > transition. This will make everything as clean and neat as it can be > because: I think what you propose is a good solution. I suppose 4.0.1 will be woody's primary X server, will it not ? or else each package will have to be compiled differently for XF3.3.6 and XF4.0.1. Also, please remeber to have lintian check about app-default stuff when you release the XF4 packages. Best way to make all developper of package aware of the problem (well sure you could fill bugs to all package using app-defaults also, with a nice bug reporting script doing the job) ... Friendly, Svne LUTHER -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
