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.sh, 
so I couldn't use it with the main portage tree. Unless there's a way to do 
this in stock portage? I don't have any experience with the python side of 
portage, so please enlighten my ignorance...

>
> You can use SANDBOX_DEBUG_LOG and SANDBOX_DEBUG instead of modifying the
> sandbox- works just the same.  
I'll look at doing that, the less modifications the better.

> Also, variables changing _will_ cause 
> 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 
seems safest. The problem is that some ebuilds (eg fftw) modify CFLAGS, thus 
invalidating the cache.

How safe do you think it is to ignore these variables entirely? Some of them 
like LDFLAGS might affect the results of some configure tests. We could have 
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 be 
very high...

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951