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
__________________________
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
