[Aboriginal] Couple of bugs.

[David Seikel]

On Sat, 9 Apr 2011 10:35:56 -0500 Rob Landley <rlandley at parallels.com>
wrote:

> On 04/09/2011 10:06 AM, David Seikel wrote:
> > On Sat, 9 Apr 2011 09:16:56 -0500 Rob Landley
> > <rlandley at parallels.com> wrote:
> > 
> >> I need to figure out what infrastructure goes into aboriginal linux
> >> and what goes into the separate control-images.  (Automative native
> >> build control images.  Distro bootstrapping.  I suck at naming
> >> things, anybody have a suggestion?  They can share the mailing list
> >> until there's enough traffic ot justify splitting it off, but I
> >> have to name the mercurial repository in order to put it online...)
> > 
> > Rainbow serpent?  "moves through water and rain, shaping landscapes,
> > naming and singing of places, swallowing and sometimes drowning
> > people; strengthening the knowledgeable with rainmaking and healing
> > powers; blighting others with sores, weakness, illness, and death."
> 
> Never heard of it before.

Australian aboriginal mythology that is reasonably common across
Australia, and quite well known here.

> > The control images could be both examples, and bootstrap steps to
> > the popular distros you have already mentioned.  Stopping short of
> > being distros or distro builders, and letting the distro maintainers
> > themselves deal with the next step once we get them bootstrapped.
> > Though perhaps a full BLFS build is on the cards, since that has a
> > limit on the packages, is a good shake down, and a good match.
> 
> Yup.  There's good reasons to _do_ it, it's just the scope of the
> control images heap could grow larger than the rest of aboriginal
> linux combined.  How many distros are there?

That's why I said "popular distros you have already mentioned".  That's
where you draw the line and say no.  LFS, Gentoo, Debian, Red Hat, and
Ubuntu.  Maybe ArchLinux as well.  Certainly not Android.

> > Could be both separate, and being able to use Aboriginal Linux as
> > the build environment by having the two side by side, so people can
> > run both with simple scripts, then use the results to build some
> > sort of bootable image, or keep running it under qemu.
> > 
> > Could also have the option of combining it into one image, and not
> > two where one is mounted automatically, then have to manually
> > chroot into it to actually do anything with the bootstrap under
> > qemu.
> 
> The control images are target independent, the system images are
> target specific.  (And the control images can be pretty darn big, the
> LFS one is 350 megs.)  It makes sense to me to keep them separate.

Eventually a lot of users of the system will want to build bootable
images, plus for the likes of LFS, include the toolchain that has been
used so far.

> If you use the run-emulator.sh, it runs the build automatically, but
> there's a 3 second delay where it prompts you to press a key to get a
> shell prompt, and only starts the build if you don't.
> 
> I can easily change how that works, but it's really a user interface
> question.  (Aesthetic issue, not necessarily a one true answer there.)

Does it do the chroot step into the bootstrap image when you press
that key?

> > I'd probably dump a EFL on frame buffer, and EFL on X minimal
> > bootstrap into the EFL repo, as an example to others to not start
> > dumping random collections of bootstraps into your repos.  They
> > already have an OpenEmbedded area in their SVN.
> 
> I do want to set up a vnc desktop export.  In theory x.org does this
> built-in, in practice I've misplaced the instructions I got it to work
> with last time.  (Maybe it was in BLFS somewhere...)

Or don't pass -nographic to qemu, which I already have a modified
run-emulator.sh doing.  Something I'll need to play with more for this
project.


Think I have come up with an acceptable way for me to create a multi
partition bootable image suitable for DDing onto a CF card, without
having to use root on the host.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/aboriginal-landley.net/attachments/20110410/1bd5870b/attachment-0003.pgp>