From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32009 invoked from network); 9 Oct 2004 09:45:04 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 9 Oct 2004 09:45:04 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CGDmh-0008T9-2x for arch-gentoo-portage-dev@lists.gentoo.org; Sat, 09 Oct 2004 09:45:03 +0000 Received: (qmail 20783 invoked by uid 89); 9 Oct 2004 09:45:01 +0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@lists.gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 4066 invoked from network); 9 Oct 2004 09:45:01 +0000 From: Dan Armak Reply-To: danarmak@gentoo.org To: gentoo-portage-dev@lists.gentoo.org Date: Sat, 9 Oct 2004 11:45:44 +0200 User-Agent: KMail/1.7 References: <1097265907.8869.27.camel@localhost.localdomain> In-Reply-To: <1097265907.8869.27.camel@localhost.localdomain> Organization: Gentoo Technologies, Inc. MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1124702.jTISPyLpgk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410091145.54054.danarmak@gentoo.org> Subject: Re: [gentoo-portage-dev] re: confcache X-Archives-Salt: 621488c9-903b-4ae9-a49d-6fd57d9de5d3 X-Archives-Hash: 4d0d89bd6d64086763065d2c76557a62 --nextPart1124702.jTISPyLpgk Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 08 October 2004 22:08, Brian Harring wrote: > Well... that's weird, attempted to send this directly to dan, having it > bail due to > 'failed: relaying not allowed: danarmak@gentoo.org' > I assume I'm being an idiot and screwing up the address (or local > configuration)... All I can say is, I can receive at that address quite well... > > Either way, you might want to take a look at my implementation of > confcache in > http://dev.gentoo.org/~ferringb/ebuild-daemon/51-pre20-cvs/ I did, but it's tied to your ability to call back into python from ebuild.s= h,=20 so I couldn't use it with the main portage tree. Unless there's a way to do= =20 this in stock portage? I don't have any experience with the python side of= =20 portage, so please enlighten my ignorance... > > You can use SANDBOX_DEBUG_LOG and SANDBOX_DEBUG instead of modifying the > sandbox- works just the same. =20 I'll look at doing that, the less modifications the better. > Also, variables changing _will_ cause=20 > configure to bail if they've been cached (cflags fex), so you might want > to either filter those entries (they start with ac_cv_env_), or rewrite > them (I went for rewrite, works although I worry about other cache > entries relying on the vars not changing). I dump the cache when they change in the latest revision of my patch. That= =20 seems safest. The problem is that some ebuilds (eg fftw) modify CFLAGS, thu= s=20 invalidating the cache. How safe do you think it is to ignore these variables entirely? Some of the= m=20 like LDFLAGS might affect the results of some configure tests. We could hav= e=20 separate cache data for different combinations of them... > Aside from that, there is also the md5'ing of /proc/cpuinfo- most users, > not an issue, as magnade pointed out, this is a killer for users that > have procs that adjust their frequency (laptops fex) for power saving- > this changes the md5 of /proc/cpuinfo pretty much continually, > invalidating the cache continually. We'll have to add special treatment for it then. Unfortunately I've picked this time to fall sick, so my response time may b= e=20 very high... =2D-=20 Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key =46ingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 --nextPart1124702.jTISPyLpgk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBZ7NRUI2RQ41fiVERAquJAJoCWAE1LvdaAGT7d7cbAE2g5vD8QQCeL25f gUy5nDgZggzL6SC0Xtp1BTQ= =JNM8 -----END PGP SIGNATURE----- --nextPart1124702.jTISPyLpgk--