Tag Archive
amateur astronomy awk bash b[e] supergiant cartoon conference convert evolved star exoplanet fedora figaro fits fun galaxy iraf large magellanic cloud latex linux lmc machine learning magellanic clouds massive star matplotlib meteor mypaper paper peblo photometry planet pro-am pyraf python red supergiant scisoft skinakas observatory small magellanic cloud smc spectroscopy starlink talk ubuntu university of crete video x-ray yellow hypergiant
Installing IRAF/PyRAF from the (Debian) repository directly
IRAF has become lately available through Debian‘s repositories. So I was curious to see how it works. But I was missing the right moment. About a month ago, I finally found the proper motivation so I went on to install it. As always … there were a few, minor, problems. Thanks to John K. we were able to resolve them! What follows is a small guide of what I faced during the installation (on a Debian 10/Buster).
Instead of previous (relatively) easy solutions to install IRAF now you can just do:
sudo apt-get install iraf
And the magic happens! It is typical to “mkiraf” then to build the necessary login.cl file. And that’s the very first problem as there is no such a thing (try mkiraf and you will get nothing).
Fortunately, mkiraf is not that necessary as the login.cl is just an ascii file with some default parameters set. We can easily copy such a file from another machine and we can put it here (under a proper directory, typically I create one under home, such as /home/user/iraf/). In all cases, what we need to change is the first few lines:
set home = "/home/user/iraf/"
set imdir = "home$images"
set cache = "home$cache"
set uparm = "home$uparm/"
set userid = "user"
where you replace the user with your username (or you put the appropriate path in the first line, and your username in the last one).
Another key feature is the shell used (typically xterm, xgterm, …). The original login.cl file will have already something (as the shell type is asked when IRAF is set with mkiraf), similar to:
# Set the terminal type. We assume the user has defined this correctly
# when issuing the MKIRAF and no longer key off the unix TERM to set a
# default.
if (access (".hushiraf") == no)
print "setting terminal type to 'xterm' ..."
stty xterm
Either you do not need to do anything (if you have xterm installed already) or you place the shell you are using.
Do not edit anything else from the rest of the file as these are the default IRAF parameters.
[NOTE: copy a fresh login.cl after running mkiraf, else you may end up with a version of a file with modified parameters set by the owner – although you should be always careful to ‘unlearn’ the commands and check the parameters used!)
Then you should be ready to use IRAF! Typing the usual “cl” or “ecl” unfortunately doesn’t work1 (and it is a bit frightening at the beginning). But with this installation you just do “irafcl” and the normal ecl terminal starts immediately (nice!).
However, ecl is not that convenient, so we urgently needPyRAF. This can be easily installed through pip:
pip install pyraf
pip3 install pyraf
(for Python 2 and 3, respectively). Now even though pip instals all files under separate dirs it builds only one binary under ~/.local/bin/pyraf. So if you installed PyRAF for python2 first, you will see it running properly when using python2. If you add also pip3 version then you will notice that only PyRAF for python3 is available. Frustrating? You bet!
After some exploration we figured out that PyRAF creates only one binary so it overwrites the previous one. Although we tried to change the name and see if it can run individually this didn’t work (for whatever reason … probably bound to something else?). So there is no way (I wonder?) that you can have PyRAF for both Python versions. [Before asking why to keep both versions, keep in mind that somebody may want to use scripts from older versions! ]
The (not at all convenient) solution found so far is to:
1. install first PyRAF for Python v2
2. rename the pyraf binary (~/.local/bin/pyraf) to something else (e.g. pyraf-v2, this is only a back up as it doesn’t work even if you call it explicitly)
3. install PyRAF for Python v3
4. keep the pyraf binary as it is (for use with Python 3)
5. change the names accordingly if you want to use the older version
[There is another package python3-pyraf that I didn’t test2, as I tend to keep as clean as possible Python’s installations by using pip only.]
However, even after that PyRAF may still not run properly. For example:
user@mymachine:~$ pyraf
Your “iraf” and “IRAFARCH” environment variables are not defined and could not
be determined from /usr/local/bin/cl. These are needed to find IRAF tasks.
Before starting pyraf, define them by doing (for example):
setenv iraf /iraf/iraf/
setenv IRAFARCH linux
at the Unix command line. Actual values will depend on your IRAF installation, and they are set during the IRAF user installation (see iraf.net), or via Ureka installation (see http://ssb.stsci.edu/ureka). Also be sure to run the “mkiraf” command to create a logion.cl (http://www.google.com/search?q=mkiraf).
What is missing now is to define these environment variables properly. You can either type the following lines in the terminal or add them to your .bashrc file, so that PyRAF is available at all times:
export iraf='/usr/lib/iraf/'
export IRAFARCH='linux'
Another working IRAF/PyRAF environment has been deployed!
17/7/2019 Update: Check olebole’s comment below regarding points 1 and 2.
Replacing repositories for old Ubuntu versions
Ok, I may be outdated regarding my Ubuntu version, but there are two reasons for this (fairly good from my point of view!): (i) I did not like the appearance of Ubuntu 11, and (ii) I have everything set up working in 10.10 than I do not want to change (at least before I finish my PhD).
But that does not come without a cost… I was trying to install IRAF but I was facing a problem like (similar to this error):
The following packages have unmet dependencies:
gfortran : Breaks: gfortran-4.4 (> 4.4.1) ...
E: Broken packages
But when I went on to install gfortran (manually, although the script that was running the IRAF installation should automatically find and install dependencies). Even when I tried the solution provided to the previous link (remove gcc g++ and reinstall them) i was still getting the same error (Broken packages). I played around the software sources (repositories) to see if anything was getting wrong there and I notice that, actually, the did not respond (it couldn’t “Fetch”).
When I looked at the repositories (http://archive.ubuntu.com/ubuntu/dists/) there were nothing for the 10.04, so that’s why it couldn’t locate anything. It was just a matter of a few minutes to find out the solution: older releases that are not supported move to the archive server: http://old-releases.ubuntu.com .
Following the instructions (from the post):
(i) edit the /etc/apt/sources.list and change archive.ubuntu.com to old-releases.ubuntu.com, performed with:
sudo sed -i -e 's/archive.ubuntu.com/old-releases.ubuntu.com/g' /etc/apt/sources.list
(ii) update with
sudo apt-get update && sudo apt-get dist-upgrade
solved the issue with the repositories and the installation of IRAF proceeded smoothly.