astronomy October 2013

astronomy@lists.fedoraproject.org

2 participants
2 discussions

python-astropy
by Sergio Pascual 02 Oct '13

02 Oct '13

Hi all, just to inform you that I have submited a review request of astropy https://bugzilla.redhat.com/show_bug.cgi?id=1014738 All comments and reviews are welcome Regards, Sergio

1 0

Re: [fedora-astronomy] [dev] Packaging starlink for linux distributions
by Joseph Wang 30 Sep '13

30 Sep '13

The replacement for PGPlot is an interface layer called PG2PLplot that takes the PGPlot API and converts it into calls to PLPlot which is a LGPL, unencumbered system. The problem with conversion is that it doesn't convert everything, but getting it to convert everything and fixing the interface problems should about a month. In addition to the copyright issues, there seems to have been no development on PGPlot in over a decade, whereas PLplot is being actively developed. Since Starlink has a special exception for PGplot, I'll work first on getting it packaged and I should be able to do it before the 10/15 version freeze deadline for Mageia. Once its packaged I'll work next on getting it working with the PG2PLplot interface layer. On Mon, Sep 30, 2013 at 6:21 PM, AL13N <alien(a)rmail.be> wrote: > > Just a heads up about packaging starlink for linux distributions. I've > > gotten starlink to compile and link using native libraries on Mageia, and > > I've uploaded my changes to https://github.com/joequant/starlink. I > > haven't actually try to run any of the new executables, but one step at a > > time. > > > > The big bottleneck that I have right now is PGPLOT. The trouble is that > > PGPLOT seems to have a non-distro friendly non-commercial license that > > would prevent it from being added to linux distros. > > > > Fortunately, there is a drop in replacement for PGPLOT called pg2plplot > > which links against PLplot which unlike PGPLOT is actively being > > developed. Unfortunately there are a lot of additional calls that > haven't > > been implemented yet, > > > > this PGPLOT is a dependency? > > how unfriendly is this PGLPOT? non-redistributable? > > and how bad is this pg2plot? if it forks from PGPLOT, doesn't it have the > same license issues? > > and if it's a drop-in replacement, how can it have unimplemented calls? > >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

astronomy October 2013