| 1 |
On Friday 08 October 2004 22:08, Brian Harring wrote: |
| 2 |
> Well... that's weird, attempted to send this directly to dan, having it |
| 3 |
> bail due to |
| 4 |
> 'failed: relaying not allowed: danarmak@g.o' |
| 5 |
> I assume I'm being an idiot and screwing up the address (or local |
| 6 |
> configuration)... |
| 7 |
All I can say is, I can receive at that address quite well... |
| 8 |
|
| 9 |
> |
| 10 |
> Either way, you might want to take a look at my implementation of |
| 11 |
> confcache in |
| 12 |
> http://dev.gentoo.org/~ferringb/ebuild-daemon/51-pre20-cvs/ |
| 13 |
I did, but it's tied to your ability to call back into python from ebuild.sh, |
| 14 |
so I couldn't use it with the main portage tree. Unless there's a way to do |
| 15 |
this in stock portage? I don't have any experience with the python side of |
| 16 |
portage, so please enlighten my ignorance... |
| 17 |
|
| 18 |
> |
| 19 |
> You can use SANDBOX_DEBUG_LOG and SANDBOX_DEBUG instead of modifying the |
| 20 |
> sandbox- works just the same. |
| 21 |
I'll look at doing that, the less modifications the better. |
| 22 |
|
| 23 |
> Also, variables changing _will_ cause |
| 24 |
> configure to bail if they've been cached (cflags fex), so you might want |
| 25 |
> to either filter those entries (they start with ac_cv_env_), or rewrite |
| 26 |
> them (I went for rewrite, works although I worry about other cache |
| 27 |
> entries relying on the vars not changing). |
| 28 |
I dump the cache when they change in the latest revision of my patch. That |
| 29 |
seems safest. The problem is that some ebuilds (eg fftw) modify CFLAGS, thus |
| 30 |
invalidating the cache. |
| 31 |
|
| 32 |
How safe do you think it is to ignore these variables entirely? Some of them |
| 33 |
like LDFLAGS might affect the results of some configure tests. We could have |
| 34 |
separate cache data for different combinations of them... |
| 35 |
|
| 36 |
> Aside from that, there is also the md5'ing of /proc/cpuinfo- most users, |
| 37 |
> not an issue, as magnade pointed out, this is a killer for users that |
| 38 |
> have procs that adjust their frequency (laptops fex) for power saving- |
| 39 |
> this changes the md5 of /proc/cpuinfo pretty much continually, |
| 40 |
> invalidating the cache continually. |
| 41 |
|
| 42 |
We'll have to add special treatment for it then. |
| 43 |
|
| 44 |
Unfortunately I've picked this time to fall sick, so my response time may be |
| 45 |
very high... |
| 46 |
|
| 47 |
-- |
| 48 |
Dan Armak |
| 49 |
Gentoo Linux developer (KDE) |
| 50 |
Matan, Israel |
| 51 |
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key |
| 52 |
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 |
Archives