> On Fri, 27 Jul 2012, Ben de Groot wrote:
> I understand why the council rejected Debian's C.UTF-8 option,
> but is there really no better default that we can use?
> Without any default locale set, in practically all cases that means
> that the user is presented with English, and mostly the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/27/2012 03:08 AM, Ulrich Mueller wrote:
>
> As I had pointed out before [1], changing from POSIX to an en_US
> locale will have undesirable side effects, like commas as thousands
> separators in numbers (because of LC_NUMERIC). Also the defaults
On Friday, July 27, 2012 09:08:36 AM Ulrich Mueller wrote:
> > On Fri, 27 Jul 2012, Ben de Groot wrote:
>
> > I understand why the council rejected Debian's C.UTF-8 option,
> > but is there really no better default that we can use?
>
> > Without any default locale set, in practically all case
On 27 July 2012 16:06, Dan Douglas wrote:
> On Friday, July 27, 2012 09:08:36 AM Ulrich Mueller wrote:
>> > On Fri, 27 Jul 2012, Ben de Groot wrote:
>>
>> > I understand why the council rejected Debian's C.UTF-8 option,
>> > but is there really no better default that we can use?
>>
>> > Withou
Ulrich Mueller wrote:
>> On Fri, 27 Jul 2012, Ben de Groot wrote:
>>
>> So let's upgrade to en_US.UTF-8, which is for most users more
>> desirable than the current situation. Of course we will still advise
>> them to set their desired locales in /etc/locale.gen. But at least
>> they will start with
On Fri, 27 Jul 2012 10:38:30 +0200
Cyprien Nicolas wrote:
> Ulrich Mueller wrote:
> >> On Fri, 27 Jul 2012, Ben de Groot wrote:
> >>
> >> So let's upgrade to en_US.UTF-8, which is for most users more
> >> desirable than the current situation. Of course we will still
> >> advise them to set their
On Fri, 27 Jul 2012 16:34:01 +0800
Ben de Groot wrote:
> On 27 July 2012 16:06, Dan Douglas wrote:
> > On Friday, July 27, 2012 09:08:36 AM Ulrich Mueller wrote:
> >> > On Fri, 27 Jul 2012, Ben de Groot wrote:
> >>
> >> > I understand why the council rejected Debian's C.UTF-8 option,
> >> >
Rick \"Zero_Chaos\" Farina posted on Fri, 27 Jul 2012 01:44:47 -0400 as
excerpted:
> * Messages for package app-emulation/emul-linux-x86-baselibs-20120520:
>
> * QA Notice: Missing soname symlink(s):
> *
> *usr/lib32/libgnuintl.so.8 -> preloadable_libintl.so
> *
> * QA Notice: Missing s
Ulrich Mueller schrieb:
> As I had pointed out before [1], changing from POSIX to an en_US
> locale will have undesirable side effects, like commas as thousands
> separators in numbers (because of LC_NUMERIC). Also the defaults of
> en_US for LC_MEASUREMENT and LC_PAPER are only useful in the U.S.
Il 26/07/2012 23:51, Michał Górny ha scritto:
> You are looking for QA_FLAGS_IGNORED.
Actually I'd say QA_PREBUILT.
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
signature.asc
Description: OpenPGP digital signature
Autodep[1][2] is a current implementation of this idea, with library
hook and FUSE options.
Would definitely love to see more development in this area. :)
[1]: https://dev.gentoo.org/~neurogeek/guidexml/
[2]: http://git.overlays.gentoo.org/gitweb/?p=proj/autodep.git;a=summary
On Thu, Jul 26, 2012 at 6:35 PM, Zac Medico wrote:
>
> It seems like you might need some kind of copy-on-write support, at
> least to run pkg_setup. Apparently cowbuilder uses cow hardlinks for
> that. Another way would be to use fiemap (cp --reflink).
Reflinks would be a much clearer implementat
On Thu, Jul 26, 2012 at 09:49:04PM -0500, Canek Peláez Valdés wrote:
> On Thu, Jul 26, 2012 at 9:37 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> [ snip ]
> > 9) Otherwise, at very minimum, they're failing the "build udev pretty
> > much the same as before"
>
> ./configure
> make
> make install
>
>
On Friday 27 July 2012 08:13:16 Chí-Thanh Christopher Nguyễn wrote:
> Ulrich Mueller schrieb:
> > As I had pointed out before [1], changing from POSIX to an en_US
> > locale will have undesirable side effects, like commas as thousands
> > separators in numbers (because of LC_NUMERIC). Also the defa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/27/2012 06:49 AM, Duncan wrote:
> Rick \"Zero_Chaos\" Farina posted on Fri, 27 Jul 2012 01:44:47 -0400 as
> excerpted:
>
>> * Messages for package app-emulation/emul-linux-x86-baselibs-20120520:
>>
>> * QA Notice: Missing soname symlink(s):
>>
On Wednesday 18 July 2012 12:18:35 Andreas K. Huettel wrote:
> > On Wed, Jul 18, 2012 at 5:33 PM, hasufell wrote:
> > > "epatch" is so widely used and basic that I wonder why it's still not
> > > implemented as a real helper function.
> >
> > Because then its harder to change, it must be in PMS,
On Wednesday 18 July 2012 13:29:41 Ciaran McCreesh wrote:
> On Wed, 18 Jul 2012 18:18:35 +0200 "Andreas K. Huettel" wrote:
> > > On Wed, Jul 18, 2012 at 5:33 PM, hasufell
> > >
> > > wrote:
> > > > "epatch" is so widely used and basic that I wonder why it's still
> > > > not implemented as a real
El vie, 27-07-2012 a las 13:24 -0400, Mike Frysinger escribió:
> On Friday 27 July 2012 08:13:16 Chí-Thanh Christopher Nguyễn wrote:
> > Ulrich Mueller schrieb:
> > > As I had pointed out before [1], changing from POSIX to an en_US
> > > locale will have undesirable side effects, like commas as tho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/27/2012 02:29 PM, Pacho Ramos wrote:
> El vie, 27-07-2012 a las 13:24 -0400, Mike Frysinger escribió:
>> On Friday 27 July 2012 08:13:16 Chí-Thanh Christopher Nguyễn
>> wrote:
>>> Ulrich Mueller schrieb:
As I had pointed out before [1], ch
Il 27/07/2012 13:16, Aaron W. Swenson ha scritto:
> Really, how much of an inconvenience is it that we don't use UTF-8 as
> a default?
Given that there are a ton and a half of Python packages that do not
work with a non-utf8 locale, I'd say it's quite a thing.
So either we go with an UTF-8 defaul
Hi!
We are getting nearer to a Qt5 beta release. Although it has already
been postponed a couple of times, we should expect it some time this
summer. This means we will start to see packages offering Qt5 support.
Pesa has already done a terrific job preparing live ebuilds and
eclasses for buildin
On 28/07/12 08:22, Ben de Groot wrote:
In preparation for that, we want to ask maintainers of all ebuilds in
the tree with dependencies on Qt4, to make sure that they have the
proper slot. Otherwise your package may pull in Qt5 while it may not
in fact support it.
This can be trouble if the app
On 28 July 2012 13:59, Nikos Chantziaras wrote:
> On 28/07/12 08:22, Ben de Groot wrote:
>>
>> In preparation for that, we want to ask maintainers of all ebuilds in
>> the tree with dependencies on Qt4, to make sure that they have the
>> proper slot. Otherwise your package may pull in Qt5 while it
On Fri, Jul 27, 2012 at 11:27 PM, Ben de Groot wrote:
> On 28 July 2012 13:59, Nikos Chantziaras wrote:
>> On 28/07/12 08:22, Ben de Groot wrote:
>>>
>>> In preparation for that, we want to ask maintainers of all ebuilds in
>>> the tree with dependencies on Qt4, to make sure that they have the
>>
On 28/07/12 09:46, Davide Pesavento wrote:
On Fri, Jul 27, 2012 at 11:27 PM, Ben de Groot wrote:
On 28 July 2012 13:59, Nikos Chantziaras wrote:
[...]
So what would be the methodology of making sure a package has the proper
slot?
Obviously you would need to make sure that the package actua
25 matches
Mail list logo
