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
__________________________