Re: status of Knoppix as build platform

Nate asked:

 > If you could provide the error messages from the
 > end of that build, it would help a lot.

OK: here is everything after the function that produced the error (there 
were a raft of warnings regarding the evils of defeating types with 
pointers earlier that I assume are not significant to the build):

gcc -c -Os -I//tmp/build/include -L//tmp/build/lib -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  -o Python/pythonrun.o 
Python/pythonrun.c
Python/pythonrun.c: In function `PyOS_getsig':
Python/pythonrun.c:1430: error: storage size of `context' isn't known
Python/pythonrun.c:1436: error: `SIG_ERR' undeclared (first use in this 
function)
Python/pythonrun.c:1436: error: (Each undeclared identifier is reported 
only once
Python/pythonrun.c:1436: error: for each function it appears in.)
Python/pythonrun.c:1437: warning: implicit declaration of function `sigaction'
Python/pythonrun.c:1430: warning: unused variable `context'
Python/pythonrun.c: In function `PyOS_setsig':
Python/pythonrun.c:1451: error: storage size of `context' isn't known
Python/pythonrun.c:1458: error: `SIG_ERR' undeclared (first use in this 
function)
Python/pythonrun.c:1451: warning: unused variable `context'
make[11]: *** [Python/pythonrun.o] Error 1
make[11]: Leaving directory 
`/mnt/hda3/build/gar/lang/python/work/build.d/Python-2.2.3'
make[10]: *** [build-work/build.d/Python-2.2.3/Makefile] Error 2
make[10]: Leaving directory `/mnt/hda3/build/gar/lang/python'
make[9]: *** [../../lang/python/cookies/build.d/install] Error 2
make[9]: Leaving directory `/mnt/hda3/build/gar/lang/python'
make[8]: *** [imgdep-build] Error 2
make[8]: Leaving directory `/mnt/hda3/build/gar/lang/python'
make[7]: *** [../../lang/python/cookies/singularity.d/install] Error 2
make[7]: Leaving directory `/mnt/hda3/build/gar/meta/bbc-contents'
make[6]: *** [imgdep-singularity] Error 2
make[6]: Leaving directory `/mnt/hda3/build/gar/meta/bbc-contents'
make[5]: *** [../../meta/bbc-contents/cookies/singularity.d/install] Error 2
make[5]: Leaving directory `/mnt/hda3/build/gar/meta/singularity'
make[4]: *** [imgdep-singularity] Error 2
make[4]: Leaving directory `/mnt/hda3/build/gar/meta/singularity'
make[3]: *** [../../meta/singularity/cookies/main.d/install] Error 2
make[3]: Leaving directory `/mnt/hda3/build/gar/meta/i386-livecd'
make[2]: *** [imgdep-main] Error 2
make[2]: Leaving directory `/mnt/hda3/build/gar/meta/i386-livecd'
make[1]: *** [../../meta/i386-livecd/cookies/main.d/install] Error 2
make[1]: Leaving directory `/mnt/hda3/build/gar/meta/lnx-bbc'
make: *** [imgdep-main] Error 2

I mistakenly said:

 >> meaning that it got through a lot of core
 >> packages, including glibc, gcc, perl, and the kernel.

and Nate corrected:

 >No.  gcc, glibc, XFree86, and perl are the big major-headache packages
 >that have succeeded by the time you get to python.  The kernel is near
 >the end, and furthermore, it's pretty easy to make it do what we need
 >it to do.

Thanks...I misunderstood because I got an "[install] complete for 
linux-image" and saw a bzImage under 
gar/kernel/linux-image/work/i386/linux-2.4.22/arch/i386/boot. Is the kernel 
itself under "gar/kernel/linux"? What is linux-image?

Thanks for updating versions.txt, I have it now.

I described using nfs to export my garchive to the Knoppix machine, and 
Nate warned:

 > Be careful with NFS.  Make can sometimes choke on the subtle
 > differences between NFS and POSIX filesystem semantics.  It's probably
 > ok for the garchive, though.

I did a "cvs up; make garchive" on the machine exporting the garchive just 
before using it, hoping that the build machine would then only have to 
read, not write the garchive. Would the filesystem differences matter for 
read-only access? Reminds me, though: the documentation identifies the 
possibility to export a garchive via a web server, but I assume that is 
just to make the sources available within a network, since I haven't seen a 
way to specify that the lnx-bbc build could use an http url as a garchive 
source. I guess this is because in general the build may need to update the 
garchive? Would there be any easy way to allow the build to use an 
http-served garchive as a read-only cache of sources, just for cases like this?

One more question: in the recent STABLE and HEAD gar, is there a safe 
procedure when a build blows up on a package, or when a package maintainer 
wants to test a new package, to incrementally build without first doing a 
"make super-clean"? I would assume that if ALL dependencies were encoded in 
gar, that doing a "make clean" in the package's directory, followed by a 
"make build" in lnx-bbc would suffice, but I was warned a long time ago 
that the build system wasn't really intended to safely build this way. Has 
the situation changed at all? Do package maintainers build a full bbc from 
scratch every time they want to test their portion of the build? I'm sure 
that's ok for you who can build in an hour, but my system takes WAY longer 
than that :-(.

Looks like you are making great progress with the cross-compiled gar build. 
Thanks!

Bill