1 |
On Sun, 2011-02-06 at 12:48 +0100, Fabian Groffen wrote: |
2 |
> On 31-01-2011 10:50:59 +0000, Alan Hourihane wrote: |
3 |
> > On FreeMiNT there is an issue with the logfile that I've never traced |
4 |
> > and always had to disable it, with a bit of hackery. But revisiting has |
5 |
> > shown me in SpawnProcess.py there is a function called _can_log which |
6 |
> > always returns TRUE. |
7 |
> > |
8 |
> > What's the best way to make this return FALSE on FreeMiNT, until I can |
9 |
> > trace the root cause ? |
10 |
> |
11 |
> Do you have a backtrace or something? Maybe we can easily fix it, |
12 |
> instead of working around it. The code seems to use some gzip |
13 |
> "encoder", perhaps its missing on your end (though unlikely if you ask |
14 |
> me) |
15 |
|
16 |
I don't get a backtrace, just this..... |
17 |
|
18 |
* The ebuild phase 'compile' has exited unexpectedly. This type of |
19 |
* behavior is known to be triggered by things such as failed variable |
20 |
* assignments (bug #190128) or bad substitution errors (bug #200313). |
21 |
* Normally, before exiting, bash should have displayed an error message |
22 |
* above. If bash did not produce an error message above, it's possible |
23 |
* that the ebuild has called `exit` when it should have called `die` |
24 |
* instead. This behavior may also be triggered by a corrupt bash binary |
25 |
or |
26 |
* a hardware problem such as memory or cpu malfunction. If the problem |
27 |
is |
28 |
* not reproducible or it appears to occur randomly, then it is likely |
29 |
to |
30 |
* be triggered by a hardware problem. If you suspect a hardware problem |
31 |
* then you should try some basic hardware diagnostics such as memtest. |
32 |
* Please do not report this as a bug unless it is consistently |
33 |
* reproducible and you are sure that your bash binary and hardware are |
34 |
* functioning properly. |
35 |
|
36 |
Alan. |