Topic: MP7 issues

The new build system is a tremendous improvement over the last time
i tried it! Very nice work!

But I do have a few comments, sorry for the long post...

Some of the files in the ttylinux-src-mp7NS.tar.bz2 package are read/write,
some are read-only. Is there a reason for this, or just an oversight?

The ttylinux-src-mp7/pkg-cfg/thttpd-2.25b/patch directory also has
some "unusual" permissions:

% ls -lh pkg-cfg/thttpd-2.25b/patch 
ls: cannot access pkg-cfg/thttpd-2.25b/patch/htpasswd.patch: Permission denied
total 0
-????????? ? ? ? ?                ? htpasswd.patch


After doing  "make i686-2.12.1-gnu" in xbuildtool-0.1 there is a new directory
"cross-tools-2.12.1-2.6.34.6" and a subdirectory "_pkg-src" that still contains
a copy of the kernel tarball. Does this tarball need to stay, or can it be
deleted?


The xbuildtool downloads and builds binutils-2.21, but the ttylinux ws-pc-i686
downloads and builds binutils-2.20 - why not use the same version for both?


The module-init-tools-3.12 build fails here, something about docbook2man not
parsing the sgml files correctly. Maybe some incompatibities with different
versions, or even a broken docbook installation. But it's hardly worth trying
to track down the problem, since the tarball comes with ready-made man pages
that aren't used anyway. Simple solution is to "touch" the existing man pages
in the build script:

cd "${PKG_NAME}-${PKG_VERSION}"
touch *.[58]

(Others had similar problems; google 'module-init-tools docbook2man fails')



It would be nice there was a "make pkgs RESUME=yes" that could pick up
where it left off in case of a problem (As long as a completed binary
package has a newer timestamp than its pkg-src or pkg-config files,
then it shouldn't need to be rebuilt.)

It's not immediately obvious where the lists of packages, etc. are stored.
Maybe it would help if there was a FILES file in the top directory,
explaining the basic layout?


Building GCC for ws-pc-i686 gives me an error:

tar: usr/lib/gcc/i686-generic-linux-gnu/4.4.4/include-fixed/ \
xulrunner-sdk-1.9/js/fdlibm.h: Cannot stat: No such file or directory

That file is not part of the gcc sources, and I don't even have it installed.
It looks like something that is bleeding over from the original host build
system. Does that mean the entire lengthy GCC build process has to be started
over from scratch, just because the final packaging failed?

Re: MP7 issues

Hi Jeff,

Thanks for the post. Certainly there is a lack of README-type files. I'll add something with some sort of directory usage overview. With the problems coming out, I'll probably make an updated source distribution release next weekend.



Some of the files in the ttylinux-src-mp7NS.tar.bz2 package are read/write,
some are read-only. Is there a reason for this, or just an oversight?

The ttylinux-src-mp7/pkg-cfg/thttpd-2.25b/patch directory also has
some "unusual" permissions:

I had most of the files read-only to make it harder to mistakenly whack something; when I changed to this new build structure I loosened a little and now most everything in pkg-cfg is not read-only.
The permissions on pkg-cfg/thttpd-2.25b/patch are wrong; they should be 700. I botched that directory somehow.



After doing  "make i686-2.12.1-gnu" in xbuildtool-0.1 there is a new directory
"cross-tools-2.12.1-2.6.34.6" and a subdirectory "_pkg-src" that still contains
a copy of the kernel tarball. Does this tarball need to stay, or can it be
deleted?

Yes, that directory needs to stay and have the Linux source code. This is how the xbuildtool's cross-tool chain exports its Linux kernel, so that the ttylinux build process can build the correct kernel.



The xbuildtool downloads and builds binutils-2.21, but the ttylinux ws-pc-i686
downloads and builds binutils-2.20 - why not use the same version for both?

I don't know. It's all a work-in-progress and maybe binutils in ws ttylinux can be updated to 2.21  xbuildtool needs to use binutils-2.20 for tool chains with glibc-2.9, and I may have been conservative when adding binutils to ttylinux.



The module-init-tools-3.12 build fails here, something about docbook2man not
parsing the sgml files correctly.

It's back! We had this problem and I think I fixed it but must have undone the fix. The problem also is in this forum somewhere. I'll refix, probably like you suggested.



It would be nice there was a "make pkgs RESUME=yes" that could pick up
where it left off in case of a problem

I've been frustrated by that too, but I never thought to do anything about it. I'll put this idea at the top of the list of things to do.



tar: usr/lib/gcc/i686-generic-linux-gnu/4.4.4/include-fixed/ \
xulrunner-sdk-1.9/js/fdlibm.h: Cannot stat: No such file or directory

That is original host system (mine) contamination. If it does build, the worst thing is that there are corrected header files that get no use. Edit these files: ttylinux-src-mp7/pkg-cfg/gcc-4.4.4/files-*  Delete the file pathnames near the start of the file that have "fixed" in the pathname, they are:

usr/lib/gcc/*-generic-linux-gnu/4.4.4/include-fixed/<something>

but leave these three (the README isn't important of course):

usr/lib/gcc/*-generic-linux-gnu/4.4.4/include-fixed/README
usr/lib/gcc/*-generic-linux-gnu/4.4.4/include-fixed/limits.h
usr/lib/gcc/*-generic-linux-gnu/4.4.4/include-fixed/linux/a.out.h

Re: MP7 issues

Success!

After the changes above I managed to build a working iso, with only a minimum of root access:

fakeroot make init pkgs kernel
su -c 'make fsys'
fakeroot make iso

Much easier than before!

P.S. I also left the
usr/lib/gcc/i686-generic-linux-gnu/4.4.4/include-fixed/syslimits.h
file intact for the gcc-4.4.4/files-i686 list since I had it installed and it looked like it might be important.

Last edited by Jeff (2011-02-21 23:16:07)