[Aboriginal] LFS 7.3 untested

[Rob Landley]

On 03/31/2013 02:50:01 AM, Prasanna Balan wrote:
> On 17/03/13, Rob Landley wrote:
> > --target-list=arm-softmmu" and such and run with just that, and  
> system
> > images booted fine. Why are you needing the user targets?
> 
> I tried it the previous time... user targets are needed for
> control-images.System images boot fine with only softmmu

Sorry for the delay. I'm having the weirdest intermittent failures on  
the old 6.8 LFS, and trying to track down what's causing it before  
upgrading.

The control images don't need user targets, they're mounted as /dev/hdc  
in the system image. (The native-build.sh sets HDC= to the squashfs  
file, and then dev-environment.sh wraps that in the appropriate "-hdc"  
qemu command line argument and glues it to QEMU_EXTRA with  
run-emulator.sh throws on the end of the qemu command line. The init  
script tries to mount /dev/hdc on /mnt and checks for /mnt/init, and if  
it's there pauses for 3 seconds waiting for a keypress; if it gets one  
it provides a shell prompt, and if it doesn't get one it runs  
/mnt/init.)

So basically there's always /dev/hda for the root filesystem, for  
dev-environment.sh there's /dev/hdb mounted on /home, and for  
native-build there's also /dev/hdc mounted on /mnt.

Now there's a completely separate more/chroot-setup.sh function that  
sets up a chroot and bind mounts a build control image into /mnt within  
that before chrooting into it. But I only test i686 and x86_64 with  
that.

> > > And yes, it breaks at  gmp because it needs m4. Need to work on it
> > > now changing configure options.
> 
> pushed m4 on top of package list and it worked fine.

So just a sequencing issue?

> Util-linux broke
> for which I found a patch for in the buildroot tree.Can I use it
> directly as I cannot find a license statement in the aboriginal main
> page ?? buildroot is GPLv2+

The license I'm using for new code these days is
http://landley.net/hg/toybox/file/a315fb343e2b/LICENSE

Which is either a BSD style license or public domain depending on how  
you squint.

Aboriginal started life as GPLv2 and is now "I don't care". Call it  
GPLv2 that I'm never going to enforce. (I'd apply the above license if  
I felt like going through the triage work to contact old contributors  
and make sure they were ok with it or rip out their code if I couldn't.)

But mostly it doesn't come up because it's just the license on the  
scripts. The resulting binaries that gets installed aren't affected by  
the license on the scripts any more than the license on your word  
processor applies to a novel you write with it.
The corresponding images are whatever license the packages have (mostly  
GPLv2 and some BSD). The non-package files that wind up in the  
resulting system image are all in aboriginal/sources/root-filesystem  
and I think I wrote them all without any third party contribution, so I  
can probably public domain them so as not to have to care.

The build control images are BSD/public domain unless it says  
otherwise. A patch that applies to a package has to have a compatible  
license with the rest of the package or you can't distribute the  
resulting binaries, so this shouldn't be a new issue.

> > > Just add it to aboriginal and a lot of packages could be tested.  
> Lots
> > > of packages in  the 6.8 LFS version had disable-tls in their
> > > ./configure
> >
> > Because uClibc didn't have it. Presumably I can clean that out  
> now...
> 
> I read in uclibc list that they are finally planning a new release.May
> be I should wait until that.

I'm seriously looking to switch over to musl. I need to track down the  
stability problems before I can get this release out, but I'm likely to  
go musl instead upgrading uClibc, because uClibc's inability to put out  
releases can only be described as "chronic" at this point:

http://comments.gmane.org/gmane.comp.lib.uclibc.general/6876
http://lists.busybox.net/pipermail/uclibc/2005-December/034305.html
http://lists.busybox.net/pipermail/uclibc/2006-March/035777.html
http://lists.busybox.net/pipermail/uclibc/2006-April/035936.html
http://lists.uclibc.org/pipermail/uclibc/2007-September/039215.html
http://lists.busybox.net/pipermail/uclibc/2009-November/043283.html

And so on, and so forth. I thought kicking the buildroot traffic off  
onto its own mailing list might fix it (even if I had to _create_ that  
mailing list):
http://lists.busybox.net/pipermail/uclibc/2006-July/036836.html

But no.  Then I thought appointing a new maintainer more or less by  
fiat might fix it:
http://lists.busybox.net/pipermail/uclibc/2008-October/041191.html

But no...

I think it's endemic to uClibc. *shrug*

Rob
 1364747227.0