Re: [fedora-astronomy] astronomy Digest, Vol 33, Issue 8

[Joseph Wang]

I'll spend the weekend tweaking the packages.  One thing that would be easy
to do is to create a script that would repackage the source iraf code to
remove anything unnecessary and we can use that for the base source
distribution.  Once that's been done, it ought to simplify both the
licensing and the build.

One other thing on my wish list is to use gfortran for the back end.  The
problem with this is that there is one f77-ism.  f77 allocates a double,
int, and string array with one item and then does an equivalence which then
creates a shared memory space.  I don't know how to do this (or know if it
can be done) in f90.

On Fri, May 31, 2013 at 8:00 PM,
wrote:
> Send astronomy mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://admin.fedoraproject.org/mailman/listinfo/astronomy
> or, via email, send a message with subject or body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of astronomy digest..."
>
> Today's Topics:
> Re: Build iraf RPM on fedora (Sergio Pascual)
> Re: Build iraf RPM on fedora (Ole Streicher)
>
> Message: 1
> Date: Thu, 30 May 2013 23:47:07 +0200
> From: Sergio Pascual 
> To: Olе Streicher 
> Cc: Astronomy Mailing List 
> Subject: Re: [fedora-astronomy] Build iraf RPM on fedora
> Message-ID:
>         <CACta-KZ=O4m70ywp5+Rw89X2QiRJ-Sh58DLx3m=
> [e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> 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
> > 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  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
> > [e-mail]
> > http://fedoraproject.org/wiki/SIGs/Astronomy
> > https://admin.fedoraproject.org/mailman/listinfo/astronomy
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.fedoraproject.org/pipermail/astronomy/attachments/20130530/9f03...
> >
>
> Message: 2
> Date: Fri, 31 May 2013 10:44:19 +0200
> From: Ole Streicher 
> To: Sergio Pascual 
> Cc: Astronomy Mailing List 
> Subject: Re: [fedora-astronomy] Build iraf RPM on fedora
> Message-ID: 
> Content-Type: text/plain; charset=UTF-8
>
> 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
>
> astronomy mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/astronomy
>
> End of astronomy Digest, Vol 33, Issue 8

astronomy Digest, Vol 33, Issue 8

[Gerald Henriksen]

On Fri, 31 May 2013 20:18:39 +0800, you wrote:
> One other thing on my wish list is to use gfortran for the back end.  The
> problem with this is that there is one f77-ism.  f77 allocates a double,
> int, and string array with one item and then does an equivalence which then
> creates a shared memory space.  I don't know how to do this (or know if it
> can be done) in f90.

gfortran supports f77 as well as the newer versions.