Re: Behold! Buildbot's waterfall display has never been so green
On 11/11/2017 02:58 PM, mmuetzel wrote:
> The Windows cross builds could also need some love :)
> 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__ ()".
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.
This causes test failures in dlmread.cc, str2double.cc, importdata.m,
* 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