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

[Santiago Vila]

On Mon, Sep 03, 2018 at 01:03:27PM +0300, Adrian Bunk wrote:
> On Mon, Sep 03, 2018 at 01:22:47AM +0200, Santiago Vila wrote:
> >...
> > This single-CPU thing has been discussed before and the bugs have
> > never stopped being serious:
> > 
> > https://lists.debian.org/debian-devel/2017/02/msg00380.html
> >...
> 
> Do you have a statement from a member of the release team saying so?

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

> >...
> > Ok, my autobuilder is not one of buildd.debian.org. So what? Packages
> > *must* be buildable on any system where Debian itself runs (provided
> > there is enough RAM and disk), i.e. on any autobuilder which is not
> > misconfigured. Having a single CPU does not count as a "misconfiguration".
> 
> It is completely arbitrary if you want to define that requiring any
> amount of RAM or disk usage is fine, but a similar requirement for 
> the number of CPUs must not happen.

No, it's not arbitrary at all, because requiring a big amount of RAM
is not a bug [*], while requiring 2 CPUs has always been a serious bug.

[*] Only in very extreme cases like this one I went ahead and filed a bug:

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

but never as a serious bug.

> > Nothing else, like CPU speed, number of CPUs, instruction set above
> > the baseline amd64, etc. should be assumed or taken for granted
> > "just because buildd.debian.org is that way".
> > 
> > Otherwise the package will have a hidden and undeclared
> > "build-depends: buildd.debian.org" (so to speak), and I would consider
> > such build restriction completely unacceptable.
> >
> > No, we don't follow "de-facto standards", we just follow standards,
> > and so far we have not formally declared single-cpu systems as "unsuitable
> > for building" (by way of general resolution or by policy).
> >...
> 
> What packages actually follow is "builds on the buildds".

No, that's only a close approximation of what we do, but it's not what we do.

Building ok in buildd.debian.org is a necessary condition but it's not
sufficient.

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.

> We don't need a GR to formally declare that
> - some packages don't build with only 1 CPU,
> - some packages don't build with only 8 GB RAM
> - some packages don't build with only 70 GB storage

No, what we don't need is a GR to declare that FTBFS bugs are serious.

If you think certain serious bugs should not be RC, that's an issue
for the release managers to decide, and we would have to use
buster-ignore for that.

What you did here sounds like "downgrade because this is not RC
because I say so" to me.

> >...
> > And no, single-cpu is not exotic. You are only considering physical
> > machines, but there is a whole world of virtualization out there where
> > you can still choose the number of CPUs in the system, and single-cpu
> > is still cheaper (and I guess it will still be for a long time).
> 
> Yes, but that usually also limits the amount of RAM

You are speaking about linode, digital ocean, vultr, etc.

But other providers, like GCE or mivocloud, allow changing CPUs and
RAM in an independent way, so that's not really a problem for me.

> and you are fine with packages using any amount of that.

I'm not really "fine" with any amount of RAM, but I accept as a fact of
life that some packages will need a lot of RAM.

But I can't accept as a fact of life that a package needs several CPUs
to build, because that's a serious bug. In this case it's the package
the one needing a change, not my building setup.

[ You will notice that not even for this particular report I have
  needed a multi-cpu machine. The build log suggested that it was a
  "number-of-cpu" problem. The maintainer has suggested a patch,
  I tried it, and it worked ].

> The machine you want to enable to build all packages would
> have the following specs:
> - 1 CPU
> - 16 GB RAM
> - 75 GB storage
> 
> This is an insane configuration.

You are perhaps assuming that I'm trying to build all packages on a
single machine which is able to build everything.

That would be insane indeed, but that's *not* what I do, because
it would be a waste of resources.

I build packages in several different machines, I keep track of the amount
of RAM required by each package so that I'm efficient at using RAM.

Also, some of my virtual machines are self-hosted by KVM and virt-manager,
so I can easily have a single CPU and a lot of RAM if required.

On the contrary, I do *not* keep track of packages requiring more than
one CPU in order to build them in a different machine, because that's
a serious FTBFS bug and I should never have to special-case those
packages in my building setup.

> [...]
> 
> Don't get me wrong, a package not building on a machine with 1 CPU
> is a bug that should be reported.
> 
> But trying to enforce to be able to build every single package in the 
> archive on single-CPU machines is something that strikes me as a huge
> waste of time - we have so many far more relevant bugs that should
> be debugged and fixed before that.

You probably say that because you have absolutely no idea about the
exact (or even approximate) number of packages that do *not* build
with a single CPU.

But I do, because I have been building on single-CPU machines for a
long time already. There are actually just a few packages pending to
be reported in buster.

Now the issue is: Are you going to alter the severity of the bugs of
this kind that I will report in the following weeks just because you
think they should not be RC? Based on what?

And yet you are the one speaking about wasting time?

Thanks.