On Thursday, October 04, 2012 12:11:45 PM Florian La Roche wrote: > > And while it might seem like I could sidestep up to 5.8, I want to iterate through the whole process, using the full tree, for my own reasons. > > > Hello Lamar Owen, Hello, Florian.... > > I think there is value in a self-hosted (can fully recompile itself) build of CentOS. Definitely. However, at certain revs there are definite buildorder issues. I'm goiing to document a few in this e-mail that I've found in building 5.6 on ia64. > Some rpms failing a recompile (not all will be relevant to IA64) are: > gpm, geronimo-specs, rhythmbox, evolution-connector, gstreamer-plugins-base, > gaim, totem A quick note about totem. Totem needs gecko-devel-unstable. Good luck finding that as a package. Oh, wait, that's part of xulrunner..... but, until you build xulrunner that Provides: won't get populated, and so xulrunner needs to come before totem.... typically, a second run-through (and sometimes a third) is required to pick things like that up. Packages like luci and ricci don't even exist as separate src.rpm's; they're built from the conga src.rpm, but there is no conga binary rpm.... anyway, that's borderline ranting.... :-) A bigger problem in going from 5.5 to 5.6 is the exact build time for a package relative to the rebased gettext 0.17 that was introduced in 5.6. See https://bugzilla.redhat.com/show_bug.cgi?id=523713 for info. The short form: if a package is failing due to MKINSTALLDIRS being undefined, then you need to build it with the older gettext (there is a better solution, but a rebuilder isn't supposed to modify the spec file to properly fix the bug, and CentOS is supposed to be bug-compatible (which is nice when you're tracking down build failures, as long as those failures and solutions are documented in the bugzilla)). Packages impacted by the gettext rebase includes pam (which hasn't seen an update in quite a while, so the current pam distributed in 5.8 might not rebuild from source on an unmodified 5.8 system; I haven't tried it, but it's pretty likely to be true). The latest pam SRPM in the upstream public ftp is the one from 5.6. And it won't rebuild from source with the gettext in 5.6. You need the older gettext to build it. But an automatic resolver will not see that; it will only see the dependency on 'gettext' for pam, and will rebuild gettext first, which will then break the pam build in a fantastically arcane way: +++++ rm -f ja.gmo && /usr/bin/msgfmt -c --statistics -o ja.gmo ja.po ja.po:7: nplurals = 1... ja.po:208: ...but some messages have 2 plural forms /usr/bin/msgfmt: found 1 fatal error 104 translated messages. make: *** [ja.gmo] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.58821 (%build) +++++ (you will find one public bugzilla that mentions this, but the solution is in a duplicate bug report that is 'private' and off-limits.... at least the bug cause is hinted at enough, and a link to the gettext rebase is provided so that a simple downrev of gettext in the repos that feed the build roots, then rebuild pam (and other packages with the same problem), then put the new gettest back in since some packages won't build with the older gettext and require the newer one.....) (I can hear Johnny saying 'told you all over a year ago this thing couldn't be easily automated, and requires manual legwork.....'). (I'll do the :-< for him so he doesn't have to..... :-) ). Again, the proper solution, which is editing the spec file to re-gettextize all the po stuff, isn't something a straight rebuilder can do, as the result is not 'bug compatible' at that point. Only upstream can truly fix the bug. And some of my 5.5 (and other 5.6) source rpm build failures are likely to be similar, at which point, if the package hasn't been updated since 5.4 (several meet that criterion) then I'll just use the SLC 5.4 package for now. It may require downrevving to 5.3, 5.2, or even 5.1 to get some to rebuild to get 'CentOS' binaries rather than 'SLC' binaries, but for my purposes I don't really care, as long as they're 'free' binaries..... This stuff requires detective work, and good bugzilla, google, and mailing list archive searching. And a healthy dose of patience and broad knowledge of package building and how things fail. A separate 5.6 updates rebuild status report later in the morning, once I get a few more of the 11 failing packages (that are relevant to ia64) to rebuild. The rest of the 5.6 update built fine, just took a while.