Re: [Plplot-devel] Plplot now working well with Debian Buster + release timing

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

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
__________________________