So, after some cleanups in the package and a backported patch from upstream
that increases the test timeout from 2 to 4 minutes (and this consistently fixes
failures on i386), we now have two runs in a row where the armhf builder OOM:
so your comment regarding --threads=0 does not seem to apply? -- not sure, please let me know what you think.
The consistent OOM is surprising given that you state that the worker has 250GB of RAM. Looking at the logs,
I note that the tests are being passed the option -p 160 by the dh-golang helper, so it will build
and run test executables concurrently. That confirms to me that we are indeed running on these 250GB/160 core workers.
Is it possible that armhf is setting up ulimits that limits the amount of memory the test may allocate?
The thing is, I am able to pass the tests just fine on the on the porterbox
abel.debian.org, which
has significantly fewer cores (4) and memory (4GB).
Maybe we need to limit the concurrent builds/test in debian/rules so that it never users more than
let's say 8 cores or something?
As far as I understand, all golang packages use autodep8 to declare the tests,
which doesn't support adding the Architecture field. In order to get around this,
I guess I could remove the Testsuite field from debian/control and add a
debian/tests/control that looks similar to what autodep8 generates, but adds
the Architecture: !armhf restriction.
Is that best practice or am I overlooking something?