[Slackbuilds-users] Unstated requirement (apparently) to build octave

[Jim Diamond]

Hi again Matteo,

On Sat, Mar 21, 2020 at 20:46 (+0100), Matteo Bernardini wrote:

> Il giorno sab 21 mar 2020 alle ore 20:29 James Diamond via
> SlackBuilds-users <slackbuilds-users at slackbuilds.org> ha scritto:

>> On Sat, Mar 21, 2020 at 19:52 (+0100), Matteo Bernardini wrote:

>>> Il giorno sab 21 mar 2020 alle ore 18:22 James Diamond via
>>> SlackBuilds-users <slackbuilds-users at slackbuilds.org> ha scritto:

>>>> Hi,

>>>> I often ssh in to a much faster machine to run sboupgrade to build new
>>>> versions of various SB packages.  It turns out that when I try this
>>>> with octave, it fails repeatably.  But if I VNC in and run it from a
>>>> terminal open on that machine, it succeeds.

>>>> It seems that while building it wants to use/access/look at/investigate/...
>>>> the graphics, and that fails during an ssh -Y connection.  Possibly if I
>>>> reset DISPLAY it would be happy.  Or didn't use -Y.  Or something else...

>>>> In any case, should someone add a comment to the README about this, to
>>>> keep other people who might run into this from wasting too much of
>>>> their time?

>>>> Cheers.

>>>> Jim

>>> Hi Jim,

>>> I don't know what's happening there but I just built octave
>>> successfully on my headless slackware64-14.2 virtual machine.

>> Hi Matteo,

>> interesting.  I wish I had saved the error messages (I will regenerate
>> them if anyone is particularly interested, but they occur after a lot
>> of compiling, when the tests are being done).

>> Perhaps in your case the test suite recognizes that there is no
>> graphics card and doesn't try various tests, or, at least, doesn't get
>> fooled by the fact that the local graphics card and the $DISPLAY
>> graphics card don't match.

>> Cheers

>> Jim

> FWIW,

> # lspci | grep VGA
> 00:02.0 VGA compatible controller: Red Hat, Inc. QXL paravirtual
> graphic card (rev 04)
> # set | grep DISPLAY
> #

> IMHO code running on the host executing the SlackBuild has no way to
> know which hardware is on a remote DISPLAY.

Well, that may be so.  However, after 1525 seconds of compiling on a
somewhat low-end Xeon, here is the end of the show:
  ...
  help/which.m ................................................... PASS    8/8   
  image/cmpermute.m .............................................. PASS   19/19  
  image/cmunique.m ............................................... PASS   19/19  
  image/colormap.m ............................................... PASS    9/9   
  image/contrast.m ............................................... PASS    1/1   
  image/frame2im.m ............................................... PASS    4/4   
  image/getframe.m ...............................................libGL error: failed to authenticate magic 2
libGL error: failed to load driver: i965
fatal: caught signal Illegal instruction -- stopping myself...
/bin/sh: line 1: 14187 Illegal instruction     (core dumped) /bin/sh ../run-octave --norc --silent --no-history -p /tmp/SBo/octave-5.2.0/test/mex /tmp/SBo/octave-5.2.0/test/fntests.m /tmp/SBo/octave-5.2.0/test
Makefile:27887: recipe for target 'check-local' failed
make[3]: *** [check-local] Error 132
make[3]: Leaving directory '/tmp/SBo/octave-5.2.0'
Makefile:26265: recipe for target 'check-am' failed
make[2]: *** [check-am] Error 2
make[2]: Leaving directory '/tmp/SBo/octave-5.2.0'
Makefile:25976: recipe for target 'check-recursive' failed
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory '/tmp/SBo/octave-5.2.0'
Makefile:26267: recipe for target 'check' failed
make: *** [check] Error 2


I will point out that on the compiling Xeon, I am using the
Nouveau driver, and the string "965" does not appear anywhere in
/var/log/Xorg.0.log.

However, on the laptop I am ssh'ed in from, Xorg.0.log has
[     8.295] (II) Module vesa: vendor="X.Org Foundation"
[     8.295]    compiled for 1.18.0, module version = 2.3.4
[     8.295]    Module class: X.Org Video Driver
[     8.295]    ABI class: X.Org Video Driver, version 20.0
[     8.295] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
        i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
        915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
        Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
        GM45, 4 Series, G45/G43, Q45/Q43, G41, B43

Also, running xrandr and/or xdpyinfo from the Xeon shows that a
program running on the Xeon can find out my screen configuration and
other information, so I can imagine some nosy X program finding out
what is going on.  In fact, running glinfo on the Xeon gives output
starting with
        libGL error: failed to authenticate magic 2
        libGL error: failed to load driver: i965
        GL_VERSION: 3.0 Mesa 11.2.2
so again, programs running on the Xeon can know a lot about the laptop
from which I ssh'ed into the Xeon.

This may have nothing to do with anything, but the fact that the above
error message whined about i965 and the only i965 driver in use that I
know about is the one on my laptop made me put those together.
However, I freely admit the reasoning is not rock-solid.

Cheers.
                                Jim