I got Hello world on fedora 18.
The main roadblock was that f2c.h on fedora has had the fortran types changed a bit.
Hi Joseph,
I haven't managed yet to get iraf built in mock. I create an srpm using the two files you attach and another patch more from your previous mail. I then build the rpm using mock but the compilation fails.
Have you used mock to build the srpms? If not, please do so. It's the only way to be sure that the dependencies are handled correctly.
I would appreciate a lot if you could upload your working source rpm somewhere so that I can download it and recompile it in my system.
And thanks a lot for your hard work.
Regards, Sergio
2013/5/7 Joseph Wang joequant@gmail.com:
I got Hello world on fedora 18.
The main roadblock was that f2c.h on fedora has had the fortran types changed a bit.
I've gotten the SRPM to build with mock and uploaded a link to dropbox
https://dl.dropboxusercontent.com/u/1025783/iraf-2.16-1.src.rpm
On Thu, May 16, 2013 at 7:39 AM, Sergio Pascual sergiopr@fedoraproject.orgwrote:
Hi Joseph,
I haven't managed yet to get iraf built in mock. I create an srpm using the two files you attach and another patch more from your previous mail. I then build the rpm using mock but the compilation fails.
Have you used mock to build the srpms? If not, please do so. It's the only way to be sure that the dependencies are handled correctly.
I would appreciate a lot if you could upload your working source rpm somewhere so that I can download it and recompile it in my system.
And thanks a lot for your hard work.
Regards, Sergio
2013/5/7 Joseph Wang joequant@gmail.com:
I got Hello world on fedora 18.
The main roadblock was that f2c.h on fedora has had the fortran types changed a bit.
On 05/17/2013 01:11 PM, Joseph Wang wrote:
I've gotten the SRPM to build with mock and uploaded a link to dropbox
https://dl.dropboxusercontent.com/u/1025783/iraf-2.16-1.src.rpm
Hi Joseph,
I've downloaded the srpm and recompiled it for F19 using mock in F18. Then I installed the rpm in F19 beta and it seems to work fine, though it needs java as a Requires because of the VO tools like Aladin. After installing java-1.7.0-openjdk, Aladin opened fine.
Thanks for your work! All the best, Germán.
On Thu, May 16, 2013 at 7:39 AM, Sergio Pascual <sergiopr@fedoraproject.org mailto:sergiopr@fedoraproject.org> wrote:
Hi Joseph, I haven't managed yet to get iraf built in mock. I create an srpm using the two files you attach and another patch more from your previous mail. I then build the rpm using mock but the compilation fails. Have you used mock to build the srpms? If not, please do so. It's the only way to be sure that the dependencies are handled correctly. I would appreciate a lot if you could upload your working source rpm somewhere so that I can download it and recompile it in my system. And thanks a lot for your hard work. Regards, Sergio 2013/5/7 Joseph Wang <joequant@gmail.com <mailto:joequant@gmail.com>>: > I got Hello world on fedora 18. > > The main roadblock was that f2c.h on fedora has had the fortran types > changed a bit. >
Fedora astronomy mailing list astronomy@lists.fedoraproject.org http://fedoraproject.org/wiki/SIGs/Astronomy https://admin.fedoraproject.org/mailman/listinfo/astronomy
Hi Joseph,
very nice, now it works: compiles and the basic things seem to work (display, imstat, etc)
I have run "fedora-review" on the rpm. It is an automated tool that checks if the package follows fedora guidelines. Some, if not all, the recomendations my be applied to Mageia.
The directory to install must be %{_libdir}/iraf and not %{_datadir}/iraf, as the package is arch dependent
After the install there are a bunch of source files remaining under iraf. I have used find -name "*.f" -o -name "*.c" ... -delete to remove them. I have removed also empty files and dirs.
fedora-review checks the licenses of the files. Here there are two issues: * There is not a license file for Iraf that I can find. If it is hidden in some doc/doc/doc directory it should really go in the top level directory * The software in iraf is under different licenses. fedora-review checks the files in the source tree and tries to group them under license. The present licenses are: BSD (3 clauses), BSD (4 clauses), GPL v1 or later, GPl v2 or later, CDDL, MIT/X11. I'm not a lawyer, but CDDL and BSD (4 clauses) are not GPL compatible, so the combined work cannot fulfill the requirements of every license.
There are bundled libraries (cfitsio, readline, expat, etc) that should be unbundled. Probably everything under vendor should be unbundled.
I have updated the rpm file to use _libdir and to remove some of the most obvious source files. Please have a look here:
http://guaix.fis.ucm.es/~spr/iraf-2.16-2.src.rpm
Best regards, Sergio
2013/5/17 Joseph Wang joequant@gmail.com
I've gotten the SRPM to build with mock and uploaded a link to dropbox
https://dl.dropboxusercontent.com/u/1025783/iraf-2.16-1.src.rpm
On Thu, May 16, 2013 at 7:39 AM, Sergio Pascual < sergiopr@fedoraproject.org> wrote:
Hi Joseph,
I haven't managed yet to get iraf built in mock. I create an srpm using the two files you attach and another patch more from your previous mail. I then build the rpm using mock but the compilation fails.
Have you used mock to build the srpms? If not, please do so. It's the only way to be sure that the dependencies are handled correctly.
I would appreciate a lot if you could upload your working source rpm somewhere so that I can download it and recompile it in my system.
And thanks a lot for your hard work.
Regards, Sergio
2013/5/7 Joseph Wang joequant@gmail.com:
I got Hello world on fedora 18.
The main roadblock was that f2c.h on fedora has had the fortran types changed a bit.
Hi Joseph, Sergio,
I am working on a Debian package for IRAF, so I am following the discussion here closely. I intend to base the Debian package on your work. There are, however, still some issues to be solved. As for other astronomy packages, it would probably be good to coordinate us here a bit, so that the packages match closely, that the Linux fragmentation does not make it too hard to switch between Debian and Fedora.
Here are my thoughts for the Debian package. Feel free to ignore them or to discuss them here ;-) :
Splitting into smaller packages ===============================
Arch-dependent and arch-independent package -------------------------------------------
Most of the files are arch independent; it does not make sense to duplicate them for every architecture. This is important for Debian which has a dozens of official and inofficial ports, but may be an issue for (potential) fedora ports as well. Extending to other architectures seems mainly a problem of the zsvjmp.s file, which already exists for i386, x64_64, and ppc (and others). Since this code is quite small, it is probably not too difficult to port it to the oder Fedora and Debian architectures; I could ask port maintainers to help writing the code once it works for the main architectures.
Documentation would be another sub-package (which would be an optional installation), as well as maybe a -dev or -src package (which contains the files needed to rebuild/update the IRAF package, if this is needed at all -- I have doubts here).
Split-off of large subpackages ------------------------------
I would split off the VO and NOAO packages. I am not sure whether everyone needs these packages, so they could be made optional. Both could be also split into arch-dependent, arch-independent and documentation packages. Maybe other sub-packages are useful as well.
Directory tree ==============
According to the FHS, the architecture independent files should go into /usr/share/iraf/ (is this %_{datadir}/iraf?), which then are linked into /usr/lib/iraf/ (in Debian better /usr/lib/x86_64-linux-gnu/iraf/ to allow multiarch). So, the IRAF base dir could look like
$ ls -l $iraf
drwxrwxr-x 2 oles 4096 Okt 18 2012 bin drwxrwxr-x 2 oles 4096 Okt 18 2012 dev -> /usr/share/iraf/dev drwxrwxr-x 4 oles 4096 Okt 18 2012 doc -> /usr/share/doc/iraf drwxrwxr-x 2 oles 4096 Okt 18 2012 extern -> /usr/share/iraf/extern -rw-rw-r-- 1 oles 0 Okt 18 2012 HS.PCIX.GEN drwxrwxr-x 2 oles 4096 Okt 18 2012 include -> /usr/include/iraf -rw-rw-r-- 1 oles 0 Okt 18 2012 IRAF.NET -rw-rw-r-- 1 oles 0 Okt 18 2012 IS.PORT.GEN drwxrwxr-x 6 oles 4096 Okt 18 2012 lib -> /usr/share/iraf/lib [...] drwxrwxr-x 4 oles 4096 Okt 18 2012 unix/ drwxrwxr-x 2 oles 4096 Mai 13 11:47 util -> /usr/share/iraf/util drwxrwxr-x 13 oles 4096 Okt 18 2012 vo/
I removed the bin.* here completely; the binaries are stored directly in /usr/lib/iraf/bin/ (resp. /usr/lib/x86_64-linux-gnu/iraf/bin/ for multiarch). The IRAF subdirectories (unix, vo, noao) I would handle in a similar manner.
Patches =======
I would propose not to use one huge patch, but to split it up into smaller patches, by subject. As far as I analyzed your patch, it could be split up into:
fix_fncache.patch fortran.patch irafuser_csh.patch libc.patch link_executables.patch mksys.patch shared_readline.patch unop_int.patch voclient.patch vodata.patch xc.patch
Copyright =========
To your (Sergio) issue, I have a small comment:
Sergio Pascual sergiopr@fedoraproject.org writes:
* The software in iraf is under different licenses. fedora-review checks the files in the source tree and tries to group them under license. The present licenses are: BSD (3 clauses), BSD (4 clauses), GPL v1 or later, GPl v2 or later, CDDL, MIT/X11. I'm not a lawyer, but CDDL and BSD (4 clauses) are not GPL compatible, so the combined work cannot fulfill the requirements of every license.
As far as I analyzed the licenses, CDDL is used for unix/boot/xyacc/* and unix/hlib/stdarg-solaris.h. BSD-4 is used only in unix/hlib/libc/stdarg-freebsd.h. The stdarg-*.h files are not used for Linux, so they are not part of a combined work in Debian or Fedora.
xyacc is used to build the system. The output of xyacc is not necessarily licensed by CDDL. xyacc is also not linked to GPL code. Perhaps it may be omitted completely from the binary distribution? It could also go into a separate (CDDL-licensed) package, if there is a use for it.
Best regards
Ole
Hi Ole,
I completely agree on trying to coordinate efforts.
My comments about the points you rise:
* Splitting into smaller packages. As all the .cl, .dat, .par, .key files, etc are shareable between arches I agree that they should go to /usr/share/iraf and in a differente package. Notice that there are still a bunch of files (READMEs, csh scripts, text files with docs about implementation, etc) that are basically not need in the running system and could be removed.
Speaking about arches, an ARM port would be very cool...
Regarding docs and noao and vo packages, I have my doubts. The docs are used in the internal documentation system (when you type "help" in cl). In my experience, users type "help" all the time. Tasks are complex, with long lists of parameters and you need the doc system to understand what the task does. The noao package contains basic subpackages. CCD processing is in noao.imred.ccdred Long slit spectrosocopy is in noao.twodspec. In fact, I preloaded noao in my login.cl just to avoid loading myself everytime I entered Iraf. I haven't used vo, thought.
Spliting said packages would mean that, to have a functional iraf, one usually would install iraf, iraf-noao, iraf-doc, iraf-noao-doc and (iraf-vo, iraf-vo-doc). Too many packages in my opinion. I prefer just iraf for binaries and iraf-common (for example) for noarch data.
We need an iraf-dev if we want to be able to build external iraf packages. The xc compiler should go in this package. And the headers and libraries.
And x11iraf (where xgterm lives) has to be another package. And we need .desktop files for it.
* Copyright. Probably you are right.
Best, Sergio
2013/5/28 Olе Streicher debian-devel@liska.ath.cx
Hi Joseph, Sergio,
I am working on a Debian package for IRAF, so I am following the discussion here closely. I intend to base the Debian package on your work. There are, however, still some issues to be solved. As for other astronomy packages, it would probably be good to coordinate us here a bit, so that the packages match closely, that the Linux fragmentation does not make it too hard to switch between Debian and Fedora.
Here are my thoughts for the Debian package. Feel free to ignore them or to discuss them here ;-) :
Splitting into smaller packages
Arch-dependent and arch-independent package
Most of the files are arch independent; it does not make sense to duplicate them for every architecture. This is important for Debian which has a dozens of official and inofficial ports, but may be an issue for (potential) fedora ports as well. Extending to other architectures seems mainly a problem of the zsvjmp.s file, which already exists for i386, x64_64, and ppc (and others). Since this code is quite small, it is probably not too difficult to port it to the oder Fedora and Debian architectures; I could ask port maintainers to help writing the code once it works for the main architectures.
Documentation would be another sub-package (which would be an optional installation), as well as maybe a -dev or -src package (which contains the files needed to rebuild/update the IRAF package, if this is needed at all -- I have doubts here).
Split-off of large subpackages
I would split off the VO and NOAO packages. I am not sure whether everyone needs these packages, so they could be made optional. Both could be also split into arch-dependent, arch-independent and documentation packages. Maybe other sub-packages are useful as well.
Directory tree
According to the FHS, the architecture independent files should go into /usr/share/iraf/ (is this %_{datadir}/iraf?), which then are linked into /usr/lib/iraf/ (in Debian better /usr/lib/x86_64-linux-gnu/iraf/ to allow multiarch). So, the IRAF base dir could look like
$ ls -l $iraf
drwxrwxr-x 2 oles 4096 Okt 18 2012 bin drwxrwxr-x 2 oles 4096 Okt 18 2012 dev -> /usr/share/iraf/dev drwxrwxr-x 4 oles 4096 Okt 18 2012 doc -> /usr/share/doc/iraf drwxrwxr-x 2 oles 4096 Okt 18 2012 extern -> /usr/share/iraf/extern -rw-rw-r-- 1 oles 0 Okt 18 2012 HS.PCIX.GEN drwxrwxr-x 2 oles 4096 Okt 18 2012 include -> /usr/include/iraf -rw-rw-r-- 1 oles 0 Okt 18 2012 IRAF.NET -rw-rw-r-- 1 oles 0 Okt 18 2012 IS.PORT.GEN drwxrwxr-x 6 oles 4096 Okt 18 2012 lib -> /usr/share/iraf/lib [...] drwxrwxr-x 4 oles 4096 Okt 18 2012 unix/ drwxrwxr-x 2 oles 4096 Mai 13 11:47 util -> /usr/share/iraf/util drwxrwxr-x 13 oles 4096 Okt 18 2012 vo/
I removed the bin.* here completely; the binaries are stored directly in /usr/lib/iraf/bin/ (resp. /usr/lib/x86_64-linux-gnu/iraf/bin/ for multiarch). The IRAF subdirectories (unix, vo, noao) I would handle in a similar manner.
Patches
I would propose not to use one huge patch, but to split it up into smaller patches, by subject. As far as I analyzed your patch, it could be split up into:
fix_fncache.patch fortran.patch irafuser_csh.patch libc.patch link_executables.patch mksys.patch shared_readline.patch unop_int.patch voclient.patch vodata.patch xc.patch
Copyright
To your (Sergio) issue, I have a small comment:
Sergio Pascual sergiopr@fedoraproject.org writes:
- The software in iraf is under different licenses. fedora-review
checks the
files in the source tree and tries to group them under license. The
present
licenses are: BSD (3 clauses), BSD (4 clauses), GPL v1 or later, GPl v2
or
later, CDDL, MIT/X11. I'm not a lawyer, but CDDL and BSD (4 clauses) are
not
GPL compatible, so the combined work cannot fulfill the requirements of
every
license.
As far as I analyzed the licenses, CDDL is used for unix/boot/xyacc/* and unix/hlib/stdarg-solaris.h. BSD-4 is used only in unix/hlib/libc/stdarg-freebsd.h. The stdarg-*.h files are not used for Linux, so they are not part of a combined work in Debian or Fedora.
xyacc is used to build the system. The output of xyacc is not necessarily licensed by CDDL. xyacc is also not linked to GPL code. Perhaps it may be omitted completely from the binary distribution? It could also go into a separate (CDDL-licensed) package, if there is a use for it.
Best regards
Ole _______________________________________________ Fedora astronomy mailing list astronomy@lists.fedoraproject.org http://fedoraproject.org/wiki/SIGs/Astronomy https://admin.fedoraproject.org/mailman/listinfo/astronomy
Hi Sergio and all,
Am 30.05.2013 23:47, schrieb Sergio Pascual:
I completely agree on trying to coordinate efforts.
Nice to hear :-)
- Splitting into smaller packages. As all the .cl, .dat, .par, .key
files, etc are shareable between arches I agree that they should go to /usr/share/iraf and in a differente package. Notice that there are still a bunch of files (READMEs, csh scripts, text files with docs about implementation, etc) that are basically not need in the running system and could be removed.
When browsing around the iraf sources, I found several "strip" scripts that could be converted to a "shared" install script. Something like
TARGET=/usr/share/iraf for j in $(find . -name *.hlp \ -o -name *.hd \ -o -name *.men \ -o -name *.cl \ -o -name *.par \ -o -name *.key \ -o -name *.dat \ -o -name *.mip \ -o -name *.fits \ -o -path ./dev/* \ | cut -c3-) ; do install -p -D -m 644 $j $TARGET/$j done rm -f $TARGET/dev/tapecap.* $TARGET/dev/README
should do the job for all files needed at runtime. These are ~ 20 MB.
Speaking about arches, an ARM port would be very cool...
Yes. If you know someone with assembler experience: as.linuxarm/zsvjmp.s is the file we need.
Regarding docs and noao and vo packages, I have my doubts. The docs are used in the internal documentation system (when you type "help" in cl). In my experience, users type "help" all the time. Tasks are complex, with long lists of parameters and you need the doc system to understand what the task does. The noao package contains basic subpackages. CCD processing is in noao.imred.ccdred Long slit spectrosocopy is in noao.twodspec. In fact, I preloaded noao in my login.cl http://login.cl just to avoid loading myself everytime I entered Iraf. I haven't used vo, thought.
With documentation, I tend to agree -- although I can imagine that the documentation is not strictly needed when running a prefabricated script non-interactively (f.e. on a computing farm). However, we would not save much if we split it.
What concerns splitting VO and NOAO: Even upstream (NOAO) splits (or splitted) them up in their binary releases ("ib" for IRAF binary and "nb" for "NOAO binary"). For me, it makes sense to separate between the (generic) IRAF system and the (more algorithm-related) NOAO package, even if most people will always install them together.
Spliting said packages would mean that, to have a functional iraf, one usually would install iraf, iraf-noao, iraf-doc, iraf-noao-doc and (iraf-vo, iraf-vo-doc).
Someting like
iraf iraf-common iraf-noao iraf-noao-common ifaf-vo iraf-vo-common
Alternatively, one could create "iraf-base" and "iraf-base-common" packages that hold the base system, and an "iraf" virtual packages that joins everything together via dependencies.
Too many packages in my opinion. I prefer just iraf for binaries and iraf-common (for example) for noarch data.
The end-user will not need to fiddle with these packages; he would just install IRAF. On Debian, I would create a "recommends" dependency, which means "packages that are installed together, wich declares a "strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations". I would guess the same exists in Fedora.
To have a comparison with other large package suites, look f.e. to the "libreoffice" suite. Except for language packs, I don't know anyone who would only install the writer -- but it is split up into lo-base, bsh, calc, core, draw, ...
We need an iraf-dev if we want to be able to build external iraf packages. The xc compiler should go in this package. And the headers and libraries.
Sure. Main issue for me would be to have a list of files that should be included. Would we basically need just .h and .a files? What about sources (.x, .c, .f)? Also, I think the header should go into /usr/include/iraf/, right?
And x11iraf (where xgterm lives) has to be another package. And we need .desktop files for it.
Yes. I would, however, recommend that x11iraf also gets a separate source package. In the moment, it is build as part of the iraf pkg, but it has its own (independent) source tar file.
Also, I think that x11iraf is not 64 bit clean, so even if it may be build on x86_64, it will probably crash there. Therefore it makes IMO sense to have a separate package that builds only on 32-bit platforms (mainly i386) -- and (for Debian) one could use the Multiarch approach to run it.
Best regards
Ole
Hi all,
one more proposal regarding directory structure: According to the freedeskto.org, the directories imlib$ and cache$ should go into the user's home dir on default:
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
which leads to a change in mkiraf.csh (see below). This creates and uses the files
${HOME}/.local/share/imdir - as user image directory ${HOME}/.cache/iraf - as user cache dir
Best regards
Ole
--- a/unix/hlib/mkiraf.csh +++ b/unix/hlib/mkiraf.csh @@ -4,7 +4,7 @@
# The following definitions are site dependent. [SITEDEP]
-set iraf = "/iraf/iraf" +set iraf = "/usr/share/iraf" set imdir = "/iraf/imdirs" set cachedir = "/iraf/cache" set ttymsg =\ @@ -93,16 +93,22 @@ pwd | sed -e "s;.*;s+U_UPARM+&/uparm/+;" >> _sed
if (! (-e "$imdir" && -w "$imdir") ) then - set imdir = HDR$ - whoami | sed -e "s;.*;s+U_IMDIR+${imdir}/+;" >> _sed + if ( ${?XDG_DATA_HOME} == 0 ) then + setenv XDG_DATA_HOME ${HOME}/.local/share + endif + echo "s+U_IMDIR+${XDG_DATA_HOME}/imdir/+" >> _sed + mkdir -p ${XDG_DATA_HOME}/imdir/ else whoami | sed -e "s;.*;s+U_IMDIR+${imdir}/&/+;" >> _sed whoami | sed -e "s;.*;mkdir $imdir/& 2> /dev/null;" | sh endif
if (! (-e "$cachedir" && -w "$cachedir") ) then - set cachedir = /tmp/ - whoami | sed -e "s;.*;s+U_CACHEDIR+${cachedir}/+;" >> _sed + if ( ${?XDG_CACHE_HOME} == 0 ) then + setenv XDG_CACHE_HOME ${HOME}/.cache + endif + echo "s+U_CACHEDIR+${XDG_CACHE_HOME}/iraf/+" >> _sed + mkdir -p ${XDG_CACHE_HOME}/iraf/ else whoami | sed -e "s;.*;s+U_CACHEDIR+${cachedir}/&/+;" >> _sed whoami | sed -e "s;.*;mkdir $cachedir/& 2> /dev/null;" | sh
On 06/04/2013 06:11 PM, Olе Streicher wrote:
Hi all,
one more proposal regarding directory structure: According to the freedeskto.org, the directories imlib$ and cache$ should go into the user's home dir on default:
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
which leads to a change in mkiraf.csh (see below). This creates and uses the files
${HOME}/.local/share/imdir - as user image directory ${HOME}/.cache/iraf - as user cache dir
Wouldn't be safer to use ${HOME}/.local/share/iraf/imdir instead of ${HOME}/.local/share/imdir?
Regards, Germán.
Best regards
Ole
--- a/unix/hlib/mkiraf.csh +++ b/unix/hlib/mkiraf.csh @@ -4,7 +4,7 @@
# The following definitions are site dependent. [SITEDEP]
-set iraf = "/iraf/iraf" +set iraf = "/usr/share/iraf" set imdir = "/iraf/imdirs" set cachedir = "/iraf/cache" set ttymsg =\ @@ -93,16 +93,22 @@ pwd | sed -e "s;.*;s+U_UPARM+&/uparm/+;" >> _sed
if (! (-e "$imdir" && -w "$imdir") ) then
- set imdir = HDR$
- whoami | sed -e "s;.*;s+U_IMDIR+${imdir}/+;" >> _sed
if ( ${?XDG_DATA_HOME} == 0 ) then
setenv XDG_DATA_HOME ${HOME}/.local/share
endif
echo "s+U_IMDIR+${XDG_DATA_HOME}/imdir/+" >> _sed
mkdir -p ${XDG_DATA_HOME}/imdir/ else whoami | sed -e "s;.*;s+U_IMDIR+${imdir}/&/+;" >> _sed whoami | sed -e "s;.*;mkdir $imdir/& 2> /dev/null;" | sh endif
if (! (-e "$cachedir" && -w "$cachedir") ) then
- set cachedir = /tmp/
- whoami | sed -e "s;.*;s+U_CACHEDIR+${cachedir}/+;" >> _sed
- if ( ${?XDG_CACHE_HOME} == 0 ) then
- setenv XDG_CACHE_HOME ${HOME}/.cache
- endif
- echo "s+U_CACHEDIR+${XDG_CACHE_HOME}/iraf/+" >> _sed
- mkdir -p ${XDG_CACHE_HOME}/iraf/ else whoami | sed -e "s;.*;s+U_CACHEDIR+${cachedir}/&/+;" >> _sed whoami | sed -e "s;.*;mkdir $cachedir/& 2> /dev/null;" | sh
Fedora astronomy mailing list astronomy@lists.fedoraproject.org http://fedoraproject.org/wiki/SIGs/Astronomy https://admin.fedoraproject.org/mailman/listinfo/astronomy
"Germán A. Racca" german.racca@gmail.com writes:
Wouldn't be safer to use ${HOME}/.local/share/iraf/imdir instead of ${HOME}/.local/share/imdir?
Right. I'll change that (for Debian, however; for Fedora this should be incorporated in Joseph's patch)
Best
Ole
astronomy@lists.fedoraproject.org
-
"Germán A. Racca" -
Joseph Wang -
Ole Streicher -
Sergio Pascual