Building RPMs on SLES10SP2-ppc64

Well, it turns out that building stuff on ppc64 is a *real* pain in the ass, at least on anything SUSE related. I do have to tweak every damn spec to include this:

Otherwise, ld is gonna fail when linking, as it’s gonna try linking the generated 64bit code (-m64 is passed on via RPM_OPT_FLAGS to CFLAGS) as 32bit code, which ain’t gonna work at all …

On top of that, stuff ain’t building due to multiple problems (for example nagios and vim, cause ld is unable to find the fitting -lperl (for nagios) and -lXt (for vim)) as well as source errors …

Creating multi-distribution RPM/XML repositories

Well, as we do have quite a few custom built RPM’s, I was searching for a new solution to manage the repo(s). Currently I do have a single repository per distribution.

One thing one needs to know about createrepo (from createrepo), it doesn’t support this type of thing in the first place. So I had to come up with another way of doing it. First, I created a proper layout (much like the Debian Official Repository layout):

  • dists/
    • sle9/ (contains the repodata for SLES 9)
    • sle10/ (contains the repodata for SLES 10)
    • esx35/ (contains the repodata for VMware ESX 3.5)
  • i586/
  • noarch/
  • ppc64/
  • src/
  • x86_64/

As you can see, this is gonna get tricky in regards to managing the RPMS in a single place, while keeping the distributions apart.

So I went ahead, rewrote the script that perviously managed our two repositories for SLES 9/10. The limitation I pointed out above (keeping the RPMS in a single place), is easily overcome by using bind-mounts (sure it looks messy).

Now the only problem I’m still facing is that createrepo isn’t even looking at the excludes when it’s called by the script. But if I pass the raw command line the script is calling on a simple shell, it works like a charm .. So I don’t have the slightest clue right now, why in gods name it ain’t working … 🙁

SLES-9 (once again)

OK, so today was the highlight of the week … We updated apache2 on Tuesday (yeah, that’s still 2.0.49, so if you have some exploits – try them 😛 ) and now out of the sudden we have major performance issues. We looked nearly the whole forenoon for a reason, *why* the frackin’ apache was using 236% of the CPU’s.

In the afternoon, when my co-worker decided to go home (that was ~1500), I decided to revert back to the old patch level. But that isn’t as easy as you think (at least on SLES). The only thing I wanted to do, was something like this:

Looks like SuSE (or Novell who bought SuSE sometime 3 or 4 years ago) doesn’t consider reverting to an older patch level. Which means I would have to remove apache2, apache2-prefork, apache2-mod_php4; fetch the basic RPMS from our FTP server (which sadly forbids directory listing, so I can’t exactly look for the original RPMS) and I tried to blindly to fetch them.

Foooked. Didn’t work .. now I cron’ed the POS to restart every half an hour, so at least we have *some* solution. Will see about reverting the the last patch tomorrow again, hopefully I’ll find the original RPMS.

AIX 5.3 Linux Toolkit

OK, so I skipped rebuilding a newer RPM version (for now) and I’m currently rebuilding anything that fit’s into app-dev according to IBM …

The list reads like this:

OK, I’m not exactly rebuilding these old versions, I’m actually using their old specs to compile newer versions of these. I’m currently at coreutils-6.7, which really takes ages. But will see about the rest.

Oh, and btw .. if anyone happens to search for a way to extend a logical volume on AIX, use chfs.

That’s what I used to enlarge the logical volume containing /opt about 4 (what kind of unit is that ?).

AIX-5.3 & rpm-4.4.7

OK, so I tried to install the AIX Toolkit today, to build some newer rpm’s (yaaaaah, I *hate* RPMS myself, still it’s way better than distributing plain tar.gz archives) but looks like either AIX or rpm-4.4.7 doesn’t like me.

Now I’ve to figure out how to get libm (that’s /lib/libm.so) installed on AIX. Will see about that later and/or tomorrow.

SLES-9.2 (continued)

OK, so after yesterdays battle with SLES and rpm, I decided to simply upgrade rpm (again rpmbuild -bb rpm.spec as in from source).

I had to tune (hah, remove stuff that isn’t working on this ancient gcc-3.3.3 ie. -fstack-protector) a bit to get it working, wasted 20 minutes worth of CPU time and ~30 of my time. I finally gave up. I couldn’t persuade neither rpm, nor git to compile on the damn SLES/Dell.

While the above was running, I did some compile-testing on Tim’s behalf (he back ported the e1000-driver updates from 2.6.18 to our 2.6.17 branch), seems to work so far.

On a more personal note, I’d like to stab all people neglecting their promises!

SLES-9.2

Hrm, today I tried to install some extra programs I need for devel-stuff (quilt, git, subversion) on an ancient (not sooo ancient) SuSE Linux Enterprise Server 9.2.

Did I already mention I hate rpm-based distros ? Ah and I missed to tell you, that I really love USE-flags …

Ok, so it took me half the afternoon, to rebuild half of all installed packages (heh, kde* depends upon expat*; but who need X or even KDE on a server-machine?) and figured that everything was for nothing.

I found no RPM/SRPM providing te_ams, so I couldn’t install xmlto, which in fact resulted that I couldn’t install git. Also took a look at the git.spec file, where something like –without=docs is mentioned.

Either its this ancient rpm-version, or that generally doesn’t work. So I’m fscked, not git on that machine and short-handed just ssh -e rsync’ed my local linux-git to that machine. It’s a bit inconvenient, but works.

I’ll look into that tomorrow, maybe I even manage to get the damn git working on that machine (or even dump SLES9 in favour of SLES10 / Gentoo!).