Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] ISO 0.9.4-test5 x86/ppc/x86-64 are out

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Karsten Behrmann <BearPerson AT gmx.net>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] ISO 0.9.4-test5 x86/ppc/x86-64 are out
  • Date: Thu, 23 Jun 2005 23:42:43 +0200

Duane wrote:
> Andrew wrote:
> > Write up a template for people to fill out, items for each menu item,
> > if they used it and what they put in it. Items for all the intermediate
> > steps if they see anything unusual. That will also make it easier to
> > figure out what people did to cause a bug and how to reproduce it.
> > Perhaps even a simple web-based form to automate the form...
> How about setting a flag to log all the console inputs and outputs into
> a file as well as a written report? The file is saved in
> /var/log/sorcery/iso_install. This can be sent off with the test report.
> The flag that turns the log on is on in teh test iso and off in the
> final iso, but can be turned on.

I think this is a pretty good idea.
What we need (eventually, so maybe not in the old installer anymore) is
a good _logging_ system.
I take my definition of a log from [0], a quite nice resource IMO.
Let me give a brief introduction to logging:
There is printlining, and there is logging.
Printlining is something like
echo "ROOT=$ROOT, BOOT=$BOOT"
sleep 10

While logging is more or less
echo "$(date) bootloader: ROOT=$ROOT, BOOT=$BOOT" >/tmp/install.log
A good logging would also include variables to fine-tune the amount
of stuff that is logged.
The advantages of logging are:
- The log can be sent in with a bug report
- You can debug later without having to rely on "I saw XY pop up for a second"
- You don't have to neccessarily be at the box in order to track the bug

Good, tunable logging also offers:
- You may not need to modify the program to track down a bug in a special case
- Logging can be defaulted to seperate values for testing or for stable ISO's
- You can ask the user "could you turn logging up to X before doing Z"
- It gives precise info when you (know you) need it, and less useless info
where you know you don't

So, how are we going to do this on the ISO?
I would propose the following scheme:
we define
debug_log( component, priority, log message)
This function will log the message if the current log level is >= $2.
If a specific log level for $1 exists, it uses it instead of the global level.

I would suggest logging to /tmp/something, as it is available during the
entire
install, and copying that file to the disk at the end of the install
(or timestamp the filename and copy it on whenever the installer is exited)

I'd propose the following as log format:
$(date +%H:%M:%S) $2 ($1): $3

Quickly ending this post, mother shooing me to bed :/
Karsten

Attachment: pgpiZxp6lAX7p.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page