MMT yum repository.

The MMT yum repository

Here at the MMT Observatory we have found it useful to keep a number of packages in RPM format available in our own custom YUM repository. This fine tradition was begun by Tim Pickering. In 2009, after Tim fled the country, this collection was inherited by Tom Trebisky, who now does his best to maintain it.

Setting up (the mmt-repos package)

To start things out, you should fetch and install (probably via rpm, unless you somehow set up a mmt.repo file) the package http://mmto.org/fedora/mmt/13/RPMS/x86_64/mmt-repos-1.0-1.fc13_tjt.noarch.rpm. This package is unsigned, so you may need to fetch it via:

yum install --nogpgcheck mmt-repos

This package contains the mmt.repo file and a couple of GPG keys which it will try to install. If these keys are already in your RPM key database, you may get some harmless complaints like:

  Installing     : mmt-repos-1.0-2.fc13_tjt.noarch
  Non-fatal POSTIN scriptlet failure in rpm package mmt-repos-1.0-2.fc13_tjt.noarch
  error: /etc/pki/rpm-gpg/RPM-GPG-KEY-TEP: import failed.
  error: /etc/pki/rpm-gpg/RPM-GPG-KEY-tjt: import failed.
  warning: %post(mmt-repos-1.0-2.fc13_tjt.noarch) scriptlet failed, exit status 1

It requires some fairly intricate scripting to locate and delete or replace keys in the RPM database, so I haven't attempted to do this in order to avoid such errors, sensible though that might be. In other words, it is a pain and I am lazy.

The mmt_env package

This package is a big list of dependencies (contained within the RPM spec file) that serves to pull a selection of packages (lots of them) which we view as "standard features" on the machines we administer.

In addition to the spec file, this package contains three files that we use to "tailor the user environment", namely:

MMT.menu
mmt.csh
mmt.sh

Rebuilding this package is straightforward. There is no tarball, and the usual change that requires rebuilding is to add a new package dependency to the spec file. If other files are changed, they should be replaced in rpmbuild/SOURCES/mmt_env-1.0, the spec file edited and then the command:

rpmbuild -ba --sign mmt_env.spec
-- give it my (PEN) passphrase

After this, it is a matter of copying the results into the repo directory, creating links and issuing createrepo . commands in the affected repository directories.

I have used a ruby script mklinks_env.rb in the repo/RPMS directory which even does the remote copy from my build machine.

Mindterm

Mindterm is an ssh client implemented as a java applet. With this stashed on your website, you can have ssh access to your desktop from any machine with a browser and a healthy java runtime. It drops mindterm.jar into /var/www/html/ssh, so you should expect that and link to it accordingly. Tested and working as version 2.4.1 with Fedora 13 on 7/14/2010.

Iraf

This is version 2.14.1 of the astronomical image reduction and analysis software from NOAO. As of 7/13/2010 this works with Fedora 13. It consists of a set of 29 packages (best installed as a lump via yum install iraf\* along with the package x11iraf which should also be installed.

Rebuilding iraf-ccdacq

Typically what happens is that Skip makes changes on Alewife (a 32 bit machine) to files in /iraf/ccdacq, then asks me to rebuild the rpm and put it in our repository. Here is what to do:

ssh alewife
cd /iraf
tar czvf /home/tom/ccdacq.tar.gz
ssh cholla
cd rpmbuild/SOURCES/iraf-ccdacq-3.0
-- backup the existing ccdacq.tar.gz (maybe)
scp alewife:ccdacq.tar.gz .
-- edit ccdacq.spec (bump the Release number)
rpmbuild -ba --sign ccdacq.spec
-- give it my (PEN) passphrase

After this, a new srpm and rpm are in SRPMS and RPMS respectively. They get whatever ending (.fc12_tjt) is specified in the file .rpmmacros. The thing now is to move them to the repository. Note that this rpm is not really architecture specific (it gets built as x86_64 because the spec file grabs that from the machine (cholla) on which they are built, but it does not matter, and in fact all the files for fc10, fc11, fc12, and for i386 and for x86_64 are links to the same file.

First I copy the source rpm, make links for it, and rebuild the repo data, like this:

ssh mmt
cd /home/fedora/mmt/FC12/SRPMS
scp cholla:/home/tom/rpmbuild/SRPMS/iraf-ccdacq-3.0-7.fc12_tjt.src.rpm .
createrepo .
./mklinks_ccd.rb

The ruby script goes to ../../FC11/SRPMS and makes a symbolic link and runs the createrepo command there (same is done also for FC10).

Next I copy the "binary" rpm, make links, and rebuild the repo data. Again, I use a ruby script to avoid all the repetitious typing, and there are now 5 links to make rather than two.

flash-plugin

This is the now deprecated flash plugin for 64 bit firefox. I am told that it contains security holes that are actively being exploited, so there is nothing good about that. Firefox will complain and warn you if you install it (as of Fedora 13). Adobe is working on a new 64 bit plugin, but as of July, 2010 nothing is available. The recommendation is to install a 32 bit flash plugin within your 64 bit firefox, which can be done with some fuss. Another option is to simply run a 32 bit firefox and plugin on a 64 bit system, which may annoy the purist, but works just fine.

perl, PDL, pgplot

Not really related, but we use them together.

tcl pgplot

Tcl always finds new ways to stir up trouble, so be on your toes.

python-pyraf

In November of 2010, with the advent of fedora 14, this would no longer install, and I had an opportunity to look into the details. It may make a nice case study of the rpm building process.

xephem

We used to maintain this, but Craig Kulesa (just down the hall) now offers an RPM that he is packaging (and he has 3.7.3 all packaged up). So, being lazy, I just copy his packages (one for the i386 and a source RPM).

His package is unsigned, which is fine by me, but does require that the --nogpgcheck option be used with yum to install this particular package out of our repository, which is at best a variance with how we have our repository set up.

In the process of rebuilding his source RPM for a x86_64 target, I learned that this requires the openmotif libraries. Craig used to static link against openmotif, thus avoiding a dependency, but as of Fedora 13 there are no static openmotif libraries available, so I found a dynamic link to be necessary.

Openmotif is available from the rpmfusion-nonfree repository, and I installed it all via: yum install openmotif\*. Certainly openmotif-devel is needed for the rebuild.

This package places the include files for openmotif in /usr/include/openmotif and the libraries in /usr/lib64/openmotif (for a 64 bit system). The 32 bit libraries would be in /usr/lib/openmotif.

Note that lesstif might be an alternative to openmotif and places its libraries at /usr/lib/libXm.so.2 -- apparently lesstif and openmotif can both peacefully coexist?

`DT3155 driver`

We currently build this for our 32 bit systems only, but there may or may not be a good reason for that. Have any comments? Questions? Drop me a line! Adventures in Computing / [email protected]