On 1/27/21 12:12 PM, Rafael Laboissière wrote:
N.B.: I am moving this discussion into the mailing list of the Debian
Octave Group and also adding Qianqian Fang (the original developer of
the package and also upstream author) to the Cc list.
* John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> [2021-01-22
12:10]:
Source: octave-iso2mesh
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org
The last upload octave-iso2mesh arbitrarily limited the list of build
architectures on the assumption that only certain architectures have
buildds with enough disk spaces which is certainly not true. The
available disk space depends on the buildd used, not the architecture.
Furthermore, it may happen that the buildd disk space fills up which
can happen if the machine crashes, gets automatically rebooted and
the previous builds are therefore not cleaned up. This is something
observed on the buildd blaauw which crashes regularly due to a bug in
the kernel [1].
Could you therefore remove the architecture limitation list or - at
least - re-add the Debian Ports architectures (e.g. alpha, hppa,
ia64, m68k, powerpc, ppc64, riscv64, sh4, sparc64 and x32)?
hi Rafael, thanks for looping me in.
@Adrian,
as Rafael mentioned, the crash was caused by is compiling libCGAL based
executables when building iso2mesh-tools, which is a dependency of
octave-iso2mesh.
Most of these errors were caused by "*virtual memory exhausted*" error
by gcc during compilation. I've seen similar errors when submitting
iso2mesh for Fedora previously, see
https://bugzilla.redhat.com/show_bug.cgi?id=1758626#c11
one of the failed builds can be found at the below link, but the log
files seems to no longer exist
https://koji.fedoraproject.org/koji/taskinfo?taskID=38115425
occasionally, the build may go through, but often times, it comes back
in the next build attempt.
I'd love to make iso2mesh available on all supported platforms (which it
should compile if given enough virtual memory), but given the unreliable
compilation, excluding some of these platform is just practical
workaround. Eventually, we can either solve this issue by fine tuning
the build system virtual memory parameters, or work with CGAL developers
to find out if there is a flag to reduce memory overhead. I suppose this
issue is not alone, and should appear on other utilities that depend on
libcgal-dev.
if anyone knows other workarounds to build libcgal-based binaries on
embedded processors, we are happy to know and implement.
Qianqian
I am the responsible person for the build architecture limitation. It
was an attempt to get octave-iso2mesh into bullseye, at least for a
limited set of release-official architectures. However, the package
did not yet migrated into testing, even though a request for the
removal of the binary packages for armel, armhf, and mipsel have been
filed (see Bug#979623).
Those architectures have been removed because the CGAL-dependent
building consumes lots of memory. I think that other packages in
Debian are been hit by the same problem.
I fully agree that this is not an ideal situation. I think that, once
Bug#979623 is fixed, we should remove the architecture restriction.
What do the others think?
Best,
Rafael Laboissière
