[gentoo-dev] RFC patch for subversion.eclass (bug 401737)
Hi,
any objections against following patch for subversion.eclass?
Fixes bug 401737. Basically respects ESVN_{USER,PASSWORD} during
reemerge of a package.
--- subversion.eclass 2012-02-07 11:56:27.0 +0200
+++ subversion.eclass 2012-02-07 11:59:38.0 +0200
@@ -469,7 +469,9 @@
local target="${1}"
local key="${2}"
- env LC_ALL=C svn info "${target}" | grep -i "^${key}" | cut -d" " -f2-
+ env LC_ALL=C svn info \
+ ${options} --username "${ESVN_USER}" --password
"${ESVN_PASSWORD}" \
+ "${target}" | grep -i "^${key}" | cut -d" " -f2-
}
## -- subversion__get_repository_uri()
--- #
justin
[gentoo-dev] Help on getting media-libs/svgalib fixed
Hello You can see current opened bugs for svgalib here: https://bugs.gentoo.org/buglist.cgi?quicksearch=media-libs% 2Fsvgalib;list_id=812773 Most of them already contain a patch that is supposed to fix each bug report, the problem is that svgalib doesn't build at all on amd64 and, then, would be interesting if anybody with a x86 system could check if patches fix the problems and commit them. Thanks a lot :-) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: LANG=en_GB.UTF-8 by default
Excerpts from Ben's message of 2012-02-19 03:04:19 +0100: > On 19 February 2012 09:00, James Cloos wrote: > > Without LC_COLLATE="C" things like [a-z]* gets a false=positive > > match on files like Makefile. [...] > > > > The real fix is to have root be C.UTF-8. Which differs from C only > > in that the charset is utf-8. > > In my opinion we should set a default environment with the following > values: > > LANG=en_US.UTF-8 > LC_ALL= > LC_COLLATE=C This is only on my setups or this is "xy_XY.utf8" instead of "xy_XY.UTF-8"? -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Re: LANG=en_GB.UTF-8 by default
> On Sun, 19 Feb 2012, Ben wrote: > In my opinion we should set a default environment with the following > values: > LANG=en_US.UTF-8 > LC_ALL= > LC_COLLATE=C > This offers the best default options to the majority of users, and > is easy to customize for those who wish to use another locale. At least, LC_NUMERIC=C should be added to this, otherwise numbers will be formatted with commas as thousands separators. Also en_US.UTF-8 for LC_MEASUREMENT and LC_PAPER means imperial units and letter paper, which isn't optimal for users outside of the U.S. Ulrich
Re: [gentoo-dev] Re: LANG=en_GB.UTF-8 by default
On 19 February 2012 23:14, Ulrich Mueller wrote: >> On Sun, 19 Feb 2012, Ben wrote: > >> In my opinion we should set a default environment with the following >> values: > >> LANG=en_US.UTF-8 >> LC_ALL= >> LC_COLLATE=C > >> This offers the best default options to the majority of users, and >> is easy to customize for those who wish to use another locale. > > At least, LC_NUMERIC=C should be added to this, otherwise numbers will > be formatted with commas as thousands separators. > > Also en_US.UTF-8 for LC_MEASUREMENT and LC_PAPER means imperial units > and letter paper, which isn't optimal for users outside of the U.S. > > Ulrich > I think those users (and that includes myself) should then set LANG to something more appropriate to their use case. Ben
[gentoo-dev] Re: LANG=en_GB.UTF-8 by default
On 19/02/2012 15:56, Ben wrote: On 19 February 2012 23:14, Ulrich Mueller wrote: On Sun, 19 Feb 2012, Ben wrote: In my opinion we should set a default environment with the following values: LANG=en_US.UTF-8 LC_ALL= LC_ALL isn't needed here because, unlike other LC_* settings, it does not inherit from LANG and, thus, will be undefined anyway. Although the above would not directly cause any harm, I am entirely certain that its mere presence would encourage users to explicitly define it where they most definitely should not. The misinformation that LC_ALL should be defined was propagated by the localization doc for rather a long time and it was rather challenging to impress upon its maintainers that change was required. Let's not repeat old mistakes. LC_COLLATE=C This offers the best default options to the majority of users, and is easy to customize for those who wish to use another locale. At least, LC_NUMERIC=C should be added to this, otherwise numbers will be formatted with commas as thousands separators. Also en_US.UTF-8 for LC_MEASUREMENT and LC_PAPER means imperial units and letter paper, which isn't optimal for users outside of the U.S. Ulrich I think those users (and that includes myself) should then set LANG to something more appropriate to their use case. I agree; the defaults should not be over-engineered. For proper localisation, set LANG appropriately and done. The real issue is that locale configuration isn't mentioned in the handbook. It does, however, mention locale.gen so we're half-way there. --Kerin
[gentoo-dev] Re: LANG=en_GB.UTF-8 by default
On 19/02/2012 01:00, James Cloos wrote: "KM" == Kerin Millar writes: KM> Arch also used to define LC_COLLATE="C" by default, probably to KM> mitigate unpredictable behaviour in some applications, but have KM> since dropped this additional variable so they must have deemed it KM> no longer necessary. Without LC_COLLATE="C" things like [a-z]* gets a false=positive match on files like Makefile. Indeed, character classes are a potential minefield. Incidentally, I just tested Ubuntu and Arch with only LANG set to a UTF-8 locale:- $ echo Makefile | sed -re 's/[a-z]//g' # collation rules ignored M $ echo Makefile | grep -Eo '[a-z]*' # collation rules ignored akefile In neither case are the collation rules being obeyed. In Gentoo, however:- $ echo Makefile | sed -re 's/[a-z]//g' # collation rules obeyed $ echo Makefile | grep -Eo '[a-z]*' # collation rules ignored akefile Obeying the collation rules is ostensibly the correct thing to do but, until everyone starts using named character classes (which will never happen), it's not safe. The thing that worries me here is the inconsistency in Gentoo. LC_COLLATE="C" is sufficient to work around the issue but the above makes me wonder why we still need it. --Kerin
Re: [gentoo-dev] Re: LANG=en_GB.UTF-8 by default
> On Sun, 19 Feb 2012, Ben wrote: >>> In my opinion we should set a default environment with the >>> following values: >> >>> LANG=en_US.UTF-8 >>> LC_ALL= >>> LC_COLLATE=C >> >>> This offers the best default options to the majority of users, and >>> is easy to customize for those who wish to use another locale. >> >> At least, LC_NUMERIC=C should be added to this, otherwise numbers >> will be formatted with commas as thousands separators. >> >> Also en_US.UTF-8 for LC_MEASUREMENT and LC_PAPER means imperial >> units and letter paper, which isn't optimal for users outside of >> the U.S. > I think those users (and that includes myself) should then set LANG > to something more appropriate to their use case. And why should we set the default to an US locale then? IMHO something like LANG=C LC_CTYPE=en_US.utf8 would be much less intrusive if you just want UTF-8, without influencing other i18n variables. Ulrich
[gentoo-dev] Last rites: app-text/notecase-pro
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras (19 Feb 2012) # Illegal license. Bug #390205 # Removal in 30 days app-text/notecase-pro - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJPQXt/AAoJEPqDWhW0r/LCauQP/RQ5aDWRadqpA0l/v7vFMdfL CkmfLchN1xC1y7Jh1xzcjo/g/vqU7KTxehTY24FwyKSreXvR43BJfU2dugcQ8xSD oq1Nu4H/CrBn0idPtb8+Njm3nZCct2vLUpy+CgekAYNp6CLAOi0H5sP5VgZpVElp benH6ooe8x2uwyZ+QJjTp9pjecRAlLDVS15oqPH5jeb+elsmWYOJKyBgbtyVNsOJ heToViVLybAdp2mQK6W9imh4K0zRcrsjF2s4rSpVufX8+CI6q1xu9mkDjSHb0kVX uj6PF4l9GK6BqlOs+DieQOSjRooAnoEhRVkxPruJneIXCQbd2VOpLTuFgx5S5vqT iQvnKQtUcoriP+Nov2LhG1MlxBqkzc6diZRCVSyGF48n5gs3RJpWn09LHLYdFEGP 1VqVoManxrrp43LI0H+TU1hD5QH6VgBjoeMEZXmyr97xKY2CdETUQV2x8WLURCol sMa277IORs+P12Jn8nk51RXsXCNhk6vPsklSKJ5PSddW9GVjyCRg8cSDQUVptAHy TYXzD28W+Qm6kGCWtZUX4DKnVDwJGADcTTlJzCwVtjwo7ftyjvUI3gHKrUHuz/DD +KxFx0pATJUijJX+yodcqoXw3hXINoYkFqZBVzgIpfiFvTQD3cAzMTwaX0jW+8yt IfK1a6dmFn360CvkrH26 =JOac -END PGP SIGNATURE-
Re: [gentoo-dev] Re: LANG=en_GB.UTF-8 by default
On Sun, Feb 19, 2012 at 11:56:40PM +0800, Ben wrote: > On 19 February 2012 23:14, Ulrich Mueller wrote: > >> On Sun, 19 Feb 2012, Ben wrote: > > > >> In my opinion we should set a default environment with the following > >> values: > > > >> LANG=en_US.UTF-8 > >> LC_ALL= > >> LC_COLLATE=C > > > >> This offers the best default options to the majority of users, and > >> is easy to customize for those who wish to use another locale. > > > > At least, LC_NUMERIC=C should be added to this, otherwise numbers will > > be formatted with commas as thousands separators. > > > > Also en_US.UTF-8 for LC_MEASUREMENT and LC_PAPER means imperial units > > and letter paper, which isn't optimal for users outside of the U.S. > > > > Ulrich > > > > I think those users (and that includes myself) should then set LANG to > something more appropriate to their use case. According to our localization guide, there is a safe default that forces UTF-8 characters but doesn't force any language. I have the following single line in /etc/env.d/02locale: LC_CTYPE=en_US.UTF-8 What do you think? William pgpn8ilNNBPSD.pgp Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-02-19 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2012-02-19 23h59 UTC. Removals: www-apps/tikiwiki 2012-02-13 19:30:57 a3li media-tv/linuxtv-dvb-headers2012-02-15 19:17:08 hd_brummy app-shells/prll 2012-02-16 20:18:06 jlec dev-util/chromium-tools 2012-02-18 10:15:38 phajdan.jr net-wireless/wispy-tools2012-02-19 22:30:06 robbat2 Additions: app-laptop/thinkfan 2012-02-13 02:27:50 xmw dev-python/python-fastimport2012-02-13 05:13:05 tetromino dev-vcs/bzr-fastimport 2012-02-13 05:16:15 tetromino dev-vcs/git-bzr-ng 2012-02-13 05:18:11 tetromino dev-perl/Module-Implementation 2012-02-13 14:22:41 tove dev-perl/MooseX-Types-DateTime 2012-02-13 15:36:31 tove dev-perl/MooseX-Types-DateTime-MoreCoercions2012-02-13 15:42:47 tove dev-util/gtk-builder-convert2012-02-13 23:08:50 tetromino dev-perl/Router-Simple 2012-02-14 15:01:29 tove dev-python/tox 2012-02-14 20:49:40 djc dev-python/virtualenvwrapper2012-02-14 21:00:24 djc gnustep-apps/lapispuzzle2012-02-14 22:46:58 voyageur sys-fs/rar2fs 2012-02-15 06:43:11 ssuominen app-text/getxbook 2012-02-15 08:45:36 grozin dev-python/joblib 2012-02-15 10:46:13 djc gnustep-apps/gemas 2012-02-15 12:47:19 voyageur media-plugins/gst-plugins-rtmp 2012-02-15 12:53:44 ford_prefect dev-python/python-geoclue 2012-02-15 16:18:22 jlec dev-python/python-sqlparse 2012-02-15 16:18:25 jlec app-text/unac 2012-02-15 16:57:25 tetromino virtual/linuxtv-dvb-headers 2012-02-15 17:52:51 hd_brummy media-libs/leptonica2012-02-16 00:06:55 sbriesen gnome-extra/zeitgeist-extensions2012-02-16 07:46:28 jlec app-admin/aws-as-tools 2012-02-16 10:20:00 lxnay app-admin/aws-rds-tools 2012-02-16 10:27:14 lxnay app-admin/aws-cw-tools 2012-02-16 14:20:50 lxnay app-admin/aws-iam-tools 2012-02-16 15:10:46 lxnay kde-misc/akonadi-git-resource 2012-02-16 16:16:39 johu dev-python/pympler 2012-02-16 19:36:32 jlec sys-process/prll2012-02-16 20:14:16 jlec net-wireless/spectools 2012-02-17 03:30:54 steev x11-wm/spectrwm 2012-02-18 03:18:07 xmw dev-python/github2 2012-02-18 04:55:52 radhermit www-client/dwb 2012-02-18 09:20:33 radhermit x11-misc/lightdm-gtk-greeter2012-02-18 11:23:25 hwoarang x11-wm/razorqt 2012-02-18 11:59:37 hwoarang dev-php/pecl-taint 2012-02-18 14:15:06 olemarkus x11-plugins/prpltwtr2012-02-19 08:00:17 jdhore dev-perl/TeX-Encode 2012-02-19 14:33:19 dilfridge app-emacs/rpm-spec-mode 2012-02-19 14:59:15 sochotnicky dev-util/rpmdevtools2012-02-19 15:29:57 sochotnicky -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: www-apps/tikiwiki,removed,a3li,2012-02-13 19:30:57 media-tv/linuxtv-dvb-headers,removed,hd_brummy,2012-02-15 19:17:08 app-shells/prll,removed,jlec,2012-02-16 20:18:06 dev-util/chromium-tools,removed,phajdan.jr,2012-02-18 10:15:38 net-wireless/wispy-tools,removed,robbat2,2012-02-19 22:30:06 Added Packages: app-laptop/thinkfan,added,xmw,2012-02-13 02:27:50 dev-python/python-fastimport,added,tetromino,2012-02-13 05:13:05 dev-vcs/bzr-fastimport,added,tetromino,2012-02-13 05:16:15 dev-vcs/git-bzr-ng,added,tetromino,2012-02-13 05:18:11 dev-perl/Module-Implementation,added,tove,2012-02-13 14:22:41 dev-perl/MooseX-Types-DateTime,added,tove,2012-02-13 15:36:31 dev-perl/MooseX-Types-DateTime-MoreCoercions,added,tove,2012-02-13 15:42:47 dev-util/gtk-builder-convert,added,tetromino,2012-02-13 23:08:50 dev-perl/Router-Simple,added,tove,2012-02-14 15:01:29 dev-python/tox,added,djc,2012-02-14 20:49:40 dev-python/virtualenvwrapper,added,djc,2012-02-14 21:00:24 gnustep-apps/lapispuzzle,added,voyageur,2012-02-14 22:46
[gentoo-dev] Unstabling a package
Any specific procedure to unstable a package? Specifically MythTV. While there's a lot of user interest in the package, there's just not enough dev help with the package to really keep it up to snuff to what could be considered stable. Its woefully behind and I'd just be happier to drop the current stable and bump everything as unstable. -- Doug Goldstein
Re: [gentoo-dev] Unstabling a package
On Sun, Feb 19, 2012 at 9:46 PM, Doug Goldstein wrote: > Any specific procedure to unstable a package? Specifically MythTV. > While there's a lot of user interest in the package, there's just not > enough dev help with the package to really keep it up to snuff to what > could be considered stable. Its woefully behind... The current unstable package for mythtv was the upstream stable version only a few weeks ago. I was contemplating stabilizing it, although with 0.24.2 out it might make more sense to target that version. The current stable version should certainly be removed ASAP - it contains numerous bugs and some QA issues that have been fixed in the unstable version. The only thing the stable version has going for it is support for more plugins. If I get a long weekend I might try upgrading to 0.24.2 and getting that into portage (assuming nobody else beats me to it). Unfortunately my only mythtv system is essentially a production system, so I can't really have it down for any length of time. If we do make mythtv unstable I'd prefer that we not drop versions too quickly. If somebody else is able to keep up with the bleeding-edge versions more power to them, but if the consensus is that the older versions have to go most likely I'd just start maintaining my own overlay and abandon the one in portage. I can really only do a serious version bump maybe 2-3 times per year at most. I'm not convinced that going completely unstable is really going to solve anything, however. I'd rather have a core of stable functionality than something bleeding-edge for something like mythtv. Then again, that might just be personal preference. Rich
[gentoo-dev] Re: LANG=en_GB.UTF-8 by default
On 20/02/2012 00:11, William Hubbs wrote: On Sun, Feb 19, 2012 at 11:56:40PM +0800, Ben wrote: On 19 February 2012 23:14, Ulrich Mueller wrote: On Sun, 19 Feb 2012, Ben wrote: In my opinion we should set a default environment with the following values: LANG=en_US.UTF-8 LC_ALL= LC_COLLATE=C This offers the best default options to the majority of users, and is easy to customize for those who wish to use another locale. At least, LC_NUMERIC=C should be added to this, otherwise numbers will be formatted with commas as thousands separators. Also en_US.UTF-8 for LC_MEASUREMENT and LC_PAPER means imperial units and letter paper, which isn't optimal for users outside of the U.S. Ulrich I think those users (and that includes myself) should then set LANG to something more appropriate to their use case. According to our localization guide, there is a safe default that forces UTF-8 characters but doesn't force any language. I have the following single line in /etc/env.d/02locale: LC_CTYPE=en_US.UTF-8 That looks good but perhaps it should also define LANG=POSIX, which is similar to Ulrich's proposal. Something like: # To configure for your region, set LANG to an appropriate locale, then comment # or remove LC_CTYPE. Run "locale -a" to obtain a list of available locales. LANG=POSIX LC_CTYPE=en_US.utf8 I know that adding LANG=POSIX doesn't do anything in this case but I have a feeling that its presence would be instructive to new users. If a user is asked to configure something which isn't present, it often generates questions which might otherwise be avoided. I've changed "en_US.UTF-8" to "en_US.utf8" there for similar reasons. Not to mention that, if one is curious and searches for "posix locale" via Google, the first link is for the Open Group specification :) I reckon that this, along with some basic information in the handbook, would be a step in the right direction. --Kerin
[gentoo-dev] Re: LANG=en_GB.UTF-8 by default
On 20-02-2012 03:07:33 +, Kerin Millar wrote: > I know that adding LANG=POSIX doesn't do anything in this case but I > have a feeling that its presence would be instructive to new users. If a > user is asked to configure something which isn't present, it often > generates questions which might otherwise be avoided. I've changed > "en_US.UTF-8" to "en_US.utf8" there for similar reasons. I don't understand. UTF-8 is the codeset, that utf8 is recognised as the same thing is IMO a GNUism. glibc understands "UTF-8" perfectly fine these days, so it should preferably be used instead. (Even the man-page, utf8(7), suggests that.) -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
