Re: [gentoo-dev] Re: Dropping localepurge
On Tue, Jan 31, 2012 at 10:17:56AM -0500, Mike Frysinger wrote: On Monday 30 January 2012 19:39:03 »Q« wrote: AIUI, LINGUAS is the only variable that should affect what locale stuff gets installed. Is that right? yes -mike This should also affect man pages installation? Looking at LC_MESSAGES it doesn't look that bad. But man pages are out of control. Piotr Szymaniak. -- Stajesz sie odpowiedzialny na zawsze za to, co oswoiles. -- Antoine De Saint-Exupery, Le Petit Prince signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Dropping localepurge
120130 »Q« wrote: I'll start filing bugs (as time permits - this doesn't seem like an urgent issue to me) and see what happens. Today's offender was webkit, putting a lot of stuff in /usr/share/locale/*/LC_MESSAGES/ I've filed bugs 401525 + 401563 for Rekonq + Sane-backends. I plan to run 'localepurge' every week after I've done a system update submit further bugs for each offending pkg. At least for now, 'localepurge' makes this process much easier, so it should remain available until all offenders have been reported. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] Re: Dropping localepurge
On Monday 30 January 2012 19:39:03 »Q« wrote: AIUI, LINGUAS is the only variable that should affect what locale stuff gets installed. Is that right? yes -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Dropping localepurge
On E, 2012-01-30 at 06:56 -0500, Philip Webb wrote: 120130 Mart Raudsepp wrote: Do you even have LINGUAS set in /etc/make.conf or something? Because at least evince, gdk-pixbuf, xkeyboard-config and gnome-doc-utils DO honor LINGUAS. All GNOME packages that use intltool (that is pretty much everything except a few low-level libraries) honor LINGUAS much more than localepurge would ever be able clean afterwards. For example, .desktop files only have translation lines for languages listed in LINGUAS. Same for gconf and dconf schemas. Also all end-user documentation in /usr/share/gnome/help/appname/lang_code/ Per above, we would close at least 4 of those bugs as INVALID or at least OBSOLETE (if some older version had it wrong). At least in GNOME we feel quite strong about things properly honoring LINGUAS per old standard GNU conventions. This means installing ALL translations if LINGUAS is unset, and none if LINGUAS is set to an empty string. Above said, I also do find a use on some systems for localepurge, to catch the packages that don't honor it. Though for embedded deployments I might as well not include the non-interesting language directories in the image. Thanks for the useful polite response. I will look into LINGUAS. How to set it is not mentioned in make.conf.example or in man make.conf : where is it documented ? http://www.gentoo.org/doc/en/guide-localization.xml#doc_chap3 covers this. I presume you only have things set in /etc/locale.nopurge or so then, and wrongly expect packages to honor it. Specific packages do not and can not look at that file, as it's localepurge specific and upstream projects shouldn't have any knowledge of it. LINGUAS is the standard environment variable for this with gettext based systems, and intltool honors it as well. I remember a longer description of it in some info file, but right now only found http://www.gnu.org/software/gettext/manual/html_node/Installers.html Bugs are hopefully appreciated by maintainers for packages that don't honor that environment variable (set via /etc/make.conf). If an upstream doesn't honor it, they are probably just not using the standard autoconf/automake glue for it correctly (or use a different build system support for it wrongly or the build system is suboptimal on this). Some Gentoo packages also have a LINGUAS USE_EXPAND, so show up in emerge --verbose --ask world and similar outputs. This is typically used when extra downloads are necessary for the languages (e.g firefox or libreoffice per-language packs), and often don't honor the LINGUAS unset == all languages convention. Packages that don't need any extra downloads or long building time do not expose this as USE_EXPAND USE flags and just silently work it out in their build system, and that's the most reasonable approach for us. Hope this helps, Mart Raudsepp
Re: [gentoo-dev] Re: Dropping localepurge
120130 Mart Raudsepp wrote: On E, 2012-01-30 at 06:56 -0500, Philip Webb wrote: Thanks for the useful polite response. I will look into LINGUAS. How to set it is not mentioned in make.conf.example or in man make.conf : where is it documented ? http://www.gentoo.org/doc/en/guide-localization.xml#doc_chap3 I presume you only have things set in /etc/locale.nopurge and wrongly expect packages to honor it. Specific packages do not and can not look at that file, as it's localepurge specific and upstream projects shouldn't have any knowledge of it. LINGUAS is the standard environment variable for this with gettext based systems, and intltool honors it as well. I remember a longer description of it in some info file, but right now only found http://www.gnu.org/software/gettext/manual/html_node/Installers.html Bugs are hopefully appreciated by maintainers for packages that don't honor that environment variable set via /etc/make.conf. I added a line 'LINGUAS=en' to make.conf rebooted, emerged the 6 pkgs I listed in a previous msg ran 'localepurge' again. This time, only 'rekonq' 'sane-backends' offended. If an upstream doesn't honor it, they are probably just not using the standard autoconf/automake glue for it correctly or use a different build system support for it wrongly or the build system is suboptimal on this. I'm surprised at 'sane-backends', which is a longstanding app, but 'rekonq' is a recent invention may need informing re the issue. Some Gentoo packages also have a LINGUAS USE_EXPAND, so show up in emerge --verbose --ask world and similar outputs. This is typically used when extra downloads are necessary for the languages (e.g firefox or libreoffice per-language packs) and often don't honor the LINGUAS unset == all languages convention. Packages that don't need any extra downloads or long building time do not expose this as USE_EXPAND USE flags and just silently work it out in their build system, and that's the most reasonable approach for us. Yes, I've seen it in output for 'emerge -pv' for FF LO. Hope this helps, Yes, that's exactly the kind of response users need: LINGUAS is some way down the doc you refer to I assumed LANG was enough. I also realised that as 'localepurge' is a script, I can move it to /usr/local/bin/ , if it does fall out of the tree. I will file bugs for the 2 offending pkgs above leave the hard-working devs to get on with their other affairs. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] Re: Dropping localepurge
On Mon, Jan 30, 2012 at 02:32:13PM +0200, Mart Raudsepp wrote I remember a longer description of it in some info file, but right now only found http://www.gnu.org/software/gettext/manual/html_node/Installers.html [...deletia...] Some Gentoo packages also have a LINGUAS USE_EXPAND, so show up in emerge --verbose --ask world and similar outputs. This is typically used when extra downloads are necessary for the languages (e.g firefox or libreoffice per-language packs), and often don't honor the LINGUAS unset == all languages convention. A question about LINGUAS settings, or the documentation thereof. The URL you pointed to says LINGUAS should then contain a space separated list of two-letter codes, stating which languages are allowed.. But emerge -pv firefox (and others) contains a list of 2 and 5 character codes, e.g. en and -en_GB -en_ZA. How is that handled? -- Walter Dnes waltd...@waltdnes.org
[gentoo-dev] Re: Dropping localepurge
On Sun, 29 Jan 2012 14:09:57 -0500 Mike Frysinger vap...@gentoo.org wrote: On Sunday 29 January 2012 00:01:50 Philip Webb wrote: Below is the output from 'localepurge' after this week's system update. Please don't drop it till 'should' does = 'does'. the vast majority of that output comes from like 3 or 4 packages. file bugs if you want things to actually get fixed. -mike That was only from one week of updates. localepurge routinely cleans quite a bit for me, though I can't guess how many packages. I'll start filing bugs (as time permits - this doesn't seem like an urgent issue to me) and see what happens. AIUI, LINGUAS is the only variable that should affect what locale stuff gets installed. Is that right? Before filing bugs, I'd like to be sure my results aren't because of bad settings on my end. I have $ grep -i linguas /etc/make.conf LINGUAS=en_US en $ env | grep LANG LANG=en_US.UTF-8 LANGUAGE= $ env | grep LC_ LC_CTYPE=en_US.UTF-8 Today's offender was webkit, putting a lot of stuff in /usr/share/locale/*/LC_MESSAGES/
[gentoo-dev] Re: Dropping localepurge
On Mon, 30 Jan 2012 16:58:30 -0500 Walter Dnes waltd...@waltdnes.org wrote: A question about LINGUAS settings, or the documentation thereof. The URL you pointed to says LINGUAS should then contain a space separated list of two-letter codes, stating which languages are allowed.. But emerge -pv firefox (and others) contains a list of 2 and 5 character codes, e.g. en and -en_GB -en_ZA. How is that handled? A locale name is generally named ab_CD where ab is your two (or three) letter language code (as specified in ISO-639) and CD is your two letter country code (as specified in ISO-3166). Look in /usr/share/locale to get an idea of what is available. -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
