From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1MIVES-00037K-Ch for garchives@archives.gentoo.org; Sun, 21 Jun 2009 22:09:48 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 72014E0473; Sun, 21 Jun 2009 22:09:46 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 34909E0473 for ; Sun, 21 Jun 2009 22:09:46 +0000 (UTC) Received: from mail.isohunt.com (b01.ext.isohunt.com [208.71.112.51]) by smtp.gentoo.org (Postfix) with ESMTP id 88ED06519F for ; Sun, 21 Jun 2009 22:09:45 +0000 (UTC) Received: (qmail 11228 invoked from network); 21 Jun 2009 22:09:44 -0000 Received: from tsi-static.orbis-terrarum.net (HELO curie.orbis-terrarum.net) (76.10.188.108) (smtp-auth username robbat2@isohunt.com, mechanism login) by mail.isohunt.com (qpsmtpd/0.33-dev on beta01) with (AES256-SHA encrypted) ESMTPSA; Sun, 21 Jun 2009 22:09:44 +0000 Received: (qmail 7435 invoked by uid 10000); 21 Jun 2009 15:09:41 -0700 Date: Sun, 21 Jun 2009 15:09:41 -0700 From: "Robin H. Johnson" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Gentoo stats server/client @ 2009-06-21 Message-ID: References: <4A3D8C60.2040701@hartwork.org> <4A3E49C6.5070804@hartwork.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8JPrznbw0YAQ/KXy" Content-Disposition: inline In-Reply-To: <4A3E49C6.5070804@hartwork.org> User-Agent: Mutt/1.5.16 (2007-06-09) X-Archives-Salt: c5c30799-33ac-41cb-bb42-5b48ab6af67a X-Archives-Hash: 0c732dffa438477fca6a638f8feaf38f --8JPrznbw0YAQ/KXy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 21, 2009 at 04:55:02PM +0200, Sebastian Pipping wrote: > Robin H. Johnson wrote: > > Relevant to this, I might not want to disclose my profile inheritance > > tree. Here's one of them for you: > > /etc/make.profile > > /etc/managed-portage/hosts/build_webdb/make.profile > > /etc/managed-portage/common/post/make.profile > > /etc/managed-portage/class/webdb/make.profile > > /etc/managed-portage/class/db/make.profile > > /etc/managed-portage/class/web/make.profile > > /etc/managed-portage/common/pre/make.profile > > /etc/managed-portage/location/surrey/make.profile > > /etc/managed-portage/hwtype/nehalem/make.profile > > /usr/portage/profiles/default/linux/amd64/2008.0 > Which of these is the target of the /etc/make.profile link? > The last one? My current approach resolves the soft link and > cuts of the profiles dir prefix. So in case it's the last for > you that would be $MP =3D /etc/managed-portage. There is a symlink right now, but there might not be in future. /etc/make.profile/parents -> $MP/hosts/build_webdb/make.profile $MP/hosts/build_webdb/make.profile/parents: $MP/common/pre/make.profile $MP/location/surrey/make.profile $MP/class/webdb/make.profile $MP/hwtype/nehalem/make.profile $MP/common/post/make.profile $MP/class/webdb/make.profile/parents: $MP/class/db/make.profile $MP/class/web/make.profile $MP/hwtype/nehalem/make.profile/parents: /usr/portage/profiles/default/linux/amd64/2008.0 The following have no parents: $MP/class/db/make.profile $MP/class/web/make.profile $MP/common/pre/make.profile $MP/common/post/make.profile $MP/location/surrey/make.profile > To auto-filter profiles would parsing profiles.desc work? > Would a synced CVS checkout of > > give anything more that I could or should use? I'm wondering how profiles should be reported. Rather than just the endpoint, I'm thinking that we should resolve them and generate a list, like the above, then explicitly whiteout the non-public ones. So in the above, you'd report: =3D=3D=3D (censored) X 13 default/linux/amd64/2008.0 =3D=3D=3D The resolving can be terminated at each profile that is listed in profiles.desc, so you can just report default/linux/amd64/2008.0 and not all the profiles that make that up. > I see. How about this approach instead: > - Get list of overlays from layman-global.txt, through either > A) Download and keep a snapshot of layman-global.txt in sync ourselves Just A, per your other email. > - Take the official tree and globa overlays (overlays from > layman-global.txt) into account for statistics >=20 > - Resolve ${storage} from /etc/layman/layman.cfg >=20 > - Include ebuilds from ${storage}/{global,overlays,here} and > /usr/portage/ >=20 > What it does not catch is people putting their own ebuilds > right into the main tree. As they lose them all on the next sync > are we safe to assume that no one really does that? > If not are there alternatives to comparing to a synced checkout > of gentoo-x86 (either rsync or CVS)? Why does the raw content of the trees matter? I can see the source (which tree) of a given package that is already installed mattering, but not the raw content of the tree. > Any concerns or ideas for improvement? /usr/portage might NOT be from the public rsync. - Many devs have it straight from CVS. - Infra has it stripped of a lot of GUI packages (like gnome, kde etc). --=20 Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 --8JPrznbw0YAQ/KXy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Robbat2 @ Orbis-Terrarum Networks - The text below is a digital signature. If it doesn't make any sense to you, ignore it. iEYEARECAAYFAko+r6UACgkQPpIsIjIzwiyhMwCeLLZE285BcSc5PYp2/AuYY9qQ f0sAnj4x0BqMeE66YpF5lNZwccrXPEg6 =Fl+4 -----END PGP SIGNATURE----- --8JPrznbw0YAQ/KXy--