List Archive: gentoo-alt
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Sun, 2011-02-06 at 12:48 +0100, Fabian Groffen wrote:
> On 31-01-2011 10:50:59 +0000, Alan Hourihane wrote:
> > On FreeMiNT there is an issue with the logfile that I've never traced
> > and always had to disable it, with a bit of hackery. But revisiting has
> > shown me in SpawnProcess.py there is a function called _can_log which
> > always returns TRUE.
> > What's the best way to make this return FALSE on FreeMiNT, until I can
> > trace the root cause ?
> Do you have a backtrace or something? Maybe we can easily fix it,
> instead of working around it. The code seems to use some gzip
> "encoder", perhaps its missing on your end (though unlikely if you ask
I don't get a backtrace, just this.....
* The ebuild phase 'compile' has exited unexpectedly. This type of
* behavior is known to be triggered by things such as failed variable
* assignments (bug #190128) or bad substitution errors (bug #200313).
* Normally, before exiting, bash should have displayed an error message
* above. If bash did not produce an error message above, it's possible
* that the ebuild has called `exit` when it should have called `die`
* instead. This behavior may also be triggered by a corrupt bash binary
* a hardware problem such as memory or cpu malfunction. If the problem
* not reproducible or it appears to occur randomly, then it is likely
* be triggered by a hardware problem. If you suspect a hardware problem
* then you should try some basic hardware diagnostics such as memtest.
* Please do not report this as a bug unless it is consistently
* reproducible and you are sure that your bash binary and hardware are
* functioning properly.