Bug#907829: p4est: FTBFS on single CPU machines

[Adrian Bunk]

On Sun, Sep 30, 2018 at 09:08:30PM +0200, Santiago Vila wrote:
>...
> There needs to be a *very* powerful reason for a package to "need"
> more than one CPU, and so far I have never found a package which
> "legitimately" needs more than one CPU.
>...

Noone disagrees that these are bugs.

But it is simply rude trying to use RC bugs saying
  To reproduce, please try building with sbuild on a single-CPU machine, as I did.
for forcing this as high priority upon other people.

For the binary packages we are providing as part of our releases to
our users it is not relevant whether a single-CPU machine can build 
a package, and as already explained there are plenty of other reasons why
some supported machine might not be able to build some specific package.

It is fine if you have your personal pet project of keeping packages 
buildable on single-CPU machines, and there is some overlap with other
peoples pet projects like keeping the hppa port of Debian alive.

If someone wants to works on keeping Debian buildable on single-CPU 
machines or keeping the hppa port alive that is fine - everyone has
the right to decide what he wants to do with his own time.

But trying to use RC bugs for forcing other people to do the work
on such a pet project like keeping Debian buildable on single-CPU
machines or keeping the hppa port alive is not OK - there is no
excuse for trying to force other people to work on your pet project.

Already for some time your attempts to force doing the work on your 
pet project upon other people has generated perfectly understandable
hostility from other developers towards you that obscures all the
useful other work you are doing.

And yes, this is nothing more than your personal pet project.
Noone else doing build testing would even consider using
a single-CPU machine for that in 2018.

> > The result is the same in both cases - a machine supported by Debian 
> > cannot build a package.
> 
> Except that in one case we have a bug and we both agree that it's a
> bug, and in the other case it is not a bug and we both agree that it's
> not a bug.
>...

Please do not make incorrect claims about what I said.

Let me repeat what I actually said about RAM usage:

<--  snip  -->

Bugs that are nearly always involved is that every major release of gcc 
regresses on memory usage.

Including cases where even "-O0 -g0" uses 2 GB RAM:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79030

For anyone who cares about building on low-end machines fixing such bugs 
should be the highest priority.

<--  snip  -->

Your "it is not a bug" claim is also completely wrong in the cases where 
the memory usage of the compiler exceeds the virtual address space on a 
32bit architecture, I am constantly submitting workaround patches for 
such cases - and different from single-CPU building these memory 
exhaustion bugs are RC build failures that do happen on our buildds.

> Thanks.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed