Bug#907829: p4est: FTBFS on single CPU machines

[Adrian Bunk]

On Tue, Oct 02, 2018 at 09:43:39PM +0200, Santiago Vila wrote:
> 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?
>...
> 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.
>...

There would be some logic behind your reasoning if you would apply the 
same standards you have for CPU usage to packages that FTBFS due to low 
amount of RAM.

You don't, that's why it is hard to take you seriously.

And the real-world problems when building software in 2018 are about RAM,
not single-CPU machines.

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

Cheaper only in fairytale world where other resources like RAM or 
storage aren't billed for a longer amount of time when the build
takes forever due to lack of CPUs.

Are you actually paying for the kind of virtual machines you are describing?

Everyone else uses the common-sense approach of using CPU-strong 
machines for CPU-intensive tasks like package building, if you
have made different practical experiences I'd be interested in
seeing the bills.

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

It is not a FTBFS on any buildd for a release architecture.

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

This is not about when to fix it, it is about who has to do the fixing.

It is *you* who is responsible to do the fixing for your pet project of 
building on single-CPU machines, not the maintainer.

Most other people do consider it nuts to do serious package building 
on single-CPU machines in 2018.

You are being a complete asshole when you are trying to use RC bugs for 
forcing other people to spend any time *ever* on your pet project.

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