Release candidate available

The first release candidate for Octave 6.3 is available now at alpha.gnu.org:

-rw-r--r-- 1 3003 3002  21641445 Jun 06 15:12 octave-6.2.90.tar.lz
-rw-r--r-- 1 3003 3002        95 Jun 06 15:12 octave-6.2.90.tar.lz.sig
-rw-r--r-- 1 3003 3002  25329812 Jun 06 15:12 octave-6.2.90.tar.xz
-rw-r--r-- 1 3003 3002        95 Jun 06 15:12 octave-6.2.90.tar.xz.sig
-rw-r--r-- 1 3003 3002  32858984 Jun 06 15:12 octave-6.2.90.tar.gz
-rw-r--r-- 1 3003 3002        95 Jun 06 15:12 octave-6.2.90.tar.gz.sig
-rw-r--r-- 1 3003 3002 341334180 Jun 06 14:59 octave-6.2.90-w64-installer.exe
-rw-r--r-- 1 3003 3002        95 Jun 06 14:59 octave-6.2.90-w64-installer.exe.sig
-rw-r--r-- 1 3003 3002 334306012 Jun 06 15:03 octave-6.2.90-w64.7z
-rw-r--r-- 1 3003 3002        95 Jun 06 15:03 octave-6.2.90-w64.7z.sig
-rw-r--r-- 1 3003 3002 595668577 Jun 06 15:11 octave-6.2.90-w64.zip
-rw-r--r-- 1 3003 3002        95 Jun 06 15:11 octave-6.2.90-w64.zip.sig
1 Like

Downloaded and built tarball on Kubuntu 18.04. make check passes with no failures.

Thanks. I’ll run some tests on Windows when I come around to it.

The mailing lists are rather inactive recently. Should we still announce the release candidate on the maintainer and the help mailing lists to get “maximum” test coverage?

Edit: I ran __run_test_suite__ and the tests for all Octave packages bundled in the Windows installer without noticing any regressions.

Edit 2: I noticed that version 1.2.3 of the matgeom package was released a few days ago. But we are still packaging matgeom version 1.2.2 in the Windows installer.
Should we update to the newer version before the final release?

The matgeom package is pure m-code. I think it is straight forward for users to update it via pkg install later.

I ran a pkg update after installing and other than a couple warnings about shadowed functions it installed just fine.

1 Like

For a minor release, I don’t think it is necessary to update packages.

I’m unable to reproduce the problem with hgsave using the Windows binary I uploaded on a Windows 10 system.

Some Octave packages are hard to compile on Windows. Or we are applying local patches (e.g., to make them work on that OS).
So as a general guide, we decided to update Octave packages on the release branch to avoid possible issues with pkg update on Windows.

That doesn’t apply in this particular case (like @siko1056 and @nrjank reported).

But I’m still leaning towards updating the package in MXE Octave. I ran pkg update matgeom followed by pkg test geometry and didn’t see any regressions. Since it consists only of .m files and seems to work fine after the update on Windows, it is probably very low risk to update the package between release candidate and final release.
On the other hand, the update probably includes fixes, and we’ll avoid questions where the answer would be "run pkg update matgeom".

What do you think?

If the package update doesn’t block the release, causes no additional effort (rebuilding everything from scratch) and no regressions happen in tests, just update it :slightly_smiling_face:

OK. I guess I was assuming that it was reasonably easy to use a pkg install or update command to get newer versions, even on Windows. If not, then updating to the latest package is fine with me.

Is matgeom the only one that needs to be updated or are there others?

Since matgeom (June 1st) I did not release anything on Octave Forge.

@ttl wants to release control 3.3.0 soon, but he seems to be testing the package right now.

Same for OpenSUSE 15.2: no failures :slightly_smiling_face:

a pkg update off the release candidate only identified matgeom as having an available update.

I updated the matgeom package here:
mxe-octave: 25921af60e29

The release of control 3.3.0 is in preparation, but will still take some time. Therefore, this release should not be included in the 6.3 release of octave.
I would like to have more feedback about the install process on different platforms and will post the link to a release candidate soon.

using installer on Win10 (i9-9880h) with openblas

>> test eigs
***** testif HAVE_ARPACK
 A = magic (100) / 10 + eye (100);
 opts.v0 = (1:100)';
 opts.maxit = 10;
 warning ("off", "Octave:eigs:UnconvergedEigenvalues", "local");
 d = eigs (A, 10, "sm", opts);
 if (isreal (d))
   assert (d(10), NaN);
 else
   assert (d(10), NaN +1i*NaN);
 endif
!!!!! test failed
eigs: error in dneupd: DNAUPD did not find any eigenvalues to sufficient accuracy.
This should not happen.  Please, see https://www.gnu.org/software/octave/bugs.html, and file a bug report

and

>> test subplot
***** test
 hf = figure ("visible", "off");
 unwind_protect
   for ii = 1:9
     hax(ii) = subplot (3,3,ii);
   endfor
   subplot (3,3,1);
   assert (gca (), hax(1));
   subplot (2,1,1);
   assert (ishghandle (hax),[false(1,6), true(1,3)]);
 unwind_protect_cleanup
   delete (hf);
 end_unwind_protect
!!!!! test failed
ASSERT errors for:  assert (ishghandle (hax),[false(1, 6), true(1, 3)])

  Location  |  Observed  |  Expected  |  Reason
    (4)           1            0         Abs err 1 exceeds tol 0 by 1
    (5)           1            0         Abs err 1 exceeds tol 0 by 1
    (6)           1            0         Abs err 1 exceeds tol 0 by 1
>>


Perhaps relevant:

>> for ii = 1:9
     hax(ii) = subplot (3,3,ii);
   endfor
>>    subplot (3,3,1);
>>    assert (gca (), hax(1));
>>    subplot (2,1,1);
>> ishghandle (hax)
ans =

  0  0  0  1  1  1  1  1  1

>>

Those tests pass for me on Windows 10 (i5-4690).

Did you set anything special in your .octaverc or other startup files?

No. I really do not use octave on Windows, install it just for the test.

For me:

>> version -blas
ans = OpenBLAS (config: OpenBLAS 0.3.12 NO_LAPACK NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY Haswell MAX_THREADS=24)
>> test eigs
PASSES 190 out of 190 tests
>> test subplot
PASSES 3 out of 3 tests
>> for ii = 1:9
     hax(ii) = subplot (3,3,ii);
   endfor
>> subplot (3,3,1);
>> assert (gca (), hax(1));
>> subplot (2,1,1);
>> ishghandle (hax)
ans =

  0  0  0  0  0  0  1  1  1

Does it also fail with reference BLAS?

With ref blas eigs passes, but subplot still fails (both gui and cli) the same way.

The default branch of MXE Octave builds OpenBLAS 0.3.13. The release branch is still on OpenBLAS 0.3.12.

Could you please check if the error with eigs also occurs with a nightly build from the default branch? You can download a nightly build (“octave-mxe-default-w64” for a build from the default branch) from here:
Buildbot (octave.space)