Behold! Buildbot's waterfall display has never been so green

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Behold! Buildbot's waterfall display has never been so green

John W. Eaton
Administrator
See attached screenshot.  Or visit

   http://buildbot.octave.org:8010/waterfall

I hope we can keep things all green all the time.

Also, can someone please give the OS X build some love and make it green
as well?

jwe

buildbot.png (161K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Behold! Buildbot's waterfall display has never been so green

mmuetzel
The Windows cross builds could also need some love :)
Summary:

  PASS                            15807
  FAIL                                1
  REGRESSION                          4
  XFAIL (expected failure)            5
  XFAIL (reported bug)               34
  SKIPPED (feature)                  58
  SKIPPED (run-time condition)       26

Those 4 regressions are bug 45507. The fail is intermittent for
"__opengl_info__ ()".

fntests_fails.log
<http://octave.1599824.n4.nabble.com/file/t371856/fntests_fails.log>  



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: Behold! Buildbot's waterfall display has never been so green

John W. Eaton
Administrator
On 11/11/2017 02:58 PM, mmuetzel wrote:

> The Windows cross builds could also need some love :)
> Summary:
>
>    PASS                            15807
>    FAIL                                1
>    REGRESSION                          4
>    XFAIL (expected failure)            5
>    XFAIL (reported bug)               34
>    SKIPPED (feature)                  58
>    SKIPPED (run-time condition)       26
>
> Those 4 regressions are bug 45507. The fail is intermittent for
> "__opengl_info__ ()".
>
> fntests_fails.log
> <http://octave.1599824.n4.nabble.com/file/t371856/fntests_fails.log>

True.

I'd like to add testing for the Windows builds.  Since they are cross
compiled, we'll need to do something like this once the nsis installer
or zip file is built:

   * start a VM running windows that can accept shell commands over an
ssh network connection

   * transfer the nsis installer or zip file

   * run the installer or unpack the zip file

   * run the octave tests

This could be one or more buildbot steps.  I'm not exactly sure how to
make the first part work.  It would be nice if it could use virtualbox
since that's what I already use but other solutions would also be OK if
someone can show me what to do.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Behold! Buildbot's waterfall display has never been so green

Mike Miller-4
In reply to this post by John W. Eaton
On Sat, Nov 11, 2017 at 10:32:02 -0500, John W. Eaton wrote:
> Also, can someone please give the OS X build some love and make it green as
> well?

We've looked at some of these before, here is a short summary of the
test failures on macOS.

* LLVM C++ library defect in number parsing. This results in Octave
  unable to parse a string like "4i" into a complex number with
  functions like scanf and str2double.

  This bug occurs on any operating system when Octave is built with the
  LLVM clang compiler and the LLVM C++ standard library.

  The LLVM devs are aware of this and seem to be waiting for some C++
  standards work to clarify this case before making any changes.

  LLVM bug https://bugs.llvm.org/show_bug.cgi?id=17782

  Octave bug https://savannah.gnu.org/bugs/?47413 (closed won't fix)

  This causes test failures in dlmread.cc, str2double.cc, importdata.m,
  and io.tst.

* Less accurate inverse trigonometric and hyperbolic functions in the
  macOS system math library?

  I'm not sure if anyone has looked into these yet.

  This broad description is meant to capture test failures in mappers.cc
  and asech.m (functions acos, acosh, asin, asinh, and asech).

  Most or all of these may be due to system library accuracy problems,
  which I think we also may see on Windows in some of these cases.

* The default system temporary directory seems to be symlinked or
  containerized somehow on macOS. The system defines the default
  temporary directory to be "/var/tmp" (normally "/tmp" on GNU/Linux
  systems). In Octave's test for fileattrib, it tries to ensure that the
  "Name" property is the same, but "/private/var/tmp" is returned.

  This test in fileattrib.m could be dropped or modified to avoid making
  the assumption that the default temporary directory is not a symlink.

  Maybe a simple canonicalize_file_name will fix this.

* There is a test in camzoom.m that tries to assert a specific viewing
  angle, which is failing with a slight tolerance error of 2*eps. I
  assume this would be safe to fix with a tolerance argument.

* The last two sorting tests in complex.tst are failing when the single
  precision and double precision results are compared to each other. I
  don't know if anyone has looked into this or where the underlying
  error happens.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Behold! Buildbot's waterfall display has never been so green

mmuetzel
In reply to this post by John W. Eaton
I managed to login via SSH to a Windows VirtualBox. This was on a Windows
Host. But the steps shouldn't differ much for a Linux host. (I tried to
start a VirtualBox inside my Ubuntu VM. But let's say: It didn't like it
much....).
So here is what I did:
1. Download a Windows VM for VirtualBox from [1]. I went with the Windows 10
machine. If you have another Windows installation available, you might
prefer to go with that because the "free" VMs de-activate after 90 days. (I
don't know what would happen after that date.)
2. After having started the VM, I downloaded the OpenSSH server from [2] and
installed it following the instruction on [3]. The following command didn't
work for me:
.\FixHostFilePermissions.ps1 -Confirm:$false
But the following did (with manual confirmation for each permission change):
.\FixHostFilePermissions.ps1
I also had to stop a running "OpenSSHd" service before I could start the new
one (step 11 in that guide).
3. After that, I shut down the VM and changed the network adapter to
"Host-only adapter". With that change, I could connect to the VM from the
VirtualBox host using PuTTY.

Hope that helps setting up a testing environment for Windows builds.

Markus

[1]
https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/#downloads
[2] https://github.com/PowerShell/Win32-OpenSSH/releases
[3] https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH




--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: Behold! Buildbot's waterfall display has never been so green

Dmitri A. Sergatskov
In reply to this post by John W. Eaton
​John,

I just realized you set --without-osmesa on all buildbots.
I would suggest to remove it at least on fedora's.
I think LD_PRELOAD trick is better -- at lease OSMesa related code gets compiled
and executed.​

Dmitri.
--


Reply | Threaded
Open this post in threaded view
|

Re: Behold! Buildbot's waterfall display has never been so green

John W. Eaton
Administrator
On 11/18/2017 05:37 PM, Dmitri A. Sergatskov wrote:

> I just realized you set --without-osmesa on all buildbots.
> I would suggest to remove it at least on fedora's.
> I think LD_PRELOAD trick is better -- at lease OSMesa related code gets
> compiled
> and executed.​

What library should be preloaded for the fedora build systems?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Behold! Buildbot's waterfall display has never been so green

Dmitri A. Sergatskov
On Sat, Nov 18, 2017 at 6:55 PM, John W. Eaton <[hidden email]> wrote:
On 11/18/2017 05:37 PM, Dmitri A. Sergatskov wrote:

I just realized you set --without-osmesa on all buildbots.
I would suggest to remove it at least on fedora's.
I think LD_PRELOAD trick is better -- at lease OSMesa related code gets compiled
and executed.​

What library should be preloaded for the fedora build systems?


​I have had it preloaded in the buildbot environment for quite some time;
you do not need to do anything special.

You can see it in e.g.:

LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0
 
jwe

​Dmitri.
​--

Reply | Threaded
Open this post in threaded view
|

Re: Behold! Buildbot's waterfall display has never been so green

John W. Eaton
Administrator
On 11/18/2017 08:10 PM, Dmitri A. Sergatskov wrote:

> On Sat, Nov 18, 2017 at 6:55 PM, John W. Eaton <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 11/18/2017 05:37 PM, Dmitri A. Sergatskov wrote:
>
>         I just realized you set --without-osmesa on all buildbots.
>         I would suggest to remove it at least on fedora's.
>         I think LD_PRELOAD trick is better -- at lease OSMesa related
>         code gets compiled
>         and executed.​
>
>
>     What library should be preloaded for the fedora build systems?
>
>
> ​I have had it preloaded in the buildbot environment for quite some time;
> you do not need to do anything special.
>
> You can see it in e.g.:
> http://buildbot.octave.org:8010/builders/gcc-fedora/builds/977/steps/configure/logs/stdio
>
> LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0

Maybe I'm being dumb here, but where do you set that for the buildslave?
  I'd like to do the same for mine.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Behold! Buildbot's waterfall display has never been so green

Dmitri A. Sergatskov
On Tue, Nov 21, 2017 at 4:19 PM, John W. Eaton <[hidden email]> wrote:
On 11/18/2017 08:10 PM, Dmitri A. Sergatskov wrote:
On Sat, Nov 18, 2017 at 6:55 PM, John W. Eaton <[hidden email] <mailto:[hidden email]>> wrote:

    On 11/18/2017 05:37 PM, Dmitri A. Sergatskov wrote:

        I just realized you set --without-osmesa on all buildbots.
        I would suggest to remove it at least on fedora's.
        I think LD_PRELOAD trick is better -- at lease OSMesa related
        code gets compiled
        and executed.​


    What library should be preloaded for the fedora build systems?


​I have had it preloaded in the buildbot environment for quite some time;
you do not need to do anything special.

You can see it in e.g.:
http://buildbot.octave.org:8010/builders/gcc-fedora/builds/977/steps/configure/logs/stdio

LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0

Maybe I'm being dumb here, but where do you set that for the buildslave?  I'd like to do the same for mine.

​I just put it in .bashrc.
So I actually login buildbot user...

 

jwe

Dmitri.

Reply | Threaded
Open this post in threaded view
|

Re: Behold! Buildbot's waterfall display has never been so green

John W. Eaton
Administrator
On 11/21/2017 06:41 PM, Dmitri A. Sergatskov wrote:

> ​I just put it in .bashrc.
> So I actually login buildbot user...

Oh.  On my debian systems, it is started by a system init script.  I'm
not sure how to add to the environment for the buildslave process.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Behold! Buildbot's waterfall display has never been so green

Dmitri A. Sergatskov
On Tue, Nov 21, 2017 at 6:29 PM, John W. Eaton <[hidden email]> wrote:
On 11/21/2017 06:41 PM, Dmitri A. Sergatskov wrote:

​I just put it in .bashrc.
So I actually login buildbot user...

Oh.  On my debian systems, it is started by a system init script.  I'm not sure how to add to the environment for the buildslave process.

jwe


​It is still a user. What happens if  you put .bashrc [*] in its $HOME
(i.e. /var/lib/buildbot )

[*] it should be .profile really

Dmitri.
--


Reply | Threaded
Open this post in threaded view
|

Re: Behold! Buildbot's waterfall display has never been so green

John W. Eaton
Administrator
On 11/21/2017 07:43 PM, Dmitri A. Sergatskov wrote:

> On Tue, Nov 21, 2017 at 6:29 PM, John W. Eaton <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 11/21/2017 06:41 PM, Dmitri A. Sergatskov wrote:
>
>         ​I just put it in .bashrc.
>         So I actually login buildbot user...
>
>
>     Oh.  On my debian systems, it is started by a system init script.
>     I'm not sure how to add to the environment for the buildslave process.
>
>     jwe
>
>
> ​It is still a user. What happens if  you put .bashrc [*] in its $HOME
> (i.e. /var/lib/buildbot )
>
>
> [*] it should be .profile really

The Debian package appears to create the buildbot user with the shell
set to /bin/false or /usr/sbin/nologin.

I thought maybe I could export variables in the environment when the
buildslave process starts, but that doesn't seem to work for me either.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Behold! Buildbot's waterfall display has never been so green

Dmitri A. Sergatskov


On Tue, Nov 21, 2017 at 9:32 PM, John W. Eaton <[hidden email]> wrote:
On 11/21/2017 07:43 PM, Dmitri A. Sergatskov wrote:
On Tue, Nov 21, 2017 at 6:29 PM, John W. Eaton <[hidden email] <mailto:[hidden email]>> wrote:

    On 11/21/2017 06:41 PM, Dmitri A. Sergatskov wrote:

        ​I just put it in .bashrc.
        So I actually login buildbot user...


    Oh.  On my debian systems, it is started by a system init script.     I'm not sure how to add to the environment for the buildslave process.

    jwe


​It is still a user. What happens if  you put .bashrc [*] in its $HOME
(i.e. /var/lib/buildbot )


[*] it should be .profile really

The Debian package appears to create the buildbot user with the shell set to /bin/false or /usr/sbin/nologin.

I thought maybe I could export variables in the environment when the buildslave process starts, but that doesn't seem to work for me either.

jwe


​At this moment I am guessing -- if buildbot runs as a service you may try to create a file​
/etc/sysconfig/buildbot and add "LD_PRELOAD=..." line in there.

Dmitri.
--


Reply | Threaded
Open this post in threaded view
|

Re: Behold! Buildbot's waterfall display has never been so green

John W. Eaton
Administrator
In reply to this post by Dmitri A. Sergatskov
On 11/21/2017 07:43 PM, Dmitri A. Sergatskov wrote:

> ​It is still a user. What happens if  you put .bashrc [*] in its $HOME
> (i.e. /var/lib/buildbot )
>
>
> [*] it should be .profile really

I swear on a stack of Emacs manuals that I tried this yesterday and it
didn't work.  But I must have been confused because it does work for me now.

I guess it does work even though the login shell is /bin/false or
/usr/sbin/nologin, because eventually buildslave does run a shell
command to execute commands, and however that happens, it reads the
.profile file.

So I now have the LD_PRELOAD in the environment for my buildslaves and I
removed the --without-osmesa configuration option in the buildmaster
configuration.

Sorry for the confusion.

jwe