On Saturday, October 06, 2012 02:30:49 PM Lamar Owen wrote: > Ok, and for the status record: > > I'm working through the 5.5 and 5.6 build failures, but have started the 5.7 package build in the background, using the same two-step I documented in a previous message (that is, disable the [smock] automatic repo, build centos-release and centos-release-notes, and, avahi and buildsys-macros this time, then re-enable the [smock] repo and build the rest). And the 5.7 new/changed packages that are relevant to ia64 are built, sans three: kudzu, NetworkManager, and mod_nss. I'm going to look into those three failures, but in the meantime I'll put the builder to work getting the 5.8 changed/new packages built. Again, my first order of business is to get up to a 5.8, even if that 5.8 is not fully upstream binary compatible. Then I'll look at what it's going to take to attain full binary compatibility at the 5.8 level. And I have a good idea, now, of what it's going to take, and that will mean a very large, very long, mass rebuild with staged buildroots, going all the way up from Karanbir's c5-wip tree as the base, and building the entire set of source packages in the correct order. But I also have an idea of how to obtain the buildorder, and in theory, it shouldn't be too tricky (in practice, it's probably not going to be that easy, either). But I'll need the upstream source RPM archive in full in order to do it this way, and I'll need to write some scripts to use the upstream source rpm archive to derive a set of buildorders (since there will be more than one possibility due to exact upstream buildorder uncertainty). And then it will be a very long build; at least a couple of weeks or more of the build machine doing nothing but churning packages. I was expecting about a month of work, but my guesstimate is that it will take longer than that to get to 100% compatibility. My hat is off to the CentOS build team for getting the releases out as quickly as they did; yeah, I say quickly, even in the case of 5.6, which everyone complained about. The 5.5 to 5.6 build, taken as a chunk, is not an easy build, and I'm just about positive that my results are not 100% upstream binary compatible (and I don't have any way of checking at the 5.6 level). The 5.4 to 5.5 upgrade also wasn't an easy one; these things take a lot of work, and a lot of waiting on serialized builds. Yes, serialized; you probably could do parallel chain builds of some things, but you may miss compatibility when you do. And to reverse-engineer the buildorder required to attain 100% compatibility is a pain. And the buildorder, by the time you reach 5.5, has almost nothing to do with buildrequires; in fact, the buildrequires chain being followed directly will cause build failures going from 5.5 to 5.6....but you need buildrequires to properly build some packages, anyway! The order and lag of a package going in to the active upstream buildroots relative to its buildorder (I'm just about positive at this point that the lag for a package getting into the active upstream buildroots is variable and depends on upstream's QA time) is also one of those things that will make you pull out your remaining hair. Anyway, for my own purposes strict 100% binary compatibility may not matter; at that point I'll need to call what I've built something other than 'CentOS,' really, and go through the trademark sanitizing process so that someone using our boxes won't think they're using 'real' CentOS. It will depend on how important binary compatibility is to me, and on the results of a test of binary compatibility at the 5.8 level.