I've made a walkthrough for installing IRAF on Ubuntu Edgy AMD64 in a 32-bit chroot. It should work fine on i386 too.

I installed IRAf on Edgy last week. But on a Dell Inspiron 9400 with Intel Core Duo. Did it very much the same except I used the generic linux binaries. Have you installed STSDAS/TABLES yet? At the moment the STSDAS ftp server is down so I can't install anything but they only have binaries for Redhat. I was planning on trying to compile STSDAS/TABLES but after looking at your webpage, I noticed that you installed the Redhat binaries and things are working. Now I'm wondering how much of a difference there is to the distro specific binaries.

Jason

Well, I wanted 2.13b2, which comes with the ECL, and there are only Red Hat binaries for that. There shouldn't be anything fundamentally different between the Red Hat and 'generic' Linux binaries as long as you have the right dependencies.

I have no need for STSDAS/TABLES just yet, so I haven't bothered installing them.

Just re-establishing ownership of this thread - for some reason my account totally vanished from the site!

I've updated the original walkthrough to include a proper installation of X11IRAF, and written a new walkthrough for installing binaries for TABLES, STSDAS and PyRAF on Ubuntu Edgy. Once again I'm running the x86 binaries on amd64 in a 32-bit chroot, and have encountered no major problems yet.

Hello,

I'm having a problem with tables. I received an error message :

ERROR on line 477: Cannot open connected subprocess (ttools$x_ttools.e)

I'm using Ubuntu (Edgy). Might it be some installing problem? Maybe the binaries.

I appreciate any help.

Did you follow my exact instructions? What command caused that error? ttools seems to work for me.

This was resolved in another thread (see http://iraf.net/phpBB2/viewtopic.php?t=85806&postdays=0&postorder=asc&start=15), but I just noticed your guides mention to put the binaries in a 'bin.redhat' directory. In general the system determines the architecture from the existence of a /etc/redhat-release file when it isn't defined in the user environment explicitly. My guess is that you defined IRAFARCH (and perhaps $arch, $hbin, etc) for redhat on your system, but the other user was using the default environment? In any case, Ubuntu is Debian-based and so 'linux' is the proper architecture name, however you should be able to install redhat binaries in a bin.linux and have them work.

-Mike

Without having any IRAF installation experience, I wanted everything to be internally consistent with the architecture that the binaries were expecting, just in case it affected something. I just used "-m redhat" for the IRAF install script and patched the X11IRAF install script to add a similar option. Ecl.csh sets IRAFARCH and MACH by detecting the name of the folder in which binaries are present. I should probably set it in the environment to be sure.

At any rate, it all seems to work fine. At some point I'll probably update the walkthrough for STSDAS and TABLES 3.6, at which point I may as well just use the generic 'linux' architecture with the RH binaries.

By the way, (when) will you be unifying the redhat and linux architectures?

UPDATE: The walkthroughs have been updated. They now use the "linux" architecture, STSDAS/TABLES 3.6, stsci_python 2.4, and don't require a chroot on amd64.

By the way, (when) will you be unifying the redhat and linux architectures?

This is still part of the plan for the final V2.13 release, finding time to do it is the holdup at the moment. Packages like stsdas/tables will also likely still release with a 'redhat' arch so that needs to be addressed as well (probably with the network installer also being planned).

-Mike[/quote]

This page describes how to setup IRAF on a Ubuntu/Debian machine. Apart from the exact commands, there are some instructions in square brackets that need to be followed. Installation of X11IRAF, DS9, Tables, and STSDAS are included.

http://geco.phys.columbia.edu/~rubab/iraf/

Well, I have Ubuntu 7.04 installed on my amd64 laptop, I think may be the same...
The problem is that the links you use as argument for wget give me error 404 (not found). Maybe they were moved?

The link to ds9 had become obsolete, it has been updated. Please let me know if you find any other broken links.

Also, since you are using AMD64, be sure to use the instructions for 64-bit installation.

Well, thank you
I've a question, 'cause I'm not an expert... I've a problem in 64-bit procedure. When I run

source irafuser.csh

I've no output or prompt and when I run

sudo ./install

I've a broken pipe error. Can you help me? I really don't know what does this mean... Thanks for the patience

You are not supposed to get a prompt after typing the "source" command, so that's okay.

I have come to know at least two reasons for the broken pipe errors, but they are not very reproducible on my side I am afraid. Anyway, try -

1. Make sure that you are typing in the default paths as suggested by the on screen prompts after ./install . In most cases, people try to come up with their own set of paths that's might not be compatible or type back the prompts incorrectly.

2. The more serious problem is that apparently some machines don't adopt to Ubuntu as well as they do to Debian, specially if you are running 64-bit machines and are using the force architecture handle to install stuffs. Try it on Debian if you can.

Excuse me, but I think I haven't understood...

I read:

source irafuser.csh

[[Choose default paths as will be shown in on-screen prompt parentheses.
Type "y" only where "yes" returns "huh?".]]

sudo ./install

Well, after source command, I've no output or prompt. I don't understand the meaning of phrase in parentheses: where I've to type "y"? Where I've to choose default paths?

Your suggest suppose ./install command goes? This gave to me broken pipe...

I'm sorry if they are stupid questions, but I don't know what to do... :oops:

Yes, the square brackets instruction is applicable after ./install . I intentionally put it ahead because it is a vital instruction.

If you are indeed following all the 64-bit instruction steps and are still getting broken pipe, then the only suggestion I have left, as mentioned before is trying it on Debian instead.

Sorry for not being able to be of more help.