ANNOUNCEMENT: Octave 7.1 RC2 now available!

Could someone point me to a (hopefully concise, simple) set of directions to set up an emulated 32-bit arm system on a Debian host so that I can try to reproduce the problem for myself?

Do you have an arm64 hardware?
Both Sébastien and myself are running chroot (me on Ubuntu and him, presumably, on Debian, both on arm64 hardware).

Nothing suitable for building Octave. I found some blog posts describing how to install an arm image with qemu but they seem complicated. I could try following one of those how-to guides but I was hoping for a bit simpler solution.

I have this:

but they are all seem to be sold out.

Of course the ideal is to have access to real ARM hardware, and to create some armel chroot inside, as pointed by @dasergatskov. In particular this is possible on Android devices, see: ChrootOnAndroid - Debian Wiki

I did my testing on real ARM hardware that belongs to the Debian project. Unfortunately I cannot give you access to it, because some track record of Debian contributions is needed before I can sponsor you.

Otherwise, I think the easiest solution is to create a foreign-architecture chroot inside a x86 machine, using transparent qemu emulation for running the binaries. See EmDebian/CrossDebootstrap - Debian Wiki

Since qemu emulation is not strictly the same as real hardware, there is a risk that the issue will not be replicable there, but it’s impossible to tell without testing. Another problem with qemu emulation is that it’s quite slow, so it’s going to take a long time to build Octave and repeatedly run the testsuite.

@jwe Well, actually you contributed to Debian as upstream developer of Octave. So maybe I can request temporary access to our ARM machines for you. Let me know if you want to try that route.

1 Like

Fosshost seems to have an aarch64 hosting.
1 Like

If you’re discussing FossHost let me crosslink Project infrastructure discussion - #6 by sr229 and tag @sr229.

I think we have a solution for bug #62207 now, so are there any other items left that would prevent making the 7.1.0 release?

Should we make a new test release first or just go to 7.1.0 now?

1 Like


We need a wider testing now than what RC can provide. Then we can make 7.2 :slight_smile:


Yes, 7.1 please, with 7.2 close behind based on feedback. Release early and often :smiley:

1 Like

Do we want to wait for @sebastien to confirm that this is actually fixed for the systems he was testing on? Or are we confident enough that the segfaults that @dasergatskov and @sebastien were seeing have been caused by the same underlying issues?

In the latter case, we could go ahead and release 7.1.0 imho.

I have uploaded to Debian the 7.0.92 tarball on top of which I applied the latest two buffer overflow changes. The build succeeded on all release architectures, including ARM 32-bit and MIPS 32-bit. Given the random nature of this bug, we cannot be 100% sure that it is now fixed, but that seems likely.


Thanks for testing.

Yes, it seems a bit random but uninitialized or out-of-bounds memory access could definitely cause that kind of trouble.

Unless there are any objections, I’ll start preparing the 7.1.0 release soon, so please try to avoid making any more changes on stable until that is done.


I pushed changesets to update version numbers for both Octave and mxe-octave and uploaded tar files for the 7.1.0 source release to I’m building Windows installers now and can upload those when the builds are done. I don’t currently have a way to test the installers myself. Would someone like to do that before we put them on Is it worth checking or should we just forge ahead?


I could try installing on Windows and run the test suite.

Thanks, I’ll let you know where to find them before I transfer them to

1 Like

I’m having trouble pulling MXE Octave via https:

$ hg pull --verbose --debug
Rufe von ab
sending capabilities command
query 1; heads
sending batch command
Suche nach Änderungen
taking initial sample
query 2; still undecided: 88, sample size is: 88
sending known command
(sent 3 HTTP requests and 4517 bytes; received 513 bytes in responses)
Abbruch: HTTP Error 502: Bad Gateway

I think my last update was about 2 days ago. It was still working then.
The web interface still shows the latest(?) pushes up to 911c098e5930 from the same PC…

Edit: Must be something on my end. Tried with my laptop and it still works…
Sorry for the noise.

I saw an automated e-mail that 7.1.0 had been uploaded to I went and downloaded the source, built, and installed and it all runs fine on a vanilla Kubuntu 18.04 box.

I added a 7.1.0 Release tag on Savannah, and hid the tags for the release candidates 7.0.90 and 7.0.92 now that they are unnecessary.


Download has not updated from 6.4.0 to 7.1.0 yet. Does it take place automatically?