Comment 0 for bug 1911400

This is failing reliably on autopkgtes infra:

- initially vs 3.1.3
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/o/octave-parallel/20201210_093838_8516f@/log.gz
- Trigger octave/6.1.1~hg.2020.12.27-3 octave-parallel/4.0.0-2build1 octave-struct/1.0.16-8:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/o/octave-parallel/20210108_091245_ef9a9@/log.gz
- all-proposed:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/o/octave-parallel/20210112_151852_47229@/log.gz
- this actually fails before the new octave, with the intorduction of the new octave-parallel
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/o/octave-parallel/20201024_131217_175b0@/log.gz

Containers with hirsute and hirsute-proposed work fine.
The following is the same in debian-sid, hirsute and hirsute-proposed:

root@h:~/octave-parallel-3.1.3# DH_OCTAVE_TEST_ENV="xvfb-run -a" /usr/bin/dh_octave_check --use-installed-package
Checking package...
Checking m files ...
[inst/pararrayfun.m]
...
[parcellfun]
PASSES 1 out of 1 test
Summary: 11 tests, 11 passed, 0 known failures, 0 skipped

Local VM based autopkgtests all work.
They work for hirsute and hirsute-proposed and and a selection of just
octave,octave-parallel,octave-struct.

Even the old tests against octave-parallel 3.1.3 failed.
So it is not just "coming with 4.x" of octave-parallel.
On LP they failed as well:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/o/octave-parallel/20210106_025958_c2157@/log.gz

Checking slightly deeper showed that the initial fail vs 3.1.3 was
NOT the same, it was a badpkg
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/o/octave-parallel/20201210_093838_8516f@/log.gz
But reruns of that apear to be the same as we see in other times
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/o/octave-parallel/20210102_194323_dbfce@/log.gz

All failing ones of them come down to:

!!!!! test failed
int32 scalar cannot be indexed with {

In comparison this seems fine on debci, there all 4.0.0-2 runs LGTM
https://ci.debian.net/packages/o/octave-parallel/unstable/amd64/
https://ci.debian.net/data/autopkgtest/unstable/amd64/o/octave-parallel/9643500/log.gz

Another moving piece in this puzzle is dh-ocatve which was updated on
30th December 2020. There isn't an old version of that in hirsute anymore,
it migrated.
 dh-octave | 0.7.6 | groovy/universe | source, all
 dh-octave | 1.0.3 | hirsute/universe | source, all
But the changelog isn't too suspicious.

Not sure if it is important - but the order on the tests differ.
Each run seem to have a random combination, but that is true for good and
bad runs.

Just to be clear on the error, it is of this type:
https://octave.org/doc/v4.2.1/Integer-Data-Types.html
octave:4> data.foo
error: scalar cannot be indexed with .
octave:5> data = int32(1234)
data = 1234
octave:6> data.foo
error: int32 scalar cannot be indexed with .

But without a reproducer it is hard where it might be from.
Maybe language dependent as local repros tend to get soem remainders
of local lang.

I'm out of good ideas, but will continue before taking a step back and masking the test.

Next:
I'll try to create a PPA that does the tests more verbose via:
xvfb-run -a octave-cli --debug --verbose --no-history --no-init-file --no-window-system inst/parcellfun.m
Maybe comparing that between local VM and autopkgtest.u.c will help to spot
the issue.

Further TODO's
- try the old dh-octave