plplot-devel

[Plplot-devel] This next release cycle should finish in early 2018

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

The 5.13.0 release has now been completed.  (See my recent post to
plplot-general for links to the details).

I encourage all of you to test the website (I already know of one dead
external link there to Homebrew packaging of PLplot, but I hope none
of you find any many more of those), and test this release tarball by
downloading it, using gpg --verify on it, and building PLplot with it.

And similarly with

git tag --verify plplot-5.13.0 
git checkout plplot-5.13.0

and building and testing that version.

The freeze on pushes to master is now rescinded, i.e., you are strongly
encouraged to push any private topic branches to master that you have
matured to your satisfaction.

I hope to continue the pace of a release every 6 months on average,
but 5.13.0 was 7 months after 5.12.0 so to make up for that I would
like to release in late January 2017, i.e., 5 months from now or a
year after 5.12.0 was released. That deadline is actually pretty soon,
so please start working on whatever interests you with PLplot now to
give the rest of us the maximum time to evaluate your work before the
next release.

Here are some development topics I am aware of that might make
it into the next release.

@Phil: Your private topic branch dealing with a setjmp/longjmp
implementation of C exceptions still needs a small amount of work in
my opinion to mature it (see my last suggestions to you about how to
mature that topic). Can we get this topic going again?

@Jim: I was reminded while writing up your work on the gdi device
driver in README.release, that this is "a first step to a
Unicode-aware driver that uses the GDI+ API (along with the Uniscribe
API to handle Unicode text)."  Are you willing to start that next step?

Arjen:

Your comprehensive tests on MinGW-w64/MSYS2, Cygwin, and MSVC (+ Unix
tools to help with testing) are really important since they are
fundamental to improving our build system for those platforms. 
Nevertheless, because 5.13.0 was late we jointly decided to make the
compromise of putting off some of your planned comprehensive testing
until after 5.13.0 was released.  So now that that post-release time
has arrived what is the next test you have planned here?

For my own part I have a massive ToDo list of all the minor issues
discovered during the last release cycle that I put off fixing until
later. Well "later" has arrived!  Therefore, during this release cycle
I hope to work steadily through at least a substantial fraction of
these issues.

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] This next release cycle should finish in early 2018

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

Hi Alan,

"Alan W. Irwin" <ir...@be...> writes:
> The 5.13.0 release has now been completed.  (See my recent post to
> plplot-general for links to the details).
>
> I encourage all of you to test the website (I already know of one dead
> external link there to Homebrew packaging of PLplot, but I hope none
> of you find any many more of those), and test this release tarball by
> downloading it, using gpg --verify on it, and building PLplot with it.

That is great news! We (in Debian) like to have a verified chain for the
source... I will enable this in my packaging.

I run into the first problem, concerning Python support:

During the cmake run, I get the following:

[...]
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.4", minimum required is "3") 
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.4", minimum required is "2") 
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.13+") 
[...]
-- WARNING: ENABLE_python is OFF so setting ENABLE_pyqt4 to OFF.
[...]
ENABLE_python:          OFF
ENABLE_qt:              ON
ENABLE_pyqt4:           OFF

and consequently the pyqt4 bindings are not created. Explicitly using
-DENABLE_python does not help.

Any idea what to do?

Best regards

Ole

Re: [Plplot-devel] This next release cycle should finish in early 2018

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

On 2017-08-26 11:12+0200 Ole Streicher wrote:

> Hi Alan,
>
> "Alan W. Irwin" <ir...@be...> writes:
>> The 5.13.0 release has now been completed.  (See my recent post to
>> plplot-general for links to the details).
>>
>> I encourage all of you to test the website (I already know of one dead
>> external link there to Homebrew packaging of PLplot, but I hope none
>> of you find any many more of those), and test this release tarball by
>> downloading it, using gpg --verify on it, and building PLplot with it.
>
> That is great news! We (in Debian) like to have a verified chain for the
> source... I will enable this in my packaging.
>
> I run into the first problem, concerning Python support:
>
> During the cmake run, I get the following:
>
> [...]
> -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.4", minimum required is "3")
> -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.4", minimum required is "2")
> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.13+")
> [...]
> -- WARNING: ENABLE_python is OFF so setting ENABLE_pyqt4 to OFF.
> [...]
> ENABLE_python:          OFF
> ENABLE_qt:              ON
> ENABLE_pyqt4:           OFF
>
> and consequently the pyqt4 bindings are not created. Explicitly using
> -DENABLE_python does not help.
>
> Any idea what to do?

Hi Ole:

I need more context to help me to figure out what is going wrong.

Please send me the complete compressed output from cmake command and also
the compressed CMakeCache.txt file.

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] This next release cycle should finish in early 2018

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

On 2017-08-26 02:26-0700 Alan W. Irwin wrote:

> On 2017-08-26 11:12+0200 Ole Streicher wrote:
>
>> Hi Alan,
>> 
>> "Alan W. Irwin" <ir...@be...> writes:
>>> The 5.13.0 release has now been completed.  (See my recent post to
>>> plplot-general for links to the details).
>>> 
>>> I encourage all of you to test the website (I already know of one dead
>>> external link there to Homebrew packaging of PLplot, but I hope none
>>> of you find any many more of those), and test this release tarball by
>>> downloading it, using gpg --verify on it, and building PLplot with it.
>> 
>> That is great news! We (in Debian) like to have a verified chain for the
>> source... I will enable this in my packaging.
>> 
>> I run into the first problem, concerning Python support:
>> 
>> During the cmake run, I get the following:
>> 
>> [...]
>> -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.4", 
>> minimum required is "3")
>> -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.4", 
>> minimum required is "2")
>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found 
>> version "2.7.13+")
>> [...]
>> -- WARNING: ENABLE_python is OFF so setting ENABLE_pyqt4 to OFF.
>> [...]
>> ENABLE_python:          OFF
>> ENABLE_qt:              ON
>> ENABLE_pyqt4:           OFF
>> 
>> and consequently the pyqt4 bindings are not created. Explicitly using
>> -DENABLE_python does not help.
>> 
>> Any idea what to do?
>
> Hi Ole:
>
> I need more context to help me to figure out what is going wrong.
>
> Please send me the complete compressed output from cmake command and also
> the compressed CMakeCache.txt file.

Hi Ole:

The additional context you sent me off-list reads as follows:

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.4", minimum required is "3") 
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.4", minimum required is "2") 
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.13+") 
Traceback (most recent call last):
   File "<string>", line 1, in <module>
ImportError: No module named 'numpy'
-- WARNING: NumPy header not found. Disabling Python binding

This simply means you need to install the python3-numpy package
(to be consistent with the above python3), and all should be well.

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] This next release cycle should finish in early 2018

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

"Alan W. Irwin" <ir...@be...> writes:
> I did take a quick look at the above URL but saw no obvious issues. So
> it appears your Debian repackaging efforts have been a complete
> success for our latest version of PLplot.  Congratulations on that
> achievement!

Hopefully. Maybe our ftp-masters find some issues (it will take a while
....), but I think they can be resolved quickly. After they give the OK,
we will see how it compiles on all our platforms; I will come back if
there are problems.

> Once your CI tests are implemented, will those test the master branch
> of PLplot against changes on that branch or will those test fixed
> PLplot-5.13.0 against any further packaging changes that you do and
> also general Debian Sid changes?

They will test the precompiled Debian package (in sid) against any
changes of the environment. So, if any of the bindings (f.e.) fails due
to some incompatible changes, we can see this immediately.

Best

Ole

Re: [Plplot-devel] This next release cycle should finish in early 2018

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

On 2017-08-26 14:36+0200 Ole Streicher wrote:

> On 26.08.2017 12:43, Alan W. Irwin wrote:
[...]
>> This simply means you need to install the python3-numpy package
>> (to be consistent with the above python3), and all should be well.
>
> Thanks With installing python3-numpy as well, it works. I didn't update
> the dependencies from plplot-12 (where we had  Python-2 bindings only).

Hi Ole:

I feel pretty strongly this discussion belongs on the PLplot development
list so I have put it back there again.

When you immediately posted that Python failure for plplot-5.13.0, I
was beginning to wonder if I would need to quickly release 5.13.1 to
fix whatever problem you had found.  So it is a big relief to me to
hear from you there is no plplot-5.13.0 issue in this regard and
installing the right version of the numpy package completely fixed the
issue.  :-)

>
> This opens however a new can of worms for me: If we are able to build
> Python-2 *and* Python-3 packages, it would be great to do so. Also, I'd
> like to build it for all supported Python minor versions (3.5 and 3.6
> for the moment, and Python 2.7) during the package build. Is there any
> way to configure or patch this? Supporting all Debian-supported versions
> is part of our Python policy.

That policy might need some adjustments, i.e., Python2 support should
be allowed, but I am pretty sure it should not be mandatory because
upstream Python developer support of Python2 is obviously not as active as
Python3 support, and that sometimes causes problems for Python2.

For an example of this, consider our examples/python/pytkdemo
interactive example that demonstrates use of our Tcl-based plframe
GUI under Python.  This is a complex beast with namespace issues
I have not yet been able to track down so to work around those I
do a double import of bindings/python/Plframe.py using

import Plframe
from Plframe import *

Such double imports to work around namespace issues are fairly common,
but from my python2 interactive testing experience this double import
would sometimes generate *.pyc corruption issues for the
bindings/python/Plframe.pyc file which should automatically be
generated by Python by that first import *only* if
bindings/python/Plframe.pyc does not exist or if
bindings/python/Plframe.py has been updated.

I consulted with a Python developer concerning this issue, and his
advice was to move to Python3 because there were known race conditions
that had been fixed in that latter case, but he wasn't sure if they
had been fixed for Python2, and he strongly implied that Python
developers tended to concentrate on Python3 for obvious reasons so
issues did slip through the cracks for Python2, and this corruption
issue was probably just one example of that.

So once (thanks to Hazen's efforts) PLplot was ready for Python3, I
started to use it almost exclusively to test it, and my tests showed
complete reliability and also no bindings/python/Plframe.pyc
corruption issue. So based on that demonstrated Python2 corruption
issue that Python3 solved, I updated our build system to make Python3
the preference if both Python3 and Python2 were available. And ever
since that change I have never run into that *.pyc corruption issue.
So my experience certainly jibes with what the Python developer said.

Now it could be that developer had some axe to grind, and he was
therefore too discouraging about the reliability of Python2.  So it is
possible that race condition for Python2 that seems to be the source
of this *.pyc corruption issue has been fixed in later Python2
versions than I currently have with Debian Jessie (2.7.9-2+deb8u1).
But my experience this Python developer's attitude toward Python2
should certainly give Debian developers some food for thought about
any mandatory Python2 requirements they may have in their Python
policy.

Those Debian policy issues aside, Plplot continues to work fine for
python2 aside from the relatively rare corruption issue for
bindings/python/Plframe.pyc which is straightforward (although
annoying) to work around by removing that corrupt file so that python
will regenerate it (typically in reliable fashion for quite a while).
Furthermore, this issue will likely go away once I figure out how to
move to a single name-spaced import of PLframe, and I suspect, in any
case, you likely don't bother to package the still somewhat
experimental examples/python/pytkdemo along with the special Plframe
module and Pltk_init extension module that are unique needs of that
example.

So I suggest if you still want to build a python2 package for PLplot,
that you do that in a separate build where both python2 and
python-numpy are available and you use the cmake option
-DFORCE_PYTHON2=ON.  In that case and assuming that Python2 and
python-numpy are installed, our build system will do the right thing
with regard to building the Python2 plplot module using consistent
Python2 library and numpy versions, and also use the correct install
location for the resulting Python2 plplot module.  Also, this extra
build does not need to cost your very much since you can use
(-DFORCE_PYTHON2=ON -DDEFAULT_NO_DEVICES=ON -DPLD_extqt=ON
-DDEFAULT_NO_BINDINGS=ON -DENABLE_python=ON -DENABLE_qt=ON
-DENABLE_pyqt4=ON) to, for example, configure a build and install of
just the minimum PLplot components you need to support both python and
pyqt4 under Python2.

Alternatively, you might be able to trace through the
-DFORCE_PYTHON2=ON logic in cmake/modules/python.cmake, and provide a
patch to simultaneously support both Python2 and Python3 builds. But
that is a lot of work with a lot of chance to introduce build-system
errors/inconsistencies so I think the above multiple build approach
is much better.

>
> One solution could be to write a standard "setup.py", which would allow
> to run the Debian Python build machinery here. This automatically builds
> the Python modules for all supported versions, and installs them in the
> preferred path. Would you think it is problematic to write one? (I am
> not asking that you do it yourself; I just want to know if it is worth
> the effort).

Let's face it, the setup.py approach requires you to implement a
python-based build system and build systems are always tricky.  And
that is especially true when you are trying to simultaneously support
more than one version, see comment above.  So I think you are talking
about a considerable amount of implementation work, maintenance, and
potential errors.  In the distant past we used a setup.py approach for
our Python components but eventually abandoned it once we figured out
everything we needed to do with our autotools-based build system at
that time and we continued without using the setup.py approach when we
implemented the CMake-based build system that replaced that
autotools-based build system a decade ago.

In sum, that decision about implementing a setup.py approach is up to
you, but my advice is to not bother with that and instead use our
existing CMake-based build system to do what you want using the above
multiple build approach.

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] This next release cycle should finish in early 2018

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

On 2017-08-26 13:15-0700 Alan W. Irwin wrote:

[...]
> Plplot continues to work fine for
> python2 aside from the relatively rare corruption issue for
> bindings/python/Plframe.pyc [... which will likely go away once I figure out how to
> move to a single name-spaced import of PLframe.

Hi Ole:

That turned out to be an easy fix (see commit 1b93965) so I assume
that corruption issue (that only occurred intermittently for Python2)
is now gone.

> So I suggest if you still want to build a python2 package for PLplot,
> that you do that in a separate build where both python2 and
> python-numpy are available and you use the cmake option
> -DFORCE_PYTHON2=ON.  In that case and assuming that Python2 and
> python-numpy are installed, our build system will do the right thing
> with regard to building the Python2 plplot module using consistent
> Python2 library and numpy versions, and also use the correct install
> location for the resulting Python2 plplot module.  Also, this extra
> build does not need to cost you very much since you can use
> (-DFORCE_PYTHON2=ON -DDEFAULT_NO_DEVICES=ON -DPLD_extqt=ON
> -DDEFAULT_NO_BINDINGS=ON -DENABLE_python=ON -DENABLE_qt=ON
> -DENABLE_pyqt4=ON) to, for example, configure a build and install of
> just the minimum PLplot components you need to support both python and
> pyqt4 under Python2.

You have already said that you decided to simplify your life by not
trying the above approach to support Python2.  But PLplot (after the
above commit) now works well both for Python2 and Python3, and it
would be a shame if either Debian Python2 or Python3 users did not
have access to PLplot. Furthermore, assuming you have since decided to
support both Python-3.5 and Python-3.6 with two separate builds, then
adding a third build as above to support Python2 should be
straightforward for you.  So I hope you decide to go ahead and do
that.

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] This next release cycle should finish in early 2018

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

On 2017-08-27 11:00+0200 Ole Streicher wrote:

> One point there however remains: I need to support all Python 3 versions
> we have in Debian; currently Python 3.5 and Python 3.6. The difference
> are just the shared library stubs, which are compiled using the specific
> header files (the package will contain both shared libs). Do you have an
> idea how I could simply do this?

Use multiple builds.

Also to make this easier for you I have now (commit e320210)
improved user control of the Python version.

So for one build you specify -DPLPLOT_PYTHON_EXACT_VERSION=3.5.0
and for the other you specify -DPLPLOT_PYTHON_EXACT_VERSION=3.6.0,
and it should "just work" according to my tests of the above
commit.

> I also have then a question about the dependencies: The old (plplot-10)
> Debian package had a build dependency on python-gtk2, a package that
> does not exist for Python 3. I would suspect that it is not needed anymore?

software@raven> find . -type f |grep -v .git |xargs grep -li gtk |less

found a large number of files where gtk is mentioned, but none of them
are relevant to python.  I dimly recall that we used to have a GTK
binding that also included a python interface, but that was superseded
by the pango/cairo related components of PLplot so is long gone now.
So I suspect this build dependency on python-gtk2 is an extremely
ancient artifact that you can just ignore from now on.

> And, a final point; I think we already shortly discussed that: Debian
> will drop Qt4 support at some point. Since I am doing a major
> restructuration of the Package structure anyway, it may be worth to use
> qt5 only in the plplot package as well; otherwise I would have to do
> that switching in a few months anyway. Would you agree here?

Our Qt-related components work extremely well with Qt4, and also work
pretty well (aside from small character alignment issues and a
segfault for pyqt5) with the Debian Jessie version of Qt5. But those
Qt5 issues are bound to go away as that library matures (and in fact
may have gone away already with the later versions of Qt5 that you
have access to with later Debian versions).  But I also don't think you
should throw away our superb Qt4 capabilities prematurely.  So I
suggest you use a multiple build approach here as well (one with
-DPLPLOT_USE_QT5=ON and one with the default value of that option
[-DPLPLOT_USE_QT5=OFF]).

> Best regards, and already many thanks for the help!

You are welcome.

And thanks very much to you for taking on the responsibility of Debian
(and Debian-derived distribution) packaging of PLplot!  That job is
important because if you make the assumption that the fraction of
popularity contest statistics for PLplot represents the fraction of
Linux users who actually use PLplot on a monthly basis, then the
PLplot users who are using the binary versions of PLplot that you and
other packagers (such as Orion for Fedora) are creating far outnumber
the ~7000 users who download PLplot each year according to SF
statistics.

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] This next release cycle should finish in early 2018

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

Hi Alan,

On 28.08.2017 00:13, Alan W. Irwin wrote:
> On 2017-08-27 11:00+0200 Ole Streicher wrote:
>> One point there however remains: I need to support all Python 3
>> versions we have in Debian; currently Python 3.5 and Python 3.6.
>> The difference are just the shared library stubs, which are
>> compiled using the specific header files (the package will contain
>> both shared libs). Do you have an idea how I could simply do this?
> 
> Use multiple builds.
> 
> Also to make this easier for you I have now (commit e320210) improved
> user control of the Python version.
> 
> So for one build you specify -DPLPLOT_PYTHON_EXACT_VERSION=3.5.0 and
> for the other you specify -DPLPLOT_PYTHON_EXACT_VERSION=3.6.0, and it
> should "just work" according to my tests of the above commit.

Thank you for this; I am however still unsure: Multiple builds would
mean to (currently) triple the whole build process (2.7, 3.5, 3.6),
right? Or can I build the Python binding individually?

>> The old (plplot-10) Debian package had a build dependency on
>> python-gtk2, a package that does not exist for Python 3. I would
>> suspect that it is not needed anymore?

> [...] So I suspect this build dependency on python-gtk2 is an
> extremely ancient artifact that you can just ignore from now on.

Thank you for the confirmation.

> Our Qt-related components work extremely well with Qt4, and also
> work pretty well (aside from small character alignment issues and a 
> segfault for pyqt5) with the Debian Jessie version of Qt5. But those 
> Qt5 issues are bound to go away as that library matures (and in fact 
> may have gone away already with the later versions of Qt5 that you 
> have access to with later Debian versions).  But I also don't think
> you should throw away our superb Qt4 capabilities prematurely.  So I 
> suggest you use a multiple build approach here as well (one with 
> -DPLPLOT_USE_QT5=ON and one with the default value of that option 
> [-DPLPLOT_USE_QT5=OFF]).

Here, I have the similar objection as above: it duplicates the number of
builds. And combined with the Python triple (for Python-plplot-qt) we
would need to compile the code six times.

Additionally, the number of packages would increase even more. pgplot
currently builds already 27 binary packages. If we would split by the Qt
version we would have:

plplot-driver-qt4, plplot-driver-qt5,
libplplotqt4-2, libplplotqt5-2,
python-plplot-qt4, python-plplot-qt5,
python3-plplot-qt4, python3-plplot-qt5

so four more packages. For a library that is deprecated, this sounds a
bit overkill, especially for a soon-to-be-removed package. I read the
deprecation message I mentioned in my other mail that they will write RC
bug reports quite soon, so Qt4 packages will not survive for more than a
few months. And the general package restructuring I do in the moment is
a good moment to drop it.

> You have already said that you decided to simplify your life by not
> trying the above approach to support Python2.  But PLplot (after the
> above commit) now works well both for Python2 and Python3, and it
> would be a shame if either Debian Python2 or Python3 users did not
> have access to PLplot. Furthermore, assuming you have since decided to
> support both Python-3.5 and Python-3.6 with two separate builds, then
> adding a third build as above to support Python2 should be
> straightforward for you.  So I hope you decide to go ahead and do
> that. 

Sure; if there is not much effort to support Python 2 aside of all
Python 3 versions, I will not remove the packages.

Best regards

Ole

Re: [Plplot-devel] This next release cycle should finish in early 2018

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

On 2017-08-29 11:44+0200 Ole Streicher wrote:

> Hi Alan,
>
> On 28.08.2017 00:13, Alan W. Irwin wrote:
>> On 2017-08-27 11:00+0200 Ole Streicher wrote:
>>> One point there however remains: I need to support all Python 3
>>> versions we have in Debian; currently Python 3.5 and Python 3.6.
>>> The difference are just the shared library stubs, which are
>>> compiled using the specific header files (the package will contain
>>> both shared libs). Do you have an idea how I could simply do this?
>>
>> Use multiple builds.
>>
>> Also to make this easier for you I have now (commit e320210) improved
>> user control of the Python version.
>>
>> So for one build you specify -DPLPLOT_PYTHON_EXACT_VERSION=3.5.0 and
>> for the other you specify -DPLPLOT_PYTHON_EXACT_VERSION=3.6.0, and it
>> should "just work" according to my tests of the above commit.
>
> Thank you for this; I am however still unsure: Multiple builds would
> mean to (currently) triple the whole build process (2.7, 3.5, 3.6),
> right? Or can I build the Python binding individually?

Mostly individually.  For example, if you used the cmake parameters
(-DFORCE_PYTHON2=ON -DDEFAULT_NO_DEVICES=ON -DPLD_extqt=ON
-DDEFAULT_NO_BINDINGS=ON -DENABLE_python=ON -DENABLE_qt=ON
-DENABLE_pyqt5=ON) to configure a build and install of just the
minimum PLplot components you need to support both python and pyqt5
under Python2, then that means there is a large saving in build cost
since few devices are built and few bindings are built.  Of course,
there is some duplication of build effort here, but it is tiny (just
the duplicate rebuild of the plplot C library and its small C library
dependencies, i.e., csironn, csirocsa, and qsastime) relative to what
a full PLplot build costs.

>> Our Qt-related components work extremely well with Qt4, and also
>> work pretty well (aside from small character alignment issues and a
>> segfault for pyqt5) with the Debian Jessie version of Qt5. But those
>> Qt5 issues are bound to go away as that library matures (and in fact
>> may have gone away already with the later versions of Qt5 that you
>> have access to with later Debian versions).  But I also don't think
>> you should throw away our superb Qt4 capabilities prematurely.  So I
>> suggest you use a multiple build approach here as well (one with
>> -DPLPLOT_USE_QT5=ON and one with the default value of that option
>> [-DPLPLOT_USE_QT5=OFF]).
>

[...]
> If we would split by the Qt
> version we would have:
>
> plplot-driver-qt4, plplot-driver-qt5,
> libplplotqt4-2, libplplotqt5-2,
> python-plplot-qt4, python-plplot-qt5,
> python3-plplot-qt4, python3-plplot-qt5
>
> so four more packages. For a library that is deprecated, this sounds a
> bit overkill, especially for a soon-to-be-removed package.

Having finally read the reference you gave concerning how soon Qt4 is
going to be removed from Debian, I now agree building Qt4-related
components of PLplot would be overkill (although the multiple build
cost would have been low since as in the python case above there is a
way to pare down the Plplot build to just the bare essentials
concerning its Qt-related components).

To summarize, I think you should do multiple builds for python 2.7,
3.5, and 3.6 (with relatively small extra build cost), but I agree you
should stick strictly to Qt5 for our Qt-related components because Qt4
is about to be removed from Debian.

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] This next release cycle should finish in early 2018

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

Hi Alan,


On 29.08.2017 19:48, Alan W. Irwin wrote:
> To summarize, I think you should do multiple builds for python 2.7,
> 3.5, and 3.6 (with relatively small extra build cost), but I agree you
> should stick strictly to Qt5 for our Qt-related components because Qt4
> is about to be removed from Debian.

in the last days, I managed to create the Debian package for the new
plplot version. Since there are changes in the Debian package structure
(new and renamed packages), it has to be approved by our ftp-masters,
and therefore I uploaded a pre-release to our "experimental" branch
(also to prepare the required recompilation of the dependent packages).
As long as the new package is not accepted, you will find the metadata here:

https://ftp-master.debian.org/new/plplot_5.13.0%2Bdfsg-1~exp1.html

For the Python stuff, I finally used a patch that builds for all
available Python versions. The patch is Debian specific and
straightforward, and I intend to maintain it together with the Debian
package. For curiosity, I however attach it.

The current upload is not the final version; I intend to still add f.e.
Continuous Integration tests. So if you feel that we should still change
things, we can.

Best regards,

and already thank you for your help so far!

Ole

Re: [Plplot-devel] This next release cycle should finish in early 2018

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

On 2017-09-09 14:21+0200 Ole Streicher wrote:

> Hi Alan,
>
>
> On 29.08.2017 19:48, Alan W. Irwin wrote:
>> To summarize, I think you should do multiple builds for python 2.7,
>> 3.5, and 3.6 (with relatively small extra build cost), but I agree you
>> should stick strictly to Qt5 for our Qt-related components because Qt4
>> is about to be removed from Debian.
>
> in the last days, I managed to create the Debian package for the new
> plplot version. Since there are changes in the Debian package structure
> (new and renamed packages), it has to be approved by our ftp-masters,
> and therefore I uploaded a pre-release to our "experimental" branch
> (also to prepare the required recompilation of the dependent packages).
> As long as the new package is not accepted, you will find the metadata here:
>
> https://ftp-master.debian.org/new/plplot_5.13.0%2Bdfsg-1~exp1.html
>
> For the Python stuff, I finally used a patch that builds for all
> available Python versions. The patch is Debian specific and
> straightforward, and I intend to maintain it together with the Debian
> package. For curiosity, I however attach it.
>
> The current upload is not the final version; I intend to still add f.e.
> Continuous Integration tests. So if you feel that we should still change
> things, we can.

Hi Ole:

I did take a quick look at the above URL but saw no obvious issues. 
So it appears your Debian repackaging efforts have been a complete
success for our latest version of PLplot.  Congratulations on that
achievement!

Once your CI tests are implemented, will those test the master branch
of PLplot against changes on that branch or will those test fixed
PLplot-5.13.0 against any further packaging changes that you do and
also general Debian Sid changes?

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] This next release cycle should finish in early 2018

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

Dear Alan,

On 09.09.2017 20:35, Alan W. Irwin wrote:
> I did take a quick look at the above URL but saw no obvious issues. So
> it appears your Debian repackaging efforts have been a complete
> success for our latest version of PLplot.  Congratulations on that
> achievement!

Yesterday, the package go accepted, and our autobuilders already
successfully created binary packages for a number of platforms:

 * Intel 32 and 64 bit, both Linux and kfreebsd
 * ARM 64bit

On some platforms, the build however failed: on PowerPC 64 bit (both big
and little endian), mips (32 bit, big endian) and s390x (64 bit, big
endian) the ocaml test "x09ocaml" failes with an segmentation fault:

<<BUILDDIR>>/plplot_test/test_ocaml.sh: line 27:
 22680 Segmentation fault
 "$ocamldir"/x${index}ocaml -dev $device \
 -o "${OUTPUT_DIR}"/x${index}${lang}%n.$dsuffix $options 2> test.error \
 >| "${OUTPUT_DIR}"/x${index}${lang}_${dsuffix}.txt

On PowerPc 32 bit (an unofficial Debian Platform), I get an error when
x00ocaml is built:

«BUILDDIR»/examples/ocaml/x00ocaml: error while loading shared
libraries: R_PPC_REL24 relocation at 0x20690ee8 for symbol
`gettimeofday' out of range

Could you have a short look, especially for the first failure? It is not
necessarily a regression, since the ocaml bindings weren't built in the
Debian package since quite a while.

If it is a ocaml bug, I would write a bug report for the ocaml package
and then disable the x09ocaml test until it is fixed.

For the architectures that are still waiting to be built (ARM 32 bit,
MIPS little endian 32 and 64 bit, Alpha, PA-RISC), I will give an update
when they are ready.

Best regards

Ole

Re: [Plplot-devel] This next release cycle should finish in early 2018

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

On 2017-09-15 10:06+0200 Ole Streicher wrote:

> Dear Alan,
>
> On 09.09.2017 20:35, Alan W. Irwin wrote:
>> I did take a quick look at the above URL but saw no obvious issues. So
>> it appears your Debian repackaging efforts have been a complete
>> success for our latest version of PLplot.  Congratulations on that
>> achievement!
>
> Yesterday, the package go accepted, and our autobuilders already
> successfully created binary packages for a number of platforms:
>
> * Intel 32 and 64 bit, both Linux and kfreebsd
> * ARM 64bit

Hi Ole (with CC to Hez because of the OCaml issues):

The Intel 32- and 64-bit platforms are obviously the most important
hardware platforms to get right so that is very encouraging news
indeed.

>
> On some platforms, the build however failed: on PowerPC 64 bit (both big
> and little endian), mips (32 bit, big endian) and s390x (64 bit, big
> endian) the ocaml test "x09ocaml" failes with an segmentation fault:
>
> <<BUILDDIR>>/plplot_test/test_ocaml.sh: line 27:
> 22680 Segmentation fault
> "$ocamldir"/x${index}ocaml -dev $device \
> -o "${OUTPUT_DIR}"/x${index}${lang}%n.$dsuffix $options 2> test.error \
> >| "${OUTPUT_DIR}"/x${index}${lang}_${dsuffix}.txt
>
> On PowerPc 32 bit (an unofficial Debian Platform), I get an error when
> x00ocaml is built:
>
> «BUILDDIR»/examples/ocaml/x00ocaml: error while loading shared
> libraries: R_PPC_REL24 relocation at 0x20690ee8 for symbol
> `gettimeofday' out of range
>
> Could you have a short look, especially for the first failure? It is not
> necessarily a regression, since the ocaml bindings weren't built in the
> Debian package since quite a while.
>
> If it is a ocaml bug, I would write a bug report for the ocaml package
> and then disable the x09ocaml test until it is fixed.

I don't have the OCaml expertise to help you decide whether this is a
PLplot bug or an OCaml bug.  But I suspect the latter because of
the build success of our ocaml binding on other platforms.

@Hez:
Got any ideas about this?

@Ole:
To introduce you, Hez was the primary developer of our ocaml binding and
examples.  However, he has not been contributing to PLplot recently so
if he does not respond to the above question, I suggest you simply turn
off all OCaml-related packages on the hardware platforms where those
are failing to build.

By the way, thanks for the reference to
<https://buildd.debian.org/status/package.php?p=plplot&suite=experimental>
that you sent later.  I haven't had a chance to look at it yet for any
non-OCaml issues, but if you spot any of those, let me know.

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] This next release cycle should finish in early 2018

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

Ole Streicher <deb...@li...> writes:
[...]

I forgot to attach the URL with all build logs:

https://buildd.debian.org/status/package.php?p=plplot&suite=experimental

Cheers

Ole