Bug#932795: Ethics of FTBFS bug reporting

[Ansgar <ansgar@debian.org>]

Russ Allbery writes:
> Ansgar <ansgar@debian.org> writes:
>> Even more, from the "32 bit archs in Debian" BoF at DebConf15 I remember
>> the suggestion that one might have to switch to 64-bit compilers even on
>> 32-bit architectures in the future...  So building packages would in
>> general require a 64-bit kernel, multi-arch and 4+ GB RAM.
[...]
> I'm rather dubious that it makes sense to *require* multiple cores to
> build a package for exactly the reason that Santiago gave: single-core VMs
> are very common and a not-very-exotic environment in which someone may
> reasonably want to make changes to a package and rebuild it.  But maybe
> I'm missing something that would make that restriction make sense.

Well, the package that gave raise to this issue is this:

   The p4est software library enables the dynamic management of a
   collection of adaptive octrees, conveniently called a forest of
   octrees. p4est is designed to work in parallel and scale to hundreds
   of thousands of processor cores.

I doubt many people from that application domain work with single-core
systems.

There are other interesting issues as well: I recently had problems with
running a numerics library in a VM where the CPU supports AVX-2, but the
VM instance did not.  But the library used the CPU model to select its
preferred implementation (which then used AVX-2 instructions)...

Just like issues with single-CPU systems this is a bug, but not one with
a high priority for me.

Ansgar