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

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

On 2018-12-18 13:16-0800 Alan W. Irwin wrote:

[...]
> But meanwhile, I hope you are both able to test your binary packages
> for PLplot and your package containing the installed examples for
> plplot-5.14.0-10-g66d68d93e in the above way subject to the temporary
> "all installed" constraint.

@Ole and Orion:

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.

The other purpose of bringing this installed examples test topic up
again, is as a recent Debian Buster update (and very likely on Fedora as well)
fontconfig has by default started to give the highest preference to
the Noto fonts.  Most of those are really nice with deserved
popularity, but one of them, "Noto Color Emoji" is an old-fashioned
pure bitmapped font (likely OK for Emoji's in text but not much
else) that has exposed a long-standing issue in libLASi which simply
gave up (threw an error and exited) for libLASi-1.1.2 and all prior
versions when encountering a pure bitmapped font.

The reason for this result is old-fashioned pure bitmapped fonts are
completely incompatible with the libLASi library (since it needs
scalable outline font information to represent glyphs rather than an
old-fashioned bitmap).  Of course, this library response to pure
bitmapped fonts is much too severe, and the result of this libLASi bug
is that PLplot comprehensive tests error out for the psttf and psttfc
devices (which depend on libLASi to do the work).  This error occurs
when PLplot encounters the Aries glyph symbol in example 7 since
pango/fontconfig by default chooses "Noto Color Emoji" to render that
glyph and ~15 others).  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.

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

@Orion: My understanding from
<https://rpmfind.net/linux/rpm2html/search.php?query=libLASi.so.1()(64bit)>
is that Fedora packaging of libLASi is only one bugfix version behind
(libLASi 1.1.2 is packaged rather than the desired 1.1.3).  The Fedora
libLASi packager may not have dealt with 1.1.3 yet because the 1.1.3
release is so recent, but if that situation persists I hope you get in
touch with him to remind him there is an important upstream bugfix
release that should be packaged instead of 1.1.2 to avoid PLplot
comprehensive testing errors with the psttf and psttfc devices.

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

* PLplot currently accepts any version of libLASi.  I need to change that
   so it only accepts libLASi-1.1.3 or above since the prior versions
   are obviously contaminated with the showstopper pure bitmapped font issue
   and several other important issues as well that are fixed in libLASi-1.1.3.

I hope to deal with both these PLplot issues by early next week.

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
__________________________