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

Santiago Vila sanvila at unex.es
Fri Sep 7 13:45:31 BST 2018


On Fri, Sep 07, 2018 at 10:46:36AM +0300, Adrian Bunk wrote:
> On Thu, Sep 06, 2018 at 10:46:07PM +0200, Santiago Vila wrote:
>
> > 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.

I was trying to argue that the official autobuilders are not, and
should not be, the only measure by which we consider a bug to be
serious or not.

And I put a very simple example: Imagine that all our amd64
autobuilders are Intel and there is a package which FTBFS on AMD.

Are you really trying to tell me that the FTBFS bug would not be
serious "because it does not happen on buildd.debian.org"?

I would like to believe that you would say "baseline violation",
since that's what you said (and I fully agree) here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906697

Now you could maybe argue that using a package and building it are
"different" things.

And they are in fact different things: Being able to build a package
is actually *more* important than being able to use it, because
building is a *precondition* for use. If I try to build a package and
it fails, there is no package to use. This is the very reason why we
consider a FTBFS to be serious. The package is completely unsuitable
for release. It prevents the package from working at all because there
is no package to use at all.

Now the question: Do you want to deprecate using Debian on
single-core, or only building Debian on single-core?

> > 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?

I have actually used many of them. The most popular ones like vultr,
digital ocean or linode offer all-in-one packages in which more CPUs
means more RAM and of course more money, usually in powers of two.

For example, if we compare the most expensive single-CPU with the
cheapest multi-CPU on Vultr, that means going from $10/month to
$20/month:

https://www.vultr.com/pricing/

This is double the price for something which may or may not take
half the time (depending on the package).

So yes, I already did the math and definitely building on several CPUs
is not cheaper.

On GCE you can pay for CPUs and RAM independently, but CPUs are
generally more expensive than RAM:

https://cloud.google.com/compute/pricing

(The disk here is very cheap: $0.04 by GB-month).

Why are we discussing about the price, anyway?

Are you trying to discriminate against people who build on single-cpu
because they are rich, because they are poor, because in your opinion
they don't use their resources efficiently, because of what?

Thanks.



More information about the debian-science-maintainers mailing list