Re: [gentoo-dev] UTF-8 locale by default
On 01-08-2012 21:00:23 -0400, Mike Gilbert wrote: Diego mentioned the python issue. Honestly, if some asian person has whatever charset that I often find in spam messages, but is not UTF-8, are you then going to tell that person to switch to UTF-8 to get those python packages emerged? I hope not. There is a difference between there is a UTF-8 locale available on the system and en_US.UTF-8 locale is in effect. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] UTF-8 locale by default
On Thu, 2012-08-02 at 08:42 +0200, Fabian Groffen wrote: On 01-08-2012 21:00:23 -0400, Mike Gilbert wrote: Diego mentioned the python issue. Honestly, if some asian person has whatever charset that I often find in spam messages, but is not UTF-8, are you then going to tell that person to switch to UTF-8 to get those python packages emerged? I hope not. Yes. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] UTF-8 locale by default
On 01/08/2012 23:42, Fabian Groffen wrote: Honestly, if some asian person has whatever charset that I often find in spam messages, but is not UTF-8, are you then going to tell that person to switch to UTF-8 to get those python packages emerged? I hope not. Tell that to the Python team I guess. My tinderbox _has_ utf8 locales available, but doesn't set in by default - Python stuff fails to build or test - not going to be fixed with change your locale reasoning. Is it mental? Yes. Would I like that to change? Yes. Do I care ẃhether that's through the use of cluebyfour on the Python team or by setting an utf-8 locale by default? Not in the least. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: UTF-8 locale by default
Peter Stuge posted on Thu, 02 Aug 2012 07:36:07 +0200 as excerpted: Walter Dnes wrote: The fact that other distros do it does not constitute justification for us to do it. Unfortunately that exact reason, along with Fedora is doing it, was cited by a very active developer as reason to reject technical points which I tried to make a few times. But that is off-topic. Let's leave it for later. All I'm saying is don't underestimate pack mentality. I don't know if it applies here, but there's a difference between other distros do it, and that's the way upstream created it. If upstream is effectively another distro, the first might be true as well, but gentoo has always had a policy of trying to do it upstream's way unless there's a good reason not to, and that's quite different than just following the distro pack. (You likely know this already, but other readers may not, so I'm emphasizing it.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] UTF-8 locale by default
On Thu, Aug 2, 2012 at 2:21 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 01/08/2012 23:42, Fabian Groffen wrote: Honestly, if some asian person has whatever charset that I often find in spam messages, but is not UTF-8, are you then going to tell that person to switch to UTF-8 to get those python packages emerged? I hope not. Tell that to the Python team I guess. My tinderbox _has_ utf8 locales available, but doesn't set in by default - Python stuff fails to build or test - not going to be fixed with change your locale reasoning. Is it mental? Yes. Would I like that to change? Yes. Do I care ẃhether that's through the use of cluebyfour on the Python team or by setting an utf-8 locale by default? Not in the least. Please apply the cluebyfour to the upstream developers of python and python modules. :-) I do try to fix unicode problems if I run into them. However, sometimes it just isn't worth the effort.
Re: [gentoo-dev] UTF-8 locale by default
On Thu, 02 Aug 2012 11:21:40 -0700 Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 01/08/2012 23:42, Fabian Groffen wrote: Honestly, if some asian person has whatever charset that I often find in spam messages, but is not UTF-8, are you then going to tell that person to switch to UTF-8 to get those python packages emerged? I hope not. Tell that to the Python team I guess. My tinderbox _has_ utf8 locales available, but doesn't set in by default - Python stuff fails to build or test - not going to be fixed with change your locale reasoning. not that it is hard to set LC_ALL=sth before running the failing command, or make the pm do it... we already fix regexp bugs with other locales (or workaround them by setting LC_ALL=C), it falls under the same category. you just need to teach people, and maybe mandate an utf8 locale to be present; the same way they do not consider estonian alphabet ordering 'broken' they would not consider not having an utf8 locale 'broken', esp. when said utf8 is far from being optimal in terms of size for asian languages. A.
Re: [gentoo-dev] UTF-8 locale by default
On 31 July 2012 05:33, Michael Orlitzky mich...@orlitzky.com wrote: On 07/30/12 12:28, Michał Górny wrote: My point here is that you want the thing to change. So you first try to convince people here to change. We practically did a small survey here and in the result we didn't agree on doing the change. So you're saying we should do another survey on another group, hoping that this time the result will be on your side. We didn't do a survey, we asked, Is there a reason for not using at least en_US.UTF-8 as a sane default value? Unsurprisingly, the responses contained reasons for not using en_US.UTF-8 as the default. I think its a shame that : 1. the current handbook way to change timezone is manually editing a file. 2. the handbook doesn't mention `eselect locale` 3. `eselect locale list` is useless if you have *all* locales available to you. 4. `eselect locale` can only set the LANG variable. 5. that eselect doesn't have an interactive mode yet. Why? because this problem could be made simpler by providing a way to use a recommended locale for your timezone, which is likely to yield a more sane default for that timezone. It would also make it easier to validate the value the user chooses for their Timezone value. Consider: eselect timezone list # all level 1 timezones + groups , ie: like ls /usr/share/zoneinfo eselect timezone list America/ # contents of /usr/share/zoneinfo/America eselect timezone set America/Chicago # /etc/timezone is updated to 'America/Chicago' # /etc/localtime is replaced with /usr/share/zoneinfo/America/Chicago eselect locale set --all auto # LANG and LC_* are set using the values defined as default for America/Chicago eselect locale set --ctype auto # Only LC_CTYPE is autopopulated. eselect locale list # 600 items because you have a vanilla locale.defs eselect locale list --timezone # shows a list of LOCALE values for the current TZ, with the one that would be used as default first/marked up differently eselect locale list en # shows english locale options eselect locale set --ctype en_US.utf8 The benefits of setting these locales this way are obvious to me at least, you can set locales to a value that is sensible automatically. You also can validate a users choice of locale and provide feedback, such as, you can list non-installed locales, and then tell the user if thy try to use a locale that isn't installed yet they need to update locales.def The only way I can suggest something better, would be an interactive locale setter, something like 'tzselect' , except sets timezone *and* locale information, with the ability to automatically update locales.def and add new locale definitions and regenerate the locale database. This way, you could have a selection process more like this: https://gist.github.com/3240866 #? 1 The following information has been given: United States Eastern Time Therefore TZ='America/New_York' will be used. Local time is now: Thu Aug 2 17:33:17 EDT 2012. Universal Time is now: Thu Aug 2 21:33:17 UTC 2012. Is the above information OK? 1) Yes 2) No #? 1 Your Current locale settings are: LANG=POSIX The recommended settings for your locale are : LANG=en_US.utf8 LC_CTYPE=en_US.utf8 Do you wish to change your locale settings at this time? 1) No 2) Yes - Use recommended settings 3) Yes - Configure locale interactively. At least this way, the effort required to configure your system into a very good logical UTF8 default is trivial. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] UTF-8 locale by default
On 07/27/2012 07:24 PM, Mike Frysinger wrote: yes, and i'm waiting on the POSIX group to formalize C.UTF-8. that's the only real option in my mind for making unicode the default. any other amalgamations of various locales is ugly as sin. When they meet? I'd be fine with a pre-release =P lu
Re: [gentoo-portage-dev] How to prevent dispatch-conf from reverting valid changes
On 08/01/2012 11:36 PM, Pacho Ramos wrote: El mié, 01-08-2012 a las 16:14 -0700, Zac Medico escribió: On 08/01/2012 03:19 AM, Pacho Ramos wrote: On every openrc update I get dispatch-conf wanting to revert all my changes in /etc/conf.d files, like KEYMAP, clock... Is there any way to prevent it from doing that? Thanks a lot for the info Maybe we can trace the behavior back to the diff3 command that it's using. Inside /usr/lib/portage/pym/portage/dispatch_conf.py we have this command: DIFF3_MERGE = diff3 -mE '%s' '%s' '%s' '%s' Are you able to reproduce the problem by running this command manually? Something like this: diff3 -mR /etc/conf.d/hostname \ /etc/config-archive/etc/conf.d/hostname.dist \ /etc/conf.d/._cfg_hostname /tmp/mrgconf I will probably need to reemerge it as I already merged changes and re-edited config files. Anyway, diff3 looks to not admit -R option: $ diff3 -mR /etc/conf.d/hostname /etc/config-archive/etc/conf.d/hostname.dist /etc/conf.d/._cfg_hostname diff3: opción inválida -- R diff3: Pruebe `diff3 --help' para más información. Sorry, that -mR a typo. As you can see in the DIFF3_MERGE value above, it's diff -mE. -- Thanks, Zac
