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