On Wed, 2015-11-11 at 11:28 +0100, Justin (jlec) wrote:
> # Justin Lecher (28 Feb 2015)
> # Unfixed security problems
> # No upstream support anymore
> # CVE-2015-{0219,0220,0221,0222,5145}
> # #536586
> # #554864
> =dev-python/django-1.4*
> =dev-python/django-1.5*
> =dev-python/django-1.6*
> # No
Jason A. Donenfeld wrote:
>
> I'd be in favor of full-on LC_ALL=C.
Setting LC_ALL seems wrong as it is meant as a quick hack
and should not be relied on by a "generic" tool like portage.
Better define to *unset* LC_ALL (remembering the previous value,
see below) and to set (all?) other LC_* to d
> On Wed, 11 Nov 2015, Mike Gilbert wrote:
> On Wed, Nov 11, 2015 at 6:18 PM, Ulrich Mueller wrote:
>> In the meantime, we could go with the minimum changes necessary to
>> unbreak the bash 4.2 case conversion operators. Setting LC_COLLATE
>> to C and LC_CTYPE to some sane locale should be su
Robin H. Johnson posted on Wed, 11 Nov 2015 23:11:48 + as excerpted:
> On Thu, Nov 05, 2015 at 12:54:06PM +0100, Alexis Ballier wrote:
>> It's not perfectly clean but I don't see any problem here:
>> ChangeLog-2015 : all ChangeLog from CVS ChangeLog: autogenerated from
>> git
> FYI, this was
On Wed, Nov 11, 2015 at 6:18 PM, Ulrich Mueller wrote:
>> On Wed, 11 Nov 2015, Matthias Maier wrote:
>
>> On Wed, Nov 11, 2015, at 15:52 CST, "Jason A. Donenfeld"
>> wrote:
>
>>> I'd be in favor of full-on LC_ALL=C.
>
>> ++
>
>> I'm surprised that we do not have such a policy already.
>
> LC
> On Wed, 11 Nov 2015, Matthias Maier wrote:
> On Wed, Nov 11, 2015, at 15:52 CST, "Jason A. Donenfeld"
> wrote:
>> I'd be in favor of full-on LC_ALL=C.
> ++
> I'm surprised that we do not have such a policy already.
LC_ALL=C would disable UTF-8, and I am told that this would cause
probl
On Thu, Nov 05, 2015 at 12:54:06PM +0100, Alexis Ballier wrote:
> It's not perfectly clean but I don't see any problem here:
> ChangeLog-2015 : all ChangeLog from CVS
> ChangeLog: autogenerated from git
FYI, this was implemented.
For reference, the old CVS changelogs are now taken from HEAD of thi
On Wed, Nov 11, 2015, at 15:52 CST, "Jason A. Donenfeld"
wrote:
> I'd be in favor of full-on LC_ALL=C.
++
I'm surprised that we do not have such a policy already.
Best,
Matthias
I'd be in favor of full-on LC_ALL=C. Ebuilds are meant for having a
particular determinism. They're machine scripts. The operations they do
need to be consistent.
For user-facing parts, such as printing information, or sorting user-shown
text, I can understand ebuild authors might want in some spe
> On Wed, 11 Nov 2015, Ciaran McCreesh wrote:
> On Wed, 11 Nov 2015 07:16:42 +0100
> Patrick Lauer wrote:
>> Wouldn't it be 'easier' (fsov easy) to have portage use sane-default
>> locale settings, so that estonian or turkish users don't get hit by
>> weirdness in the [a-z] character class et
On 11/11/15 10:09, Michał Górny wrote:
> I'd rather use the old standard 80. Minus 8 characters for friendly
> e-mail quoting, which is also kinda 'old standard'.
You can suggest as above, with this tone, and probably you would get
some consensus.
Personally I think 80col is nice since you can ha
> On Wed, 11 Nov 2015, Michael Orlitzky wrote:
> We just got a bug,
> https://bugs.gentoo.org/show_bug.cgi?id=565500
> due to the `uptime` binary changing locations in
> sys-process/procps-3.3.11-r2. The nagios-plugins package picks up
> the location of `uptime` while it's installing, so wh
We just got a bug,
https://bugs.gentoo.org/show_bug.cgi?id=565500
due to the `uptime` binary changing locations in
sys-process/procps-3.3.11-r2. The nagios-plugins package picks up the
location of `uptime` while it's installing, so when users upgrade
procps, some plugins stop working.
Is there
On Wed, 11 Nov 2015 07:16:42 +0100
Patrick Lauer wrote:
> Wouldn't it be 'easier' (fsov easy) to have portage use sane-default
> locale settings, so that estonian or turkish users don't get hit by
> weirdness in the [a-z] character class etc.?
Paludis forces all the LC variables to sane values. A
# Justin Lecher (28 Feb 2015)
# Unfixed security problems
# No upstream support anymore
# CVE-2015-{0219,0220,0221,0222,5145}
# #536586
# #554864
=dev-python/django-1.4*
=dev-python/django-1.5*
=dev-python/django-1.6*
# Not supported by any django version upstream supports
dev-python/south
dev-pyt
On Sun, 8 Nov 2015 10:35:04 +0100
Michał Górny wrote:
> Hello, everyone.
>
> As you probably don't know, Justin lately noticed that we're carrying
> some ugly hacks in Python 3.2+ where we diverge from upstream and break
> binary compatibility for the sake of 'aesthetics'. While we're not yet
>
On Wed, 11 Nov 2015 07:16:42 +0100
Patrick Lauer wrote:
> On 11/11/2015 03:51 AM, Mike Frysinger wrote:
> > On 10 Nov 2015 18:53, Mike Frysinger wrote:
> >> i randomly stumbled across an ebuild that was using ^^ to make a variable
> >> uppercase. this is new to bash-4.0 and thus invalid for EA
On Tue, 10 Nov 2015 18:53:03 -0500
Mike Frysinger wrote:
> On 31 Oct 2015 09:08, Michał Górny wrote:
> > On Sat, 31 Oct 2015 03:06:21 -0400 Mike Frysinger wrote:
> > > On 30 Oct 2015 18:20, Michał Górny wrote:
> > > > On Fri, 30 Oct 2015 12:03:59 + (UTC) "Justin Lecher" wrote:
> > > >
> On Wed, 11 Nov 2015, Mike Frysinger wrote:
>> This is wrong on so many levels. :( It starts with the fact that the
>> dot over the lowercase latin i historically never was a diacritical
>> mark [1].
>>
>> Maybe we should advise users in our documentaion that they should
>> avoid such broken
19 matches
Mail list logo
