plplot-devel

[Plplot-devel] PLplot Debian package

[Ole S. <deb...@li...>]

Hi,

I am a member of the Debian Astro and Debian Science teams.

As you may know, PLplot has a Debian package that was also shipped with
the latest Debian release [1]. However, the package is outdated and not
properly maintained anymore, and so our MIA team decided to "orphan" the
package [2], which means that it needs a new maintainer.

Since PLplot is a dependency of a number of astronomy packages, I
decided to take over the maintenance of PLplot, and to put it under
Debian Science team maintenance. This basically means that the Debian
specific files are going to be maintained on the Debian infrastructure
<https://anonscm.debian.org/cgit/debian-science/packages/plplot.git>
instead of being part of the original tarball.

The reason is that we want to have an easy way to change the
Debian files if needed. For example, in preparation of the last Debian
release, we already needed to apply some changes, which are now not
reflected in the original PLplot git repository.

What I already did with PLplot is to change the Debian packaging
structure (git branches, patches) to use the "git-buildpackage" way of
building Debian packages, and to update to the latest PLplot version
(5.12.0). The next step is to simplify the structure of the Debian
specific files and to update them for the latest tools that help to
build debian packages, and to fix the Debian specific bugs that popped
up in the last years.

My first question is now if there is a volunteer to help or even take
over the maintenance of the package. The volunteer should join the
Debian Science team for the packaging. If someone wants to take over, we
will help if there are any problems with the packaging. If you want to
help, please contact me; by directly by e-mail, or via our mailing list
<deb...@li...>.

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?

If you have other comments on the Debian packaging, I would be also very
glad to hear from you.

Best regards

Ole

[1] https://tracker.debian.org/pkg/plplot
[2] https://bugs.debian.org/867049
[3] https://www.debian.org/social_contract#guidelines
[4] https://lists.debian.org/debian-legal/2008/10/msg00002.html

Re: [Plplot-devel] PLplot Debian package

[Alan W. I. <ir...@be...>]

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
<https://github.com/sakov?tab=overview&from=2017-05-01&to=2017-05-31&utf8=%E2%9C%93>)

Apparently there is licensing text for the full modern versions of nn
and csa at <https://github.com/sakov/nn-c/blob/master/nn/LICENSE> and
<https://github.com/sakov/csa-c/blob/master/csa/LICENSE>. 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 +0000  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 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
    <https://github.com/sakov/csa-c/blob/master/csa/LICENSE> (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
__________________________
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
__________________________

Re: [Plplot-devel] PLplot Debian package

[Alan W. I. <ir...@be...>]

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

[...]
<https://github.com/sakov/csa-c/blob/master/csa/LICENSE>
[...]

> 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
<https://www.freebsd.org/internal/software-license.html> 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
>   <https://github.com/sakov/csa-c/blob/master/csa/LICENSE> (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
__________________________

Re: [Plplot-devel] PLplot Debian package

[Ole S. <deb...@li...>]

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 <https://github.com/sakov/nn-c/blob/master/nn/LICENSE>
> and <https://github.com/sakov/csa-c/blob/master/csa/LICENSE>. 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: <pav...@gm...>. 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

Re: [Plplot-devel] PLplot Debian package

[Alan W. I. <ir...@be...>]

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 <https://github.com/sakov/nn-c/blob/master/nn/LICENSE>
>> and <https://github.com/sakov/csa-c/blob/master/csa/LICENSE>. 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: <pav...@gm...>. 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 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!

OK. Thanks very much for confirming the modern csa license is
DSFG-compliant and for finding Pavel's modern e-mail address.

I will follow up soon by contacting Pavel at the gmail address you
found above with a CC to you, and we will see what he says.

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
__________________________

Re: [Plplot-devel] PLplot Debian package

[Alan W. I. <ir...@be...>]

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
__________________________

Re: [Plplot-devel] PLplot Debian package

[Ole S. <deb...@li...>]

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
  deb...@li...
  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

Re: [Plplot-devel] PLplot Debian package

[Alan W. I. <ir...@be...>]

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
__________________________

Re: [Plplot-devel] PLplot Debian package

[Ole S. <deb...@li...>]

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

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

[Alan W. I. <ir...@be...>]

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 users of this package never tried the
toggle_plplot_use command either (or gave up on it when it immediately
errored out as above).

Anyhow, Ole, if you can replicate the above tests (both without and
with the patch) using octave-4, then I suspect your decision will be
to drop this patch entirely.

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
__________________________

Re: [Plplot-devel] PLplot Debian package

[Alan W. I. <ir...@be...>]

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
__________________________

Re: [Plplot-devel] PLplot Debian package

[Ole S. <deb...@li...>]

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

Re: [Plplot-devel] PLplot Debian package

[Alan W. I. <ir...@be...>]

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 -- works
-- Check for working Phobos
-- Check for working Phobos -- works
-- Check for working Tango
-- Check for working Tango -- unavailable

So phobos (rather than tango) is the right library in general on Debian.  Furthermore,

irwin@raven> locate gphobos2
/usr/lib/gcc/x86_64-linux-gnu/4.9/libgphobos2.a
irwin@raven> dpkg --search /usr/lib/gcc/x86_64-linux-gnu/4.9/libgphobos2.a
libphobos-4.9-dev: /usr/lib/gcc/x86_64-linux-gnu/4.9/libgphobos2.a

However, from
<https://packages.debian.org/stretch/amd64/libgphobos-6-dev/filelist>
the name of the library has been changed to
/usr/lib/gcc/x86_64-linux-gnu/6/libgphobos.so (or
/usr/lib/gcc/x86_64-linux-gnu/6/libgphobos.a)

Finally,

software@raven> find cmake/modules/language_support/cmake/ -type f |xargs grep phobos
cmake/modules/language_support/cmake/CMakeDInformation.cmake:           SET(DSTDLIB_FLAGS "-L${D_PATH}/lib -ltango -lphobos")
cmake/modules/language_support/cmake/CMakeDInformation.cmake:           SET(DSTDLIB_FLAGS "-lgphobos2")
cmake/modules/language_support/cmake/CMakeDInformation.cmake:           SET(DSTDLIB_FLAGS "-L${D_PATH}/lib -lphobos")
cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:  CMAKE_FLAGS "-DLINK_LIBRARIES=${D_PATH}/lib/libphobos2.a"
cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:  #CMAKE_FLAGS "-DLINK_LIBRARIES=gphobos"
cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:  CMAKE_FLAGS "-DLINK_LIBRARIES=gphobos2"
cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:  CMAKE_FLAGS "-DLINK_LIBRARIES=${D_PATH}/lib/libphobos.a"
cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:  CMAKE_FLAGS "-DLINK_LIBRARIES=${D_PATH}/lib/libtango.a;${D_PATH}/lib/libphobos.a"
cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:# if both tango and phobos are selected try to choose which one is available

So I am virtually positive the issue is in our CMake D language
support logic (i.e., in one or both of the above files), and it also
appears those files have already gone through some changes between the
library name of gphobos and gphobos2.  But probably that was for an
earlier generation of a phobos library name change so that logic
likely needs changing for the latest generation of a phobos library
name change as well.  However, I am tied up with other PLplot release
issues at the moment, and have no way to quickly test phobos library
name changes so if you were willing to look further in those files and
come up with a patch that works for you, I would be happy to accept
that patch.

>
> 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?

I don't have access to octave4 so I am not sure. "git blame"
tells me that warning was initially put in coincident with the following
commit message:

commit 8cd0971dd17177d8baedcc03acdb5e1c6230167d
Author: Alan W. Irwin <ai...@us...>
Date:   Wed Jul 8 13:21:37 2015 -0700

     Build system: Implement WARNING message for the Octave-4 case

     Note that the WARNING message warns the users of potential build
     errors but does not actually disable Octave in case someone wants to
     experimentally try Octave-4 once the swig fix for Octave-4 #include
     issues becomes available.

So it appears to me the original problem was caused by some swig
issues (our octave binding is generated using swig), and my guess is
that swig issue has likely been fixed in the two years since.

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.

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
dependency version issues that remain.  So I plan to do that
after the release of 5.13.0.  But any help you can supply for
more modern Debian versions than the one I am using now
would be quite helpful.

By the way, if you are interested in the history of the Debian
packaging of PLplot from 2003 to 2014, then you should take a look at

git log --name-status -- debian

results.

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
__________________________

Re: [Plplot-devel] PLplot Debian package

[Ole S. <deb...@li...>]

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/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.

> 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 dependency version issues that remain. So I plan to do that 
> after the release of 5.13.0. But any help you can supply for more
> modern Debian versions than the one I am using now would be quite
> helpful.

What I would recommend here is "schroot", which is a Debian package. It allows you to test multiple versions of the OS at the same; for example Stretch (or the Debian testing) on a Debian Jessie machine. The home dir keeps mounted, and so one can easily switch between different Debian versions quickly, and you don't destroy the main setup for a test.

> By the way, if you are interested in the history of the Debian
> packaging of PLplot from 2003 to 2014, then you should take a look at
> 
> git log --name-status -- debian
> 
> results.

Thank you! I will have a look.

Best regards

Ole

Re: [Plplot-devel] PLplot Debian package

[Alan W. I. <ir...@be...>]

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&, 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 <https://github.com/swig/swig/issues/847>
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 for
yourself) that swig-3.0.12 does fix the above issue, then you should
talk to the Debian packagers for swig to see how they want to address
this swig issue.

@Orion:

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

>
>> 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 dependency version issues that remain. So I plan to do that
>> after the release of 5.13.0. But any help you can supply for more
>> modern Debian versions than the one I am using now would be quite
>> helpful.
>

> What I would recommend here is "schroot", which is a Debian package.
It allows you to test multiple versions of the OS at the same; for
example Stretch (or the Debian testing) on a Debian Jessie machine.
The home dir keeps mounted, and so one can easily switch between
different Debian versions quickly, and you don't destroy the main
setup for a test.

Thanks for that suggestion which looks like exactly what I need.

@Orion and Ole:

My principal focus right now is to get 5.13.0 out the door in a timely
manner. So my current plan is to make that release, install Debian
Stretch from scratch, and deal with any new PLplot "library version"
issues that show up for that distribution.  Then install schroot and
deal with any additional such issues that show up on Testing and
Unstable.  But help from you guys with such testing and fixing of
PLplot against the latest versions of libraries would be much
appreciated as well.  And we have not yet done a code freeze for
5.13.0 so your patches for fixes to get into 5.13.0 would be welcome.

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
__________________________

Re: [Plplot-devel] PLplot Debian package

[Orion P. <or...@co...>]

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 <https://github.com/swig/swig/issues/847>
> 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 for
> yourself) that swig-3.0.12 does fix the above issue, then you should
> talk to the Debian packagers for swig to see how they want to address
> this swig issue.
> 
> @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

Octave tests are run at the end an errors ignored.

-- 
Orion Poplawski
Technical Manager                          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                   http://www.nwra.com

Re: [Plplot-devel] PLplot Debian package

[Alan W. I. <ir...@be...>]

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
<http://octave.1599824.n4.nabble.com/utf8-does-not-appear-to-work-for-function-documentation-strings-generated-with-texinfo-td4663317.html>)
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
__________________________

Re: [Plplot-devel] PLplot Debian package

[Ole S. <deb...@li...>]

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

[Plplot-devel] PLplot Debian package -- spelling issues fixed

[Alan W. I. <ir...@be...>]

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

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

The "directories" spelling issues had already been independently
corrected in this release cycle, but the "continuous" and "argument"
spelling issues were splattered across 22 files in our source tree!
So thanks for reporting those, and I have now fixed them in an
automated way (commit 5fc9108).

I have now reviewed all your posts, and I believe this e-mail
concludes my specific response to topics you have raised so far
(although the C exception handling work that spun off from our
discussion obviously continues due to Phil's efforts to finish his
proof of concept with some input and lots of well-deserved
encouragement from me).

I have very much appreciated your input and help (especially with the
nn and csa licensing issues), and I look forward to more input from
you once you have had a chance to package the git master branch of
PLplot that is soon going to lead to the release of 5.13.0.

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
__________________________

Re: [Plplot-devel] PLplot Debian package

[Alan W. I. <ir...@be...>]

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
__________________________

Re: [Plplot-devel] PLplot Debian package

[Ole S. <deb...@li...>]

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

Re: [Plplot-devel] PLplot Debian package

[Alan W. I. <ir...@be...>]

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

> 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.

To explain further we have three major configuration modes

1. The default (-DBUILD_SHARED_LIBS=ON, -DENABLE_DYNDRIVERS=ON) which
builds shared PLplot libraries and dynamically
loaded (separate) devices.

2. Shared PLplot libraries (-DBUILD_SHARED_LIBS=ON) and nondynamic devices (-DENABLE_DYNDRIVERS=OFF)
where the C and C++ device driver
code is made part of our core library.

3. Static PLplot libraries (-DBUILD_SHARED_LIBS=OFF which forces
-DENABLE_DYNDRIVERS=OFF)

We continue to maintain 2 for historical reasons, and probably the
same could be said of 3.  But from your question I assume you are using
1.

Furthermore, your question inspired me to look at the
-DDEFAULT_NO_DEVICES=ON case (for 1 although case 2 and 3 should give
similar results).  For that case (and assuming you do not specify any
devices to build which is what I did) the library and examples build
without issues, but they are useless.  Here is an example of what
happens:

software@raven> examples/c/x00c

*** PLPLOT ERROR, IMMEDIATE EXIT ***
No device drivers found - please check the environment variable
PLPLOT_DRV_DIR
Program aborted

So it is your call as packager, but you should be aware for case 1 if
you do split up the library and dynamic devices, and a user installs
only the library, that library will be essentially useless.

Of course, I just noticed the above warning message when no device
drivers are installed is pretty useless/misleading, but I don't want
to deal with that now so if someone wants to send a patch....

> 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?

There is
<http://www.linux-magazin.de/ausgabe/1996/12/Plplot/plplot.html>, 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.

Another slightly better possibility (but still bad) is users have
created the Wikipedia article https://en.wikipedia.org/wiki/PLplot,
but that is already quite dated (e.g., it refers to our subversion
repository!) and is seriously incomplete, i.e., it simply copies a
small subset of an extremely dated copy of the plplot.sourceforge.net website
which I assume your metadata already refers to as our home page.

So I think the best answer to your question in the short term is no,
you should leave the "preferred citation" metadata empty.

But in the long-term I think it is important for one of the PLplot
developers or heavily interested users to write up PLplot in an
accessible article simply to give some much-needed publicity to this
quite useful plotting solution.  Any volunteers?

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
__________________________

Re: [Plplot-devel] PLplot Debian package

[Alan W. I. <ir...@be...>]

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

> There is
> <http://www.linux-magazin.de/ausgabe/1996/12/Plplot/plplot.html>, 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,
<http://web.archive.org/web/20020624083333/www.linux-magazin.de/ausgabe/1996/12/Plplot/plplot.html>.
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
__________________________

Re: [Plplot-devel] PLplot Debian package

[Ole S. <deb...@li...>]

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

Re: [Plplot-devel] PLplot Debian package

[Alan W. I. <ir...@be...>]

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
__________________________