fixed a typo
- Subject: fixed a typo
- From: umeboshi at gregscomputerservice.com (Joseph Rawson)
- Date: Wed, 23 May 2007 18:31:27 -0500
- Message-id: <email@example.com>
- In-reply-to: <46549C3E.firstname.lastname@example.org>
- References: <email@example.com> <firstname.lastname@example.org> <46549C3E.email@example.com>
On Wednesday 23 May 2007 14:55, Daniel Baumann wrote:
> Joseph Rawson wrote:
> > I would be glad to help with this. I only need a general direction to
> > work in. I can see where you are already checking for the presence of
> > stage files.
> note: stage files handling is pretty naiive, if you have a better idea
It's not naive, it's just not yet completely implemented.
> how to do it, i'm eager to know. additionally, as this was not of so
> much importance to me, it's not implemented on all helpers properly (as
> you correctly spotted out, most helpers are just depending on
The problem I have is figuring out where the forks are in the lh_* scripts.
The fork between debootstrap/cdebootstrap is easy to see, but take for
instance the bootloaders and linux-image, and which lh_binary_$image scripts
ddepend on which bootloaders. I'm sorry if I don't make much sense here,
but I am still browsing around the code, and not as familiar as you are with
it. I guess I still need more time to go through everything.
I was just thinking that a script called lh_binary_image that runs the for
loop across $L_B_Images and call the lh_bin_iso/hdd separately.
> yes. it should be possible to build multiple binary images in one shot.
> > One method of fixing this would be to make a stage file
> > like .stage/binary_linux-image.$LBI (shortened) and check for the stage
> > file in the case statement. This would resolve that particular problem.
> looks like a good idea, yes.
> > I haven't been on a system where the disk isn't the biggest bottleneck in
> > so long I've neglected to think of those situations.
> ever had anything non-i386/non-amd64? ;)
Not really, except a zaurus. I made a machine with dual p3's and 4 scsi
drives. That's the fastest disks I ever came across. The only way I know to
escape the disk bottleneck is to use tmpfs. I used to build my debian
packages in tmpfs in the past because it was so much quicker.
> btw, for further stuff, it would be nice if you can move on to the
> mailinglist, better place to actually discuss something.
ok, I just subscribed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/debian-live-devel/attachments/20070523/5886d451/attachment.pgp