Bug#753620: wishlist: idl/gdl-written software
I propose to close this bug. There are now three packages close to upload: * mpfit (gdl-mpfit) - http:://bugs.debian.org/788869 * coyote (gdl-coyote) - http:://bugs.debian.org/789081 * idlastro (gdl-idlastro) - http:://bugs.debian.org/788826 This bug mentiones other packages which will unfortunately not make their way into Debian: * CMSVLIB (http://www.physics.wisc.edu/~craigm/idl/cmsave.html) has a non-free, and problematic license: is allows to use the routine only if one has an IDL license. * tex2idl (http://physics.mnstate.edu/craig/textoidl/) is also not DFSG-free So, there is nothing left here to do here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753620: Fwd: Re: Bug#753620: wishlist: idl/gdl-written software
Original Message Subject: Re: Bug#753620: wishlist: idl/gdl-written software Resent-Date: Sun, 6 Jul 2014 12:44:12 + (UTC) Resent-From: debian-as...@lists.debian.org Date: Sun, 06 Jul 2014 14:43:48 +0200 From: debian-de...@liska.ath.cx (Оlе Ѕtrеісhеr) Reply-To: Ole Streicher deb...@liska.ath.cx To: debian-as...@lists.debian.org Sergio Gelato sergio.gel...@astro.su.se writes: In a Debian world, these packages only work with GDL, so GDL is required (and not just recommended). OK, maybe it really should depend on gnudatalanguage | idl-interpreter (or whatever the virtual package name would be), just like some Java libraries depend on default-jre-headless | java5-runtime-headless . The policy requires that a package in main can only depend on other packages in main. I am not sure how this is for the operands of the | operator. I have no ambition to dictate Debian policy so I'll bow out of further discussion on this point. There's always equivs anyway. For packages in main, the policy is a dictate; that's the idea of Debian. Contrib and non-free are different. I worry a bit that otherwise GDL is just used as an excuse to ship packages that require non-free software in main. I don't think that should be a concern: wouldn't you agree that if the package doesn't work with GDL it shouldn't recommend (much less depend on) GDL? It then falls outside the scope of this discussion since the reasons (if any) to include it in Debian would not be related to GDL. If a package does not work if the dependencies are fullfilled, it should not be in Debian. Just to make it clear: I'm not asking for anyone to package idlastro and friends. If someone does, then I'll consider using the packages and will be grateful if they meet my needs. I think I can see some value in: -- providing a policy and/or a canonical example for how to package GDL add-ons (as we have for Perl, Python, Java, Ruby, Octave, etc.) This one is independent of whether a package goes into Debian main (I still think this is only possible for packages that function with GDL) or Debian contrib or non-free (no problem with a dependency from IDL). -- testing idlastro etc. with GDL and resolving or documenting any incompatibilities found. Since the original request was an outcome from a GDL conference, I would think that was the original idea. The latter might help make GDL a viable alternative to proprietary IDL; right now the users I support don't perceive it as such. The idea of Debian is to distribute free software. The compromise for proprietary software and its dependencies are the contrib and non-free archives (which are not a regular part of Debian itself). So, our (Debians) effort should go into the GDL support in the first place. I leave it to those who would actually do the work to decide whether it's worth their time. Agreed. Again: There is nothing wrong with putting a package into contrib if it does not work with GDL. The procedure is mainly the same. Best regards Ole -- To UNSUBSCRIBE, email to debian-astro-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87tx6uwtbv@our.domain.is.not.set -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753620: wishlist: idl/gdl-written software
Hi Axel, hi All, Thanks for quick reply. On 04/07/14 00:32, Axel Beckert wrote: While the gnudatalanguage package is their main dependency, this is actually nothing we can fix in the gnudatalanguage Debian package itself. Bascially for each software you listed, there should be an RFP (need to be filed against the pseudo-package wnpp, neither without package attribution nor attributed to the gnudatalanguage package). I've already reassigned the GSHHS stuff to the wnpp pseudo-package. I can reassign and clone this bug report for each of these programs, but you will likely need to add some more details (licenses, etc.) afterwards to make the proper RFPs. Alternatively you can write new RFP bug reports (against the wnpp pseudo package) on your own and I'll close this one afterwards. If you are on Debian you can use the command reportbug wnpp to get assisted filing of the RFP bug reports. (Not sure if that works on Ubuntu, too.) I'll of course do the resubmission myself. Although I did not recall the wnpp tag yesterday, I had intentionally linked this discussion with gdl package - perhaps before starting submitting multiple RFPs we can discuss some issues here? - where to place the IDL/GDL-written software in the system - how to inform GDL package about their location? - how to make these packages usable for IDL / PV-WAVE users? - how to name these packages? - should idlastro be splitted into multiple subpackages? - should idlastro become a dependency of gdl? - can you guys from the debian-astro team maintain these packages? - what other IDL/GDL-written software is of interest? Looking forward to hearing your comments, Thanks, Sylwester -- http://www.igf.fuw.edu.pl/~slayoo/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753620: Fwd: Re: Bug#753620: wishlist: idl/gdl-written software
Original Message Subject: Re: Bug#753620: wishlist: idl/gdl-written software Resent-Date: Fri, 4 Jul 2014 12:45:41 + (UTC) Resent-From: debian-as...@lists.debian.org Date: Fri, 04 Jul 2014 14:45:14 +0200 From: debian-de...@liska.ath.cx (Оlе Ѕtrеісhеr) Reply-To: Ole Streicher deb...@liska.ath.cx To: debian-as...@lists.debian.org Hi Sylwester, Sylwester Arabas sara...@igf.fuw.edu.pl writes: perhaps before starting submitting multiple RFPs we can discuss some issues here? thank you very much for your interest, and I also would like to see GDL packages in Debian. I think that the questions you raised for discussion are all important and should be solved before actually starting the packaging. However, I never used IDL or GDL myself, so I can only do some unspecific comments. - where to place the IDL/GDL-written software in the system Since they are not machine specific, maybe a good place would be /usr/share/gdl-packages/ ? - how to inform GDL package about their location? No idea. - how to make these packages usable for IDL / PV-WAVE users? Since IDL is non-free, I would consider this not as a primary goal. I would concentrate on GDL. - how to name these packages? use gdl- as prefix? However, this sounds ugly for the whole package: gdl-idlastro. - should idlastro be splitted into multiple subpackages? I would split it, if the different parts are somehow usable independently. Also, not all packages may be usable under GDL (yet), right? - should idlastro become a dependency of gdl? GDL should be a requirement of the package(s). Again: priority should be the use with GDL -- and only packages that work with GDL can go into Debian (main); everything else would have to go into contrib. Sponsors and also the ftp-masters will take much more efforts for packages in Debian main than for those in contrib, since software freedom is one of the main goals of Debian (and also one of the reasons for myself). Can you give an overview what of idlastro works with GDL and what not? How complete is GDL compared to IDL? - can you guys from the debian-astro team maintain these packages? There is no real fixed team; we are more a community of volunteers. If you are willing to spend some effort, you can maintain the packages yourself (and therefore join us :-) ). From the Debian side, we can (and will) help you with all the debian specific issues, but for the GDL part maybe you are more qualified? - what other IDL/GDL-written software is of interest? I heared of mpfit, but isn't there an astrolib somehow? This also depends on what actually works with GDL. Best regards Ole -- To UNSUBSCRIBE, email to debian-astro-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87a98pxpgl@our.domain.is.not.set -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753620: Fwd: Re: Bug#753620: wishlist: idl/gdl-written software
Original Message Subject: Re: Bug#753620: wishlist: idl/gdl-written software Resent-Date: Fri, 4 Jul 2014 13:56:29 + (UTC) Resent-From: debian-as...@lists.debian.org Date: Fri, 4 Jul 2014 15:50:19 +0200 From: Sergio Gelato sergio.gel...@astro.su.se To: debian-as...@lists.debian.org * Оlе Ѕtrеісhеr [2014-07-04 14:45:14 +0200]: Sylwester Arabas sara...@igf.fuw.edu.pl writes: - how to inform GDL package about their location? No idea. One would want to augment the !PATH variable within GDL. This can be done in a startup script or by the user setting an environment variable. I'm not sure it's desirable for the packages to unconditionally add themselves to the !PATH (some of them may be too specialised and/or interfere with one another or with users' own code), but that could be under debconf control. I don't think GDL currently looks for startup file snippets under /etc but that should be an easy feature to add, if desired. - how to make these packages usable for IDL / PV-WAVE users? Since IDL is non-free, I would consider this not as a primary goal. I would concentrate on GDL. Still, I for one would like them to be usable with proprietary IDL as well. I certainly do not expect the Debian maintainers to develop workarounds for bugs in IDL that are not present in GDL; that sort of thing can be left to the upstream developers. Concentrate on GDL sounds right in that sense. - should idlastro become a dependency of gdl? GDL should be a requirement of the package(s). I'd vote for a simple Recommends:, to cater for those who want to use the packages in some other way (e.g., in conjunction with proprietary IDL). Again: priority should be the use with GDL -- and only packages that work with GDL can go into Debian (main); everything else would have to go into contrib. And can be moved to main as GDL's feature coverage catches up. Yet one could argue, given GDL's goal of compatibility with IDL, that any unsupported feature is to be treated as a bug (usually in GDL) rather than as an argument for relegating the package to contrib. Should a test suite for a package in main have to be in contrib just because some tests are still failing? -- To UNSUBSCRIBE, email to debian-astro-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140704135019.ga11...@hanuman.astro.su.se -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753620: [gnudatalanguage-devel] Fwd: Re: Bug#753620: wishlist: idl/gdl-written software
On 07/04/2014 03:25 PM, Sylwester Arabas wrote: - how to make these packages usable for IDL / PV-WAVE users? Since IDL is non-free, I would consider this not as a primary goal. I would concentrate on GDL. I wonder what Sywester means by making useable... - should idlastro be splitted into multiple subpackages? I would split it, if the different parts are somehow usable independently. Also, not all packages may be usable under GDL (yet), right? Those are tons of IDL script files. I doubt we can tell if a particular script will fail or not, since it depends on how it is used and the history. I mean, a script that makes nice plots may pass for double precision data, and fail on integer data, a tool using the cursor may crash only when the user clicks where nobodoy ever would have thought clicking possible, etc... Another point is that this idlastro --- which by the way, is the same as astrolib, no? is a bunch of not-so-well-if-any maintained files, do we want to support (read: inherit the problems of) them? My suggestion: we make a small installer-like script that will start at the first use of GDL, that ask for downloading idlastro+coyotelib+mpfit directly from their respective sites (see http://idlastro.gsfc.nasa.gov/). May be do the same for gsshsg data, as well. No need of handling that at debian level. best Gilles attachment: gilles_duvert.vcf
Bug#753620: Fwd: Re: Fwd: Re: [gnudatalanguage-devel] Fwd: Re: Bug#753620: wishlist: idl/gdl-written software
Original Message Subject: Re: Fwd: Re: [gnudatalanguage-devel] Fwd: Re: Bug#753620: wishlist: idl/gdl-written software Resent-Date: Fri, 4 Jul 2014 15:56:44 + (UTC) Resent-From: debian-as...@lists.debian.org Date: Fri, 4 Jul 2014 17:46:16 +0200 From: Sergio Gelato sergio.gel...@astro.su.se To: debian-as...@lists.debian.org * Gilles Duvert [2014-07-04 16:57:53 +0200]: Those are tons of IDL script files. I doubt we can tell if a particular script will fail or not, since it depends on how it is used and the history. I mean, a script that makes nice plots may pass for double precision data, and fail on integer data, a tool using the cursor may crash only when the user clicks where nobodoy ever would have thought clicking possible, etc... I'd call such failures bugs, either in GDL or in the scripts. I think Ole was referring to scripts that are incompatible with GDL by design (i.e., because they rely on some feature of proprietary IDL that won't/can't be implemented in GDL). -- To UNSUBSCRIBE, email to debian-astro-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140704154616.gb11...@hanuman.astro.su.se -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753620: Fwd: Re: Bug#753620: wishlist: idl/gdl-written software
Original Message Subject: Re: Bug#753620: wishlist: idl/gdl-written software Resent-Date: Fri, 4 Jul 2014 16:20:44 + (UTC) Resent-From: debian-as...@lists.debian.org Date: Fri, 04 Jul 2014 18:20:27 +0200 From: debian-de...@liska.ath.cx (Оlе Ѕtrеісhеr) Reply-To: Ole Streicher deb...@liska.ath.cx To: debian-as...@lists.debian.org Sergio Gelato sergio.gel...@astro.su.se writes: * Оlе Ѕtrеісhеr [2014-07-04 14:45:14 +0200]: Sylwester Arabas sara...@igf.fuw.edu.pl writes: - should idlastro become a dependency of gdl? GDL should be a requirement of the package(s). I'd vote for a simple Recommends:, to cater for those who want to use the packages in some other way (e.g., in conjunction with proprietary IDL). In a Debian world, these packages only work with GDL, so GDL is required (and not just recommended). I worry a bit that otherwise GDL is just used as an excuse to ship packages that require non-free software in main. If these packages work with GDL: why should one use IDL then? And if they don't: why should we put them into Debian? Again: priority should be the use with GDL -- and only packages that work with GDL can go into Debian (main); everything else would have to go into contrib. And can be moved to main as GDL's feature coverage catches up. Sure. Yet one could argue, given GDL's goal of compatibility with IDL, that any unsupported feature is to be treated as a bug (usually in GDL) rather than as an argument for relegating the package to contrib. Should a test suite for a package in main have to be in contrib just because some tests are still failing? If a package is unusable with GDL, or so buggy that it is not worth using it without IDL, I would think that it has an RC bug, so it should not make its way into Debian -- independently whether its the packages or GDLs fault. Why not first fix the problem in GDL, and then include the package in Debian? Best Ole -- To UNSUBSCRIBE, email to debian-astro-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8761jdxfhw@our.domain.is.not.set -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753620: Fwd: Re: Fwd: Re: [gnudatalanguage-devel] Fwd: Re: Bug#753620: wishlist: idl/gdl-written software
Original Message Subject: Re: Fwd: Re: [gnudatalanguage-devel] Fwd: Re: Bug#753620: wishlist: idl/gdl-written software Resent-Date: Fri, 4 Jul 2014 16:28:13 + (UTC) Resent-From: debian-as...@lists.debian.org Date: Fri, 04 Jul 2014 18:27:55 +0200 From: debian-de...@liska.ath.cx (Оlе Ѕtrеісhеr) Reply-To: Ole Streicher deb...@liska.ath.cx To: debian-as...@lists.debian.org Sergio Gelato sergio.gel...@astro.su.se writes: * Gilles Duvert [2014-07-04 16:57:53 +0200]: Those are tons of IDL script files. I doubt we can tell if a particular script will fail or not, since it depends on how it is used and the history. I mean, a script that makes nice plots may pass for double precision data, and fail on integer data, a tool using the cursor may crash only when the user clicks where nobodoy ever would have thought clicking possible, etc... I'd call such failures bugs, either in GDL or in the scripts. I think Ole was referring to scripts that are incompatible with GDL by design (i.e., because they rely on some feature of proprietary IDL that won't/can't be implemented in GDL). No: I am against including anything that does not work with GDL. It is the same as we may have Wine which is designed to be compatible to MS Windows, but we would not include (DFSG-Free) Windows programs that fail to run under Wine just because that is Wines fault. I really think: If a script doesn't work with GDL, fix GDL first and then include it in Debian. I also worry a bit about the lack of maintenance of the scripts: if they are unmaintained, we should not take them (without feeling responsible for maintenance ourself). This includes fixing of if a user clicks somwhere unusual, the program crashes. I am a bit afraiud that we don't find someone who will take this. Best Ole -- To UNSUBSCRIBE, email to debian-astro-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871tu1xf5g@our.domain.is.not.set -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753620: wishlist: idl/gdl-written software
Hi All, Thanks for all the comments! On 04/07/14 14:45, Оlе Ѕtrеісhеr wrote: - where to place the IDL/GDL-written software in the system Since they are not machine specific, maybe a good place would be /usr/share/gdl-packages/ ? For the record, we have already /usr/share/gnudatalanguage/ There, under a lib subdirectory, reside the GDL-written .pro files that constitute part of the GDL routine library. We could then place other stuff in: /usr/share/gnudatalanguage/idlastro /usr/share/gnudatalanguage/cmsvlib /usr/share/gnudatalanguage/tex2idl /usr/share/gnudatalanguage/mpfit /usr/share/gnudatalanguage/coyote ... But on the other hand, these packages are in fact not related with GDL. Yet, doing it this way would make it easy to expose everything to GDL in one recursive path specification. - how to name these packages? use gdl- as prefix? However, this sounds ugly for the whole package: gdl-idlastro. There is one historic identifier as a candidate for prefix, i.e. idl-pvwave that is part of the comp.lang.idl-pvwave newsgroup name that dates back to 1995. - should idlastro be splitted into multiple subpackages? I would split it, if the different parts are somehow usable independently. Also, not all packages may be usable under GDL (yet), right? I doubt anyone knows a comprehensive answer to this question (but I'm not an astronomer, and I have never used idlastro/astronlib/astron/...). Can you give an overview what of idlastro works with GDL and what not? How complete is GDL compared to IDL? ditto. That really depends on what you use in IDL. For some people GDL has more features than IDL (let's say they only do file-format conversion with GDL, and they get a bonus with gettext path completion at the GDL prompt); for others GDL lacks some functionality but is the only viable option e.g. if they need 1000 instances of IDL-code running at the same time, what is simply out-of-question with IDL per-process licensing fees. for others it is simply fairly functional; for others it is still basically useless (e.g. if they only use IDL for widget-based map plotting); for others it will never be of any use (e.g. if they rely on .sav-format binaries with pre-compiled IDL code). I know of real-world examples for all of the cases listed above. - what other IDL/GDL-written software is of interest? Let me answer myself: CMSVLIB (http://www.physics.wisc.edu/~craigm/idl/cmsave.html) This one enables GDL to read IDL's .sav files (only data, not program code). On 04/07/14 16:57, Gilles DUVERT wrote: - how to make these packages usable for IDL / PV-WAVE users? Since IDL is non-free, I would consider this not as a primary goal. I would concentrate on GDL. I wonder what Sywester means by making useable... I posed this question quite abstractly, but in fact I don't have a very good example. Some thoughts: not mixing the library files with GDL .pro files, keeping any workarounds separately... - nothing really specific. My suggestion: we make a small installer-like script that will start at the first use of GDL, that ask for downloading idlastro+coyotelib+mpfit directly from their respective sites (see http://idlastro.gsfc.nasa.gov/). May be do the same for gsshsg data, as well. No need of handling that at debian level. What about updates? Why not to benefit from the packaging-system dependency database? Mirrors, package reviews, bug trackers - it all works and was designed right for this purpose. You mentioned gshhs - apparently, just yesterday, their FTP directory structure has changed. This would make such script not functional. There would be no automated mechanism to inform us that such thing does not work. A gshhs package would not be affected. Again, thanks for all the comments. Best, Sylwester -- http://www.igf.fuw.edu.pl/~slayoo/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753620: wishlist: idl/gdl-written software
Package: gnudatalanguage Severity: wishlist Dear All, As a follow-up from a recent discussion at the GDL workshop in Paris, I'd like to ask for any possibilities of shipping idl/gdl-written software in Debian. A flagship example is the NASA Astronomy Library written in IDL but released as free and open source software under the BSD-2 license, see: http://idlastro.gsfc.nasa.gov/ Could it (or a subset of its routines) be packaged in Debian? I guess that a lot of GDL users do expect the FITS i/o functionality out-of-the-box - having idlastro package as a dependency would allow it. Other IDL/GDL-written candidates for packaging would include: - MPFIT (actually a dependency of idlastro) http://www.physics.wisc.edu/~craigm/idl/fitting.html - Coyote library (also a dependency of idlastro) http://www.idlcoyote.com/documents/programs.php - TeX2IDL http://physics.mnstate.edu/craig/textoidl/ To sum up, pending support from Debian-Astro (I'm not an astronomer) I suggest extending the GDL package wishlist with at least idlastro-fitsio package. Comments welcome! Thanks, Sylwester -- http://www.igf.fuw.edu.pl/~slayoo/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753620: wishlist: idl/gdl-written software
Hi Sylwester, Sylwester Arabas wrote: Package: gnudatalanguage While the gnudatalanguage package is their main dependency, this is actually nothing we can fix in the gnudatalanguage Debian package itself. Bascially for each software you listed, there should be an RFP (need to be filed against the pseudo-package wnpp, neither without package attribution nor attributed to the gnudatalanguage package). I've already reassigned the GSHHS stuff to the wnpp pseudo-package. I can reassign and clone this bug report for each of these programs, but you will likely need to add some more details (licenses, etc.) afterwards to make the proper RFPs. Alternatively you can write new RFP bug reports (against the wnpp pseudo package) on your own and I'll close this one afterwards. If you are on Debian you can use the command reportbug wnpp to get assisted filing of the RFP bug reports. (Not sure if that works on Ubuntu, too.) (Please tell me which variant you prefer.) Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
