SCIENTIFIC-LINUX-USERS Archives

September 2012

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Lamar Owen <[log in to unmask]>
Reply To:
Lamar Owen <[log in to unmask]>
Date:
Fri, 28 Sep 2012 01:26:12 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (13 lines)
On Monday, September 24, 2012 09:18:31 AM Lamar Owen wrote:
> And juding by the lack of response, I'm going to assume that there isn't any interest from the broader SL community, and while I will post about successful completion, I'll not bore everyone with progress reports.

Ok, I did get some responses, mostly 'attaboys' and 'sounds cool' things, and I appreciate the kind words.  It's been a while since I've seen the word 'kerfuffle' in print, and that was worth a good solid chuckle, and being reminded that a lot of the IA64 machines out there from HP are running OpenVMS (nothing wrong with that; I have a VAXstation 4000 sitting in my office I boot up into VMS 5.2 every once in a great while, and I purchase the OpenVMS hobbyist CD's for VAX and Alpha a while back, got the hobbyist license, etc).  Good stuff, all it all, just nobody really interested in trying a more up to date SL IA64 right now.

So, this will be pretty much my last post on this subject here, since for the sake of compatibility with other systems on campus I'm 'cross-grading' over to a centos source base.  The SL CERN 5.4 binary base served very well indeed for bootstrapping up to a CentOS 5.5 base, but I now have one of my Altix boxen successfully brought up to my own rebuild of CentOS 5.5.  There are several missing packages; well, 81 source packages were going to be rather difficult either to rebuild or to get to even run on ia64 (valgrind, for instance, isn't even buildable for ia64, grub makes no sense (elilo is where the booting action is), and even SLC 5.4 didn't ship openoffice.org or some other GUI packages, and so I decided that the 3,389 packages successfully built (had to update the config to pull in the partial 5.5 repo, plus the chkconfig and lvm2 packages from 5.4, to get the last successful packages to build, which included critical ones like chkconfig and lvm2!) should be enough to update the 5.4 systems I had running.

And, after doing the two-step and the cha-cha with the yum configs and release rpms (short form: yum update centos-release and centos-release-notes, which will replace sl-release; yum remove the yum config, then rpm -Uvh the yum and yum-fastest-mirror packages, do a yum clean all, point the base repo to the local mirror, and do a yum update yum rpm glibc, then yum update everything else), and waiting quite a while for 469 packages to update and 8 packages to install, and a reboot later and I'm running my own rebuilt equivalent to CentOS 5.5 on ia64.  I have neither tried nor do I plan to attempt any binary compatibility comparisons with upstream, unless I find a prebuilt package that for some reason won't install or run due to wierd binary issues.  I'm not likely to find that, since the software we'll be running on these boxes will mostly be built from source, or will be 32-bit software running under Intel's ia32el.  In the case of 32-bit software, it's a snap to point the compatibility layer at the CentOS i386/i686 libraries, and those are binary compatible with upstream (so things like EMC's HostAgent and ServerUtility, among others, will run fine).

While rebuilding with an SL base would likely have worked pretty much the same way, since all but a handful of my other machines are running CentOS of some version I decided I'd rather go that route.  If you're interested in following the progress of stepwise rebuilding up through 5.6, 5.7, and 5.8 on ia64, I'll be posting periodic updates to the centos-devel list.

It has already been very educational, and has shed a lot of light on what kind of process rebuilding upstream's source packages is really like for the SL and CentOS teams.  And it's really nothing like you imagine it to be.

ATOM RSS1 RSS2