Re: [gentoo-dev] [RFC] RESTRICT=parallel for builds that can't be executed in parallel

[Enrico Weigelt]

* Luca Barbato  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 doenst want to keep
an close eye on each single build/merge.

In this concrete example, the package's build system is misdesigned.
They shouldn't rely on runtime benchmarks for build time decisions
in the first place - this is unpredictable. But this is not an
issues distros should have to cope with.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [gentoo-dev] A policy to support random superuser account names

[Alec Warner]

On Fri, Apr 30, 2010 at 11:07 AM, Michał Górny  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 exists. Although most users will never even
> think of changing the superuser account name, it is perfectly legit
> to do so, and to use any name for that account. Moreover, it is
> perfectly legit to name an unprivileged user 'root' too.

Whether it is legitimate or not is irrelevant.  Users can chose to do
all sorts of legitimate but in the end utterly retarded things to
their systems and developers chose whether or not to support them.
gcc flags are a common case here (I can legitimately set a number of
flags; but most developers ignore reports with odd flags.)

>
> Thus, the above assumption is clearly incorrect and may result in many
> issues with ebuilds using it. These range from builds failing because
> of chown 'invalid user' error to packages being installed with
> incorrect file ownership.

I'd say the assumption is correct in 95% of cases; so it remains a useful one.

>
> From what I've heard already, similar problem has hit Gentoo/*BSD users
> already, with superuser group not being named 'root'. Although some
> files were fixed to properly use numeric GID in the specific case,
> no UID-related changes were done.
>
> Moreover, not all developers agree with the case being an issue,
> and they even refuse patches clearly fixing it [1]. Thus, I guess that
> a clear policy regarding referencing the superuser account should be
> enforced.

Users do a number of utterly ridiculous things to their system and
developers are free to reject bug reports for any number of reasons
(this being one of them.)

>
> 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.

Except as stated they are not fixed (as Fabian pointed out).  I'm
happy to support something like setting ROOT_UID and ROOT_GID in
gentoo-x86 profiles and using those.  Then if you want to do something
utterly ridiculous to your system you can just set the appropriate
variables.

This will likely take a GLEP though; plus it is a major change to a
lot of software we have; are you willing to make said changes?  Making
a proposal like this is all well and good but you are asking for a lot
of work to be done for what is essentially very little gain for users.

-A

>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=315779
>
> --
> Best regards,
> Michał Górny
>
> 
> 
>

Re: [gentoo-dev] A policy to support random superuser account names

[Alec Warner]

On Fri, Apr 30, 2010 at 11:07 AM, Michał Górny  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 exists. Although most users will never even
> think of changing the superuser account name, it is perfectly legit
> to do so, and to use any name for that account. Moreover, it is
> perfectly legit to name an unprivileged user 'root' too.

Whether it is legitimate or not is irrelevant.  Users can chose to do
all sorts of legitimate but in the end utterly retarded things to
their systems and developers chose whether or not to support them.
gcc flags are a common case here (I can legitimately set a number of
flags; but most developers ignore reports with odd flags.)

>
> Thus, the above assumption is clearly incorrect and may result in many
> issues with ebuilds using it. These range from builds failing because
> of chown 'invalid user' error to packages being installed with
> incorrect file ownership.

I'd say the assumption is correct in 95% of cases; so it remains a useful one.

>
> From what I've heard already, similar problem has hit Gentoo/*BSD users
> already, with superuser group not being named 'root'. Although some
> files were fixed to properly use numeric GID in the specific case,
> no UID-related changes were done.
>
> Moreover, not all developers agree with the case being an issue,
> and they even refuse patches clearly fixing it [1]. Thus, I guess that
> a clear policy regarding referencing the superuser account should be
> enforced.

Users do a number of utterly ridiculous things to their system and
developers are free to reject bug reports for any number of reasons
(this being one of them.)

>
> 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.

Except as stated they are not fixed (as Fabian pointed out).  I'm
happy to support something like setting ROOT_UID and ROOT_GID in
gentoo-x86 profiles and using those.  Then if you want to do something
utterly ridiculous to your system you can just set the appropriate
variables.

This will likely take a GLEP though; plus it is a major change to a
lot of software we have; are you willing to make said changes?  Making
a proposal like this is all well and good but you are asking for a lot
of work to be done for what is essentially very little gain for users.

-A

>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=315779
>
> --
> Best regards,
> Michał Górny
>
> 
> 
>

Re: [gentoo-dev] A policy to support random superuser account names

[Fabian Groffen]

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
equivalent of "root" does not have uid = 0.  So if you want to do it
right, you probably use a variable or two that define for the host in
use what/who the root user is.  Much like we (the Prefix guys) already
store in Portage who is supposed to be the "portage" user, and who is
the "root" user, similar for their groups.


-- 
Fabian Groffen
Gentoo on a different level

[gentoo-dev] A policy to support random superuser account names

[Michał Górny]

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 name, it is perfectly legit
to do so, and to use any name for that account. Moreover, it is
perfectly legit to name an unprivileged user 'root' too.

Thus, the above assumption is clearly incorrect and may result in many
issues with ebuilds using it. These range from builds failing because
of chown 'invalid user' error to packages being installed with
incorrect file ownership.

From what I've heard already, similar problem has hit Gentoo/*BSD users
already, with superuser group not being named 'root'. Although some
files were fixed to properly use numeric GID in the specific case,
no UID-related changes were done.

Moreover, not all developers agree with the case being an issue,
and they even refuse patches clearly fixing it [1]. Thus, I guess that
a clear policy regarding referencing the superuser account should be
enforced.

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.

[1] http://bugs.gentoo.org/show_bug.cgi?id=315779

-- 
Best regards,
Michał Górny





signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC][NEW] Utility to find orphaned files

[Enrico Weigelt]

* Daniel Pielmeier  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 also search under /lib/modules and I am sure you do not consider all
> contents there as unneeded.

hmm, perhaps there's some way to assign these files to some package ?
 
> You also need to consider that your tool will return other false positives 
> like
> byte compiled python modules and perl header files. In general everything an
> ebuild does in phases where it adds files to file-system but files are not
> stored to CONTENTS (pkg_{pre,post}inst). At this point the files are needed 
> but
> not recognized by the package manager. If the ebuild does not take care of 
> this
> files when removing (pkg_{pre,post}rm) the package they will remain on the
> file-system and are now unneeded.

Assuming these files are not optional/temporary (aka: can be regenerated on
the fly), I see a generic design problem here: everything belonging to some
package (excluding content data and configs, of course) should be assigned
to the package.

The big Q: how can we achieve this ?


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [gentoo-dev] ccache causing problems

[Robin H. Johnson]

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 ccache triggered by some
package.
1. backup the contents of your ccache.
2. Clear the cache.
3. Build once to populate the cache.
4. Build again to build against the cache (once or twice, should have
   identical results).

If step 4 passes, you know you had corruption in your cache.
If step 4 fails, then I'm interested in where it failed, esp. if you can
run the entire process again and repeat the problem on demand.

Note however, that while I have a high level of trust in ccache, I do
think there are more latent bugs in distcc.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85