The numerous commits to cvs HEAD tonight represent the current state of my efforts to get 3.5.x to build on debian stable (3.0r3).
I deliberately avoid apt-getting packages unless I'm absolutely convinced that it's the only solution to building si. Sometimes, though, I'll apt-get a package if I don't know w.t.f. I'm doing ;-). With the patches I applied to HEAD tonight, a user can get a kernel and initrd boot image for 2.6.10 on 32-bit debian stable x86 *without* having to do any upgrades to the system (e.g. module-init-utils, *-devel). Here are what I know or think are bugs (that I would welcome help with) related to these changes to HEAD: 1) You have to make more than once because the first pass through the kernel build mistakenly thinks it needs to use 'modprobe.old' to process the module list. I'm sure that something is reading information from the build host instead of our source tree, but, I just haven't had the time to figure out how to convince the si linux kernel build to use a module list and modprobe that aren't part of the build host distro. 2) There are places where source code tarballs get rebuilt (e.g. openssh) when it's not necessary, and there may be cases where source packages fail to get rebuilt when they should. (see my earlier posting in response to dannf's changes to lvm.rul related to 'include make.d/*.rul') 3) I revised the main Makefile in what I consider a fairly lame attempt to deal with (2). 4) The addition of the variable BOEL_MKLIBS_LOCATIONS to the main Makefile for si does not fall under the description above in (3). I'd welcome a better way to do it, but at the very least, anyone who is adding a source build to the si tree should pay attention to the dependencies that other source trees might have and to what mklibs does when building the boel_binaries tarball. In particular, it seems like more and more file systems leverage off of the libuuid implementation in e2fsprogs rather than implementing their own version of uuid. Ditto that for -lz. 5) I tried to find all the inconsistencies between our source builds and what mklibs imports, but I might have missed something. 6) I think this should "build right" on a 64 bit architecture, but I haven't tested it. Sorry Sean! Sorry Dann! I did get rid of the need to import /usr/kerberos/lib ;-). 7) Some of the source versions should be upgraded. 8) Only a masochist would use a p2/400 with only 128mb and debian stable to do test builds. Jeez, that's me! 9) I haven't tested beyond 'make'... In particular, I have no idea what 'make install' will do, or what any of the si_* commands will do. See (8). 10) I haven't updated the spec file (yet). 11) You have to 'touch config.inc' to get make to work at all. I'm looking forward to 'config' becoming the default make rule, provided our configure script is "better" than the ones most of our source tarballs ;-). 12) The lvm and devmapper build should be decoupled. Right now they're both in one rule file, and they're the only sources coupled this way. See (4). 13) there's an sfdisk.rul file that should be burned down, if for no other reason than it triggers multiple builds of util-linux. 14) I only patched things that caused compilation or linkage aborts... there are still a bunch of "interesting" warning messages that might be significant. 15) All of these patches have to do with making the build more internally consistent, with the hope of increasing the number of platforms upon which si will build by decreasing external dependencies. In particular, these patches don't do squat about new 'real' bugs like the busybox vs tar bug posted today. ( I do think these patches should make "upgrade to latest release" a little bit easier, if that's the bug fix). ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Sisuite-devel mailing list Sisuite-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-devel
