Re: Re: status of Knoppix as build platform

Just now Bill Immerman made 15 LEDs in my apartment flash with this:
> 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 
> [error messages from gcc]

I've submitted this as a bug against the python package.  It looks
like maybe some header files are not present in Knoppix or perhaps the
configure script for python is not finding everything it needs.  At
any rate, let's move discussion of this particular bug to the bug
tracking system.

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

Sorry, you're right, kernel/linux-image is built as a dependency of
meta/bbc-contents before python.  I think this is because we need
System.map for something.  The kernel that's actually used on the ISO
is built later, as a dependency of meta/lnx.img.

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

Yes, that should work just fine.  It's when you use make to update
things across an NFS mount that you can run into trouble.

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

Well, the default GARCHIVEROOT is /var/www/garchive.  If you build
your garchive in that directory, and you're running apache with
DocumentRoot set to /var/www (the default for Debian's apache
package), then your garchive is on the web.  If it's a server on a
local network, then just add http://<your-server's-name>/garchive/ to
the end of FILE_SITES in gar.conf.mk so that it is preferred over
sites that are out on the Internet.  If your DocumentRoot is
different, adjust GARCHIVEROOT to suit.

> 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"?

If you're building a package and it fails before it installs anything,
then you can safely clean, modify, and rebuild the failed package over
and over and over until it works.  You just need to make sure you're
building it for the correct DESTIMG.  The LNX-BBC is made up of four
DESTIMGs, and at build time there is a fifth which is not included on
the disc.  The main one on the LNX-BBC is "singularity", so if you
just want some piece of software to be included in your LNX-BBC,
you'll need to run "make DESTIMG=singularity install" rather than just
"make install".  The other three on-disc DESTIMGs are related to
bootstrapping, and the one at runtime is for BUILDDEPs.

If you're running "make DESTIMG=singularity install" in packages in
order to have them included on a custom LNX-BBC ISO, note that it's
best to do this before you start the normal ISO build.

If you don't, then what happens is the singularity filesystem image
will not contain your package and at the very least you'll have to
rebuild meta/singularity to produce an updated singularity filesystem
image.  Chances are if you have to rebuild meta/singularity, you'll
have to rebuild meta/lnx-bbc and either meta/i386-livecd or
meta/ppc-livecd, because the filesystem image that these packages
produce (the actual ISO image) contains the singularity filesystem
image and will need to be rebuilt to contain the updated one.  The
easiest way to do all this updating is to run "make clean" in the meta
category and then "make build" in meta/lnx-bbc, but really you should
just avoid the trouble by building your customizations first and then
building in meta/lnx-bbc.

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

If it's just one package, then yes, you can do that.  But if you have
a package that is failing because one of its dependencies is messed
up, there's no general way around having to make super-clean other
than manually reverting the DESTDIR to it's pre-installation state
(i.e. removing files that the broken dependency installed).

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

It depends on what the "portion" is.  If the "portion" is just one
package and it's failing before it installs anything, then there's
generally no need to make super-clean.  If the "portion" is a large
set of interdependent pacakges, then it's make super-clean every time.
However, in that case, I'd recommend building just that part while
you're working on it, and not a whole ISO.

-Nate

-- 
--< ((\))< >----< [email protected] >----< http://www.movealong.org/ >--
pub  1024D/05A058E0 2002-03-07 Nate Riffe (06-Mar-2002) <[email protected]>
     Key fingerprint = 0DAC F5CB D182 3165 D757  C466 CD42 12A8 05A0 58E0