Iraf has been developed by NOAO until 2006, when the user support was transferred to a volunteer effort, iraf.net. That was about version 2.12. In 2007, NOAO recollected the patches and user contributions, and together with other improvements, released version 2.14. Iraf is vast and ancient. It's partly written in C and partly written in SPP, a custom made language. SPP needs a custom compiler that it's included in the iraf core. SPP is converted into fortran (using f2c) and compiled with the C compiler. Iraf works in different architectures, but lacks x86_64 support. A project[1] exists to port iraf to x86_64, and it's basically the work of one person, Chisato Yamauchi[2]. This work it's outside NOAO or iraf.net. I help him doing the testing of his developments in my Fedora system, as he develops in CentOS. Iraf includes a copy of the libc of the time of its early developments (mid-80s), replicating the functionality of basic system calls. It also includes a modified copy of ncar[3] graphics library 1.0 (current version is 5.0). ncar wasn't free at that time (I don't know if it's free know, it seems to be composed of several packages, some free and some not). Iraf graphics facility, x11iraf, contains non-free code also. I tried to package it in the past[4], but the package couldn't be included due to legal restrictions again. That's where the thread[5] in iraf.net comes from. It was me complaining about the license text in the iraf.net faq no representing the real status of iraf and x11iraf, misleading into believing that both were free software when they weren't. You can see also the answer to the complains about closed code in iraf, basically "please fix it yourself and send me the patches". As iraf is very far from trivial to compile, I suppose that the number of patches received across the years is nearly zero. Neither iraf.net or noao provide tools to work in iraf development, such as a version control system. So, if we want to develop something based in iraf, we at least need to establish a source tree somewhere. Don't call it a fork if you want, but it's the only way to work. [1] http://sourceforge.net/projects/iraf64 [2] http://www.ir.isas.jaxa.jp/~cyamauch/ [3] http://ngwww.ucar.edu/index.html [4] https://bugzilla.redhat.com/show_bug.cgi?id=249614 [5] http://iraf.net/phpBB2/viewtopic.php?t=86793

> If I understood well, our better (and only ?) option if we want IRAF > in Fedora is to push it to our trac server and work hard, right ? ( i > do not consider the waiting solution ) Yes, that's my opinion. But I would like to hear some others.

On Sun, 25 May 2008 22:12:39 +0200, you wrote: >Sergio Pascual wrote: >>> If I understood well, our better (and only ?) option if we want IRAF >>> in Fedora is to push it to our trac server and work hard, right ? ( i >>> do not consider the waiting solution ) >> >> Yes, that's my opinion. But I would like to hear some others. > >Sadly true that it's our last solution. An alternative is to not include iraf in Fedora directly but instead package it up for RPM Fusion (rpmfusion.org). While obviously not ideal it does at least get iraf packaged for Fedora, and a project to replace the non-free bits could still go ahead without the pressure of getting iraf in as soon as possible.