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

[Santiago Vila]

On Thu, Sep 06, 2018 at 09:01:02PM +0300, Adrian Bunk wrote:
> On Mon, Sep 03, 2018 at 03:31:30PM +0200, Santiago Vila wrote:
>
> > FTBFS bugs have always been serious. Do you have a statement from a
> > member of the release team saying specifically that those bugs
> > should be buster-ignored?
> > 
> > (That's what we should really do, btw, if we wanted a serious bug not
> > to be RC).
> 
> https://release.debian.org/buster/rc_policy.txt
> ...
> 4. Autobuilding
> ...
> 	Packages must autobuild without failure on all architectures on
> 	which they are supported.
> ...

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.

In our case single-core amd64 is the same arch as multi-core amd64, so
a FTBTS in single-core amd64 is a FTBFS in amd64 for all purposes, and
amd64 is a released architecture.

Moreover, the above paragraph has more than one possible interpretation.

For some people (maybe you), "autobuild" in the phrase above is
only what happens in buildd.debian.org.

For me, autobuilding is just what autobuilders do. There is a set of
autobuilders in buildd.debian.org, there is another in
reproducible-builds, and I also have my own autobuilders.

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.

Literally tons and tons of FTBFS bugs have been filed on the basis
that the package failed to build in standard-configured autobuilders
(not necessarily buildd.debian.org).

I think this supports my interpretation of "autobuilding".

> Other cases of problems that do not happen when autobuilding like for
> example building with locales other than C are also usually considered
> Severity: important.

I agree with this, for a FTBFS bug to be reported as serious, it
usually needs to happen in an autobuilder which is not misconfigured.

The standard autobuilder has LANG=C and if not we call it misconfigured,
and for that reason most people do not usually report those bugs as important.

But being single-core in no way is a "misconfiguration", and I refuse
to consider such thing on the same "level" as building with a locale
different than C. An autobuilder which is single-core is not "defective".

[...]
> > Missing build-depends, for example, have always been serious bugs,
> > even if they do not happen in the official buildds.
> > 
> > Therefore "builds in buildd.debian.org" and "it has a FTBFS which is RC"
> > are not always the same thing.
> 
> This case has an own item in the list:
> 
> https://release.debian.org/buster/rc_policy.txt
> ...
> 4. Autobuilding
> 
> 	Packages must list any packages they require to build beyond those
> 	that are "build-essential" in the appropriate Build-Depends: fields.
> ...
> 
> There doesn't seem to be a similar special case for single-core machines.

I'm not sure what exactly you mean here.

There is not a special case for Intel CPUs. If official autobuilders
on amd64 had all of them Intel CPUs and a package FTBFS on AMD, it
would be a serious bug, because being Intel would be accidental, not
part of the "standard to build Debian packages".

> > You are perhaps assuming that I'm trying to build all packages on a
> > single machine which is able to build everything.
> >...
> 
> No, what I am saying is that you are focussing on a case that is
> mostly irrelevant in practice, and that trying to make it a high
> priority for other people to solve such issues is therefore a
> waste of time.

I'm not really "focusing" on single-core, it's just what I usually do
to build packages, that's all. In my QA work, 99% of the bugs I find
are not related to the number of CPUs at all.

Our problem is that you are trying to make single-core users as
second-class citizens of the amd64 architecture (in a similar way
unreleased architectures are already second-class because their FTBFS
may not be serious), while I still believe they deserve exactly the
same level of support of multi-core users, because there is only one
amd64 architeture, not two.

> [...]
> For VMs it would be a waste of money to pay for a VM that has a huge 
> amount of RAM and storage but only one CPU for building packages.
> It is both faster and cheaper to use a multi-CPU VM for that.

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.

> 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, the activity of package building will usually
happen (or must happen) on multi-core machines as well. That's yet to
be seen (and in fact, my autobuilders are a clear counter-example).


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

I would certainly see your point if the number was 200 or 300, but
the fact is that it's not.

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?

(I would say we need more people doing QA, not less).

And again: Do you plan to downgrade the few pending bugs I still have
to report about this? Based on what? On your subjective feeling of
that's relevant and it's irrelevant, on your subjective feeling of
what's practical and it's not?

Thanks.

(With apologies to the p4est maintainers, who at this point may be
wondering why are still discussing about the severity of this bug
and a few ones that will come and that will surely be equally easy and
simple to fix than this one).