Bug#907829: p4est: FTBFS on single CPU machines

[Santiago Vila]

On Sun, Sep 30, 2018 at 11:49:26PM +0300, Adrian Bunk wrote:

> Noone disagrees that these are bugs.

True, but you seem to consider them second-class FTBFS bugs.

However, it is not "just a bug", which is how you seem to paint it.

It is a FTBFS bug, possibly the worst kind of bug a package may have,
the kind of bug that should never be present in a stable release.
That's why we consider FTBFS bugs as serious, to ensure that a stable
release does not have any such bugs.

You seem to think that it's fine to require a "must build" only in
buildd.debian.org, but you do not realize that doing so is like having
an implicit "build-depends: buildd.debian.org".

We ship Debian packages to our users, but we do not ship
buildd.debian.org as part of the distribution.

So, we can't honestly say that "packages build from source" if they
only build ok in buildd.debian.org, which is the reason buildd.debian.org
should not be the "standard" to measure if a package builds or not.

And that's precisely why we invented build-depends, to make the builds
reproducible for everybody (reproducible as in "every time I try to
build the package, the package is built"), not just reproducible in
buildd.debian.org.

But now, in a stable release, we can't even have the assurance that
the package will build, because in addition to build-depends, the
build machine is now supposed to be a clone of buildd.debian.org in
every sense.

Why in earth do we want build-depends, then, if not to ensure that the
packages will build for everybody?

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

I'm not forcing anything. It's a FTBFS bug in a release architecture,
and it's therefore serious by nature. I'm not really "making" it RC.

As far as priority is concerned, I don't dictate the priority by which
maintainers should fix their serious bugs. If they want to say "hello" every
29 days in the bug report to avoid the autoremoval, that's up to them.

And BTW, I'm *offering* ssh access to the maintainers in case they are
unable to reproduce the bugs, yes, such a rude person I am.

> Noone else doing build testing would even consider using
> a single-CPU machine for that in 2018.

That's your opinion. Just because *you* would not do it personally
does not mean nobody should do it or that it's a bad idea.

I have already shown that it's *cheaper*. And yet you insist that it's
not the right(TM) way to build packages. Are you going to pay for the
extra money I would spend on virtual machines, just so that I build
packages "the only way approved by you" to build packages?

> > > 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:
> 
> [...]

Hmm, no, sorry, I was not referring to the paragraph you quote or the
kind of structural problems you describe.

I was just talking in a completely general sense, i.e. it is not a bug
for a package to "require" 4 GB of RAM to build (I mean "require" as
in "it builds with 4 GB but it does not build with 3 GB"). I would
hope that we agree on that.

Thanks.