On Fri, Apr 30, 2010 at 01:02:48AM +0200, Gilles Dartiguelongue wrote:
it's just like any package failing with some gcc/linked/whatever flag,
you just don't stop using that flag where it works just because of one
package, nor do you stop using gcc.
And for anybody that thinks they have a bug in
* Daniel Pielmeier bil...@gentoo.org schrieb:
What about searching the complete file system but using an exclude file where
you can put directories and files which should not be searched. It is tedious
to
tell every path on the command-line. Also for instance if you specify /lib it
will
Hello,
I would like to put an emphasis on the fact that many eclasses
and ebuilds in gx86 are relying on an assumption that the superuser
account is always supposed to be named 'root'.
In fact, no such constraint exists. Although most users will never even
think of changing the superuser account
On 30-04-2010 20:07:26 +0200, Michał Górny wrote:
In my opinion, that policy should clearly indicate that the numeric
UID/GID should be always used for referencing the superuser account
as they are fixed unlike the names.
Just to complicate matters a bit, there are platforms where the
On Fri, Apr 30, 2010 at 11:07 AM, Michał Górny gen...@mgorny.alt.pl wrote:
Hello,
I would like to put an emphasis on the fact that many eclasses
and ebuilds in gx86 are relying on an assumption that the superuser
account is always supposed to be named 'root'.
In fact, no such constraint
On Fri, Apr 30, 2010 at 11:07 AM, Michał Górny gen...@mgorny.alt.pl wrote:
Hello,
I would like to put an emphasis on the fact that many eclasses
and ebuilds in gx86 are relying on an assumption that the superuser
account is always supposed to be named 'root'.
In fact, no such constraint
* Luca Barbato lu_z...@gentoo.org schrieb:
I wonder if that case shouldn't be handled better with an huge ewarn so
people concerned would really run it in a benchmark environment, alone.
ewarns should be circumvented (make it work w/o them), IMHO.
I can imagine I'm not the only person who
