Re: [Plplot-devel] PLplot Debian package (debian patch for toggle_plplot_use.m)

[Alan W. Irwin]

Hi Ole:

On 2017-07-13 09:12+0200 Ole Streicher wrote:


Then, there is one remaining patch that may be interesting for you
(attached). I have however no idea about it; it is a remnant from the
past. Could you give me a hint whether it is needed for me or for you?



From some digging with "git log" and "git blame" in the debian

subdirectory of the PLplot repository, it appears
debian/patches/proper-path-handling.diff has different metadata
and name _but the same contents_ as the patch you are concerned about.
And debian/changelog has the following comment about that
patch:

* Adjust the upstream code for working with Octave 3.6.1, by adding the
  following patches:

  + debian/patches/replace-deprecated-split.diff
  + debian/patches/proper-path-handling.diff
  + debian/patches/fix-boolean-operators.diff

Later on with the commit message "Remove obsolete debian patches." the
first and third of those three patches were removed, but the
proper-path-handling.diff patch remained as of commit
68e499b4ca^ (where commit 68e499b4ca was where I recently removed
the whole debian subdirectory).

The patch is for the bindings/octave/PLplot/toggle_plplot_use.m file
which we do not currently test in any automated way. That octave
function is apparently designed to toggle between native plot
functionality and the equivalent PLplot functionality.  Furthermore,
that function is currently designed to be used only for the installed
case where our various octave support files (*.m files) are installed in a
more rational set of directories than the build-tree case.

So I tested toggle_plplot_use.m as follows:

make -j4 install

# N.B. All tests below need to build nothing further and just refer to what
# is installed by the above make command.

# octavedir holds the appropriate octave installation directories for PLplot
# which will be used in a later octave run.  Note the installation
# prefix here, /home/software/plplot/installcmake/, will have to be
# changed if anyone else wants to follow this test procedure.

export \
octavedir="/home/software/plplot/installcmake/share/plplot_octave":"/home/software/plplot/installcmake/share/plplot_octave"/support:"/home/software/plplot/installcmake/share/octave/site/m"/PLplot:"/home/software/plplot/installcmake/lib/octave":/home/software/plplot/installcmake/share/plplot5.12.0/examples/octave/

# Test that non-PLplot (native) plotting works fine for octave.

irwin@raven> octave -f -q
octave:1> x=-pi:0.1:pi;
octave:2> plot(x,sin(x));
octave:3> exit

# Test that PLplot plotting works fine for octave (this is where we
use octavedir) with plplot_stub (which changes the plot environment to
the PLplot variant).

irwin@raven> octave -f -q
octave:1> warning("off","Octave:shadowed-function");
octave:2> addpath(getenv("octavedir"));
octave:3> plplot_stub;
octave:4> x=-pi:0.1:pi;
octave:5> plot(x,sin(x));
octave:6> exit

# Test of toggle_plplot_use to switch from PLplot to native plotting
irwin@raven> octave -f -q
octave:1> warning("off","Octave:shadowed-function");
octave:2> addpath(getenv("octavedir"));
octave:3> plplot_stub;
octave:4> toggle_plplot_use;
Use PLplot: on
octave:5> x=-pi:0.1:pi;
octave:6> plot(x,sin(x));
octave:7> toggle_plplot_use;
Use PLplot: off
octave:8> plot(x,sin(x));
octave:9> exit
error: closefig: A(I): index out of bounds; value 3 out of bound 1
error: called from:
error:   /home/software/plplot/installcmake/share/plplot_octave/closefig.m at 
line 40, column 5
error:   /home/software/plplot/installcmake/share/plplot_octave/closeallfig.m 
at line 33, column 7

The above worked (i.e., generated both a PLplot type of plot
originally but followed with a native type of plot at the end, but
generated those error messages on exit.  Furthermore,
other attempts to use toggle_plplot_use for switching back and
forth between the two plot enviroments either did not work or
ended up as segfaults.

I then modified that installed version of toggle_plplot_use.m
using the latest version (commit 68e499b4ca^) of 
debian/patches/proper-path-handling.diff
that exists in our repository.  That patch applied cleanly, i.e.,

software@raven> patch -p1 /home/software/plplot/installcmake/share/octave/site/m/PLplot/toggle_plplot_use.m /tmp/proper-path-handling.diff 
patching file /home/software/plplot/installcmake/share/octave/site/m/PLplot/toggle_plplot_use.m


but makes the corresponding octave toggle_plplot_use command unusable, i.e.,

octave:6> toggle_plplot_use;
error: sq_string cannot be indexed with {
error: evaluating argument list element number 1
error: called from:
error: 
/home/software/plplot/installcmake/share/octave/site/m/PLplot/toggle_plplot_use.m
 at line 42, column 3

So from these tests, unpatched toggle_plplot_use.m is problematic (it
sort of works with Octave-3.8.2, but there are issues including segfaults 
sometimes), but
patching it with this patch makes it not work at all!  So I suspect
when Rafael implemented this patch years ago, he never tested it, and
I guess the Debian 

Re: [Plplot-devel] PLplot Debian package

[Alan W. Irwin]

Hi Ole:

On 2017-07-19 15:15+0200 Ole Streicher wrote:


All is fine for me after disabling [1] the mentioned tests. Since UTF-8
is one one case, I will keep the octave bindings in the 5.13.0 packaging.


I am glad that you were able to prove that non-ascii UTF-8 in the user
strings is the only Octave-4.2 issue left.


One more small issue, which I reported some time ago to the Debian
package [2]: The pkgconfig file specifies the need to link to libshp:

$ pkg-config --libs plplotd
-lplplotd -lltdl -lm -lshp -lcsirocsa -lcsironn -lqhull -lqsastime

but in fact, -lshp is not needed. It would be nice if this linker flag
could be removed here.
(and, just to be sure: at that time, the library was called
"libplotlibd", while now it is "libplotlib" without the "d", right?)


Yes on the change in library name without the suffix d.

However, the above pkg-config results are dated and come from an
era when we didn't properly distinguish the shared and static
cases.  But the above results which included -lshp were correct
for the static case although incomplete in other ways.

Here are the pkg-config results from plplot git master branch (for a
non-standard install location):

software@raven> pkg-config --libs plplot
-L/home/software/plplot/installcmake/lib -lplplot

software@raven> pkg-config --libs --static plplot
-L/home/software/plplot/installcmake/lib -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/4.9 -lplplot -lltdl -lm -lshp
-lfreetype -lcsirocsa -lcsironn -lqhull -lqsastime -lstdc++ -lm -lc

So for the static case we do (correctly) add in -lshp (and the rest)
because the plplot core library depends on all those libraries (for
example -lshp allows PLplot to handle maps (e.g., for standard example 19)
using the shapelib capabilities) so they have to be specifically
mentioned when linking to the static version of libplplot.

So there should be no bug for you to deal with in this modern case
(and for 5.12.0, I believe).

The only case where -lshp should not be included in the static link
line is if the PLplot build system does not find libshp.so (or
libshp.a) in which case the PLplot core library map capability falls
back to a much less useful and therefore deprecated map format.
So that is a situation to be avoided by installing libshp whenever
possible.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Ole Streicher]

Hi Alan,

On 18.07.2017 20:45, Alan W. Irwin wrote:
> To Ole and Orion:
> 
> Here is what I suggest you do to decide whether you want to package
> the Octave bindings of PLplot until this UTF-8 error is fixed.  The
> octave examples that are run in our tests are controlled by
> plplot_test/test_octave.sh.in. That file has the "p" list and
> standard list of examples.
> There is nothing but ascii strings in the "p" examples
> so leave that list as is.  Of the standard examples, 18, 24, 26,
> and 33 are the ones that use UTF-8 strings (I derived that list by running
> 
> grep utf-8 examples/python/x??.py
> 
> .)
> 
> So to create a pure ascii test of Octave you should exclude
> those examples from the standard examples list.
> 
> Then build the test_diff_psc target, and make your packaging decision
> based on the results of that pure-ascii test of octave.
> 
> By the way, please run that test verbosely, e.g.,
> 
> make VERBOSE=1 test_diff_psc >& test_diff_psc.out
> 
> and if that output file still shows some errors for the pure ascii
> Octave test case, please send it to me.

All is fine for me after disabling [1] the mentioned tests. Since UTF-8
is one one case, I will keep the octave bindings in the 5.13.0 packaging.

One more small issue, which I reported some time ago to the Debian
package [2]: The pkgconfig file specifies the need to link to libshp:

$ pkg-config --libs plplotd
-lplplotd -lltdl -lm -lshp -lcsirocsa -lcsironn -lqhull -lqsastime

but in fact, -lshp is not needed. It would be nice if this linker flag
could be removed here.
(and, just to be sure: at that time, the library was called
"libplotlibd", while now it is "libplotlib" without the "d", right?)

Best regards

Ole

[1]
https://anonscm.debian.org/cgit/debian-science/packages/plplot.git/tree/debian/patches/Disable-octave-UTF-8-tests.patch
[2] https://bugs.debian.org/787818

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Alan W. Irwin]

On 2017-07-18 15:32+0200 Ole Streicher wrote:


On 14.07.2017 22:48, Orion Poplawski wrote:

Well, it compiles.  There are longstanding test failures though:

5: *** PLPLOT ERROR, ABORTING OPERATION ***
5: UTF-8 string is malformed: ???M??, aborting operation


Just for the records, and to keep you informed about the Debian
packaging process: I fixed swig in Debian (by backporting the same patch
as Fedora), and could finally compile the octave bindings. Then I run
into the same UTF-8 errors as Orion (with octave 4.2.1 and plplot 5.12.0).

I am still unsure if this is minor (special case only), or if I should
disable octave-plplot for 5.13 (but tend to keep it).


To Ole and Orion:

Here is what I suggest you do to decide whether you want to package
the Octave bindings of PLplot until this UTF-8 error is fixed.  The
octave examples that are run in our tests are controlled by
plplot_test/test_octave.sh.in. That file has the "p" list and
standard list of examples.
There is nothing but ascii strings in the "p" examples
so leave that list as is.  Of the standard examples, 18, 24, 26,
and 33 are the ones that use UTF-8 strings (I derived that list by running

grep utf-8 examples/python/x??.py

.)

So to create a pure ascii test of Octave you should exclude
those examples from the standard examples list.

Then build the test_diff_psc target, and make your packaging decision
based on the results of that pure-ascii test of octave.

By the way, please run that test verbosely, e.g.,

make VERBOSE=1 test_diff_psc >& test_diff_psc.out

and if that output file still shows some errors for the pure ascii
Octave test case, please send it to me.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Ole Streicher]

On 14.07.2017 22:48, Orion Poplawski wrote:
> Well, it compiles.  There are longstanding test failures though:
> 
> 5: *** PLPLOT ERROR, ABORTING OPERATION ***
> 5: UTF-8 string is malformed: �M��, aborting operation

Just for the records, and to keep you informed about the Debian
packaging process: I fixed swig in Debian (by backporting the same patch
as Fedora), and could finally compile the octave bindings. Then I run
into the same UTF-8 errors as Orion (with octave 4.2.1 and plplot 5.12.0).

I am still unsure if this is minor (special case only), or if I should
disable octave-plplot for 5.13 (but tend to keep it).

Best regards

Ole

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Alan W. Irwin]

On 2017-07-15 14:43-0700 Alan W. Irwin wrote:


There is
, but
that link is now broken, the linux magazin search function cannot find
it, I never understood that article because it was written in German,
and by now it would be completely out of date in any case. Note to
self: remove that link from our documentation.


P.S.

Actually, if you can read German and are curious about what PLplot
looked like two (!) decades ago, I did find that broken link on the internet 
archive,
.
But that is clearly not our preferred citation, and I do plan to remove
that broken link from our documentation and not replace it with
the internet archive version.

Alan

__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Ole Streicher]

Hi Alan,

On 15.07.2017 20:37, Alan W. Irwin wrote:
> Sometimes our bindings libraries have the same core name (e.g.,
> wxwidgets, qt) as the device driver, but bindings libraries and
> device drivers are completely different and there is no chance of a
> nameclash between them.  So there should be no issue of concern in
> this case.

My question here is mainly if they should reside in the same package. As
far as I understand you, they should go into separate packages.

Another small question: We maintain some metadata about our packages,
and one of the entries is the preferred citation. Is there a paper that
should serve as a reference for plplot?

For the other points, I will just wait until 5.13.0 is out.

Best regards

Ole

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Alan W. Irwin]

On 2017-07-15 11:49+0200 Ole Streicher wrote:

Hi Ole:

I feel that most of the issues you have brought up such as
installation directories and spelling are ones we should be able to
address fairly quickly so expect to see some commits from me over
the next few days dealing with them.  So my responses here will
be limited to the topics you have brought up which I feel are not issues or 
which
are issues that will take a long time to resolve.


Then, the qt and wxwidgets drivers contain *two* shared libraries: one
in the drivers subdir, and one in the normal libdir:

$INSTALL_LIBDIR/libplplotwxwidgets.so.1.2.0
$INSTALL_LIBDIR/plplot5.12.0/drivers/wxwidgets.so



What is the reason for that? Has the libplplotwxwidgets.so.1.2.0 an
independent use case (and should therefore separate into its own
package)? Or could they in principle both combined into wxwidgets.so?


We name our libraries with a "lib" prefix and install them in our
designated library location.  By default (although other options are
possible) we implement our device drivers as dynamically loaded shared
objects (dll's) whose names do not have the lib prefix, and which are
installed in our designated drivers location.  So the examples above
are our wxwidgets binding library (which allows a wxwidgets GUI to
call PLplot routines) and our wxwidgets device driver (which allows
our C library to dynamically load that device which uses a wxwidgets
GUI to display our plots).  Sometimes our bindings libraries have the
same core name (e.g., wxwidgets, qt) as the device driver, but
bindings libraries and device drivers are completely different and
there is no chance of a nameclash between them.  So there should be no
issue of concern in this case.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Ole Streicher]

Hi Alan,

thanks for the answers, and thanks for connecting with Orion. I hope to
keep everything together here.

> Yes.  We have long since implemented a CMake-based build system for
> the installed example source code + installed binary libraries that
> implements the test_diff_psc, etc., targets that also are implemented
> for our core build system.  See examples/CMakeLists.txt for details.

OK, thanks I will have a look. Should be solvable, and will help to get
early warnings in case of incompatibilities.

> Anyhow, if you and Ole don't want to mess with this issue, I will take it
> up myself once I get my hands on octave-4 (i.e., post-release).  And
> hopefully this time I will find octave developers who are more aware
> of the power of UTF-8.

I will contact the swig maintainers and probably open a bug for them.
For the UTF-8 problem, I would just wait for you (and re-enable the
ocave package when it is solved).

With the Debian specific nitpicker ("lintian"), I found a few more small
issues: First (again) tcl/tk: Currently, the shared libs are in
$INSTALL_LIBDIR, while for Debian they should be in the arch dependent
tcltk path (/usr/lib/tcltk/$ARCH/plplot5.12.0/). And for simplicity, the
tcl files themself could also live there. Is there a way to configure
that? (@orion: how is this done in Fedora?)

Then, the qt and wxwidgets drivers contain *two* shared libraries: one
in the drivers subdir, and one in the normal libdir:

$INSTALL_LIBDIR/libplplotwxwidgets.so.1.2.0
$INSTALL_LIBDIR/plplot5.12.0/drivers/wxwidgets.so

What is the reason for that? Has the libplplotwxwidgets.so.1.2.0 an
independent use case (and should therefore separate into its own
package)? Or could they in principle both combined into wxwidgets.so?

Another (probable longer-standing) topic would be the use of exit() in
several libraries in case of error. That usually has the disadvantage
that it makes debugging more complicated, since you don't get a
stacktrace; abort() may be the better solution here. Any thoughts about
that?

And, finally, there are a few spelling errors found by lintian:
 directorys -> directories
 Continous -> Continuous
 argment -> argument
 argments -> arguments

Best regards

Ole

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Alan W. Irwin]

On 2017-07-14 14:48-0600 Orion Poplawski wrote:


@Orion:

Can you confirm that PLplot now works well with Octave-4.2 on Fedora
or is there additional issues to deal with?


Well, it compiles.  There are longstanding test failures though:

5:
5: *** PLPLOT ERROR, ABORTING OPERATION ***
5: UTF-8 string is malformed: ???M??, aborting operation

Check out a build log from:
https://apps.fedoraproject.org/koschei/package/plplot?collection=f27


Hi Orion:

Just before sending this off, I looked in detail at the above error
log but could not find the above error there.  So it may be solved,
it may be obscured by another issue now, or I may have misread
the above build log.

Anyhow, the rest of this post assumes the above error is still an
issue for octave-4.2.x, but it would be interesting for Ole to confirm
that as well (once he gets the swig issue sorted out).

The PLplot core library assumes all user-supplied strings are encoded
in UTF-8, and then it converts those to UCS4 for internal use.  And
the above error message is a result of that converter tool detecting
some user input that is not encoded in UTF-8.

That process works fine for octave-3.8.2.  UTF-8 user strings are
passed from octave to our dynamically loaded octave binding shared
object which then passes those on to our own PLplot
library to do the conversion to UCS4 with success.

So I suspect that a backwards incompatibility was introduced into
octave-4.x.y (or perhaps octave-4.2.x if 4.0.x worked fine for Fedora)
so that it molests UTF-8 strings in some way so that whenever these
molested strings are transmitted to our octave binding shared
object/core PLplot library that latter library detects an invalid
UTF-8 input string (as above).

I have had troubles before with octave and UTF-8 (see
)
That issue was (eventually) satisfactorily resolved, but I was
surprised at how little Octave developers knew about UTF-8 back then
(3 years ago). For example, some of them felt you must use wide
characters to store UTF-8 which is completely incorrect; it is
designed to be stored as a string of 8-bit bytes.  Also, their
documentation translation teams seemed unaware of UTF-8.  For example,
they felt they had to be dependent on wide characters for their
translation of their English documentation strings into other human
languages.

Anyhow, if you and Ole don't want to mess with this issue, I will take it
up myself once I get my hands on octave-4 (i.e., post-release).  And
hopefully this time I will find octave developers who are more aware
of the power of UTF-8.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Orion Poplawski]

Hello all

On 07/14/2017 02:18 PM, Alan W. Irwin wrote:
> To Ole and Orion:
> 
> @Ole:
> 
> To introduce Orion, he maintains the packaging of PLplot for Fedora,
> and he has been a big help to us when dealing with "library
> version" issues.
> 
> @Orion:
> 
> To introduce Ole, he is the new maintainer of PLplot packaging for
> Debian, and it appears he has been running into some "library
> version" issues (at least in the Octave-4.2 case) that you have also
> run into in the past.
> 
> On 2017-07-14 09:40+0200 Ole Streicher wrote:
> 
>> On 13.07.2017 21:49, Alan W. Irwin wrote:
>> [Octave bindings]
>>> So I suggest you try enabling it, and then follow up with a build of
>>> the test_diff_psc target. If that test works, i.e., it produces the
>>> good octave results above, then I think you can be pretty confident
>>> all is well with an octave4 binding of PLplot.
>>
>> I tried, but then I got many error about op_lshift:
>>
>> [ 10%] Building CXX object
>> bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o
>> cd /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave &&
>> /usr/bin/c++   -DPLPLOT_HAVE_CONFIG_H -Dplplot_octave_EXPORTS
>> -I/build/plplot-5.12.0+dfsg/include -I/build/plplot-5.12.0+dfsg/lib/qsastime
>> -I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu
>> -I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/include
>> -I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave
>> -I/usr/include/hdf5/serial -I/usr/include/octave-4.2.1
>> -I/usr/include/octave-4.2.1/octave
>> -I/build/plplot-5.12.0+dfsg/bindings/swig-support  -g -O2
>> -fdebug-prefix-map=/build/plplot-5.12.0+dfsg=. -fstack-protector-strong
>> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
>> -I/usr/include/octave-4.2.1/octave/.. -I/usr/include/octave-4.2.1/octave
>> -I/usr/include/hdf5/serial -Wdate-time -D_FORTIFY_SOURCE=2
>> -I/usr/include/octave-4.2.1/octave/.. -I/usr/include/octave-4.2.1/octave
>> -I/usr/include/hdf5/serial -fPIC   -o
>> CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c
>> /build/plplot-5.1!
> 2.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx
>> In file included from
>> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:181:0:
>>
>> /usr/include/octave-4.2.1/octave/toplev.h:28:2: warning: #warning "toplev.h
>> has been deprecated; use interpreter.h instead" [-Wcpp]
>> #warning "toplev.h has been deprecated; use interpreter.h instead"
>>  ^~~
>> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
>> In function 'void SWIG_InstallBinaryOps(int, int)':
>> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2099:46:
>> error: 'op_lshift' is not a member of 'octave_value'
>> if
>> (!octave_value_typeinfo::lookup_binary_op(octave_value::op_##name,tid1,tid2))
>>  \
>>  ^
>> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2147:5:
>> note: in expansion of macro 'swigreg_binary_op'
>> swigreg_binary_op(lshift);
>> ^
>>
>> and a number of warnings about octave_value::octave_value:
>>
>> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
>> In function 'octave_value_list _wrap_plGetCursor(const octave_value_list&,
>> int)':
>> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:10770:60:
>> warning: 'octave_value::octave_value(const charMatrix&, bool, char)' is
>> deprecated: note: IS_STRING argument is ignored [-Wdeprecated-declarations]
>> retval4( 0 ) = octave_value( charMatrix( 80, 1 ), true );
>>^
>> In file included from /usr/include/octave-4.2.1/octave/ovl.h:36:0,
>> from /usr/include/octave-4.2.1/octave/ov-fcn.h:33,
>> from /usr/include/octave-4.2.1/octave/ov-builtin.h:30,
>> from /usr/include/octave-4.2.1/octave/defun-int.h:30,
>> from /usr/include/octave-4.2.1/octave/defun-dld.h:32,
>> from /usr/include/octave-4.2.1/octave/oct.h:32,
>> from
>> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:173:
>>
>> /usr/include/octave-4.2.1/octave/ov.h:244:3: note: declared here
>>   octave_value (const charMatrix& chm, bool is_string, char type = '\'');
>>   ^~~~
>>
>> So it does not build in the moment.
> 
> It appears Orion has been here before you.  A google search for the
> above error message found 
> where it appears this Octave-4.2 issue was fixed in swig-3.0.12.  In
> Fedora's case at that time, it appears they did not have access to
> swig-3.0.12 so they backported the fix to the version of swig they had
> at that time.  So if you can confirm (by building swig-3.0.12 

Re: [Plplot-devel] PLplot Debian package

[Alan W. Irwin]

To Ole and Orion:

@Ole:

To introduce Orion, he maintains the packaging of PLplot for Fedora,
and he has been a big help to us when dealing with "library
version" issues.

@Orion:

To introduce Ole, he is the new maintainer of PLplot packaging for
Debian, and it appears he has been running into some "library
version" issues (at least in the Octave-4.2 case) that you have also
run into in the past.

On 2017-07-14 09:40+0200 Ole Streicher wrote:


On 13.07.2017 21:49, Alan W. Irwin wrote:

Excellent. However, too be sure all is well with Ada and the other
computer languages we support you should build the test_diff_psc
target (which compares the plot output files for our psc device for
all our standard examples for all our supported languages (including
octave) with the equivalent C results.





I will do that. One question/proposal: is it possible to have the

tests also done on the _installed_ libraries? The rationale behind
this is that I would like to enable Continuous Integration Tests

https://ci.debian.net/doc
for the package. This would give a warning whenever an incompatible

upload for a language binding (or wherever) happens, not only when a
(occasional) rebuild is done. This early warning would also enable to
early discuss the problems with the maintainers of the other packages.

@Ole:

Yes.  We have long since implemented a CMake-based build system for
the installed example source code + installed binary libraries that
implements the test_diff_psc, etc., targets that also are implemented
for our core build system.  See examples/CMakeLists.txt for details.

One caveat is I have not yet implemented ctest for that install-tree
build system, but that is on my agenda since ctest is an excellent
way to do continuous integration testing.

Note that many years ago (even long before we ever looked at CMake) we
implemented a GNU-make + pkg-config "traditional" build system for the
installed examples, and we continue to maintain that in a minimal way.
However, for continuous integration testing you will likely want to
focus on our CMake-based build system for the installed examples.



[Octave bindings]

So I suggest you try enabling it, and then follow up with a build of
the test_diff_psc target. If that test works, i.e., it produces the
good octave results above, then I think you can be pretty confident
all is well with an octave4 binding of PLplot.


I tried, but then I got many error about op_lshift:

[ 10%] Building CXX object 
bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o
cd /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave && 
/usr/bin/c++   -DPLPLOT_HAVE_CONFIG_H -Dplplot_octave_EXPORTS 
-I/build/plplot-5.12.0+dfsg/include -I/build/plplot-5.12.0+dfsg/lib/qsastime 
-I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu 
-I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/include 
-I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave 
-I/usr/include/hdf5/serial -I/usr/include/octave-4.2.1 
-I/usr/include/octave-4.2.1/octave -I/build/plplot-5.12.0+dfsg/bindings/swig-support  
-g -O2 -fdebug-prefix-map=/build/plplot-5.12.0+dfsg=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/octave-4.2.1/octave/.. -I/usr/include/octave-4.2.1/octave 
-I/usr/include/hdf5/serial -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/octave-4.2.1/octave/.. -I/usr/include/octave-4.2.1/octave 
-I/usr/include/hdf5/serial -fPIC   -o 
CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c 
/build/plplot-5.12.0+dfsg/

obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx

In file included from 
/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:181:0:
/usr/include/octave-4.2.1/octave/toplev.h:28:2: warning: #warning "toplev.h has been 
deprecated; use interpreter.h instead" [-Wcpp]
#warning "toplev.h has been deprecated; use interpreter.h instead"
 ^~~
/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
 In function 'void SWIG_InstallBinaryOps(int, int)':
/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2099:46:
 error: 'op_lshift' is not a member of 'octave_value'
if 
(!octave_value_typeinfo::lookup_binary_op(octave_value::op_##name,tid1,tid2)) \
 ^
/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2147:5:
 note: in expansion of macro 'swigreg_binary_op'
swigreg_binary_op(lshift);
^

and a number of warnings about octave_value::octave_value:

/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
 In function 'octave_value_list _wrap_plGetCursor(const octave_value_list&, 
int)':
/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:10770:60:
 warning: 'octave_value::octave_value(const charMatrix&, 

Re: [Plplot-devel] PLplot Debian package

[Ole Streicher]

On 13.07.2017 21:49, Alan W. Irwin wrote:
> Excellent. However, too be sure all is well with Ada and the other 
> computer languages we support you should build the test_diff_psc 
> target (which compares the plot output files for our psc device for 
> all our standard examples for all our supported languages (including 
> octave) with the equivalent C results.

I will do that. One question/proposal: is it possible to have the tests also 
done on the _installed_ libraries? The rationale behind this is that I would 
like to enable Continuous Integration Tests

https://ci.debian.net/doc

for the package. This would give a warning whenever an incompatible upload for 
a language binding (or wherever) happens, not only when a (occasional) rebuild 
is done. This early warning would also enable to early discuss the problems 
with the maintainers of the other packages.

[Octave bindings]
> So I suggest you try enabling it, and then follow up with a build of
> the test_diff_psc target. If that test works, i.e., it produces the
> good octave results above, then I think you can be pretty confident
> all is well with an octave4 binding of PLplot.

I tried, but then I got many error about op_lshift:

[ 10%] Building CXX object 
bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o
cd /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave && 
/usr/bin/c++   -DPLPLOT_HAVE_CONFIG_H -Dplplot_octave_EXPORTS 
-I/build/plplot-5.12.0+dfsg/include -I/build/plplot-5.12.0+dfsg/lib/qsastime 
-I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu 
-I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/include 
-I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave 
-I/usr/include/hdf5/serial -I/usr/include/octave-4.2.1 
-I/usr/include/octave-4.2.1/octave 
-I/build/plplot-5.12.0+dfsg/bindings/swig-support  -g -O2 
-fdebug-prefix-map=/build/plplot-5.12.0+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/octave-4.2.1/octave/.. -I/usr/include/octave-4.2.1/octave 
-I/usr/include/hdf5/serial -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/octave-4.2.1/octave/.. -I/usr/include/octave-4.2.1/octave 
-I/usr/include/hdf5/serial -fPIC   -o 
CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c 
/build/plplot-5.12.0+dfsg/ob
 j-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx
In file included from 
/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:181:0:
/usr/include/octave-4.2.1/octave/toplev.h:28:2: warning: #warning "toplev.h has 
been deprecated; use interpreter.h instead" [-Wcpp]
 #warning "toplev.h has been deprecated; use interpreter.h instead"
  ^~~
/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
 In function 'void SWIG_InstallBinaryOps(int, int)':
/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2099:46:
 error: 'op_lshift' is not a member of 'octave_value'
 if 
(!octave_value_typeinfo::lookup_binary_op(octave_value::op_##name,tid1,tid2)) \
  ^
/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2147:5:
 note: in expansion of macro 'swigreg_binary_op'
 swigreg_binary_op(lshift);
 ^

and a number of warnings about octave_value::octave_value:

/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
 In function 'octave_value_list _wrap_plGetCursor(const octave_value_list&, 
int)':
/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:10770:60:
 warning: 'octave_value::octave_value(const charMatrix&, bool, char)' is 
deprecated: note: IS_STRING argument is ignored [-Wdeprecated-declarations]
 retval4( 0 ) = octave_value( charMatrix( 80, 1 ), true );
^
In file included from /usr/include/octave-4.2.1/octave/ovl.h:36:0,
 from /usr/include/octave-4.2.1/octave/ov-fcn.h:33,
 from /usr/include/octave-4.2.1/octave/ov-builtin.h:30,
 from /usr/include/octave-4.2.1/octave/defun-int.h:30,
 from /usr/include/octave-4.2.1/octave/defun-dld.h:32,
 from /usr/include/octave-4.2.1/octave/oct.h:32,
 from 
/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:173:
/usr/include/octave-4.2.1/octave/ov.h:244:3: note: declared here
   octave_value (const charMatrix& chm, bool is_string, char type = '\'');
   ^~~~

So it does not build in the moment.

> The fundamental problem, of course, (since I am the person with 
> probably the most PLplot development knowledge) is I need to upgrade 
> from Debian Jessie to Debian Stretch (now that the latter has been 
> released as the stable version of Debian), and then tackle such
> PLplot 

Re: [Plplot-devel] PLplot Debian package

[Alan W. Irwin]

On 2017-07-13 16:02+0200 Ole Streicher wrote:


Dear Alan,

On 13.07.2017 11:27, Alan W. Irwin wrote:

I already have a few small questions. First language bindings: Currently
the following are disabled:

ENABLE_ada: OFF
ENABLE_d:   OFF
ENABLE_octave:  OFF
ENABLE_pdl: OFF
ENABLE_pyqt5:   OFF

Would it be useful to (re-)enable any of them? And what would I need to
add as dependencies then?


You should _not_ disable the first 3 which are well supported (at least
on Linux).  On Debian Jessie, ENABLE_ada, ENABLE_d, and ENABLE_octave
require the gnat, gdc, and liboctave-dev packages be installed.


ADA seems to work fine, I enabled it.


Excellent.  However, too be sure all is well with Ada and the other
computer languages we support you should build the test_diff_psc target (which 
compares
the plot output files for our psc device for all our standard examples
for all our supported languages (including octave) with the equivalent
C results.

The current summary of those comparisons on Debian Jessie are as follows:

Comparison test using psc device

c++
  Missing examples:
  Differing graphical output  :
  Missing stdout  :
  Differing stdout: 
fortran

  Missing examples:
  Differing graphical output  :
  Missing stdout  :
  Differing stdout: 
java

  Missing examples:
  Differing graphical output  :
  Missing stdout  :
  Differing stdout: 
octave

  Missing examples:
  Differing graphical output  :
  Missing stdout  :
  Differing stdout: 
python

  Missing examples:
  Differing graphical output  :
  Missing stdout  :
  Differing stdout: 
tcl

  Missing examples:
  Differing graphical output  :
  Missing stdout  :
  Differing stdout: 
adastandard

  Missing examples:
  Differing graphical output  :
  Missing stdout  :
  Differing stdout: 
adatraditional

  Missing examples:
  Differing graphical output  :
  Missing stdout  :
  Differing stdout: 
ocaml

  Missing examples:
  Differing graphical output  :  16 19 33
  Missing stdout  :
  Differing stdout: 
lua

  Missing examples:
  Differing graphical output  :
  Missing stdout  :
  Differing stdout: 
d

  Missing examples:
  Differing graphical output  :
  Missing stdout  :
  Differing stdout: 
WARNING: Some graphical or stdout results were different

[100%] Built target test_diff_psc

So PLplot language support is almost perfect for this Debian Jessie platform
except for some long-standing issues with our ocaml support.  So
these results are what we should aspire to on Debian Stretch as well.



With D, I also have to install libgphobos-dev (right?),
but even then I get the following error (on newer Debian systems, f.e. Stretch,
or unstable):

-- D Compiler Install Prefix (use D_PATH env var to override): /usr
-- Check for working D compiler: /usr/bin/gdc
-- Check for working D compiler: /usr/bin/gdc -- works
-- Check for working Phobos
-- Check for working Phobos -- unavailable
-- Check for working Tango
-- Check for working Tango -- unavailable
CMake Error at 
cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:175 (MESSAGE):
 Phobos is required for this project, but it is not available!
Call Stack (most recent call first):
 cmake/modules/d.cmake:53 (enable_language)
 cmake/modules/plplot.cmake:493 (include)
 CMakeLists.txt:135 (include)
[...]
Determining if Phobos works failed with the following output:
Change Dir: /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_b0e79/fast"
make[2]: Entering directory 
'/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_b0e79.dir/build.make 
CMakeFiles/cmTC_b0e79.dir/build
make[3]: Entering directory 
'/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
Building D object CMakeFiles/cmTC_b0e79.dir/testDCompiler.o
/usr/bin/gdc   -fversion=Phobos-o CMakeFiles/cmTC_b0e79.dir/testDCompiler.o 
-c /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/CM
Linking D executable cmTC_b0e79
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_b0e79.dir/link.txt 
--verbose=1
/usr/bin/gdc   -fversion=Phobos   -Wl,-z,relro -Wl,--as-needed  
CMakeFiles/cmTC_b0e79.dir/testDCompiler.o -o cmTC_b0e79  -lgphobos2
/usr/bin/ld: cannot find -lgphobos2
collect2: error: ld returned 1 exit status
[...]



Do you have an idea what to do here? Did I use the wrong library?


Here is what I get on my Debian Jessie platform:

-- D Compiler Install Prefix (use D_PATH env var to override): /usr
-- Check for working D compiler: /usr/bin/gdc
-- Check for working D compiler: /usr/bin/gdc 

Re: [Plplot-devel] PLplot Debian package

[Ole Streicher]

Dear Alan,

On 13.07.2017 11:27, Alan W. Irwin wrote:
>> I already have a few small questions. First language bindings: Currently
>> the following are disabled:
>>
>> ENABLE_ada: OFF
>> ENABLE_d:   OFF
>> ENABLE_octave:  OFF
>> ENABLE_pdl: OFF
>> ENABLE_pyqt5:   OFF
>>
>> Would it be useful to (re-)enable any of them? And what would I need to
>> add as dependencies then?
> 
> You should _not_ disable the first 3 which are well supported (at least
> on Linux).  On Debian Jessie, ENABLE_ada, ENABLE_d, and ENABLE_octave
> require the gnat, gdc, and liboctave-dev packages be installed.

ADA seems to work fine, I enabled it. With D, I also have to install 
libgphobos-dev (right?),
but even then I get the following error (on newer Debian systems, f.e. Stretch,
or unstable):

-- D Compiler Install Prefix (use D_PATH env var to override): /usr
-- Check for working D compiler: /usr/bin/gdc
-- Check for working D compiler: /usr/bin/gdc -- works
-- Check for working Phobos
-- Check for working Phobos -- unavailable
-- Check for working Tango
-- Check for working Tango -- unavailable
CMake Error at 
cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:175 (MESSAGE):
  Phobos is required for this project, but it is not available!
Call Stack (most recent call first):
  cmake/modules/d.cmake:53 (enable_language)
  cmake/modules/plplot.cmake:493 (include)
  CMakeLists.txt:135 (include)
[...]
Determining if Phobos works failed with the following output:
Change Dir: /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_b0e79/fast"
make[2]: Entering directory 
'/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_b0e79.dir/build.make 
CMakeFiles/cmTC_b0e79.dir/build
make[3]: Entering directory 
'/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
Building D object CMakeFiles/cmTC_b0e79.dir/testDCompiler.o
/usr/bin/gdc   -fversion=Phobos-o CMakeFiles/cmTC_b0e79.dir/testDCompiler.o 
-c /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/CM
Linking D executable cmTC_b0e79
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_b0e79.dir/link.txt 
--verbose=1
/usr/bin/gdc   -fversion=Phobos   -Wl,-z,relro -Wl,--as-needed  
CMakeFiles/cmTC_b0e79.dir/testDCompiler.o -o cmTC_b0e79  -lgphobos2 
/usr/bin/ld: cannot find -lgphobos2
collect2: error: ld returned 1 exit status
[...]

Do you have an idea what to do here? Did I use the wrong library?

I also tried octave, but get the warning

-- OCTAVE = /usr/bin/octave
-- MKOCTFILE = /usr/bin/mkoctfile
-- OCTAVE_CONFIG = /usr/bin/octave-config
-- OCTAVE_VERSION = 4.2.1
-- WARNING: Octave-4 has been found which is likely to lead to build errors for 
PLplot.
-- WARNING: Disabling Octave binding. If you want to use that component of 
PLplot you
   should try installing Octave-3 (which works well with PLplot) or else try the
   experimental cmake option -DTRY_OCTAVE4=ON

Debian (Stretch and later) has Octave 4 only, so I am a bit worried enabling 
this
for the moment. Would you recommend it despite of the warning?

Best regards

Ole

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Alan W. Irwin]

On 2017-07-13 09:12+0200 Ole Streicher wrote:


Dear Alan and all,

On 12.07.2017 23:28, Alan W. Irwin wrote:

On 2017-07-12 11:00+0200 Ole Streicher wrote:
I think we are done here with all the current Debian-related topics,
but there will likely be more such topics we need to discuss in the
near future as you continue the process of updating the Debian
packaging for PLplot, and as we move closer to the release of 5.13.0.


I already have a few small questions. First language bindings: Currently
the following are disabled:

ENABLE_ada: OFF
ENABLE_d:   OFF
ENABLE_octave:  OFF
ENABLE_pdl: OFF
ENABLE_pyqt5:   OFF

Would it be useful to (re-)enable any of them? And what would I need to
add as dependencies then?


You should _not_ disable the first 3 which are well supported (at least
on Linux).  On Debian Jessie, ENABLE_ada, ENABLE_d, and ENABLE_octave
require the gnat, gdc, and liboctave-dev packages be installed.

I recommend you leave ENABLE_pdl OFF.

We have no Perl/PDL bindings.  So all that happens when ENABLE_pdl is
ON is some Perl/PDL/PLplot examples that some of us wrote many years
ago are tested against a modified version of an externally developed
Perl/PDL/PLplot package where you must follow a rather complex
procedure (see examples/perl/README.perldemos) to set up that test.
So it is a lot of work to help test an external project so I am leaning toward
donating examples/perl to that external project and removing
it and the ENABLE_pdl option completely from PLplot.

With regard to ENABLE_pyqt4 and ENABLE_pyqt5, PLplot is either built
against Qt4 or Qt5, but not both.  Qt4 is currently preferred because it is a
higher quality library than Qt5 (in terms of, e.g., character
alignment bugs).  In the Qt4 case (which you have above), ENABLE_pyqt4
and ENABLE_pyqt5 are set to ON/OFF, while in the latter case they are
set to OFF/ON.  But you will never have both ON at once.



Then, there is one remaining patch that may be interesting for you
(attached). I have however no idea about it; it is a remnant from the
past. Could you give me a hint whether it is needed for me or for you?

Another point is that TCLDIR is currently set to
/usr/share/plplot5.12.0/tcl, which is not in the package path for
Tcl/Tk. Is there a way to change this to something like
/usr/share/tcltk/plplot5.12.0 [1] with a cmake option so that I
don't need a patch here?

[1] https://pkg-tcltk.alioth.debian.org/tcltk-policy.html/ch-tcltk.html#s-paths



I will take a look at these last two issues (likely this weekend).

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Ole Streicher]

Dear Alan and all,

On 12.07.2017 23:28, Alan W. Irwin wrote:
> On 2017-07-12 11:00+0200 Ole Streicher wrote:
> I think we are done here with all the current Debian-related topics,
> but there will likely be more such topics we need to discuss in the
> near future as you continue the process of updating the Debian
> packaging for PLplot, and as we move closer to the release of 5.13.0.

I already have a few small questions. First language bindings: Currently
the following are disabled:

ENABLE_ada: OFF
ENABLE_d:   OFF
ENABLE_octave:  OFF
ENABLE_pdl: OFF
ENABLE_pyqt5:   OFF

Would it be useful to (re-)enable any of them? And what would I need to
add as dependencies then?

Then, there is one remaining patch that may be interesting for you
(attached). I have however no idea about it; it is a remnant from the
past. Could you give me a hint whether it is needed for me or for you?

Another point is that TCLDIR is currently set to
/usr/share/plplot5.12.0/tcl, which is not in the package path for
Tcl/Tk. Is there a way to change this to something like
/usr/share/tcltk/plplot5.12.0 [1] with a cmake option so that I
don't need a patch here?

[1] https://pkg-tcltk.alioth.debian.org/tcltk-policy.html/ch-tcltk.html#s-paths

Best regards

Ole

From: Rafael Laboissiere 
Date: Mon, 3 Jul 2017 22:39:22 +0200
Subject: Proper use of the rmpath function

---
 bindings/octave/PLplot/toggle_plplot_use.m | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/bindings/octave/PLplot/toggle_plplot_use.m b/bindings/octave/PLplot/toggle_plplot_use.m
index f59c0d4..c4fa644 100644
--- a/bindings/octave/PLplot/toggle_plplot_use.m
+++ b/bindings/octave/PLplot/toggle_plplot_use.m
@@ -39,9 +39,7 @@ endif
 use_plplot_path = plplot_octave_path;
 plplot_path_to_remove = char(strsplit(genpath(use_plplot_path),pathsep));
 for use_plplot_i=1:size(plplot_path_to_remove)(1)
-  if (findstr(path,deblank(plplot_path_to_remove(use_plplot_i,:))) > 0)
-rmpath(deblank(plplot_path_to_remove(use_plplot_i,:)));
-  endif
+  rmpath(plplot_path_to_remove{use_plplot_i});
 endfor
 
 if (strcmp (use_plplot_state, "on"))

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Alan W. Irwin]

On 2017-07-12 11:00+0200 Ole Streicher wrote:

[...]

[This is] the collection of information [concerning Debian

packaging] you can somehow compile-in:

[...]

See commit 68e499b which removed the debian subdirectory and
placed the information you supplied in debian_packaging/README.

[...]

Thank you again for the nice and effective cooperation! I am happy that
plplot has such great authors!


You are welcome, and I really appreciated your practical help with the
license evaluation and update process as well.

I think we are done here with all the current Debian-related topics,
but there will likely be more such topics we need to discuss in the
near future as you continue the process of updating the Debian
packaging for PLplot, and as we move closer to the release of 5.13.0.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Ole Streicher]

Dear Alan,

On 12.07.2017 09:05, Alan W. Irwin wrote:
> On 2017-07-11 13:43-0700 Alan W. Irwin wrote:
>> I agree this confusion between upstream and Debian is not ideal.
>> However, Debian packaging is important to us since it does reveal some
>> deficiencies (at least from the Debian point of view) with the
>> upstream version.  And I do have sufficient Debian packaging knowledge
>> that I can interpret a debian subdirectory tree even if I don't have
>> sufficient knowledge to create one on my own.  So I think the best
>> thing to do is to replace everything in our now out-dated debian
>> subdirectory with a README that shows how to get convenient access to
>> the latest debian packaging information that you are working on. So I
>> would appreciate you supplying that information, and once I have that
>> from you, I will make that proposed change.
> 
> I am still waiting for that information from you to help finish
> off this topic between us.

Oh, yes. Sorry. I am not sure what exactly you want here; this is
however the collection of information you can somehow compile-in:

* The users page for the source package is
  https://packages.debian.org/source/unstable/plplot
  with links to all binary packages

* There is a page with developers information about the package:
  https://tracker.debian.org/pkg/plplot

* The development repository is
  https://anonscm.debian.org/cgit/debian-science/packages/plplot.git

* The source code of the released packages can also be found at
  https://sources.debian.net/src/plplot/unstable/

* plplot will be maintained collaboratively by the debian-science
  team, so packaging specific discussion shall go to
  debian-scie...@lists.debian.org
  We are happy about volunteers wanting to help us, send patches or
  join the mainenance team.

* Debian specific bugs shall be files with the "reportbug" tool in the
  Debian bug database

> The PLplot nn and csa library licensing topic:
> 
> See my recent post concerning this issue.  The upshot is this
> licensing problem appears to be completely resolved now thanks
> to your help and Pavel Sakov's kindly (and very quick) cooperation
> with my request for permission to do that licensing update.
> Time for a big celebration for both of us!

Yea!!! That was great! And I thank you very much for your efforts and
collaboration! If only any licensing issues could be solved so nicely!

> The PLplot release topic:
> 
> I should have stated before to you (since it is completely relevant to
> your packaging effort) that I am planning a PLplot-5.13.0 release
> "soon".  A lot of issues (such as the above licensing issue) appear to
> be falling into place pretty rapidly right now so "soon" might
> actually be some time this month, but stay tuned about that.

I already integrated the 5.12.0 sources (see the git repository link
above), but I will wait with a release until 5.13.0 is out, due to the
licensing issue. And I still need to fine-tune everything and to see
which Debian specific patches are still needed and forward them to you
if useful. You have have a look on your own in the debian/patches subdir:

https://anonscm.debian.org/cgit/debian-science/packages/plplot.git/tree/debian/patches

Thank you again for the nice and effective cooperation! I am happy that
plplot has such great authors!

Best regards

Ole


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Alan W. Irwin]

Hi Ole:

Here are my further remarks on a variety of topics relevant to yur
packaging effort.

The upstream versus Debian topic:

On 2017-07-11 13:43-0700 Alan W. Irwin wrote:


I agree this confusion between upstream and Debian is not ideal.
However, Debian packaging is important to us since it does reveal some
deficiencies (at least from the Debian point of view) with the
upstream version.  And I do have sufficient Debian packaging knowledge
that I can interpret a debian subdirectory tree even if I don't have
sufficient knowledge to create one on my own.  So I think the best
thing to do is to replace everything in our now out-dated debian
subdirectory with a README that shows how to get convenient access to
the latest debian packaging information that you are working on. So I
would appreciate you supplying that information, and once I have that
from you, I will make that proposed change.


I am still waiting for that information from you to help finish
off this topic between us.

The PLplot nn and csa library licensing topic:

See my recent post concerning this issue.  The upshot is this
licensing problem appears to be completely resolved now thanks
to your help and Pavel Sakov's kindly (and very quick) cooperation
with my request for permission to do that licensing update.
Time for a big celebration for both of us!

The PLplot release topic:

I should have stated before to you (since it is completely relevant to
your packaging effort) that I am planning a PLplot-5.13.0 release
"soon".  A lot of issues (such as the above licensing issue) appear to
be falling into place pretty rapidly right now so "soon" might
actually be some time this month, but stay tuned about that.

Best wishes,

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Alan W. Irwin]

On 2017-07-11 13:42+0200 Ole Streicher wrote:


Dear Alan,

thank you very much for your quick (and very positive) answer!
Concerning the upstream changes: you could for the moment just drop the
"debian/" subdir. It will be replaced anyway during the packaging
process, and therefore no longer maintained in your git and may be
misleading for others. For any other changes, I need to look through and
will come back when I have proposals.


Hi Ole:

With regard to the above Debian "issue":

I agree this confusion between upstream and Debian is not ideal.
However, Debian packaging is important to us since it does reveal some
deficiencies (at least from the Debian point of view) with the
upstream version.  And I do have sufficient Debian packaging knowledge
that I can interpret a debian subdirectory tree even if I don't have
sufficient knowledge to create one on my own.  So I think the best
thing to do is to replace everything in our now out-dated debian
subdirectory with a README that shows how to get convenient access to
the latest debian packaging information that you are working on. So I
would appreciate you supplying that information, and once I have that
from you, I will make that proposed change.



For the csiro license problem:

On 11.07.2017 12:59, Alan W. Irwin wrote:

Apparently there is licensing text for the full modern versions of
nn and csa at 
and . I am
not a license lawyer, but the latter looks like a simple free
software license to me. If you agree, and, better yet, if you can
identify what free license it is (some form of BSD??), then it is
likely it is license that you will be able to immediately identify as
consistent with Debian's DFSG.


This is a kind-of simplified BSD-3-Clause license, as f.e. this one:

https://spdx.org/licenses/BSD-3-Clause

The difference is mainly that the original second condition is
removed/merged into the first one, and the third is then renumbered to
be the second.


Our e-mails crossed, but it appears we independently arrived at that
same conclusion.




In which case, it should be a simple matter regardless of whatever
agreement he made with Rafael in 2003+ to convince Pavel to license
our stripped version for both nn and csa that we adopted in 2003
under that same free software license.


If PLplot can use the modern versions of the library source (or the
first version from 2009 on github [1]), yes. IMO that would be the
simplest way.


The issue with that solution is Pavel's unstripped version of nn has
consistently used un-free triangle forever and Joao immediately
switched the stripped version to use the free qhull library instead.
But if ever Pavel made the decision to switch from his triangle
dependency to a free library like qhull, then presumably it would be
possible for us to adjust PLplot to use (and presumably distribute)
that modern nn library ourselves under that modified but
DSFG-compliant variant of the 3-clause BSD license currently used for
modern csa.  But in any case I would prefer not to do that work (and
similarly for adjusting us to the full modern csa library) since the
stripped down versions have been fine for our needs all these years.


In sum, I think to deal with this licensing issue, the following 4
steps are needed:

1. Identify the modern full csa licensing from the above text.  In
the following steps I assume you will be able to identify it as a
well-known free software license that is already known to be
compatible with the DFSG.


It is, for sure. However, not a common one (as far as I know).


That is good news that Debian would be happy with that license
assuming we are allowed by Pavel to adopt it.




2. Find a modern e-mail address for Pavel (surely github provides
that in some way, but I cannot find it).


I just cloned the repository and looked into his commits :-) There is
one real E-mail address: . This also f.e. appears
in the README of the enkf-c repository.


Thanks! I should have thought of git as the best tool for getting a
reliable e-mail address.  :-)




3. Ask Pavel to allow us to relicense the stripped version of nn and
csa that we adopted in 2003 [...]



4. Upstream change: Remove the misleading lib/nn/README and
lib/csa/README files and replace those with lib/nn/LICENSE and
lib/csa/LICENSE [...]



If you are willing to deal with the first two of these issues I am
willing to deal with the third and fourth, but if you would also
like to follow through with the third as well (quoting any part of
this e-mail you feel is relevant) that would be even more helpful!
In sum, I am looking forward with your help to finishing the above
steps to remove completely the licensing uncertainty for these two
PLplot libraries.


Would you contact him? This may be even better since I am just coming
from aside (and you know more about the history of the inclusion of his
libraries). If the 

Re: [Plplot-devel] PLplot Debian package

[Alan W. Irwin]

On 2017-07-11 03:59-0700 Alan W. Irwin wrote:

[...]

[...]


1. Identify the modern full csa licensing from the above text.  In the
  following steps I assume you will be able to identify it as a
  well-known free software license that is already known to be
  compatible with the DFSG.


My further google searching has found the above modern csa license
text is likely an older variant of the latest 3-clause BSD license
 where the
variation is fundamentally to merge the first two clauses together so
as not to distinguish between source and binary redistribution.
Because this variant is not an exact official free software license
(as far as I can tell) it presumably makes your job a little harder to
satisfy yourself that it is DFSG compliant, but I remain confident
(because it seems close in spirit to the 3-clause BSD) you will be
able to do that.

Alan



2. Find a modern e-mail address for Pavel (surely github provides that
  in some way, but I cannot find it).

3. Ask Pavel to allow us to relicense the stripped version of nn and
  csa that we adopted in 2003 (and which does not depend on the
  proprietary triangle software due to Joao's further modifications)
  with the free software license you have identified in the first
  step above.  Alternatively, if it turns out the above modern
  licensing text for csa is not DFSG compatible, then ask Pavel
  to relicense our stripped version under the LGPL.  Frankly, I
  would be surprised if he objected to either request, but to
  be clear I prefer the license above (if suitable) for
  our stripped version just to be consistent with the modern
  nn and csa licensing as much as possible (i.e., with
  the triangle note dropped).

4. Upstream change: Remove the misleading lib/nn/README and
  lib/csa/README files and replace those with lib/nn/LICENSE and
  lib/csa/LICENSE which are both consistent with the text in
   (or the
  LGPL if your research shows the above modern license is not DFSG
  compatible).

If you are willing to deal with the first two of these issues I am
willing to deal with the third and fourth, but if you would also like
to follow through with the third as well (quoting any part of this
e-mail you feel is relevant) that would be even more helpful!  In sum,
I am looking forward with your help to finishing the above steps to
remove completely the licensing uncertainty for these two PLplot
libraries.


__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Ole Streicher]

Dear Alan,

thank you very much for your quick (and very positive) answer!
Concerning the upstream changes: you could for the moment just drop the
"debian/" subdir. It will be replaced anyway during the packaging
process, and therefore no longer maintained in your git and may be
misleading for others. For any other changes, I need to look through and
will come back when I have proposals.

For the csiro license problem:

On 11.07.2017 12:59, Alan W. Irwin wrote:
> Apparently there is licensing text for the full modern versions of
> nn and csa at 
> and . I am
> not a license lawyer, but the latter looks like a simple free
> software license to me. If you agree, and, better yet, if you can
> identify what free license it is (some form of BSD??), then it is
> likely it is license that you will be able to immediately identify as
> consistent with Debian's DFSG.

This is a kind-of simplified BSD-3-Clause license, as f.e. this one:

https://spdx.org/licenses/BSD-3-Clause

The difference is mainly that the original second condition is
removed/merged into the first one, and the third is then renumbered to
be the second.

> In which case, it should be a simple matter regardless of whatever
> agreement he made with Rafael in 2003+ to convince Pavel to license
> our stripped version for both nn and csa that we adopted in 2003
> under that same free software license.

If PLplot can use the modern versions of the library source (or the
first version from 2009 on github [1]), yes. IMO that would be the
simplest way.

> One minor complication is that the modern nn license text which is 
> otherwise completely compatible with the modern csa license text has 
> an additional note on the end as follows:
> 
> Note: this software makes use of the Triangle software, which is 
> non-free for commercial use. See the triangle.c and triangle.h files 
> for details.

I would just remove it :-) Formal reason is that the license requires to
keep only the three parts of the original license, and also I would not
take the Note as part of the license at all. And pragmatically, since
you don't use triangle.[ch].

> In sum, I think to deal with this licensing issue, the following 4
> steps are needed:
> 
> 1. Identify the modern full csa licensing from the above text.  In
> the following steps I assume you will be able to identify it as a 
> well-known free software license that is already known to be 
> compatible with the DFSG.

It is, for sure. However, not a common one (as far as I know).

> 2. Find a modern e-mail address for Pavel (surely github provides
> that in some way, but I cannot find it).

I just cloned the repository and looked into his commits :-) There is
one real E-mail address: . This also f.e. appears
in the README of the enkf-c repository.

> 3. Ask Pavel to allow us to relicense the stripped version of nn and 
> csa that we adopted in 2003 [...]

> 4. Upstream change: Remove the misleading lib/nn/README and 
> lib/csa/README files and replace those with lib/nn/LICENSE and 
> lib/csa/LICENSE [...]

> If you are willing to deal with the first two of these issues I am 
> willing to deal with the third and fourth, but if you would also
> like to follow through with the third as well (quoting any part of
> this e-mail you feel is relevant) that would be even more helpful!
> In sum, I am looking forward with your help to finishing the above
> steps to remove completely the licensing uncertainty for these two
> PLplot libraries.

Would you contact him? This may be even better since I am just coming
from aside (and you know more about the history of the inclusion of his
libraries). If the gmail address doest not work, you could even just
open an issue in the nn-c or csa-c library to get in contact.

I am however quite happy that the problems seems to be solvable that easy!

Best regards

Ole

[1]
https://github.com/sakov/nn-c/tree/71a59e6a

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Alan W. Irwin]

Hi Ole:

Thanks for getting in touch with us concerning the Debian packaging of
PLplot. Andrew Ross (who at one time maintained Debian packaging of
PLplot) is our only Debian packaging expert.  But he has been inactive
in PLplot development for a while now so it is likely our help to you
will be limited to making upstream changes to minimize the number of
patches you have to apply and also making upstream changes to
straighten out any licensing uncertainties (see below).

On 2017-07-11 09:43+0200 Ole Streicher wrote:


The other point is already older, but a show-stopper: PLplot uses a few
old libraries from Pavel Sakov (CSIRO Marine Research), in lib/csa and
lib/nn. These libraries have a license that is not free (in the sense of
the Debian Free Software Guidelines [3]), and they are incompatible to
the LGPL of plplot. I already wrote an E-mail to the mail address given
in the README to ask him for a license change, but I am not sure whether
Pavel's address is still valid.

There was already some discussion on Debian mailing lists about that
topic 9 years ago [4], but I couldn't find a (follow-up) discussion on
the plplot-devel mailing list. Was there any discussion, and what is
your opinion about that license?


Your help with solving this licensing uncertainty (which I have not
been too concerned about before due to historical reassurances from
Rafael Laboissiere) would be much appreciated.

When this topic first came up soon after we starting using stripped
versions of Pavel's csa and nn libraries back in 2003 Rafael
Laboissiere (who was a fanatic about free software licensing)
contacted Pavel privately and afterward assured us the licensing issue
was settled (I think by getting Pavel's OK to relicense our stripped
version of his work under the LGPL, but I am by no means sure about
that).  However, after that reassurance Rafael never changed our
lib/nn/README and lib/csa/README files to reflect whatever that 2003+
agreement with Pavel was. Therefore, I agree, the issue is at least
formally still with us. And since then Rafael has completely dropped
out of the Debian world and the free software world (including PLplot)
after supporting both so strongly for so many years.  So Rafael is no
longer a good contact concerning this situation.

Do you know how to extract e-mail contact information from github?  If
so, Pavel is active on github and apparently still working on the full
versions of both nn and csa. (see
)

Apparently there is licensing text for the full modern versions of nn
and csa at  and
. I am not a
license lawyer, but the latter looks like a simple free software
license to me. If you agree, and, better yet, if you can identify what
free license it is (some form of BSD??), then it is likely it is
license that you will be able to immediately identify as consistent
with Debian's DFSG.  In which case, it should be a simple matter
regardless of whatever agreement he made with Rafael in 2003+ to
convince Pavel to license our stripped version for both nn and csa
that we adopted in 2003 under that same free software license.

One minor complication is that the modern nn license text which is
otherwise completely compatible with the modern csa license text has
an additional note on the end as follows:

Note: this software makes use of the Triangle software, which is
non-free for commercial use. See the triangle.c and triangle.h files
for details.

Our own file, lib/nn/README refers to this same "triangle" issue in a different
way.

However, I don't think we have to be concerned about that issue in the
slightest since our stripped version lib/nn contains no triangle.c or
triangle.h and lib/nn/delaunay.c contains the following comment line

// Adapted for use with Qhull instead of "triangle".

which I traced back using git blame --follow to

b583d184 (Joao Cardoso  2003-03-02 02:04:52 +  20)  *  Adapted for use with 
Qhull instead of "triangle"

The associated commit message for b583d184 was

Add a striped version of Pavel Sakov nn library to support Delaunay
linear interpolation and Natural Neighbors interpolation for
plgridata().

Note, although apparently Joao was smart enough to get rid of the
dependence on "triangle", he has long since retired from the free
software world so he is also not a good contact concerning this
situation.

In sum, I think to deal with this licensing issue, the following 4 steps
are needed:

1. Identify the modern full csa licensing from the above text.  In the
   following steps I assume you will be able to identify it as a
   well-known free software license that is already known to be
   compatible with the DFSG.

2. Find a modern e-mail address for Pavel (surely github provides that
   in some way, but I cannot find it).

3. Ask Pavel to allow us to relicense the