From alanpost at sunflowerriver.org  Sun Apr 19 15:38:20 2015
From: alanpost at sunflowerriver.org (Alan Post)
Date: Sun, 19 Apr 2015 09:38:20 -0600
Subject: [Aboriginal] lfs-bootstrap in control-images-1.1.0 incompatible
	with aboriginal-1.4
Message-ID: <20150419153820.GA5207@sunflowerriver.org>

Hello Rob,

We last spoke in March 2011.  I submitted a typo patch prepared while reading
documentation.  I have another issue to report.

A source compile of lfs-bootstrap build from control-images-1.1.0 does not
work using aboriginal-1.4, as it is missing changeset 39:31d7462a8649[1].

This causes the build to run in the root filesystem, which runs out of
disk space, creating errors like this:

checking whether make is case sensitive... yes
./configure: line 2974: cannot create temp file for here-document: No space left on device
configure: creating ./config.status
./configure: line 3135: cannot create temp file for here-document: No space left on device
./configure: line 3516: cannot create temp file for here-document: No space left on device
./configure: line 3549: cannot create temp file for here-document: No space left on device
./configure: line 3600: cannot create temp file for here-document: No space left on device
./configure: line 3677: cannot create temp file for here-document: No space left on device
./configure: line 3697: cannot create temp file for here-document: No space left on device
./conf12967subs.sh: line 1: cannot create temp file for here-document: No space left on device
configure: error: could not make ./config.status
real 1.226084
user 0.056000
sys 0.008000
autoconf died
reboot: Restarting system
reboot: machine restart
=== End native build

Applying changeset 39:31d7462a8649 causes lfs-bootstrap to build.
The binary lfs-bootstrap[2] also works.

Any chance of cutting a new control-images?  This was a real head
scratcher until I started spelunking inside your binary release
and found the cause.

-A

1: http://landley.net/hg/control-images/rev/31d7462a8649
2: http://landley.net/aboriginal/control-images/downloads/binaries/


From rob at landley.net  Sun Apr 19 23:56:52 2015
From: rob at landley.net (Rob Landley)
Date: Sun, 19 Apr 2015 18:56:52 -0500
Subject: [Aboriginal] lfs-bootstrap in control-images-1.1.0 incompatible
	with aboriginal-1.4
In-Reply-To: <20150419153820.GA5207@sunflowerriver.org>
References: <20150419153820.GA5207@sunflowerriver.org>
Message-ID: <CAOS_Y6TMtb=TWP1L5A6Z8t=7_+uc5oT-SL_wLkvxr3A4Z4ZxZw@mail.gmail.com>

On Sun, Apr 19, 2015 at 10:38 AM, Alan Post <alanpost at sunflowerriver.org> wrote:
> Hello Rob,
>
> We last spoke in March 2011.  I submitted a typo patch prepared while reading
> documentation.  I have another issue to report.
>
> A source compile of lfs-bootstrap build from control-images-1.1.0 does not
> work using aboriginal-1.4, as it is missing changeset 39:31d7462a8649[1].

Yes, that's why I checked in a change and updated the prebuilt binaries:
http://landley.net/aboriginal/control-images/downloads/binaries/

> This causes the build to run in the root filesystem, which runs out of
> disk space, creating errors like this:

I noticed. The previous build had the assumption that it was either
running via dev-environment.sh in a qemu squashfs, or via
more/chroot-splice.sh in a chroot. It used "can I write to /.testfile"
to distinguish, which wasn't a good test for tmpfs' "root is writeable
but doesn't have much free space".

> Applying changeset 39:31d7462a8649 causes lfs-bootstrap to build.
> The binary lfs-bootstrap[2] also works.
>
> Any chance of cutting a new control-images?  This was a real head
> scratcher until I started spelunking inside your binary release
> and found the cause.

Happy to. What does "cutting" mean in this context, adding a mercurial
tag? (I thought the binary images were up to date, their timestamp
says last month. Did I rebuilt them wrong?)

(I need to do a new lfs-bootstrap based on something more current, maybe 7.4.)

Rob


From alanpost at sunflowerriver.org  Mon Apr 20 00:17:23 2015
From: alanpost at sunflowerriver.org (Alan Post)
Date: Sun, 19 Apr 2015 18:17:23 -0600
Subject: [Aboriginal] lfs-bootstrap in control-images-1.1.0 incompatible
	with aboriginal-1.4
In-Reply-To: <CAOS_Y6TMtb=TWP1L5A6Z8t=7_+uc5oT-SL_wLkvxr3A4Z4ZxZw@mail.gmail.com>
References: <20150419153820.GA5207@sunflowerriver.org>
	<CAOS_Y6TMtb=TWP1L5A6Z8t=7_+uc5oT-SL_wLkvxr3A4Z4ZxZw@mail.gmail.com>
Message-ID: <20150420001723.GB5207@sunflowerriver.org>

On Sun, Apr 19, 2015 at 06:56:52PM -0500, Rob Landley wrote:
> Happy to. What does "cutting" mean in this context, adding a mercurial
> tag? (I thought the binary images were up to date, their timestamp
> says last month. Did I rebuilt them wrong?)
> 
> (I need to do a new lfs-bootstrap based on something more current, maybe 7.4.)
> 

By cutting I mean to ask for a 1.1.1 source code release at:

  http://landley.net/aboriginal/control-images/downloads/

I would certainly appreciate a refreshed LFS, but the problem I
experienced was downloading control-images-1.1.0 and aboriginal-1.4
and finding they don't work together.  I was further surprised to
learn that the binary .hdc files do not correspond to the source
code, but that at least helped me find the problem.

I haven't found any issues with the binary images, only the control
images source code.  I'm using the lfs-bootstrap as a guide to
creating my own control image.

I appreciate your explanation of the patch, I had wondering what
caused the change to a read/write root filesystem.

-A