FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 01-31-2011, 09:50 AM
Alan Hourihane
 
Default Logging

Hi all,

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 ?

Thanks,

Alan.
 
Old 02-06-2011, 10:48 AM
Fabian Groffen
 
Default Logging

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
me)


--
Fabian Groffen
Gentoo on a different level
 
Old 02-06-2011, 12:04 PM
Alan Hourihane
 
Default Logging

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
> me)

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
or
* a hardware problem such as memory or cpu malfunction. If the problem
is
* not reproducible or it appears to occur randomly, then it is likely
to
* 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.

Alan.
 

Thread Tools




All times are GMT. The time now is 02:42 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org