FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS Development

 
 
LinkBack Thread Tools
 
Old 10-06-2012, 12:35 PM
Lamar Owen
 
Default Interested in IA64 build.

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.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-06-2012, 01:11 PM
Lamar Owen
 
Default Interested in IA64 build.

On Saturday, October 06, 2012 08:35:36 AM Lamar Owen wrote:
...
> 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...

> 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.

Three more down.... e2fsprogs, util-linux, and w3m all needed the older gettext. I'll leave it as an exercise for the reader to research if the current versions in 5.8 will build with the gettext in 5.8.... :-)

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-06-2012, 01:51 PM
Lamar Owen
 
Default Interested in IA64 build.

On Saturday, October 06, 2012 09:11:16 AM Lamar Owen wrote:
> Three more down.... e2fsprogs, util-linux, and w3m all needed the older gettext. I'll leave it as an exercise for the reader to research if the current versions in 5.8 will build with the gettext in 5.8.... :-)

Also, a note. While I desire 'clean' building in mock alone, I am not married to that approach. I have found at least two packages that will not rebuild 'clean' in mock (as I have it set up; YMMV of course, and if I can figure out how to inject the things that will have to be injected for things to build 'clean') but build without issue on my test box that is currently running my rebuild CentOS 5.5.

These two are metacity and kudzu (both from 5.6). Since I'm not as interested in fully reproducing the build chain used either by upstream or by the CentOS developers in going from 5.5 to 5.6 as I am in just simply getting up to a reasonably, mostly-compatible, fully-updated 5.8, I am going to 'cheat' a bit and use those packages until I get up to 5.8. But I highly suspect at this point that 5.8 isn't going to be fully self hosting using mock. At least not unmodified 1.0.28 mock. The CentOS-Extras 0.6.13 mock with the right hints (as documented in the changelog and the patch) thrown at it may do that just fine, and so I plan at this point to try the self-hosting build on 5.8 using the older CentOS-Extras mock. But I need to get to a workable 5.8 first.

And, well, honestly I'm ok with that for my purposes. If I were building for distribution I would care about that, and I have the logs and the dowrev trees so that I can come back to it later to attempt to build with mock. But I am on a time budget for this project (well, I'm on two budgets; my time, and the electricity for the build host, which costs roughly 25 cents (US) per hour to operate) and so I need to be efficient, time-wise. And running rpmbuild as a normal user with a fully-loaded dev environment on a much smaller (and much less expensive to operate) box works for me for now. I'd like to be a purist; I don't have the luxury to be a purist. :-)

Incidentally, here's a yum trick for you that I've used a few times this morning on my test box. If you have a set of repos full of more-recently-compiled RPMS (but with the same NEVRA as what is installed) a yum update will not pull them in; to pull them in use:

yum reinstall *

(the * instead of plain * is used so that the shell won't do the globbing, but yum will).

That applies for CentOS 5; CentOS 6 has a yum that includes the 'distrosync' command, but I'm not sure it will pull in all of the new binaries like reinstall will.

You'll have to do special handling for packages that are allowed to be multiply-installed, like the kernel.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-06-2012, 06:30 PM
Lamar Owen
 
Default Interested in IA64 build.

On Saturday, October 06, 2012 09:51:37 AM Lamar Owen wrote:
> On Saturday, October 06, 2012 09:11:16 AM Lamar Owen wrote:
> > Three more down.... e2fsprogs, util-linux, and w3m all needed the older gettext. I'll leave it as an exercise for the reader to research if the current versions in 5.8 will build with the gettext in 5.8.... :-)

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).

The first four packages are building now; avahi from 5.5 didn't want to upgrade cleanly (a %postun failure) and that caused every build to fail after avahi ( since the failure occurred during the chroot yum update, about halfway through the build) built. And buildsys-macros is new for 5.7; so to be safe I'm building it separately. And those four packages built successfully, so now on the the other 204, and leave it running until Monday.....

Anyway, the build failures I've found, and that I've been working through (and I've googled and searched bugzilla.r.c, but not bugzilla.c.o, for these):

Failed on 5.5:

aspell-es, aspell-no, aspell-pt: upstream bug reports have been filed, but not fixed, quite a while back. I'm going to use the SLC5.4 versions for now.

convmv (fails tests in mock chroot with a 'smartness test failed' error; builds fine with rpmbuild as normal user, will research later)

cyrus-imapd (note: will come back to this one later, since it requires i386 packages)

gnbd-kmod (requires an older kernel-devel version than 5.5's, will need to rebuild the supporting kernel to have its -devel available in the buildroot)

jsch (segfaults compiler; researching. Won't build with rpmbuild or mock, using the 5.5 gcj.)

libsvstreams (won't build in mock or in rpmbuild; throws error in wvvector.h)

lsof (causes an arcane, insane, and lying error:
error: Package already exists: %package debuginfo

For which you can find Russ's solution at:
http://www.oldrpm.org/hintskinks/debuginfo/

(hint: the very last comment in the Changelog of lsof is the culprit)
This one posed a quandary; the fix is to edit the Changelog in the spec, changing the bogus '%install' to '%_install' instead, and I'm still researching how to fix this the 'proper rebuilder' way. )
)

metacity (there is a syntax error of some kind some where; the buildrequires listed by rpm -qip --requires on the src.rpm is funky, but it does rebuild with rpmbuild, just not with mock; using the rpmbuild handbuilt package for now)

notification-daemon (dbus-binding-tool throws an error in both mock and rpmbuild; using SLC 5.4 version for now while I investigate)

perl-XML-Parser/perl-XML-Simple (documented bugreport already on bugzilla.r.c about these two; has to do with perl-XML-SAX and a Parser order; in any case, won't build in mock or rpmbuild and requires further research. Using the SLC 5.4 versions for now)

(yelp fails unless SLC 5.4 perl-XML-Parser is in place, then it builds)

python-docs ( find-debuginfo.sh throws the error:
find: /var/tmp/python-docs-2.4.3-root: No such file or directory
when building in mock and in rpmbuild; researching how to fix this one too, but low priority)

Failures in 5.6 (updated from 5.5 packages only):

perl-XLM-Parser, perl-XML-Simple, and yelp, for the same reasons as 5.5.

metacity and kudzu needed handbuilding on a C5.5 host.

anaconda built once kudzu was built.

e2fsprogs, util-linux, w3m, and pam built under older gettext.

esc (has multiple failures, even when injecting nss-devel into the buildroot by hand. Builds fine with rpmbuild as a normal user; placed in my handbuilds repo for now).

And 5.7 is churning now, along with a normal-user rpmbuild of the 92 kernel for gnbd.....as my buildstatus script reports:

[lowen@winterstar ~]$ buildstatus57
No IA64 target: 1
No Package Found: 0
Scratch total: 2
Built binaries: 159
Built SRPMS: 54
[lowen@winterstar ~]$

(it'll slow down when it hits glibc, gcc, sblim, kernel, xulrunner, and a few other largish packages.....and I may have to recreate the chroot cache every so often; it's almost a big enough inconvenience that I'm tempted to disable the root cache altogether)

And I've successfully updated my test host (the 2 CPU Altix) to 5.6 (once I populated the local repositories properly.....):
CentOS release 5.6 (Final)
Kernel 2.6.18-238.el5 on an ia64
...

I've not upgraded the main buildhost from SLC 5.4 yet; until I find a failure that is due to the buildhost being that far downrev from the build chroot I'm going to leave it in a 'building' condition, since it is successfully building, and a botched upgrade would be painful right now.... :-)

But I want to reiterate, and I can't emphasize this enough, that what I am doing is nowhere near as difficult as what the CentOS build team did when doing this for i386 and x86_64, since I'm not yet doing thorough QA nor am I yet targeting strict binary compatibility; I can see doing that could easily make the builds take two to ten times longer.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-08-2012, 01:28 PM
Lamar Owen
 
Default Interested in IA64 build.

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.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-08-2012, 03:35 PM
Lamar Owen
 
Default Interested in IA64 build.

On Monday, October 08, 2012 09:28:29 AM Lamar Owen wrote:
> 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.

And NetworkManager and kudzu handbuild fine. Kudzu does not; I need to rebuild pciutils to not include zlib-devel, and am doing that now....

Since 5.8 includes new pciutils, doing that one instead of the downrev, and rebuilding kudzu as part of 5.8 instead of going downrev. That may come back to bite me later, but, doing it anyway. :-)
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-08-2012, 04:44 PM
Lamar Owen
 
Default Interested in IA64 build.

On Monday, October 08, 2012 11:35:06 AM Lamar Owen wrote:
> On Monday, October 08, 2012 09:28:29 AM Lamar Owen wrote:
> > 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.
>
> And NetworkManager and kudzu handbuild fine. Kudzu does not; I need to rebuild pciutils to not include zlib-devel, and am doing that now....

And so, my test box (an SGI Altix 3200, 2CPU) is now at:

CentOS release 5.7 (Final)
Kernel 2.6.18-274.el5 on an ia64

....

I'm getting closer.... the 5.8 build is at:

[lowen@winterstar ~]$ buildstatus58
No IA64 target: 0
No Package Found: 0
Scratch total: 1
Built binaries: 160
Built SRPMS: 29
[lowen@winterstar ~]$


Out of:

[lowen@winterstar ~]$ wc -l ~/c58-to-build.txt
246 /home/lowen/c58-to-build.txt
[lowen@winterstar ~]$

246 source packages.

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-08-2012, 09:21 PM
Lamar Owen
 
Default Interested in IA64 build.

On Thursday, October 04, 2012 12:10:16 PM Karanbir Singh wrote:
> On 10/04/2012 04:57 PM, R P Herrold wrote:
> > If you need 'blank' artwork template files to amend the
> > branding, please let me know out of band

> why would we not use the centos artwork here ?

If I'm not able to get binary compatibility, I don't want users thinking
they're running CentOS, with the full binary compatibility that implies.
Rebranding in this case wouldn't be so that it would be 'my' build, but
rebranding would be so that my users won't get the wrong impression of CentOS
when they find binary incompatibilities.

And when I say 'users' I'm talking about my own internal users; if we can get
binary compatibility then I'm fine with this becoming the base for 'real'
CentOS ia64 and being distributed as such, should that be desired and enough
interest, for the bandwidth it will require, is expressed.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-10-2012, 02:46 AM
Lamar Owen
 
Default Interested in IA64 build.

On Oct 8, 2012, at 9:28 AM, Lamar Owen wrote:

> ...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.

And, well, after 34 hours, 9 minutes, and 53 seconds (with an average of 213% CPU usage; having multiple CPUs does help some), the 5.8 GA tree is built, with no build failures that weren't expected (final buildstatus run:

[lowen@winterstar ~]$ buildstatus58
No IA64 target: 5
No Package Found: 4
Scratch total: 9
Built binaries: 991
Built SRPMS: 237
[lowen@winterstar ~]$

and all the No Package Found errors are due to requirements that aren't available in IA64 form...) Cool, the first build run with no real build failures. Nice.

And so, my first goal is met: I have a yummable 5.8 tree (through steps; I have a reasonably full 5.5 tree, and the 5.6, 5.7, and 5.8 incrementals). The test upgrade on my Altix 3200 demonstrated yet again how my misstep with a 'dotless' %dist tag is going to continue to bite me, and how that I need to do a full rebuild at some point. (yum reinstall * doesn't help here, since the dist tag belongs to the release, and reinstall only replaces identical NEVRA with identical NEVRA, so the older disttag doesn't get replaced, and the older disttag is leftover from the interim bootstrap tree..... argh).

But, after correcting the one issue, I then did the standard two-step (yum upgrade kernel glibc rpm yum; yum upgrade) after editing the repo files (and renaming CentOS-Vault.repo to CentOS-Vault.repo.rpmsave, since there are no ia64 files in the Vault....), and some waiting ( 19:34.69, to be exact), and a reboot later, I have:

CentOS release 5.8 (Final)
Kernel 2.6.18-308.el5 on an ia64

...

The next step is step building the 5.8 updates, probably in %{BUILDTIME} order as the first attempt, and getting a fully updated system. given some of the substantial changes since 5.8 GA (like Firefox 10, for one) the updates will likely take some time, and I'm honestly not sure if I should just try to rebuild the latest (although that's essentially what I've done up until now, for each point release)). I haven't yet looked at the full contents of the 5.8/updates/SRPMS dir, since I've been 'blinders on get 5.8 GA built' for the last two and a half weeks (of spare time work; the buildbox has churned essentially 'round the clock building, but my time has been in relatively short spurts getting things ready to kick off). So that's a task for tomorrow.

Then I'll upgrade my SLC 5.4 buildhost, now that the bulk of the initial grunt work is done. And I'll make sure to backup all the repos, logs, and other items prior to the upgrade.....

A full rebuild, using the automated QA stuff for QA (neat logging to the #centos-devel IRC channel!), and binary compatibility checking is in my long-term plans; short term there are the straggler packages from 5.5 and 5.6, some third party packages, and some third party whole repos to work on for packages I need on these boxes, like xrdp, and some manual QA of packages as I use the boxes, since they are still in the 'commissioning' phase. And I have a 20 CPU box to do a scratch install on, once I fix its hardware issues, so actually getting an installable tree and making an installable ISO would be a nice thing, and another skillset to learn a little about.....

But the first major milestone is met, and that's cool.

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 

Thread Tools




All times are GMT. The time now is 06:30 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org