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 1MIORm-0004tf-2u for garchives@archives.gentoo.org; Sun, 21 Jun 2009 14:55:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5E957E0314; Sun, 21 Jun 2009 14:55:04 +0000 (UTC) Received: from smtprelay11.ispgateway.de (smtprelay11.ispgateway.de [80.67.29.28]) by pigeon.gentoo.org (Postfix) with ESMTP id 072CBE0314 for ; Sun, 21 Jun 2009 14:55:04 +0000 (UTC) Received: from [85.179.11.219] (helo=[192.168.0.3]) by smtprelay11.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MIORj-00084y-0D for gentoo-dev@lists.gentoo.org; Sun, 21 Jun 2009 16:55:03 +0200 Message-ID: <4A3E49C6.5070804@hartwork.org> Date: Sun, 21 Jun 2009 16:55:02 +0200 From: Sebastian Pipping User-Agent: Thunderbird 2.0.0.21 (X11/20090502) 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Gentoo stats server/client @ 2009-06-21 References: <4A3D8C60.2040701@hartwork.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Df-Sender: 874396 X-Archives-Salt: 86fe6b98-89e0-40f5-bab5-739dd7229b46 X-Archives-Hash: 733819a5ad365d4be312e225509d5779 First thanks for sharing your concerns and setup bits. That's the right thing at the the right time. 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 default/linux/amd64/2008.0 To auto-filter profiles would parsing profiles.desc work? Would a synced CVS checkout of give anything more that I could or should use? >> For Overlays .. >> we filter out overlays not located below /usr/local/portage/layman/. > This is going to be fail. > 1. That's not the only location used for layman. > - At home: /code/gentoo/layman/ > - At work: /usr/local/portage-layman/ > - Gentoo Infra: /usr/portage/local/layman/ > > 2. Just because an overlay is distributed by layman does NOT mean that > it's safe to disclose the existence of, within Gentoo infra, we do > this in layman.cfg: > overlays : http://www.gentoo.org/proj/en/overlays/layman-global.txt > file:///etc/layman/infra-overlays.xml 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 B) Use heuristic on layman's cache - Resolve ${cache} from /etc/layman/layman.cfg - Parse all ${cache}/cache_*.xml files using the Layman API - Compare the list of overlays each file provides against a hardcoded snapshot of overlay names ("akoya alexxy arcon ..") - Assume the file with the highest count of matches for layman-global.txt if the count is >=50 of the number hardcoded overlays - Take the official tree and globa overlays (overlays from layman-global.txt) into account for statistics - Resolve ${storage} from /etc/layman/layman.cfg - Include ebuilds from ${storage}/{global,overlays,here} and /usr/portage/ 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)? Any concerns or ideas for improvement? > While I don't mind disclosing the list of overlays we have in infra, > other large-scale use of layman might not be happy to disclose it. Agreed. > 3. For one of my work overlays, we have a custom category called > 'ih-int', for our internal ebuilds (some just meta ebuild, others > full applications). I might not want to disclose just those package names. Right. With the approach described above the whole overlay is ignored. Sebastian