On 2018-09-20 21:09-0600 Orion Poplawski wrote:
On 09/20/2018 12:22 AM, Alan W. Irwin wrote:
On 2018-09-19 22:06-0600 Orion Poplawski wrote:
On 09/15/2018 01:49 PM, Alan W. Irwin wrote:
To Orion and Ole:
Commit a730ebe34 has removed the last of the "new software" issues I
have identified with Debian Testing = Buster.
@Orion: I encourage you to try that commit on Fedora to see if you get
similarly good results for all Linux-available components of
PLplot for that other cutting-edge Linux platform.
@Both: You both also might want to experiment with this commit as the
basis for much-improved PLplot packages for Fedora and Debian.
However such packages can only be considered preliminary until PLplot
makes an official release. What I can say on that topic is commit
a730ebe34 is an important milestone on the trail to the next release,
but we are not there yet.
For example, the CMake test that is automatically produced every night
by my computer for the CMake developers builds and tests the latest
CMake. One of those tests is the PLplot contract test which tests
whether a build (but not test) of PLplot is successful. That test is
formally succeeding, but those PLplot builds are incomplete (with the
cairo device driver dropped) because of incompatibilities with the way
we configure our cairo device driver using internal details of the
CMake pkg-config capability. Although the use of such internal
details has worked well over many years with few adjustments needed
for changes to those internal details with CMake version, it is again
no longer working with the very latest CMake. This reflects the
fundamental fragility of any method that uses internal details.
Therefore, to deal with this issue my plan is to completely rewrite
our support for the cairo device using the official CMake pkg-config
support rather than internal details of that support. And there are
also a few other topics I would like to squeeze into the next release.
So this makes the ETA of our next PLplot release still somewhat
uncertain, but I am still hoping to get it done this year (before
Christmas season) rather than early next year.
Latest git (a9d9500c) built on Fedora Rawhide:
https://koji.fedoraproject.org/koji/taskinfo?taskID=29771905
Despite the overall failure to build, looks mostly okay, but it appears
that you don't support lua 5.3:
-- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact
version "5.2")
-- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact
version "5.1")
-- LUA_INCLUDE_DIR =
-- LUA_LIBRARIES = /usr/lib64/liblua.so;/usr/lib64/libm.so
-- WARNING: Lua header and/or library not found. Disabling Lua binding
Hi Orion:
Thanks for that feedback. Lua5.3 worked here (Debian Testing = Buster)
for all but one example, but that one example exposed a Lua-5.3 bug
(at least for the Debian version of Lua5.3) that was severe
(arithmetic quit working if more than 8 (!) arrays were initialized).
See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for a
simple Lua script that triggers this Lua-5.3 bug and other details
about this bug. I temporarily worked around the problem by using our
build system to blacklist Lua-5.3 until this bug is fixed (i.e.,
in the absence of Lua5.1 or 5.2 our build system should just
cleanly drop the Lua PLplot component and continue).
Please try that simple Lua script to see whether the Fedora version of
Lua-5.3 also has this severe bug. If you do confirm, then that is
pretty good evidence it is a general Lua-5.3 bug (rather than just
Debian related), and in this case I would be willing to take this
issue to the Lua developers rather than waiting for some response to
my bug report from the Debian packagers.
It appears from
<https://kojipkgs.fedoraproject.org//work/tasks/1906/29771906/build.log>
the blacklisting worked without actual build issues (as expected), but
the actual error you get is because your rpm logic is expecting Lua
files from PLplot that are not there because of the blacklisting. So
your response to this issue likely depends on whether you can get the
above simple test script to work for Fedora's version of Lua5.3. If
that test actually works for Fedora, then it appears the Lua5.3 issue
is simply a Debian packaging issue that has nothing to do with Fedora,
and you should edit cmake/modules/lua.cmake to make the slight change
to look first for 5.3, then 5.2, then 5.1. However, if that test also
fails for you, and you think the upstream Lua5.3 fix is going to take
a while to get fixed, then you should change your rpm logic to drop
all the expected Lua results.
Alan
I replied to the debian bug. It appears that lua 5.3.5 on Fedora rawhide is
fine.
See my further traffic there.
In any case I was coming around to the view that our build system
should not blacklist Lua5.3 since the issue I observe is a run-time
issue, i.e., it does not affect builds or generation of a binary deb
or rpm. But now this conclusion is even stronger when it appears from
your Fedora results it is fairly likely the run-time issue is confined
just to Debian.
Therefore I have changed (see commit caf4801df) the Lua find logic so
if the user requests a certain version of Lua our build system will
attempt to find it, but otherwise the latest installed version of Lua
will be found.
Please try building an RPM again using this commit.
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
