From rob at landley.net  Sat Mar  2 04:27:13 2013
From: rob at landley.net (Rob Landley)
Date: Fri, 01 Mar 2013 22:27:13 -0600
Subject: [Aboriginal] The perl patches went upstream!
Message-ID: <1362198433.21837.4@driftwood>

After only 5 years! Woo!

They didn't go into 3.8, but might be in 3.8-rc1. (Actually it looks  
like Peter Anvin provided his own implementation for one of them, but  
using "bc" instead of perl is fine by me, it's in posix. I can write a  
toybox version that does it right if necessary.)

So 3.8 is out but I've got bug that reproduce on arm and powerpc to fix  
before I can cut a release. Got a bit sidetracked by work and toybox  
and speaking at CELF about why I'm doing toybox(outline  
http://landley.net/talks/celf-2013.txt and video should go up at  
http://www.youtube.com/user/TheLinuxFoundation one of these days).

Working on it...

Rob

 1362198433.0

From onefang at gmail.com  Sat Mar  2 05:48:00 2013
From: onefang at gmail.com (David Seikel)
Date: Sat, 2 Mar 2013 15:48:00 +1000
Subject: [Aboriginal] The perl patches went upstream!
In-Reply-To: <1362198433.21837.4@driftwood>
References: <1362198433.21837.4@driftwood>
Message-ID: <20130302154800.4a29384a.onefang@gmail.com>

On Fri, 01 Mar 2013 22:27:13 -0600 Rob Landley <rob at landley.net> wrote:

> After only 5 years! Woo!

Congratulations.  Sometimes persistence pays off.

-- 
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/attachments/20130302/e15f3efc/attachment.sig>

From bjorn.forsman at gmail.com  Sat Mar  2 09:20:33 2013
From: bjorn.forsman at gmail.com (=?UTF-8?Q?Bj=C3=B8rn_Forsman?=)
Date: Sat, 2 Mar 2013 10:20:33 +0100
Subject: [Aboriginal] The perl patches went upstream!
In-Reply-To: <1362198433.21837.4@driftwood>
References: <1362198433.21837.4@driftwood>
Message-ID: <CAEYzJUH-_9igmLgX0p4qwVtENaYTk9i7WYCYoJZdxG=R27nowg@mail.gmail.com>

On 2 March 2013 05:27, Rob Landley <rob at landley.net> wrote:
> After only 5 years! Woo!

Congratulations :-)

 1362216033.0

From rob at landley.net  Mon Mar 11 10:49:58 2013
From: rob at landley.net (Rob Landley)
Date: Mon, 11 Mar 2013 05:49:58 -0500
Subject: [Aboriginal] Towards a release.
Message-ID: <1362998998.12090.0@driftwood>

Got a weekend to myself, catching up on todo items.

The powerpc native build failure was another cp corner case, because  
O_NOFOLLOW varies per target. I was doing an #ifndef and #define for it  
in portability.h because uClibc is buggy and thinks that a Posix 2008  
feature is a GNU extension, in the most rercent release as of 2013.  
(I.E. define GNU_DAMMIT to get a Posix "shall define" symbol. Did I  
mention feature test macros are evil? Yeah, move to musl, bump that up  
a bit on the todo list...) So I patched the local copy of uClibc and  
took the portability.h stanza out of toybox (the build can break if  
your build environment is broken).

The arm versatile problem is that IRQ 27 for the scsi controller is  
relative to the start of the interrupt controller range, and the kernel  
changed the first interrupt on that controller to be 32. So if I add 32  
to the 27 in the driver's irq request, it boots to a shell prompt. (The  
network card is still broken because it needs the adjustment too.)

I think this is a kernel bug and that _it_ should be adding this, but I  
have yet to figure out where. Working through the dump_stack()...

Rob
 1362998998.0

From prazzb at gmail.com  Tue Mar 12 19:00:51 2013
From: prazzb at gmail.com (prasanna balan)
Date: Wed, 13 Mar 2013 00:30:51 +0530
Subject: [Aboriginal] LFS 7.3 untested
Message-ID: <CAELZRKaNwVLFZ6eS3jCEWvg5XHO6wgxiAYQ6ge+psuDss29C2A@mail.gmail.com>

Hello
     I have completed porting LFS 7.3 on top of current control
images.The reason it's untested
     is because i have recently switched to gentoo  and cannot
determine qemu's use flags for
     this purpose. If  someone can enlighten me, it'll be good. ( I
was earlier on arch but it got
     affected by a wontfix bug named systemd )

     I did this via mercurial queues. After enabling mercurial queues, just do :

     hg clone http://landley.net/hg/control-images
     cd control-images
     hg qinit -c
     cat >> .hg/patches/.hg/hgrc << EOF
     [paths]
     default = https://bitbucket.org/prazzb/control-images-patchset
     EOF
     cd .hg/patches
     hg pull -u
     cd ../..
     hg qpush -a
     ./build.sh lfs-bootstrap

     I have also enabled udev. Only thing is I've not built glibc +
tzdata  like
     rob told me to do last time. Let me know if anything doesn't work.

--prazzb

 1363114851.0

From rob at landley.net  Wed Mar 13 06:31:21 2013
From: rob at landley.net (Rob Landley)
Date: Wed, 13 Mar 2013 01:31:21 -0500
Subject: [Aboriginal] LFS 7.3 untested
In-Reply-To: <CAELZRKaNwVLFZ6eS3jCEWvg5XHO6wgxiAYQ6ge+psuDss29C2A@mail.gmail.com>
	(from prazzb@gmail.com on Tue Mar 12 14:00:51 2013)
Message-ID: <1363156281.15703.2@driftwood>

On 03/12/2013 02:00:51 PM, prasanna balan wrote:
> Hello
>      I have completed porting LFS 7.3 on top of current control
> images.

Oh good. I downloaded the 7.3 files but haven't had time to look at  
them yet.

Thanks.

> The reason it's untested
>      is because i have recently switched to gentoo  and cannot
> determine qemu's use flags for
>      this purpose.

QEMU's use flags for building it via emerge? Good luck. I just clone  
the git repo (or download the release tarball) and do:

   ./configure --disable-werror && make -j 4 && make install

Outside of my host distro's package management. (It goes into  
/usr/local.)

In any case, this should be testable in a chroot for i686 or x86_64. The
more/chroot_splice.sh wrapper sets up a chroot automatically (and  
umounts the filesystems again when you exit). It can use either an hdc  
or the directory of /mnt contents (which it --bind mounts read-only in  
the chroot, but which you can change on the host and it'll see the  
updates).

> If  someone can enlighten me, it'll be good. ( I
> was earlier on arch but it got
>      affected by a wontfix bug named systemd )

Alas.

I need to do init in toybox, which means I need to read openrc and  
upstart and runit and android's init and figure out what init should  
_look_ like these days.

>      I did this via mercurial queues. After enabling mercurial  
> queues, just do :
> 
>      hg clone http://landley.net/hg/control-images
>      cd control-images
>      hg qinit -c
>      cat >> .hg/patches/.hg/hgrc << EOF
>      [paths]
>      default = https://bitbucket.org/prazzb/control-images-patchset
>      EOF
>      cd .hg/patches
>      hg pull -u
>      cd ../..
>      hg qpush -a
>      ./build.sh lfs-bootstrap
> 
>      I have also enabled udev. Only thing is I've not built glibc +
> tzdata  like
>      rob told me to do last time. Let me know if anything doesn't  
> work.

In _theory_ now that uClibc is using TLS, glibc should build just fine.  
I admit I haven't tried it in some time...

I'm up to my neck in a deadline at work, and trying to get the next  
aboriginal linux release with the 3.8 kernel out, but I've put this  
near the top of my todo list.

Thanks,

Rob
 1363156281.0

From idunham at lavabit.com  Thu Mar 14 05:52:15 2013
From: idunham at lavabit.com (Isaac Dunham)
Date: Wed, 13 Mar 2013 22:52:15 -0700
Subject: [Aboriginal] Aboriginal Digest, Vol 26, Issue 4
In-Reply-To: <mailman.1.1363206623.8468.aboriginal-landley.net@lists.landley.net>
References: <mailman.1.1363206623.8468.aboriginal-landley.net@lists.landley.net>
Message-ID: <20130313225215.3abbd1d6.idunham@lavabit.com>

On Wed, 13 Mar 2013 13:30:23 -0700
aboriginal-request at lists.landley.net wrote:

> 
> > If  someone can enlighten me, it'll be good. ( I
> > was earlier on arch but it got
> >      affected by a wontfix bug named systemd )
> 
> Alas.
> 
> I need to do init in toybox, which means I need to read openrc and  
> upstart and runit and android's init and figure out what init should  
> _look_ like these days.

Note that openrc is not a full init.
It's a (BSD-licensed) replacement for the extra scripts that come with sysvinit, modified to be more robust and work somewhat more widely (ie, can be used with bsd init, sysvinit, or--patched--with busybox init).
You might just want to make an init that can be used by itself or have openrc added on.  
..Unless you want to replace the rc scripts yourself.
They say their goal is to be platform agnostic (it's C and posix sh), so I expect that if someone sent patches improving compatability with toybox they'd accept them.


OT: After 3.9-rc2 came out I looked at torvald's git tree, and it seems that one script switched to bc but the other two are still perl. :(

-- 
Isaac Dunham <idunham at lavabit.com>


 1363240335.0

From prazzb at gmail.com  Thu Mar 14 16:04:35 2013
From: prazzb at gmail.com (Prasanna Balan)
Date: Thu, 14 Mar 2013 21:34:35 +0530
Subject: [Aboriginal] LFS 7.3 untested
In-Reply-To: <1363156281.15703.2@driftwood>
References: <CAELZRKaNwVLFZ6eS3jCEWvg5XHO6wgxiAYQ6ge+psuDss29C2A@mail.gmail.com>
	<1363156281.15703.2@driftwood>
Message-ID: <20130314160435.GA14354@desktop>

On 13/03/13, Rob Landley wrote:
> QEMU's use flags for building it via emerge? Good luck. I just clone  
> the git repo (or download the release tarball) and do:

I did get it to work. Apparently, you need to enable both softmmu and
user target for each architecture.
My problem now is that i have core2duo with 2 GB ram so testing every
architecture becomes too much. I'm testing it at present for x86_64

And yes, it breaks at  gmp because it needs m4. Need to work on it
now changing configure options.

> In _theory_ now that uClibc is using TLS, glibc should build just fine.  
> I admit I haven't tried it in some time...

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

> Rob

prazzb

 1363277075.0

From rob at landley.net  Sun Mar 17 15:24:15 2013
From: rob at landley.net (Rob Landley)
Date: Sun, 17 Mar 2013 10:24:15 -0500
Subject: [Aboriginal] Aboriginal Digest, Vol 26, Issue 4
In-Reply-To: <20130313225215.3abbd1d6.idunham@lavabit.com> (from
	idunham@lavabit.com on Thu Mar 14 00:52:15 2013)
References: <mailman.1.1363206623.8468.aboriginal-landley.net@lists.landley.net>
	<20130313225215.3abbd1d6.idunham@lavabit.com>
Message-ID: <1363533855.15703.13@driftwood>

On 03/14/2013 12:52:15 AM, Isaac Dunham wrote:
> On Wed, 13 Mar 2013 13:30:23 -0700
> aboriginal-request at lists.landley.net wrote:
> 
> >
> > > If  someone can enlighten me, it'll be good. ( I
> > > was earlier on arch but it got
> > >      affected by a wontfix bug named systemd )
> >
> > Alas.
> >
> > I need to do init in toybox, which means I need to read openrc and
> > upstart and runit and android's init and figure out what init should
> > _look_ like these days.
> 
> Note that openrc is not a full init.

Android's init would be my obvious model _except_ that it parses config  
files that look like a shell script but aren't. This tempts people to  
add shell script snippets in there, which don't work.

> It's a (BSD-licensed) replacement for the extra scripts that come  
> with sysvinit,
> modified to be more robust and work somewhat more widely (ie, can be  
> used with bsd
> init, sysvinit, or--patched--with busybox init).

The openrc stuff gets patched, or busybox gets patched?

I could write a replacement for busybox init in a weekend. I actually  
_did_ back in 2005 but it got lost in a laptop crash.

> You might just want to make an init that can be used by itself or  
> have openrc
> added on. ..Unless you want to replace the rc scripts yourself.

Replacing the scripts is not my goal. Satisfying the use cases that led  
to upstart and android init _and_ being reasonably compatible with  
sysvinit is.

> They say their goal is to be platform agnostic (it's C and posix sh),  
> so I expect
> that if someone sent patches improving compatability with toybox  
> they'd accept them.

I need to sit down and study what everybody else did, to work out why  
they did it. This is a largeish project I haven't started yet because I  
have too many other open cans of worms to deal with at the moment. :)

> OT: After 3.9-rc2 came out I looked at torvald's git tree, and it  
> seems that one
> script switched to bc but the other two are still perl. :(

One script is in Andrew's tree, the other is in the kbuild tree I  
think. It looks like 3.10 is when they go upstream.

I should check linux-next and see if they're in there yet...

Rob
 1363533855.0

From rob at landley.net  Mon Mar 18 04:38:18 2013
From: rob at landley.net (Rob Landley)
Date: Sun, 17 Mar 2013 23:38:18 -0500
Subject: [Aboriginal] LFS 7.3 untested
In-Reply-To: <20130314160435.GA14354@desktop> (from prazzb@gmail.com on Thu
	Mar 14 11:04:35 2013)
Message-ID: <1363581498.15703.29@driftwood>

On 03/14/2013 11:04:35 AM, Prasanna Balan wrote:
> On 13/03/13, Rob Landley wrote:
> > QEMU's use flags for building it via emerge? Good luck. I just clone
> > the git repo (or download the release tarball) and do:
> 
> I did get it to work. Apparently, you need to enable both softmmu and
> user target for each architecture.

I generally just run "./configure --disable-werror" and let it select  
all the targets, but I have built "./configure  
--target-list=arm-softmmu" and such and run with just that, and system  
images booted fine. Why are you needing the user targets?

> My problem now is that i have core2duo with 2 GB ram so testing every
> architecture becomes too much. I'm testing it at present for x86_64

If it works on x86 and on powerpc you're probably good. (A little  
endian and a big endian. Arm would show up alignment issues.)

> And yes, it breaks at  gmp because it needs m4. Need to work on it
> now changing configure options.

The old one's breaking on a toybox corner case during LFS build, I need  
to fix that before I can cut a release, and that's my short term goal  
before I spend too much time on this.

> > In _theory_ now that uClibc is using TLS, glibc should build just  
> fine.
> > I admit I haven't tried it in some time...
> 
> 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...

Rob
 1363581498.0

From prazzb at gmail.com  Sun Mar 31 07:50:01 2013
From: prazzb at gmail.com (Prasanna Balan)
Date: Sun, 31 Mar 2013 13:20:01 +0530
Subject: [Aboriginal] LFS 7.3 untested
In-Reply-To: <1363581498.15703.29@driftwood>
References: <20130314160435.GA14354@desktop>
 <1363581498.15703.29@driftwood>
Message-ID: <20130331075001.GA11178@desktop>

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

> > 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.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+

> > 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.

> Rob

prazzb

 1364716201.0

From rob at landley.net  Sun Mar 31 16:27:07 2013
From: rob at landley.net (Rob Landley)
Date: Sun, 31 Mar 2013 11:27:07 -0500
Subject: [Aboriginal] LFS 7.3 untested
In-Reply-To: <20130331075001.GA11178@desktop> (from prazzb@gmail.com on Sun
	Mar 31 02:50:01 2013)
Message-ID: <1364747227.18069.10@driftwood>

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