After too much fighting, I just took us back to square 1. In future, we need to put these changes in 1 at a time, get people testing them on each platform (and distro), and confirm things are working before moving on. Throwing lots of code in there which breaks all over the place (or has hardcoded i486 architecture for ALL ARCHES) really doesn't do any good.
-Sean
On Thu, May 12, 2005 at 10:38:38AM -0400, Sean Dague wrote:
> Also, please ensure this boots on i386 in the next day. I don't think you
> fully understand the ramifications of pulling out mklibs, and while it will
> compile, nothing will actually run in the boel-binaries tarball.
>
> If it boots, I stand corrected, if it doesn't, I think reverting would be a
> good thing.
>
> -Sean
>
> On Thu, May 12, 2005 at 09:52:46AM -0400, Sean Dague wrote:
> > ppc64 is horribly broken after these changes. zlib won't even build (which
> > is the first package).
> >
> > While this cleans up certain parts of the build on x86, it pretty much
> > guarantees a lot of rework to make any other arch work. Unless you are
> > signing up for that, I would suggest reverting all the changes, and lets go
> > at this one at a time.
> >
> > -Sean
> >
> > On Thu, May 12, 2005 at 02:24:08AM -0600, Jerry DeLapp wrote:
> > > 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
> > >
> >
> > --
> > __________________________________________________________________
> >
> > Sean Dague Mid-Hudson Valley
> > sean at dague dot net Linux Users Group
> > http://dague.net http://mhvlug.org
> >
> > There is no silver bullet. Plus, werewolves make better neighbors
> > than zombies, and they tend to keep the vampire population down.
> > __________________________________________________________________
>
>
>
> --
> __________________________________________________________________
>
> Sean Dague Mid-Hudson Valley
> sean at dague dot net Linux Users Group
> http://dague.net http://mhvlug.org
>
> There is no silver bullet. Plus, werewolves make better neighbors
> than zombies, and they tend to keep the vampire population down.
> __________________________________________________________________
--
__________________________________________________________________
Sean Dague Mid-Hudson Valley
sean at dague dot net Linux Users Group
http://dague.net http://mhvlug.org
There is no silver bullet. Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________
pgpZ1WMmzWEeo.pgp
Description: PGP signature
