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

[Adrian Bunk]

On Mon, Sep 03, 2018 at 03:31:30PM +0200, Santiago Vila wrote:
> 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).

https://release.debian.org/buster/rc_policy.txt
...
4. Autobuilding
...
	Packages must autobuild without failure on all architectures on
	which they are supported.
...


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.


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

Bugs that are nearly always involved is that every major release of gcc 
regresses on memory usage.

Including cases where even "-O0 -g0" uses 2 GB RAM:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79030

For anyone who cares about building on low-end machines fixing such bugs 
should be the highest priority.


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

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.


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

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.

In reality people have nearly always multi-core machines but often not 
enough RAM. On 32bit the address space is an additional problem.

Like Debian has a huge userbase on the Raspberry Pi that has 4 CPUs
but only 1 GB RAM.

Single-core machines today are either ancient or low-end embedded,
and in either case the amount of RAM is the biggest problem.

"FTBFS on hppa" is pretty much the worst consequence in practice
when a package does not built with one core.

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.

Debian packages should build on single-core machines and it is a bug 
when they don't, but it is mostly irrelevant in practice.


> Thanks.

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