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?