Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
On Thu, Oct 23, 2003 at 09:03:48AM +0900, Tomohiro KUBOTA wrote: [...] On app-defaults files: why peoples speaking some languages are forced to modify app-default files while others don't need to do? [...] Please describe a simple scenario where changing default fonts is helpful. I do not understand why you discussed those UTF-8 issues, they does not seem related to the problems you want to solve. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
Hi, From: [EMAIL PROTECTED] (Denis Barbier) Subject: Re: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n Date: Thu, 23 Oct 2003 08:03:47 +0200 Please describe a simple scenario where changing default fonts is helpful. I do not understand why you discussed those UTF-8 issues, they does not seem related to the problems you want to solve. Ok. You know, recent xterm supports UTF-8 mode besides conventional 8bit mode. XFree86 4.3 xterm is more improved so that it can support various encodings including ISO-8859-*, KOI8-*, EUC-*, and so on. In that mode (I call locale mode now), xterm checks the current locale and choose proper encoding automatically. For example, it can display Euro when you invoke xterm in ISO-8859-15 locales, it can display Cyrillics in KOI8-R locales, Japanese in EUC-JP locales, Thai with combining characters in TIS-620 locales, and so on. On the other hand, in conventional 8bit mode, xterm doesn't care about encodings at all and it just uses given font. This is why non-ISO- 8859-1 people have to configure their font setting for xterm even if they set LANG variable. My intension is to make the locale mode default. Internally, locale mode is implemented using the UTF-8 mode and an automatically-invoked wrapper utility luit. Because of this, the locale mode always uses Unicode font. This is why my patch includes Unicode font settings. Again, my intension is to make the locale mode default, and the Unicode font setting is mere a means for that. A side effect of my patch is that non-iso-8859-1 people don't need to install xfonts-*-transcoded packages for xterm, because xterm will always use *-iso10646-1 fonts which are available in non-transcoded versions of packages. --- Tomohiro KUBOTA [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
Hi, I reopened this bug, because: - I don't think the discussion finished. - This bug is in the to-do list in the upstream. Please don't close this bug (the upstream agrees this should be improved) until my patch will be adopted or a fixed upstream version will be available as a Debian package. --- Tomohiro KUBOTA [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
Processing commands for [EMAIL PROTECTED]: reopen 215647 Bug#215647: xterm: want ISO 10646-1 fonts used by default instead of ISO 8559-1 Bug reopened, originator not changed. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
Processing commands for [EMAIL PROTECTED]: retitle 215647 xterm: change the encoding according to the current LC_CTYPE locale Bug#215647: xterm: want ISO 10646-1 fonts used by default instead of ISO 8559-1 Changed Bug title. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
Processing commands for [EMAIL PROTECTED]: tag 215647 + wontfix Bug#215647: xterm: change the encoding according to the current LC_CTYPE locale Tags were: wontfix experimental patch Tags added: wontfix thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
tag 215647 + wontfix thanks On Thu, Oct 23, 2003 at 09:30:04AM +0900, Tomohiro KUBOTA wrote: Hi, I reopened this bug, because: - I don't think the discussion finished. - This bug is in the to-do list in the upstream. Please don't close this bug (the upstream agrees this should be improved) until my patch will be adopted or a fixed upstream version will be available as a Debian package. You are presenting me with an ultimatum: accept your patch or else. You do not appear to feel there are any grounds upon which you will change your mind. This is not a sound basis for a rational discussion. Neither are your assertions that I must remove features from XTerm simple because I have made observations about its historical development. You'd get along famously with Eduard Bloch, who argues the same way. This bug will be fixed when upstream fixes it, or when a patch that upstream is comfortable with is submitted. Tagging wontfix. -- G. Branden Robinson|Optimists believe we live in the Debian GNU/Linux |best of all possible worlds. [EMAIL PROTECTED] |Pessimists are afraid the optimists http://people.debian.org/~branden/ |are right about that. signature.asc Description: Digital signature
Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
Hi, From: Branden Robinson [EMAIL PROTECTED] Subject: Re: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n Date: Wed, 22 Oct 2003 22:11:56 -0500 You are presenting me with an ultimatum: accept your patch or else. You do not appear to feel there are any grounds upon which you will change your mind. This is not a sound basis for a rational discussion. Please discuss. It is you who avoid discussion. How do you think about the concept of locale? Please discuss with the technical points. Why do you avoid concrete discussion? It is easy. Please explain why my idea is inferior than yours rationally. If you really think so, you can do it. Can't you? Please explain why requiring editing app-defaults is better than automatic locale detection, why uxterm approach is better than locale, and so on. If you have a good reason which I didn't think about, I will agree with closing this bug. Neither are your assertions that I must remove features from XTerm simple because I have made observations about its historical development. You'd get along famously with Eduard Bloch, who argues the same way. Well, what is your intention you explained xterm's historical development? I felt that you wanted to explain the reason why xterm must not support multibyte encodings (because VT100 and so on doesn't support it). Am I right? Then, from the exactly same reason, you must remove features which VT100 and so on doesn't have and xterm has. Of course I don't agree such an explanation and I don't think you must remove such features. I don't know Eduard Bloch. This bug will be fixed when upstream fixes it, or when a patch that upstream is comfortable with is submitted. Please discuss on the concrete problems, though I am now discussing with the upstream. Anyway, the patch is completely different from the patch I sent to the upstream. How many times should I say this? Tagging wontfix. It is acceptable because there are chance for discussion or we can refer the bug, but don't close. We must not hide problems. --- Tomohiro KUBOTA [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
Quoting Branden Robinson ([EMAIL PROTECTED]): I trust you're aware of the massive rearrangement of the XKB data in 4.3.0, which is why I haven't been applying much in the way of XKB data patches. Well, no, you probably weren't. That would require reading the traffic on the debian-x mailing list, wouldn't it? Which is pretty impossible for someone (like Denis) who's involved in a lot of other matters. I've re-read this whole thread, just for trying to understand why you guys are fighting. Besides the usual effect or e-mail exchanges amplifying arguments, it seems that all involved parties are in fact people who are strongly commited to Debian, in various part. All of you (this includes me also) have probably reached the point where you cannot take more work even though you would want to. Branden, you mostly say Denis come help and discuss i18n patches in deban-x, I lack time for properly do the whole work. Denis (and Kubota-san, also AFAIK), you ask Branden to change his policy about patches, which more or less asking him more work, indirectly (as a consequence of errors triggered one day or another by bad patches). I think everybody has good intentions here, but probably different points of view. Please continue to remember this and do no jump into a useless flamewar. The solution to this problem is probably by finding more and more manpower for maintaining our packages and all stuff we want to progress in Debian. If we lack manpower, we have to make sacrifices, which is always hard to accept for people who accept them. All people involved here are good people, don't forget it when thinking about throwing knifes to each other. This was my peace and love minute (I'm a 70's man. :)). Thanks for listening. As you may see, I have no solution for your xterm problem. It will maybe fix in sarge, if all parties agree on a solution. It will maybe be fixed later, it it appears impossible to do something else. Sarge will never be perfect. Just try to make it as perfect as possible... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
On Mon, Oct 20, 2003 at 11:28:10PM +0200, Denis Barbier wrote: Nope, my sole intention was to be as assholish as you were in your original post. What a noble goal. In any case, I'd say you exceeded your own expectations. That said, I would be glad to help and subscribe to debian-x just now. I am mainly interested in improving i18n support for sarge and will first review bugreports which seem to have a trivial fix. For any XKB reports, it's going to be worth looking at the xfree86 4.3.0 packages before recommending any patches for application. -- G. Branden Robinson| You live and learn. Debian GNU/Linux | Or you don't live long. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
On Tue, Oct 21, 2003 at 07:21:19AM +0200, Christian Perrier wrote: The solution to this problem is probably by finding more and more manpower for maintaining our packages and all stuff we want to progress in Debian. If we lack manpower, we have to make sacrifices, which is always hard to accept for people who accept them. I agree with your analysis. I'm not stingy with handing out access to the X Strike Force Subversion repositories. Just ask the dozen or so people who have access (most of whom don't use it for anything -- sigh). I invite those who are frustrated with i18n/l10n issues in XFree86 to step forward and take some ownership. Deadkeys busted on French keyboards, for example? Step up. Volunteers are welcome. I do expect people to be able to work within the framework I've set up (commit disruptive stuff on a branch, write reasonable commit logs, and so forth) -- this isn't an invitation to take total control over some chunk of XFree86. The reason for that is, someone still has to take responsibility for the package as a whole, and the bug reports that get filed against it, and that someone is (still) me. But you'll have a pretty free hand to experiment; we can create a branch just for i18n/l10n improvements if need be, and that way changes there can't disrupt the trunk or 4.3.0-sid branch. -- G. Branden Robinson| The power of accurate observation Debian GNU/Linux | is frequently called cynicism by [EMAIL PROTECTED] | those who don't have it. http://people.debian.org/~branden/ | -- George Bernard Shaw signature.asc Description: Digital signature
Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
Hi, From: Branden Robinson [EMAIL PROTECTED] Subject: Re: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n Date: Tue, 21 Oct 2003 15:07:51 -0500 People using UTF-8 locales should use uxterm. No. Reasons: 1. If you say People using UTF-8 locales may have to use uxterm (or other special softwares) because the main software (xterm in this case) is not improved enough, then I may agree. However, in this case, improvement is very easily possible. 2. UTF-8 is only one of many locales. How about other locales like EUC-JP, ISO-8859-11, KOI8-R, and so on so on? Do people using EUC-JP locales should use eucjpxterm? Do people using ISO-8859-13 locales should use iso885913xterm? 3. There are already a standardized way called locale for users to set only one (or a few) variable(s) such as LANG, LC_ALL, LC_MESSAGES, LC_CTYPE to order all softwares (including xterm) to follow it. In well-i18n-ed situation, all that users have to do is just to set LANG variable, and then all softwares respect it. Why do you ignore the standardized way even when it is easily implemented? I have already wrote these reasons (in different ways). If you understand what I wrote, I expect that you will never say such a thing (People using UTF-8 locales should use uxterm). Thus, I imagine you have difficulty understanding what I wrote. Please tell me what the difficulty is. --- Tomohiro KUBOTA [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
Hi, Some supplementations: From: Tomohiro KUBOTA [EMAIL PROTECTED] Subject: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n Date: Wed, 22 Oct 2003 07:58:40 +0900 (JST) 1. If you say People using UTF-8 locales may have to use uxterm (or other special softwares) because the main software (xterm in this case) is not improved enough, then I may agree. However, in this case, improvement is very easily possible. I am saying about my patch. 2. UTF-8 is only one of many locales. How about other locales like EUC-JP, ISO-8859-11, KOI8-R, and so on so on? Do people using EUC-JP locales should use eucjpxterm? Do people using ISO-8859-13 locales should use iso885913xterm? In your idea, iso885913xterm is not needed but EUC-JP is ignored. 3. There are already a standardized way called locale for users to set only one (or a few) variable(s) such as LANG, LC_ALL, LC_MESSAGES, LC_CTYPE to order all softwares (including xterm) to follow it. In well-i18n-ed situation, all that users have to do is just to set LANG variable, and then all softwares respect it. Why do you ignore the standardized way even when it is easily implemented? This is the main point. IMO, uxterm is an evil fork and a makeshift until xterm itself will be improved enough. Or, it is a version for people who don't know LANG variable or people who just want to temporarily test UTF-8. However, if we were admit uxterm as a final solution, we would have to accept UTF-8 variants for all softwares. We would have to introduce uls, uwc, uperl, used, ugrep, and so on so on. However, fortunately, original version of ls, wc, and so on will respect locale and support UTF-8, so such an evil fork is avoided. Anyway, I think your idea is useful for some softwares except xterm, since xterm can be improved with easier patch (which I sent). --- Tomohiro KUBOTA [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
Hi, From: Branden Robinson [EMAIL PROTECTED] Subject: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n Date: Sat, 18 Oct 2003 16:11:24 -0500 There are *also* discussion and communication problems, in that I feel you were not sharing vital information with me, namely that you had already submitted your patch upstream, and it had been rejected. As I said, the patch is different. That doesn't mean I will *automatically* reject your patch, but it means that I need to understand upstream's objections, and that you may need to make a stronger case for why upstream's objections are not relevant to Debian, are outweighed by other considerations unique to our OS. I remember that Dickey objected my patch because introduction of new resources will slow down the invocation procedure of xterm. I felt that the reason is very strange, because my additional resources are not too fat - ufont, ufont1, ufont2, ... which are Unicode fonts which are used instead of font, font1, font2, and so on, while usage of non-iso10646-1 fonts in UTF-8 mode is apparently wrong though xterm automatically use UTF-8 mode in some condition. If iso10646-1 font is not used automatically, xterm's feature to automatically use UTF-8 mode is meaningless, I think. He might say some additional reasons which I forget. Anyway, I will have to find discussion from my mail archive or discuss with Mr. Dickey again He didn't say that, but he may have read the patch hastily and assumed it was. Well, then did he change his idea on the current patch? Anyway, I think different patch should be appropriate between XFree86 and Debian. In XFree86 (upstream) level, addition of resources is more appropriate than my current patch. It is because xterm in upstream level may be run on various platforms with completely different set of fonts. Thus, the default font must be a font named fixed (which is always available) in the upstream level. Addition of resources will enable automatic usage of Unicode fonts and the default of fixed at the same time. On the other hand, addition of resources in Debian level is, as you might think, not very good because it is too much modified from the upstream. Also, since fonts in my patch are available in xfonts-base package in Debian, these font names are less problematic than upstream level. So, please think your own reason to reject/accept/modify my patch, apart from the different patch for the upstream and Mr. Dickey's opinion. BTW, unlike Mr. Martin Quinson may think, my patch is useful not only for CJK people but also for all non-ISO-8859-1 people. Since there are less ISO-8859-1 countries because of introduction of Euro, my patch benefits many people (and no harm for other people in US, UK, and so on). For years now I've wanted to arrange things such that the very generic X font aliases fixed, proportional, 5x7, and so forth would go through another layer of indirection; one that would allow people to choose a codeset for the font that would make sense for their locale. I had this idea way back when xfonts-cyrillic was called xfonts-cyr. I think this way may be useful for some people, if the aliases are set automatically according to the current LC_CTYPE locale. (There are already a standardized way (LC_CTYPE) to choose a codeset and we should not introduce different configuration ways for users to achieve the same thing.) However, since this is not useful for multibyte people nor UTF-8, we will need additional works anyway. Especially, UTF-8 will be more and more important in future. Thus, this idea does not reduce the amount of needed work. --- Tomohiro KUBOTA [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
On Sat, Oct 18, 2003 at 04:02:34PM -0500, Branden Robinson wrote: [...] Let's not forget, although apparently you have, that I was one of the first adopters of po-debconf. Given how often your own localization patches have been submitted and accepted (usually pretty promptly -- the next package release), I assume you're grandstanding for the audience on -i18n, because anyone who follows -x knows that your accusations are bullshit. Nope, my sole intention was to be as assholish as you were in your original post. That said, I would be glad to help and subscribe to debian-x just now. I am mainly interested in improving i18n support for sarge and will first review bugreports which seem to have a trivial fix. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
On Fri, Oct 17, 2003 at 09:36:31PM +0200, Denis Barbier wrote:
On Fri, Oct 17, 2003 at 10:52:47AM -0500, Branden Robinson wrote:
[...]
The bug submitter had already contacted the upstream maintainer of
XTerm, and the patches had been rejected by him. Apparently, the
submitter's goal was to get Debian to fork from upstream after the exact
same change had been rejected upstream.
If I follow you, Debian libtool must not be patched too.
1) My policy of not deviating from upstream is a rule of thumb, not a
straightjacket.
2) I'm not the libtool maintainer. If you have some strong emotion
about Debian not patching its libtool, then complain to him. But
don't you dare imply that *I* feel Debian's libtool shouldn't be
patched. I don't know enough about libtool to say.
It is sometimes easier to patch Debian packages because we know that
some tools are available. For instance in #179929 the same upstream
rejected a patch because GNU sed is needed, and you did not apply
it too. Do you have any good reason?
Your question presumes that there exists an answer you'd consider
good, and I suspect there isn't. So I'm not going to play that game.
And the fix is trivial, sed -e 's/[EMAIL PROTECTED]//' should do the trick without
GNU sed.
Thanks for reminding me that I need to tag the bug as
fixed-in-experimental.
I didn't see you offering to help prepare a patch suitable for
submission to the upstream maintainer back when it mattered.
Are you kidding? On the one hand patches are rejected without even
telling why, and on the other hand forks are considered as unfriendly.
I've told you why. The upstream maintainer considers the patch
unsuitable. Gratuitous forks *are* considered unfriendly, at least when
they're placed in Debian's upload queue. We've since learned that that
was inadvertent.
Our Social Contract says We Won't Hide Problems.
Given the amount of trivial bugreports related to i18n with patches
against xterm/xlibs, your interpretation seems to be We Will Expose
Problems via the BTS.
I can't test a lot of the patches that are submitted (for example,
because I don't have the proper environment configured or don't own a
non-US keyboard -- incidentally, it's extremely rare that someone with
an alternative localization setup includes that information in the bug
report; in fact, it's rare that any information on how to reproduce the
bug is given at all). I've tried applying patches blindly before, and
it often results in things breaking for other people. Many patches I
get are just flat-out wrong.
XFree86 is team-maintained these days. If you think you can be a team
player, ask to join. If all you can do is bitch about how things aren't
being handled to suit your tastes, my preference is that you'd just go
away.
After reading other i18n related bugreports, I have the feeling that
you won't apply a patch not approved by upstream, even if it is a
trivial fix for a real problem.
I won't apply a patch if I don't understand how it works, cannot test
it, and do not have anyone I trust to whom I can turn to does.
My extreme hostility to i18n is obviously clearly reflected in my
failure to ever merge any Debconf template translations.
* debian/po/ja.po: update Japanese translations (thanks, Kenshi Muto and
Takeo Nakano)
* debian/po/pt_BR.po: updated Brazilian Portuguese translations (thanks,
Andre Luis Lopes) (Closes: #206949)
* debian/po/fr.po: updated French translations (thanks, Christian Perrier)
(Closes: #207239)
* debian/po/fr.po: updated French translations (thanks, Christian Perrier)
(Closes: #207239)
* debian/po/fr.po: update French debconf template translations (thanks,
* debian/po/ca.po: updated Catalan debconf template translations (thanks,
Ivan Vilata i Balaguer) (Closes: #183317,#183322)
* debian/po/{da,de,gl,it,ja,nl,pl,sv}.po: updated debconf template
translations for several languages courtesy of Denis Barbier, after a
buggy version of po-debconf eviscerated them (Closes: #170591)
* debian/po/es.po: updated Spanish debconf template translations (thanks,
Javier Fernandez-Sanguino Peña) (Closes: #186147)
* debian/po/fr.po: updated French debconf template translations (thanks,
Christian Perrier) (Closes: #185708)
* debian/po/ru.po: updated Russian debconf template translations (thanks,
Serge Winitzki) (Closes: #182701)
* debian/po/pt_BR.po: updated debconf translations for Brazilian Portuguese
(thanks, Andre Luis Lopes) (Closes: #179352)
* debian/xdm.templates.nl: added Dutch translation (thanks, Wouter Verhelst)
(Closes: #139229)
* debian/xserver-common.templates.nl: added Dutch translation (thanks,
Wouter Verhelst) (Closes: #139230)
* debian/xserver-xfree86.templates.nl: added Dutch translation (needs
update) (thanks, Wouter Verhelst) (Closes: #139231)
* debian/xserver-xfree86.templates.sv: updated Swedish translation (needs
update) (thanks, Mikael
Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
On Sat, Oct 18, 2003 at 05:28:44AM +0900, Tomohiro KUBOTA wrote: From: Branden Robinson [EMAIL PROTECTED] Subject: Re: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n Date: Fri, 17 Oct 2003 10:52:47 -0500 It was an upstream decision which I elected to respect. Ok, I understand that you don't think there are any technical problem on my patch. You think the problem is on the discussion and communication procedure. That's not correct. The upstream maintainer informed me that there were technical problems with your patch. There are *also* discussion and communication problems, in that I feel you were not sharing vital information with me, namely that you had already submitted your patch upstream, and it had been rejected. That doesn't mean I will *automatically* reject your patch, but it means that I need to understand upstream's objections, and that you may need to make a stronger case for why upstream's objections are not relevant to Debian, are outweighed by other considerations unique to our OS. I have ever sent a similar patch to the upstream. I imagine it was one year (or more) ago. However, though the goals of the patches are similar, they are different. My previous patch to the upstream was for the xterm's source itself, while this time for the configuration file. If I remember correctly, the previous patch introduced some new resources to prevent *-iso10646-1 fonts be used in conventional 8bit mode, which is not included in this time patch at all. Yes, Mr. Dickey said some things that puzzled me a little bit. I did notice that your patch changed only the XTerm app-defaults file. In short, intent is same, implementation is diffierent. Since this time patch is for configuration file, I thought it may be applicable for distribution level. (It may also be applicable for upstream level. Either may be OK.) Did Mr. Dickey say that my patch is same as the previous one which was rejected? Then, anyway, I need to discuss with the upstream. He didn't say that, but he may have read the patch hastily and assumed it was. I think KUBOTA-san's effort to sneak his changes in through the backdoor, as it were, without apprising me of his earlier failed efforts to get them accepted upstream, was an underhanded and dishonest thing to do. Completely different implementation. This criticism should not be appropriate. Also, many Debian packages have their own configuration file which are different from the upstream. In general, small modifications for configuration file are not considered as a fork. That's true. However I'm still not sure that your alteration to the configuration is an alteration that needs to be made the Debian default. The app-defaults files are conffiles for a reason. For years now I've wanted to arrange things such that the very generic X font aliases fixed, proportional, 5x7, and so forth would go through another layer of indirection; one that would allow people to choose a codeset for the font that would make sense for their locale. I had this idea way back when xfonts-cyrillic was called xfonts-cyr. Then, we'd get something effectively the same as your xterm patch, but which would apply to all XLFD-using applications, which seems like a win. However, I've never had time to implement this. Is anyone interested in this task? -- G. Branden Robinson| There's nothing an agnostic can't Debian GNU/Linux | do if he doesn't know whether he [EMAIL PROTECTED] | believes in it or not. http://people.debian.org/~branden/ | -- Graham Chapman signature.asc Description: Digital signature
Re: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
On Fri, Oct 17, 2003 at 09:36:31PM +0200, Denis Barbier wrote: On Fri, Oct 17, 2003 at 10:52:47AM -0500, Branden Robinson wrote: [...] The bug submitter had already contacted the upstream maintainer of XTerm, and the patches had been rejected by him. Apparently, the submitter's goal was to get Debian to fork from upstream after the exact same change had been rejected upstream. If I follow you, Debian libtool must not be patched too. [EMAIL PROTECTED]:~/debian/xfree86/xsf-repo/branches/4.3.0/sid/debian/patches% wc -l * | tail -1 ls -l | wc -l 106899 total 125 -- Daniel Stone [EMAIL PROTECTED] http://www.debian.org - http://www.kde.org - http://www.freedesktop.org What's next? People turning up on my doorstep, observing that the lack of doorbell is likely to confuse people and hence removing my front door? -- David Woodhouse on usability efforts, Advogato pgp0.pgp Description: PGP signature
Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
On Tue, Oct 14, 2003 at 11:22:06AM +0900, Tomohiro KUBOTA wrote: Hi, From: Branden Robinson [EMAIL PROTECTED] Subject: Re: [patch] xterm 4.3.0-0pre1v3 i18n Date: Mon, 13 Oct 2003 14:44:21 -0500 Please file a bug and tag it experimental. Ok, I did. You should have requested to tag it directly wontfix, you would have saved yourself some work ;) Or was the discussion with upstream done in the meantime? Also, I object to your patch unless the changed font names are confined to UXTerm's application-defaults, not XTerms. Why? What is the reason? On the other hand, the current situation is apparently buggy - Mojibake occurs. See the following page: http://www.debian.or.jp/~kubota/mojibake/xterm.html I also fail to understand why the xterm program should be unusable by CJK people when the fix is so lightweighted. I may well be missing the point, but I'd like to have more details if possible. Branden, could you please provide more information about why this patch is not good, and what should be changed in it to make it acceptable? Or if you have other ideas to make xterm usable to CKJ people not willing to use UTF, could you enlight us, please? For example, what are the arguments used by upstream to convince you that this patch was bad ? I am sorry to whine that way, but I'd really like to understand the situation here. I'd be more than happy if your answer contains nothing but a bunch of pointers. Thanks for your time, Mt. -- I'm not griping, I'm just observing what a miserable experience this is. --- Calvin pgp0.pgp Description: PGP signature
Re: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
On Fri, Oct 17, 2003 at 01:14:31PM +0200, Martin Quinson wrote: You should have requested to tag it directly wontfix, you would have saved yourself some work ;) Or was the discussion with upstream done in the meantime? Yes, discussion was done with upstream in the meantime. I also fail to understand why the xterm program should be unusable by CJK people when the fix is so lightweighted. I may well be missing the point, but I'd like to have more details if possible. I'll ask Mr. Dickey if he'd like to share his reasoning with the list. Branden, could you please provide more information about why this patch is not good, and what should be changed in it to make it acceptable? It was an upstream decision which I elected to respect. Or if you have other ideas to make xterm usable to CKJ people not willing to use UTF, could you enlight us, please? For example, what are the arguments used by upstream to convince you that this patch was bad ? Since they came in private mail, I feel it is better to let Mr. Dickey make his case, if he chooses to. I am sorry to whine that way, but I'd really like to understand the situation here. I'd be more than happy if your answer contains nothing but a bunch of pointers. The bug submitter had already contacted the upstream maintainer of XTerm, and the patches had been rejected by him. Apparently, the submitter's goal was to get Debian to fork from upstream after the exact same change had been rejected upstream. I think KUBOTA-san's effort to sneak his changes in through the backdoor, as it were, without apprising me of his earlier failed efforts to get them accepted upstream, was an underhanded and dishonest thing to do. When the Debian-JP Project merged with Debian, the understanding was the Debian-JP maintainers would work with upstream authors and their fellow non-JP Debian developers in an open and communicative fashion, instead of just forking everything behind a wall of silence. In the instant case, I feel that pledge has been violated. It's happened again, just within the past day, with xft-cjk; while the person who inadvertently uploaded it to auric's queue wasn't a Debian Developer (the upload was rejected), there is probably at least one Debian developer who is aware of these patches. Has there ever been a bug filed against xft about the issues which that patch seeks to address? No. Our Social Contract says We Won't Hide Problems. I do not feel that that principle is being upheld very well by some of our developers. That KUBTOA-san has a patch for xterm that was rejected by upstream was a problem. He didn't tell me of his patch's past history with the upstream maintainer. He hid it instead. There are patches for Xft that putatively fix some CJK localization issues. Those issues have not been brought to the attention of the X Strike Force. Any Debian Developer who was aware of them and did not communicate this information to the debian-x list (or via a bug report) is hiding the problem. -- G. Branden Robinson| Debian GNU/Linux | Please do not look directly into [EMAIL PROTECTED] | laser with remaining eye. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
On Fri, Oct 17, 2003 at 10:52:47AM -0500, Branden Robinson wrote: [...] The bug submitter had already contacted the upstream maintainer of XTerm, and the patches had been rejected by him. Apparently, the submitter's goal was to get Debian to fork from upstream after the exact same change had been rejected upstream. If I follow you, Debian libtool must not be patched too. I think KUBOTA-san's effort to sneak his changes in through the backdoor, as it were, without apprising me of his earlier failed efforts to get them accepted upstream, was an underhanded and dishonest thing to do. It is sometimes easier to patch Debian packages because we know that some tools are available. For instance in #179929 the same upstream rejected a patch because GNU sed is needed, and you did not apply it too. Do you have any good reason? And the fix is trivial, sed -e 's/[EMAIL PROTECTED]//' should do the trick without GNU sed. When the Debian-JP Project merged with Debian, the understanding was the Debian-JP maintainers would work with upstream authors and their fellow non-JP Debian developers in an open and communicative fashion, instead of just forking everything behind a wall of silence. In the instant case, I feel that pledge has been violated. It's happened again, just within the past day, with xft-cjk; while the person who inadvertently uploaded it to auric's queue wasn't a Debian Developer (the upload was rejected), there is probably at least one Debian developer who is aware of these patches. Has there ever been a bug filed against xft about the issues which that patch seeks to address? No. Are you kidding? On the one hand patches are rejected without even telling why, and on the other hand forks are considered as unfriendly. Our Social Contract says We Won't Hide Problems. Given the amount of trivial bugreports related to i18n with patches against xterm/xlibs, your interpretation seems to be We Will Expose Problems via the BTS. I do not feel that that principle is being upheld very well by some of our developers. That KUBTOA-san has a patch for xterm that was rejected by upstream was a problem. He didn't tell me of his patch's past history with the upstream maintainer. He hid it instead. After reading other i18n related bugreports, I have the feeling that you won't apply a patch not approved by upstream, even if it is a trivial fix for a real problem. So I would have behaved the exact same way as Kubota-san did. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
Hi, From: Branden Robinson [EMAIL PROTECTED] Subject: Re: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n Date: Fri, 17 Oct 2003 10:52:47 -0500 It was an upstream decision which I elected to respect. Ok, I understand that you don't think there are any technical problem on my patch. You think the problem is on the discussion and communication procedure. The bug submitter had already contacted the upstream maintainer of XTerm, and the patches had been rejected by him. Apparently, the submitter's goal was to get Debian to fork from upstream after the exact same change had been rejected upstream. I have ever sent a similar patch to the upstream. I imagine it was one year (or more) ago. However, though the goals of the patches are similar, they are different. My previous patch to the upstream was for the xterm's source itself, while this time for the configuration file. If I remember correctly, the previous patch introduced some new resources to prevent *-iso10646-1 fonts be used in conventional 8bit mode, which is not included in this time patch at all. In short, intent is same, implementation is diffierent. Since this time patch is for configuration file, I thought it may be applicable for distribution level. (It may also be applicable for upstream level. Either may be OK.) Did Mr. Dickey say that my patch is same as the previous one which was rejected? Then, anyway, I need to discuss with the upstream. I think KUBOTA-san's effort to sneak his changes in through the backdoor, as it were, without apprising me of his earlier failed efforts to get them accepted upstream, was an underhanded and dishonest thing to do. Completely different implementation. This criticism should not be appropriate. Also, many Debian packages have their own configuration file which are different from the upstream. In general, small modifications for configuration file are not considered as a fork. --- Tomohiro KUBOTA [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
