Bug#907829: p4est: FTBFS on single CPU machines (?)

[Adrian Bunk]

On Thu, Sep 06, 2018 at 10:46:07PM +0200, Santiago Vila wrote:
> On Thu, Sep 06, 2018 at 09:01:02PM +0300, Adrian Bunk wrote:
>...
> Ok, I started saying "FTBFS = serious" but the above does not really
> count as a counter-example. We agree that a FTBFS bug in an unreleased
> arch is not RC, that's completely out of the discussion.
>...
> You will have noticed that we usually report FTBFS bugs when a package
> fails to build in any "correctly" configured autobuilder, we don't wait
> for the build failure to happen on buildd.debian.org.
>...

No release architectures has a single-core autobuilder at buildd.debian.org.

And it is completely out of the discussion that any would in the future.

> That's simply not true. Here is the math:
> 
> In the best case scenario, a machine with 2 CPU will usually cost
> double than a single-CPU. It will build the package in half of the
> time, but since it cost double per minute, the total cost is
> approximately the same, not cheaper at all.
> 
> But that's only the best case scenario. The worst case scenario is
> that you build all packages using 2 CPU but only a proportion of them
> support (and benefit from) parallel build. For those who don't we are
> wasting completely the extra CPU.
> 
> So no, it's not cheaper in general, and it may be even more expensive.

Which cloud provider are you using?

Your math assumes that expensive resources like RAM or storage would be 
free, and not cost you more when you have to provision them longer due 
to the longer build time.

If you want to do do the math properly, you have to take into account
that faster build times mean fewer seconds you also have to pay for 
everything else.

> > Debian packages should build on single-core machines and it is a bug 
> > when they don't, but it is mostly irrelevant in practice.
> 
> Hmm, "mostly irrelevant" and "in practice".
> 
> The problem with that is that it's highly subjective. We don't
> "optimize for Internet Explorer". We follow standards, and being
> multi-core is not an intrinsic property of the amd64 architeture.
> 
> You seem to think that because desktop computers are almost always
> multi-core these days,

"these days" was 10 years ago.

Today even cheap embedded devices like a Raspberry Pi are quadcore.

>...
> In practice, there is only a *handful* of packages that do not build
> on single-core. The actual figure is closer to 5 than 10, 20 or
> whatever is the number that you might be guessing.
> 
> Would it be the same for you if this number was 5 than if it was 200
> or 300? (BTW: What was the approximate number you had in mind?)

Yes.

These are bugs, but in reality "FTBFS on hppa" is the most relevant
consequence.

>...
> You keep talking about "not RC" for "practical" reasons, but for me it
> is *really* practical that I can build 99.98% of all Debian packages
> on single-cpu machines. It is not also a practical thing for Debian
> that people can make QA in a cheap way, without wasting CPUs?
>...

When you buy hardware today you usually get more cores than you can 
use, but RAM costs a fortune.

Like it is a real problem that plenty complete ARM quadcore systems
like the Raspberry Pi are available in the $30-40 range, but anything
with >= 8 GB RAM is ridiculously expensive.

This is the core reason why you are facing so much resistance when you 
are trying to use release critical bugs to force people to spend their
spare time on something that has no actual practical relevance.

It also obscures the many useful bug reports you submit when you are
insisting that whatever fails to build in your weird setup should be
considered release critical.

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