Re: potato bugs
[debian-sparc subscribers, please disregard the X-No-CC header above]
[though since I'm a SPARC owner now, I should subscribe...]
We now seem to have 2.2.16 boot-floppies for everyone, so the main thing
we're waiting on is X (and a fix for xserver-xsun) which is causing
problems because we don't actually know of a fix yet. :-/ In any event,
a final X should be ready one way or another in the next day or two.
So the above will probably be removed in a couple of days if not NMUed
or MUed.
If any Xsun users would like to try to help tracking down this extremely
aggravating problem, please make sure you are upgraded to 3.3.6-9, and then
replace the /usr/X11R6/bin/Xsun binary on your system with the file from
the following URL:
http://www.debian.org/~branden/Xsun
There seems to be a problem at the Xsun/kernel-framebuffer layer. I've
added a whole bunch of debugging messages ("ErrorF"'s in X server jargon)
to a couple of functions in xc/programs/Xserver/hw/sun/sunInit.c that seem
to be at the heart of the problem.
Please email the results to the debian-x list so we do not clutter the
other lists. Be sure that the /dev/fb symlink exists before trying this
server binary.
--
G. Branden Robinson |Somebody once asked me if I thought sex
Debian GNU/Linux|was dirty. I said, "It is if you're
[EMAIL PROTECTED] |doing it right."
http://www.debian.org/~branden/ |-- Woody Allen
PGP signature
Re: rman (PolyglotMan) + TkMan are now under the Artistic License.
On Tue, Jul 18, 2000 at 09:26:12AM +0200, Sven LUTHER wrote: On Mon, Jul 17, 2000 at 10:49:27PM -0500, Branden Robinson wrote: You are one of the most hysterically panicky people I have ever met. Come on, just asking questions about it ... btw, just found out that xf4 mesa is incompatible with potato and current woody wine (fix on the way for woody it seems though ...) 4.0 and 4.0.1 are substantially different; it would help if you would mention which version you are talking about when referring to bugs and incompatibilities. just mutt too commode 'g' key ... I can't parse this. But nevermind, I'll chalk it up to a hasty error. Well, but the name suggest that ggi will only run with the mesa+ggi version, and not the mesa alone version. so will ggi run with the xfree version installed Or will you not be able to run ggi with XF4 installed. But then this surely is a ggi issue more than a XF issue. Probably, but I understand Red Hat is cooking up a wrapper library that will somehow figure out which of several Mesa (GL) versions is demanded and LD_PRELOAD the right one for the application. We can probably adapt such a thing to our own purposes. Right now I'm just trying to cross the bridge of preliminary .debs. I am being held up by an incredibly aggravating Xsun bug in 3.3.6. Well, I'm sure I'll figure something out, Sven. Instead of freaking out, either calm down and contribute, or be quiet. Huh sorry, ... just wanted to tell you about what my experience in the past few month with XF4 + debian has shown me, and i thought also that discution about a topic is in a way contributing also, or are not that what the debian mailign list are all about ? Often your tone implies to me that you expect me to solve all of these problems for you. Debian is a group effort, and a volunteer effort. I can only accomplish so much and I have to prioritize the time I do have. Working for Progeny is greatly increasting the amount of time I can contribute, but there are still only so many hours in the day. Furthermore, I'm simply not experienced with the internals of the X source code. Especially not driver-level stuff. And please, don't take it bad, i just told you that, because i thought of it, and i thought that you, the all mighty Xfree maintainer could maybe benefit from it ? See my above remarks about "tone". (BTW, XF4 will not run with matroxfb on my work box, so i reverted to 3.3.6) Again, is this 4.0 or 4.0.1? -- G. Branden Robinson | You don't just decide to break Kubrick's Debian GNU/Linux| code of silence and then get drawn away [EMAIL PROTECTED] | from it to a discussion about cough http://www.debian.org/~branden/ | medicine. PGP signature
Re: sensible-x-terminal and x-terminal-emulator
On Tue, Jul 18, 2000 at 10:44:46AM +0900, Tomohiro KUBOTA wrote: Ok, I can design a way to avoid hard-coding. It will have a configuration file in /etc directory. All X terminal emulators which supports special language like multibyte, combining, right-to-left, and up-to-down languages will install its /etc item. sensible-x-terminal-emulator will check the configuration file (or directory). How about this idea? (Though this way needs more Debian Policy.) Actually, I find this very appealing on the first reading or two and would like to hear more about it. -- G. Branden Robinson |Kissing girls is a goodness. It is a Debian GNU/Linux|growing closer. It beats the hell out [EMAIL PROTECTED] |of card games. http://www.debian.org/~branden/ |-- Robert Heinlein PGP signature
Re: sensible-x-terminal and x-terminal-emulator
On Thu, Jul 20, 2000 at 11:16:11AM +0900, Tomohiro KUBOTA wrote: If it is the most important to stop the 'feedback loop' and promote international Xterm, we should rather adopt a 7-bit terminal emulator as the default so that not only Asian people but also European-language speakers are forced to develop the international Xterm! Heh, okay, I take your point. PS. I started to contact with Xterm developer. However, this does not mean that I will withdraw my sensible-x-terminal-emulator. This is mainly what I'm getting it. xterm is actively maintained these days, and what's more, its maintainer seems to really care about i18n issues. He's applied dozens of patches from Markus Kuhn, who's heavily into Unicode support on Linux. Indeed, AFAICT xterm is superior to or on par with the development pace of any other terminal program in use. This pace has been masked by the fact that most people don't know that you can get xterm separate from the XFree86 tree, which releases quite slowly. -- G. Branden Robinson | Debian GNU/Linux|kernel panic -- causal failure [EMAIL PROTECTED] |universe will now reboot http://www.debian.org/~branden/ | PGP signature
Re: rman (PolyglotMan) + TkMan are now under the Artistic License.
On Wed, Jul 19, 2000 at 10:33:38AM +0200, Sven LUTHER wrote: On Wed, Jul 19, 2000 at 01:13:21AM -0500, Branden Robinson wrote: 4.0 and 4.0.1 are substantially different; it would help if you would Well, i don't think they are so different, apart from more drivers support and the DRI stuff updated. But anyway, the incompatibility came from wine not liking thread enabled mesa, which is present in all X installs (just mesa, no DRI stuff) as well as woody mesa ... They are quite different in the bugfix department! Dozens, if not hundreds, of patches applied since 4.0 declare themselves to be bugfixes. Therefore, if someone is seeing a bug in XFree86 4.x, I want to be sure that "x" = "0.1". Well, it is considered good form when writing to lists to do a reply to all, No it isn't. It's considered good form to reply to the LIST, unless you have something private to say. Probably, but I understand Red Hat is cooking up a wrapper library that will somehow figure out which of several Mesa (GL) versions is demanded and LD_PRELOAD the right one for the application. This seems somewhat heavy to me, best would be to switch to purely XF4 for woody, and keep the 3.3.6 server as compatibility stuff, don't know exactly, We're going to be keeping some 3.x server binaries as well. We have to, unless we're going to tell some of our users to throw away their old video cards. We can probably adapt such a thing to our own purposes. Right now I'm just trying to cross the bridge of preliminary .debs. I am being held up by an incredibly aggravating Xsun bug in 3.3.6. :((( Yep, that's about how I feel. Well, this surely comes from the fact that often your tone suggest that you want everything done by yourself I want to be careful what I delegate, because (as I'm sure you can attest) no one deserves to be on the receiving end of my frustration when X is being recalcitrant. As it happens, Stephen R. Gore and I have worked it out so that he will maintain the 3.3.x servers once I have finished Debianing 4.0. Anyway, recall the mythical man-month. You can only split one task up so much before you lose more than you gain. only about this, but the tone of a mail should not hinder us working together, remember also that not everyone is a native english speaker, and so maybe don't choose the most acomodating of tones, and are aware of all the subtilities of the english tongue ... I'll try to keep this in mind. Well, my opinion is that a team work (in the manner of boot-floppies) would maybe be the best approch to the huge beast that is xfree, especially since XF4 now includes lot of other libs that were not included before (especially the mesa/GL stuff). Up to a point. Like I said, mythical man-month effects. But when i told you this some time ago, i was told to mind my own business ... At the time I didn't have space in my mind to handle 4.0. Now I do (or I'm trying to). I do not want to cross bridges before I come to them. The main decision to be made is how much of what XF4 builds should be shipped. Anything we don't ship as part of X, obviously, can be handled by others. If that includes Mesa, that's fine with me. But one person at a time has to build and upload the X packages. Well, i am not saying that i am either, but i am doing some driver work right now, and will maybe be doing some DRI work in the future, and you pick up some stuff by the way ... I have also been running XF4 on top of debian since some time now. Well, if we can learn to speak to each other just the right way, I look forward to sharing knowledge with you. :) 4.0.1 naturraly, 4.0 is very outdated, and as xfree developper, i consider it my duty to run the lastmost release of it, to do testing ... I would do so myself except I simply don't have a machine to spare for that purpose. (btw, about matroxfb, Petr (the matroxfb maintainer) told me that he will not support XF4 until there is a debian package of it ...) Which Petr is this? That is an interesting attitude to take. Holding development efforts hostage based up on the development activities of another volunteer doesn't strike me as very neighborly. Nevertheless, I hope to have .debs of some sort within the next couple of days. -- G. Branden Robinson | If you make people think they're Debian GNU/Linux| thinking, they'll love you; [EMAIL PROTECTED] | but if you really make them think, http://www.debian.org/~branden/ | they'll hate you. PGP signature
Re: rman (PolyglotMan) + TkMan are now under the Artistic License.
On Wed, Jul 19, 2000 at 04:08:09AM -0500, Branden Robinson wrote: On Wed, Jul 19, 2000 at 10:33:38AM +0200, Sven LUTHER wrote: On Wed, Jul 19, 2000 at 01:13:21AM -0500, Branden Robinson wrote: 4.0 and 4.0.1 are substantially different; it would help if you would Well, i don't think they are so different, apart from more drivers support and the DRI stuff updated. But anyway, the incompatibility came from wine not liking thread enabled mesa, which is present in all X installs (just mesa, no DRI stuff) as well as woody mesa ... They are quite different in the bugfix department! Dozens, if not hundreds, of patches applied since 4.0 declare themselves to be bugfixes. Therefore, if someone is seeing a bug in XFree86 4.x, I want to be sure that "x" = "0.1". Ok, will do, ... Probably, but I understand Red Hat is cooking up a wrapper library that will somehow figure out which of several Mesa (GL) versions is demanded and LD_PRELOAD the right one for the application. This seems somewhat heavy to me, best would be to switch to purely XF4 for woody, and keep the 3.3.6 server as compatibility stuff, don't know exactly, We're going to be keeping some 3.x server binaries as well. We have to, unless we're going to tell some of our users to throw away their old video cards. ... do you know exactly which graphic boards are not supported in XF4 ? i think i read something about all hardware supported in previous version is also supported in XF4 (well, maybe not as well, but still you can use it). And anyway, until woody ships, surely all boards will be supported ... Well, this surely comes from the fact that often your tone suggest that you want everything done by yourself I want to be careful what I delegate, because (as I'm sure you can attest) no one deserves to be on the receiving end of my frustration when X is being recalcitrant. As it happens, Stephen R. Gore and I have worked it out so that he will maintain the 3.3.x servers once I have finished Debianing 4.0. Good news, ... Anyway, recall the mythical man-month. You can only split one task up so much before you lose more than you gain. Yes, ... but i guess maintaing X, especially XF4, is not one task, but lot of different small tasks ? Well, my opinion is that a team work (in the manner of boot-floppies) would maybe be the best approch to the huge beast that is xfree, especially since XF4 now includes lot of other libs that were not included before (especially the mesa/GL stuff). Up to a point. Like I said, mythical man-month effects. Well, but having the mesa xfree maintainer speaking together on a common purely maintainer mailing list would be nice maybe ? But when i told you this some time ago, i was told to mind my own business ... At the time I didn't have space in my mind to handle 4.0. Now I do (or I'm trying to). I do not want to cross bridges before I come to them. The main decision to be made is how much of what XF4 builds should be shipped. Anything we don't ship as part of X, obviously, can be handled by Well, at first i thought i will only build the server, and reuse the old 3.3.6 stuff that shipped with debian, this didn't work too well (because of keyboard problems, xterm colorhandling got broken, and some other stuff i don't remember right now) so now i build all of X and have it replace the 3.3.6 stuff, which i keep around only to satisfy the dpkg dependencies. I installed the stuff in /usr/X11R6.4, have it use /etc/X11/XF86Config.4, and put it earlier than /usr/X11R6 stuff in both /etc/ld.so.conf and $PATH. This works more or less. didn't manage to install it as nicely on my work box here though. Also XF4 now support multihead quite nicely, but most windows manager are not aware of it, i think. others. If that includes Mesa, that's fine with me. But one person at a time has to build and upload the X packages. That is ok, ... but still making XF4 the default for woody will need adaptation in more than just the XF packages. Well, i am not saying that i am either, but i am doing some driver work right now, and will maybe be doing some DRI work in the future, and you pick up some stuff by the way ... I have also been running XF4 on top of debian since some time now. Well, if we can learn to speak to each other just the right way, I look forward to sharing knowledge with you. :) : 4.0.1 naturraly, 4.0 is very outdated, and as xfree developper, i consider it my duty to run the lastmost release of it, to do testing ... I would do so myself except I simply don't have a machine to spare for that purpose. no problem, like said, there is more than enough work to share. That said, upgrading from 4.0 to 4.0.1 (through all intermediate devel versions) caused no major problems for me. (btw, about matroxfb, Petr (the matroxfb maintainer) told me that he will not support XF4 until there is a debian package of it
Re: sensible-x-terminal and x-terminal-emulator
On Tue, Jul 18, 2000 at 01:56:34AM -0500, David Starner wrote: On Mon, Jul 17, 2000 at 10:38:01PM -0500, [EMAIL PROTECTED] wrote: I have no idea what the Vietnamese character set is called. VISCII. Since it's a 8-bit character set that's a subset of Unicode, it's little different from handling any other Latin-script language. (Except - VISCII puts letters in C1 control section, and a couple into the C0 control section.) That's interesting. So Vietnamese is an alphabetic language rather than an ideographic one? -- G. Branden Robinson |Somebody once asked me if I thought sex Debian GNU/Linux|was dirty. I said, It is if you're [EMAIL PROTECTED] |doing it right. http://www.debian.org/~branden/ |-- Woody Allen pgpN0on5BKKEK.pgp Description: PGP signature
Re: sensible-x-terminal and x-terminal-emulator
On Wed, Jul 19, 2000 at 11:30:03AM +0900, Atsuhito Kohda wrote: Please, there is no need to CC me list replies; please see the headers of this message, as well as the one to which you replied. From: [EMAIL PROTECTED] I think it is a feedback loop. Please note at least that there are already variety of terminal emulators although there is not yet sensible-x-terminal-emulator. I am saying that I think sensible-x-terminal-emulator will promote this feedback loop. For example I installed not only kterm, krxvt for Japanese but also hanterm for Hangul to test message catalogue of lynx then alternatives automatically select(s) hanterm but this is not appropriate for me. There could be many, many cases where alternatives is (are?) not sufficient, IMHO. Which is best addressed by expaning the capabilities of existing terminal emulators to be less anchored to Latin character sets. I just get the feeling that by taking a program like, say, xterm, and then customizing it separately for Hangul, Han, and Japanese, there's some duplication of effort. I think a better program would result if one started from the xterm code base and then said, I'm going to properly internationalize this program so it can handle all of these character sets. Is this harder? Yes. But the world is getting ever smaller. I'm not opposed to sensible-x-terminal-emulator as long as everyone understands what it is: an inelegant workaround made necessary by the actions of people who'd rather fork xterm than contribute to it. -- G. Branden Robinson | Optimists believe we live in the best of Debian GNU/Linux| all possible worlds. Pessimists are [EMAIL PROTECTED] | afraid the optimists are right. http://www.debian.org/~branden/ | pgpxCItDH9FWi.pgp Description: PGP signature
Re: Sawfish GNOME control center problem
On Tue, Jul 18, 2000 at 07:42:34AM -0700, Alexander Hvostov wrote: Hi everyone, I seem to be having a problem with Sawfish's GNOME capplets: Your question is inappropriate for this mailing list. Have you even read the charter of this mailing list? You can find it at the URL below but I will quote it here: This list is for the discussion and support of the X Window System within Debian. Issues of maintenance and porting of Debian's XFree86 packages are germane here, as are discussions of possible Debian policy mechanisms for ensuring the smooth interoperation of packages that use the X Window System, particularly widget sets, desktop environments, window managers, display managers, and packages that provide fonts for the X Window System. In particular, individuals involved with building official Debian XFree86 packages for any architecture are invited to join, as are those with various graphics hardware who seek to reproduce and/or fix bugs in the X server. This is not a user support list; this list is intended for those who deal with the source code of any of the X Window System components mentioned above. Please direct your query to debian-user. -- G. Branden Robinson | Measure with micrometer, Debian GNU/Linux| mark with chalk, [EMAIL PROTECTED] | cut with axe, http://www.debian.org/~branden/ | hope like hell. pgpBF9goHCbft.pgp Description: PGP signature
Re: rman (PolyglotMan) + TkMan are now under the Artistic License.
On Tue, Jul 18, 2000 at 09:26:12AM +0200, Sven LUTHER wrote: On Mon, Jul 17, 2000 at 10:49:27PM -0500, Branden Robinson wrote: You are one of the most hysterically panicky people I have ever met. Come on, just asking questions about it ... btw, just found out that xf4 mesa is incompatible with potato and current woody wine (fix on the way for woody it seems though ...) 4.0 and 4.0.1 are substantially different; it would help if you would mention which version you are talking about when referring to bugs and incompatibilities. just mutt too commode 'g' key ... I can't parse this. But nevermind, I'll chalk it up to a hasty error. Well, but the name suggest that ggi will only run with the mesa+ggi version, and not the mesa alone version. so will ggi run with the xfree version installed Or will you not be able to run ggi with XF4 installed. But then this surely is a ggi issue more than a XF issue. Probably, but I understand Red Hat is cooking up a wrapper library that will somehow figure out which of several Mesa (GL) versions is demanded and LD_PRELOAD the right one for the application. We can probably adapt such a thing to our own purposes. Right now I'm just trying to cross the bridge of preliminary .debs. I am being held up by an incredibly aggravating Xsun bug in 3.3.6. Well, I'm sure I'll figure something out, Sven. Instead of freaking out, either calm down and contribute, or be quiet. Huh sorry, ... just wanted to tell you about what my experience in the past few month with XF4 + debian has shown me, and i thought also that discution about a topic is in a way contributing also, or are not that what the debian mailign list are all about ? Often your tone implies to me that you expect me to solve all of these problems for you. Debian is a group effort, and a volunteer effort. I can only accomplish so much and I have to prioritize the time I do have. Working for Progeny is greatly increasting the amount of time I can contribute, but there are still only so many hours in the day. Furthermore, I'm simply not experienced with the internals of the X source code. Especially not driver-level stuff. And please, don't take it bad, i just told you that, because i thought of it, and i thought that you, the all mighty Xfree maintainer could maybe benefit from it ? See my above remarks about tone. (BTW, XF4 will not run with matroxfb on my work box, so i reverted to 3.3.6) Again, is this 4.0 or 4.0.1? -- G. Branden Robinson | You don't just decide to break Kubrick's Debian GNU/Linux| code of silence and then get drawn away [EMAIL PROTECTED] | from it to a discussion about cough http://www.debian.org/~branden/ | medicine. pgpod2miPfXSE.pgp Description: PGP signature
Re: potato bugs
[debian-sparc subscribers, please disregard the X-No-CC header above] [though since I'm a SPARC owner now, I should subscribe...] We now seem to have 2.2.16 boot-floppies for everyone, so the main thing we're waiting on is X (and a fix for xserver-xsun) which is causing problems because we don't actually know of a fix yet. :-/ In any event, a final X should be ready one way or another in the next day or two. So the above will probably be removed in a couple of days if not NMUed or MUed. If any Xsun users would like to try to help tracking down this extremely aggravating problem, please make sure you are upgraded to 3.3.6-9, and then replace the /usr/X11R6/bin/Xsun binary on your system with the file from the following URL: http://www.debian.org/~branden/Xsun There seems to be a problem at the Xsun/kernel-framebuffer layer. I've added a whole bunch of debugging messages (ErrorF's in X server jargon) to a couple of functions in xc/programs/Xserver/hw/sun/sunInit.c that seem to be at the heart of the problem. Please email the results to the debian-x list so we do not clutter the other lists. Be sure that the /dev/fb symlink exists before trying this server binary. -- G. Branden Robinson |Somebody once asked me if I thought sex Debian GNU/Linux|was dirty. I said, It is if you're [EMAIL PROTECTED] |doing it right. http://www.debian.org/~branden/ |-- Woody Allen pgpb4RMpb4uTA.pgp Description: PGP signature
Re: sensible-x-terminal and x-terminal-emulator
Hi, I will resend the following mail, which is originally sent to debian-devel list, to debian-x because recent discussion is also held on debian-x. From: Tomohiro KUBOTA [EMAIL PROTECTED] Subject: Re: sensible-x-terminal and x-terminal-emulator Date: Tue, 18 Jul 2000 10:44:46 +0900 Hi, From: Branden Robinson [EMAIL PROTECTED] Subject: Re: sensible-x-terminal and x-terminal-emulator Date: Sun, 16 Jul 2000 00:38:30 -0500 I'm not yet sure what I think of this whole sensible-xtermemu idea, given that xterm is all I've personally ever needed, but for consistency with the other sensible things, I think the only reasonable name for this package/program would be sensible-x-terminal-emulator. At first, the fact that all you need is xterm cannot be a reason that xterm can satisfy all people in the world. Xterm can display 8-bit, non-multicolumn, non-combining, left-to-right languages only. This is true even for XFree86-4.0-xterm. Yes, I know there is an unofficial patch for XFree86-4.0-xterm to enable multicolumn and combining characters. However, it supports these characters only via UTF-8. We need encodings such as EUC-JP, EUC-KR, EUC-CN, EUC-TW, ISO-2022-JP, ISO-2022-KR, ISO-2022-CN, BIG5, Shift-JIS, CN-GB, and so on, besides UTF-8. You need ISO-8859-1 besides UTF-8, don't you? You might be annoyed if xterm were stop to support ISO-8859-* because it supports UTF-8. It is same. # No, not the same. For example, code space of ISO-2022-INT* encoding # is larger than UTF-8. Therefore, convert original text from # ISO-2022-INT* into UTF-8 - edit it - reconvert into ISO-2022-INT* # way cannot be done. We don't _shift into_ UTF-8. UTF-8 should be one of many encodings which Debian supports (in LOCALE framework). However, I could not find any intension of Xterm (or XFree86 web site) to support encodings which I listed above. And more, hanterm has alphabet-hangul (Korean character) translation mechanism to input Korean using keyboard. xiterm+thai has similar Thai input mechanism. Will xterm integrate these mechanisms? (Though Korean can be input using 'ami' package via XIM protocol.) I hope not. Instead of all this furious forking of terminal emulators, I would hope that people would contribute to improving xterm. It is actively maintained upstream by Thomas Dickey, and he is quite diligently working at improving it, with support for variable-width fonts, and so forth. Maybe people should read the upstream xterm changelog every once in a while. This is not 'fork'. This is a wrapper. Why don't we put our efforts towards making the standard, reference implementation of a terminal emulator fit for as many locales as possible? That program would be xterm. I admit your way is better. However, do you really think xterm is the nearest to the ideal? Xterm only supports 8-bit encoding and UTF-8 (now without multicolumn and combining characters). On the other hand, kterm supports various encodings based on ISO-2022 (including ISO-8859-*. You know, ISO-8859-* are also based on ISO-2022 and can be regarded as subsets of ISO-2022). Rxvt supports a few multibyte encodings (though the supported encoding must be specified on compile). And more, kterm and rxvt supports international input via XIM protocol. (XIM support is vitally important for CJK people). I am trying to read the source code of rxvt. However, I have to study X11 programming first. (I don't know whether kterm is a living project now...) Time is a problem. We need an X terminal emulator with multi-language support NOW. On the other hand, though Xterm might be going to support every encodings in the world, it would be in future. # However, if it is likely that multi-language xterm which can display, # input, and copy-paste all encodings, at least, which Debian locales and # locale-* packages support will be in time for Debian Woody, I will # withdraw sensible-x-terminal-emulator. sensible-editor or sensible-pager at all. Instead it looks to me like you are hard-coding in all kinds of locale-specific assumptions about what terminal emulator program should be used. That way lies madness. Asian people have to do many mess of locale-specific configurations before using Linux. I bought many books on such configuraions. Don't you think this way lies much larger madness? I'd like to stop this madness ASAP. Or Debian would be defeated by other 'Japanese- localized' distributions which we don't need to read these books to use. Ok, I can design a way to avoid hard-coding. It will have a configuration file in /etc directory. All X terminal emulators which supports special language like multibyte, combining, right-to-left, and up-to-down languages will install its /etc item. sensible-x-terminal-emulator will check the configuration file (or directory). How about this idea? (Though this way needs more
Re: rman (PolyglotMan) + TkMan are now under the Artistic License.
On Wed, Jul 19, 2000 at 01:13:21AM -0500, Branden Robinson wrote: On Tue, Jul 18, 2000 at 09:26:12AM +0200, Sven LUTHER wrote: On Mon, Jul 17, 2000 at 10:49:27PM -0500, Branden Robinson wrote: You are one of the most hysterically panicky people I have ever met. Come on, just asking questions about it ... btw, just found out that xf4 mesa is incompatible with potato and current woody wine (fix on the way for woody it seems though ...) 4.0 and 4.0.1 are substantially different; it would help if you would Well, i don't think they are so different, apart from more drivers support and the DRI stuff updated. But anyway, the incompatibility came from wine not liking thread enabled mesa, which is present in all X installs (just mesa, no DRI stuff) as well as woody mesa ... mention which version you are talking about when referring to bugs and incompatibilities. Well, i ran every version in between 4.0 and 4.0.1 but am currently running a mostly 4.0.1 setup. (well with my additional glint pm3 driver work. just mutt too commode 'g' key ... I can't parse this. But nevermind, I'll chalk it up to a hasty error. Well, it is considered good form when writing to lists to do a reply to all, (key 'g' in mutt) when replying to a mail. this will reply to all persons who where recipient of the replied to mail, ... Well, but the name suggest that ggi will only run with the mesa+ggi version, and not the mesa alone version. so will ggi run with the xfree version installed Or will you not be able to run ggi with XF4 installed. But then this surely is a ggi issue more than a XF issue. Probably, but I understand Red Hat is cooking up a wrapper library that will somehow figure out which of several Mesa (GL) versions is demanded and LD_PRELOAD the right one for the application. This seems somewhat heavy to me, best would be to switch to purely XF4 for woody, and keep the 3.3.6 server as compatibility stuff, don't know exactly, ... We can probably adapt such a thing to our own purposes. Right now I'm just trying to cross the bridge of preliminary .debs. I am being held up by an incredibly aggravating Xsun bug in 3.3.6. :((( Well, I'm sure I'll figure something out, Sven. Instead of freaking out, either calm down and contribute, or be quiet. Huh sorry, ... just wanted to tell you about what my experience in the past few month with XF4 + debian has shown me, and i thought also that discution about a topic is in a way contributing also, or are not that what the debian mailign list are all about ? Often your tone implies to me that you expect me to solve all of these problems for you. Debian is a group effort, and a volunteer effort. I can Well, this surely comes from the fact that often your tone suggest that you want everything done by yourself only about this, but the tone of a mail should not hinder us working together, remember also that not everyone is a native english speaker, and so maybe don't choose the most acomodating of tones, and are aware of all the subtilities of the english tongue ... only accomplish so much and I have to prioritize the time I do have. No problem, i wrote to the list, the nice thing with it is that you can come back later and check the archive, will in the mean time i may have forgoten the stuff i wanted to say. Working for Progeny is greatly increasting the amount of time I can contribute, but there are still only so many hours in the day. Well, my opinion is that a team work (in the manner of boot-floppies) would maybe be the best approch to the huge beast that is xfree, especially since XF4 now includes lot of other libs that were not included before (especially the mesa/GL stuff). But when i told you this some time ago, i was told to mind my own business ... Furthermore, I'm simply not experienced with the internals of the X source code. Especially not driver-level stuff. Well, i am not saying that i am either, but i am doing some driver work right now, and will maybe be doing some DRI work in the future, and you pick up some stuff by the way ... I have also been running XF4 on top of debian since some time now. And please, don't take it bad, i just told you that, because i thought of it, and i thought that you, the all mighty Xfree maintainer could maybe benefit from it ? See my above remarks about tone. (BTW, XF4 will not run with matroxfb on my work box, so i reverted to 3.3.6) Again, is this 4.0 or 4.0.1? 4.0.1 naturraly, 4.0 is very outdated, and as xfree developper, i consider it my duty to run the lastmost release of it, to do testing ... (btw, about matroxfb, Petr (the matroxfb maintainer) told me that he will not support XF4 until there is a debian package of it ...) Friendly, Sven LUTHER
Re: sensible-x-terminal and x-terminal-emulator
From: Branden Robinson [EMAIL PROTECTED] Subject: Re: sensible-x-terminal and x-terminal-emulator Date: Wed, 19 Jul 2000 01:00:32 -0500 Please, there is no need to CC me list replies; please see the headers of this message, as well as the one to which you replied. Ah, very sorry. I hope this is okay :) I just get the feeling that by taking a program like, say, xterm, and then customizing it separately for Hangul, Han, and Japanese, there's some duplication of effort. I think a better program would result if one started from the xterm code base and then said, I'm going to properly internationalize this program so it can handle all of these character sets. Well it might be best if every efforts are concentrated on one point but note that we are in such a chaotic world, open source comunity, so it is inevitable and natural that there are many duplication of efforts, IMHO. I guess that you prefer unity than variety but it is your personal preference, isn't it? Don't you admit the existence of both vi and emacs or even xemacs? I'm not opposed to sensible-x-terminal-emulator as long as everyone understands what it is: an inelegant workaround made necessary by the actions of people who'd rather fork xterm than contribute to it. Hmm, then a user of rxvt is a bad person? From your tone I can not help thinking that you are opposed to sensible-x-terminal-emulator only by your preference. If there is any unpoliteness please forgive me. It is only because of my lack of English ability and never my intention. Best Regards, 2000.7.19 -- Debian JP Developer - much more I18N of Debian Atsuhito Kohda [EMAIL PROTECTED] Department of Math., Tokushima Univ.
Re: rman (PolyglotMan) + TkMan are now under the Artistic License.
On Wed, Jul 19, 2000 at 10:33:38AM +0200, Sven LUTHER wrote: On Wed, Jul 19, 2000 at 01:13:21AM -0500, Branden Robinson wrote: 4.0 and 4.0.1 are substantially different; it would help if you would Well, i don't think they are so different, apart from more drivers support and the DRI stuff updated. But anyway, the incompatibility came from wine not liking thread enabled mesa, which is present in all X installs (just mesa, no DRI stuff) as well as woody mesa ... They are quite different in the bugfix department! Dozens, if not hundreds, of patches applied since 4.0 declare themselves to be bugfixes. Therefore, if someone is seeing a bug in XFree86 4.x, I want to be sure that x = 0.1. Well, it is considered good form when writing to lists to do a reply to all, No it isn't. It's considered good form to reply to the LIST, unless you have something private to say. Probably, but I understand Red Hat is cooking up a wrapper library that will somehow figure out which of several Mesa (GL) versions is demanded and LD_PRELOAD the right one for the application. This seems somewhat heavy to me, best would be to switch to purely XF4 for woody, and keep the 3.3.6 server as compatibility stuff, don't know exactly, We're going to be keeping some 3.x server binaries as well. We have to, unless we're going to tell some of our users to throw away their old video cards. We can probably adapt such a thing to our own purposes. Right now I'm just trying to cross the bridge of preliminary .debs. I am being held up by an incredibly aggravating Xsun bug in 3.3.6. :((( Yep, that's about how I feel. Well, this surely comes from the fact that often your tone suggest that you want everything done by yourself I want to be careful what I delegate, because (as I'm sure you can attest) no one deserves to be on the receiving end of my frustration when X is being recalcitrant. As it happens, Stephen R. Gore and I have worked it out so that he will maintain the 3.3.x servers once I have finished Debianing 4.0. Anyway, recall the mythical man-month. You can only split one task up so much before you lose more than you gain. only about this, but the tone of a mail should not hinder us working together, remember also that not everyone is a native english speaker, and so maybe don't choose the most acomodating of tones, and are aware of all the subtilities of the english tongue ... I'll try to keep this in mind. Well, my opinion is that a team work (in the manner of boot-floppies) would maybe be the best approch to the huge beast that is xfree, especially since XF4 now includes lot of other libs that were not included before (especially the mesa/GL stuff). Up to a point. Like I said, mythical man-month effects. But when i told you this some time ago, i was told to mind my own business ... At the time I didn't have space in my mind to handle 4.0. Now I do (or I'm trying to). I do not want to cross bridges before I come to them. The main decision to be made is how much of what XF4 builds should be shipped. Anything we don't ship as part of X, obviously, can be handled by others. If that includes Mesa, that's fine with me. But one person at a time has to build and upload the X packages. Well, i am not saying that i am either, but i am doing some driver work right now, and will maybe be doing some DRI work in the future, and you pick up some stuff by the way ... I have also been running XF4 on top of debian since some time now. Well, if we can learn to speak to each other just the right way, I look forward to sharing knowledge with you. :) 4.0.1 naturraly, 4.0 is very outdated, and as xfree developper, i consider it my duty to run the lastmost release of it, to do testing ... I would do so myself except I simply don't have a machine to spare for that purpose. (btw, about matroxfb, Petr (the matroxfb maintainer) told me that he will not support XF4 until there is a debian package of it ...) Which Petr is this? That is an interesting attitude to take. Holding development efforts hostage based up on the development activities of another volunteer doesn't strike me as very neighborly. Nevertheless, I hope to have .debs of some sort within the next couple of days. -- G. Branden Robinson | If you make people think they're Debian GNU/Linux| thinking, they'll love you; [EMAIL PROTECTED] | but if you really make them think, http://www.debian.org/~branden/ | they'll hate you. pgpeiZ4LnIBQh.pgp Description: PGP signature
Re: rman (PolyglotMan) + TkMan are now under the Artistic License.
On Wed, Jul 19, 2000 at 04:08:09AM -0500, Branden Robinson wrote: On Wed, Jul 19, 2000 at 10:33:38AM +0200, Sven LUTHER wrote: On Wed, Jul 19, 2000 at 01:13:21AM -0500, Branden Robinson wrote: 4.0 and 4.0.1 are substantially different; it would help if you would Well, i don't think they are so different, apart from more drivers support and the DRI stuff updated. But anyway, the incompatibility came from wine not liking thread enabled mesa, which is present in all X installs (just mesa, no DRI stuff) as well as woody mesa ... They are quite different in the bugfix department! Dozens, if not hundreds, of patches applied since 4.0 declare themselves to be bugfixes. Therefore, if someone is seeing a bug in XFree86 4.x, I want to be sure that x = 0.1. Ok, will do, ... Probably, but I understand Red Hat is cooking up a wrapper library that will somehow figure out which of several Mesa (GL) versions is demanded and LD_PRELOAD the right one for the application. This seems somewhat heavy to me, best would be to switch to purely XF4 for woody, and keep the 3.3.6 server as compatibility stuff, don't know exactly, We're going to be keeping some 3.x server binaries as well. We have to, unless we're going to tell some of our users to throw away their old video cards. ... do you know exactly which graphic boards are not supported in XF4 ? i think i read something about all hardware supported in previous version is also supported in XF4 (well, maybe not as well, but still you can use it). And anyway, until woody ships, surely all boards will be supported ... Well, this surely comes from the fact that often your tone suggest that you want everything done by yourself I want to be careful what I delegate, because (as I'm sure you can attest) no one deserves to be on the receiving end of my frustration when X is being recalcitrant. As it happens, Stephen R. Gore and I have worked it out so that he will maintain the 3.3.x servers once I have finished Debianing 4.0. Good news, ... Anyway, recall the mythical man-month. You can only split one task up so much before you lose more than you gain. Yes, ... but i guess maintaing X, especially XF4, is not one task, but lot of different small tasks ? Well, my opinion is that a team work (in the manner of boot-floppies) would maybe be the best approch to the huge beast that is xfree, especially since XF4 now includes lot of other libs that were not included before (especially the mesa/GL stuff). Up to a point. Like I said, mythical man-month effects. Well, but having the mesa xfree maintainer speaking together on a common purely maintainer mailing list would be nice maybe ? But when i told you this some time ago, i was told to mind my own business ... At the time I didn't have space in my mind to handle 4.0. Now I do (or I'm trying to). I do not want to cross bridges before I come to them. The main decision to be made is how much of what XF4 builds should be shipped. Anything we don't ship as part of X, obviously, can be handled by Well, at first i thought i will only build the server, and reuse the old 3.3.6 stuff that shipped with debian, this didn't work too well (because of keyboard problems, xterm colorhandling got broken, and some other stuff i don't remember right now) so now i build all of X and have it replace the 3.3.6 stuff, which i keep around only to satisfy the dpkg dependencies. I installed the stuff in /usr/X11R6.4, have it use /etc/X11/XF86Config.4, and put it earlier than /usr/X11R6 stuff in both /etc/ld.so.conf and $PATH. This works more or less. didn't manage to install it as nicely on my work box here though. Also XF4 now support multihead quite nicely, but most windows manager are not aware of it, i think. others. If that includes Mesa, that's fine with me. But one person at a time has to build and upload the X packages. That is ok, ... but still making XF4 the default for woody will need adaptation in more than just the XF packages. Well, i am not saying that i am either, but i am doing some driver work right now, and will maybe be doing some DRI work in the future, and you pick up some stuff by the way ... I have also been running XF4 on top of debian since some time now. Well, if we can learn to speak to each other just the right way, I look forward to sharing knowledge with you. :) : 4.0.1 naturraly, 4.0 is very outdated, and as xfree developper, i consider it my duty to run the lastmost release of it, to do testing ... I would do so myself except I simply don't have a machine to spare for that purpose. no problem, like said, there is more than enough work to share. That said, upgrading from 4.0 to 4.0.1 (through all intermediate devel versions) caused no major problems for me. (btw, about matroxfb, Petr (the matroxfb maintainer) told me that he will not support XF4 until there is a
Re: potato bugs
On Wed, 19 Jul 2000 01:24:07 -0500, Branden Robinson [EMAIL PROTECTED] wrote: If any Xsun users would like to try to help tracking down this extremely aggravating problem, please make sure you are upgraded to 3.3.6-9, and then replace the /usr/X11R6/bin/Xsun binary on your system with the file from the following URL: http://www.debian.org/~branden/Xsun There seems to be a problem at the Xsun/kernel-framebuffer layer. I've added a whole bunch of debugging messages (ErrorF's in X server jargon) to a couple of functions in xc/programs/Xserver/hw/sun/sunInit.c that seem to be at the heart of the problem. OK. Here's the output on my machine (Sun Sparc 5, cg6 fb). Note that Xsun runs fine as root for me (see bug #67096), so this output may not be helpful to you. == Cannot open /dev/gpmdata, error 2. Trying /dev/sunmouse. InitOutput: entering (using VT number 7) InputOutput: populating pScreenInfo pScreenInfo-imageByteOrder = 1 pScreenInfo-bitmapScanlineUnit = 32 pScreenInfo-bitmapScanlinePad = 32 pScreenInfo-bitmapBitOrder = 1 pScreenInfo-numPixmapFormats = 2 XKB is defined InitOutput: sunDevsInited is FALSE devList = GetDeviceList (argc, argv) Successful OpenFrameBuffer (devList[0] not null and scr = 0 ( 3) Successful OpenFrameBuffer (devList[1] not null and scr = 0 ( 3) Successful OpenFrameBuffer (devList[2] not null and scr = 0 ( 3) Successful OpenFrameBuffer (devList[3] not null and scr = 0 ( 3) Successful OpenFrameBuffer (devList[4] not null and scr = 0 ( 3) Successful OpenFrameBuffer (devList[5] not null and scr = 0 ( 3) Successful OpenFrameBuffer (devList[6] not null and scr = 0 ( 3) Successful OpenFrameBuffer (devList[7] not null and scr = 0 ( 3) Successful OpenFrameBuffer (devList[8] not null and scr = 0 ( 3) Successful OpenFrameBuffer (devList[9] not null and scr = 0 ( 3) Successful OpenFrameBuffer (devList[10] not null and scr = 0 ( 3) Successful OpenFrameBuffer (devList[11] not null and scr = 0 ( 3) Successful OpenFrameBuffer (devList[12] not null and scr = 0 ( 3) Successful OpenFrameBuffer (devList[13] not null and scr = 0 ( 3) sunFbs[0].fd was -1, not stat()ing or doing linuxSetConsoleFb (scr = 0) sunFbs[1].fd was -1, not stat()ing or doing linuxSetConsoleFb (scr = 1) sunFbs[2].fd was -1, not stat()ing or doing linuxSetConsoleFb (scr = 2) InputOutput: leaving Fatal server error: no screens found X connection to :0.0 broken (explicit kill or server shutdown). Please email the results to the debian-x list so we do not clutter the other lists. Be sure that the /dev/fb symlink exists before trying this server binary. Check. % ls -l /dev/fb /dev/fb0 lrwxrwxrwx1 root root3 Jul 10 17:18 /dev/fb - fb0 crw--w--w-1 root tty 29, 0 Feb 26 1998 /dev/fb0 --Paul Vojta, [EMAIL PROTECTED]
Re: sensible-x-terminal and x-terminal-emulator
Hi,
From: Branden Robinson [EMAIL PROTECTED]
Subject: Re: sensible-x-terminal and x-terminal-emulator
Date: Wed, 19 Jul 2000 01:00:32 -0500
Please note at least that there are already variety of terminal
emulators although there is not yet sensible-x-terminal-emulator.
I am saying that I think sensible-x-terminal-emulator will promote this
feedback loop.
You might be right. However, you are too idealistic. Asian people
need sensible-x-terminal-emulator NOW. This need is concrete and
your 'feedback loop' is only a possibility. And the possibility
can be avoided because the development of software is done by
human will. It is not a natural phenomenon. This is different
from possibility to rain or snow.
If it is the most important to stop the 'feedback loop' and promote
international Xterm, we should rather adopt a 7-bit terminal emulator
as the default so that not only Asian people but also European-language
speakers are forced to develop the international Xterm!
Or, how about using KTERM as the default X terminal emulator for
Debian until the ideal international X terminal emulator will be
available? Kterm supports ISO2022-based various character sets
including ISO8859-{1,2,3,4,5,6,7,8,9}, JISX0201, JISX0208, GB2312,
and KSC5601. Much better than Xterm.
(Though Kterm does not support KOI8-R, TIS620, VISCII, and so on.)
Check http://surfchem0.riken.go.jp/~kubota/mojibake/terminal-emulators.html
for a screenshot of Kterm with variety of charsets including
ISO-8859-{1,2}, Russian, Hebrew, Japanese, and Korean.
PS. I started to contact with Xterm developer. However, this does
not mean that I will withdraw my sensible-x-terminal-emulator.
---
Tomohiro KUBOTA [EMAIL PROTECTED]
http://surfchem0.riken.go.jp/~kubota/
Re: potato bugs
We (Mike Renfro, Ben Collins, and I) found the problem. Thanks for your help! -- G. Branden Robinson| Debian GNU/Linux | The software said it required Windows [EMAIL PROTECTED] | 3.1 or better, so I installed Linux. http://deadbeast.net/~branden/ | pgpiXUPtsn4nf.pgp Description: PGP signature
