Re: [Plplot-devel] Help needed for plplot runtime tests

[Alan W. I. <Ala...@gm...>]

Hi Ole:

On 2019-02-02 15:38+0100 Ole Streicher wrote:

> Hi Alan,
>
>
> I must confess that I disabled both build time and CI tests for plplot
> in Debian, since I could not get them working properly. The main problem
> is that the tests don't play well with the way Debian maintains its
> Python extensions (especially renaming them).

The Python status when we last discussed this is I encouraged your
desire to simplify your packaging life by dropping Python2 support in the
Debian package since upstream we use Python3 by default, and within a
year or so we might drop Python2 completely ourselves.

> and I got finally lost in
> CMake, where I must admit that I do often not understand what happens.

I am pretty good with CMake if I do say so myself.  :-)

So feel free to ask questions about it here.  (I would be willing
to answer private questions about CMake as well, but others
here might be interested in both your questions and my answers so
I prefer you keep this on this mailing list.)

> On 02.02.19 10:50, Alan W. Irwin wrote:
>> I haven't yet made the upstream fix to allow users who have installed
>> only a subset of the PLplot binary packages to test the installed
>> examples.  But that fix is still on my near-term agenda (e.g., before
>> the release of 5.15.0 tentatively scheduled for mid-2019).  But
>> meanwhile, have either of you made any progress on those requested
>> tests of the "all packages installed case" for the PLplot git master
>> tip version?  Such test reports from you would be most helpful since
>> they would verify what I have done upstream up to now.
>
>
> I think this is not a problem anymore, since I now centralized all
> examples in the -doc package.

Yes, but my goal here is your integrated installed examples package
should work regardless of what PLplot binary packages are installed.
And I have completed step 1 in that process which was to factor our
exported target support into separate configuration files for each of
those exported targets.  But that change requires work by packagers to
make sure that those many different target support files (now
interpreted as imported targets) become part of the PLplot binary
package containing the executable, library, or dll (device driver)
that those (now) imported targets refer to.  Once you have completed
that packaging work, than the imported targets will exist or not
depending on whether the relevant binary packages are installed
or not.

Note, I have not yet finished the final step 2 in this upstream change
which is to make the installed example builds and tests depend on the
existence (or not) of the relevant imported targets.  But you are in a
position now to do the above binary packaging effort and test it so
long as you have installed all the relevant binary packages.  But as
soon as step 2 is completed that caveat will no longer hold and you
should be able to also test any combination of installed (or not)
binary packages with your examples package.

>> [...] So Ole (most likely) and Orion (likely) will
>> run into this libLASi bug when testing the installed PLplot examples
>> unless you either (i) disable both the psttf
>> and psttfc devices or (ii) convince Debian and Fedora packagers to
>> package libLASi-1.1.3.  I have just released that new version (see
>> <https://sourceforge.net/p/lasi/news/2019/02/liblasi-113-has-been-released/>
>>
>> which includes my quite important bugfix for the showstopping case
>> when pango/fontconfig decides to use a pure bitmapped font.
>
>
> I do not really understand what the connection between plplot and lasi
> is? Lasi is not a dependency of plplot -- is this wrong? Can you explain
> what the relation is?

Yes.  The psttf device driver (which implements the psttf and psttfc
devices) depends directly on libLASi.  Which is why this libLASi
showstopper bug that is only fixed in libLASi-1.1.3 is so important to
PLplot (unless you go out of your way to disable both the psttf and
psttfc devices).

>> @Ole: My understanding from
>> <https://packages.debian.org/source/sid/lasi> is Debian packaging
>> efforts for libLASIi are 3 bugfix versions behind (libLASi version
>> 1.1.0 is packaged rather than 1.1.3).  I think Debian is in freeze now
>> for the stable release of Debian Buster, but after that is done would
>> you be willing to package libLASi-1.1.3 and do an NMU in response to
>> [Debian bug
>> 921139](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921139).
>> That effort would propagate the important upstream pure bitmapped font
>> bug fix for all Debian and Debian derivative users.
>
>
> Lasi is an "orphaned" Debian package, which means that nobody
> specifically takes care of it. Only our QA team looks to fix serious
> problems. But since the package is rarely used, it may even be removed.
> "Someone" should take care of it. BTW, the VCS (on sourceforge) with the
> Debian package seems to not work.

The libLASi VCS at SF is subversion and is working great here
(although resurrecting my knowledge of svn felt a bit strange for a while).

But you can try out libLASi for yourself with no need to resurrect
your knowledge of subversion or learn about it for the first time.
All you need to do is to download the libLASi-1.1.3 tarball and use
standard cmake, "make all", ctest, and "make install" to configure,
build, test, and install it.

Please also look at the project sample at
<https://sourceforge.net/projects/lasi/> to see one of the beautiful
results that can be generated by this library.  (You should also find
that beautiful result in examples/ComplexTextLayoutExample.eps and
examples/ComplexTextLayoutExample.png in the build tree once you have
built the "all" target with make.  And you should find a snapshot of
that *.png file before you build in the examples subdirectory of the
source tree.

In sum, it would be a shame to lose this capability for Debian because
no maintainer had the time to change the package from 1.1.0 to 1.1.3
(which should be straightforward since the libLASi build system has
not changed that much between those versions).  And this is not a
large commitment because it is a small library that is in deep
maintenance mode with a track record of new bug fix releases not
occurring that often.  So I frankly hope you are interested enough to
try libLASi for yourself and follow up with an NMU.  But if not, then
you should definitely drop the psttf and psttfc devices from your
PLplot package.

>> @Everybody: there are still some minor PLplot issues for the psttf
>> device driver that Ole and Orion won't face when testing
>> system versions of PLplot.
>>
>> Those issues are the following:
>>
>> * The PLplot build system currently does not configure rpath
>>   information for the case when libLASi is installed in a non-system
>>   location.  To work around this issue I currently set the
>>   LD_LIBRARY_PATH environment variable appropriately to help the Linux
>>   loader find my locally built and installed version of libLASi.
>
>
> In Debian, we would specifically remove RPATH information, since libs
> are supposed to be installed in the standard dirs.

Yes, that is likely true of all distributions since they use system
locations for installed files and for that case RPATH has some
downsides with no benefits whatsoever.  To accomodate this
distribution need we have the option to turn off installed RPATH
capability using -DUSE_RPATH=OFF (which I assume your packages are
already using).  But most individual downloaders install PLplot in
non-system locations so they use the default -DUSE_RPATH=ON option
because that is the most convenient choice for their use case, i.e.,
it means they don't have to maintain the LD_LIBRARY_PATH environment
variable setting in order to get installed PLplot to work properly.

Alan
__________________________
Alan W. Irwin

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
__________________________