[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#932795: Ethics of FTBFS bug reporting



On Tue, Jul 23, 2019 at 01:30:58PM +0100, Ian Jackson wrote:

> I suggest the following approach:
> 
>  - Introduce the words "supported" and "reasonable".  So
> 
>     Packages must build from source in any supported environment;
>     they should build from source in any reasonable environment.
> 
>  - Provide a place to answer these questions:
> 
>     What is a supported, or a reasonable, environment, is not
>     completely defined, but here are some examples:
> 
>     - An environment with only one cpu available is supported.
>     - An environment with a working but non-default compiler
>       is reasonable but not supported.

I believe this is more complex than required, and will not necessarily
solve the problem.

Suppose we write clearly in Debian Policy that build environments with
one CPU are fully supported, and yet there are people who claim that
because buildds have several cores, it is wrong to report such bugs
as serious. We would be back at square one.

This is why I've described this problem as kafkaesque.

> On the point at issue, do these packages build in a cheap single-vcpu
> vm from some kind of cloud vm service ?  ISTM that this is a much
> better argument than the one you made, if the premise is true.

Sorry, I'm a little bit lost here. What do you refer exactly by "these packages"?

All packages in Debian build ok in a single CPU system, except the few
ones I've already reported in the last months/years and maybe a few
ones I have not reported yet because of lack of time. I estimate there
must be only a handful of packages with bugs like this one.

Whether single-cpu machines are cheap or not depend mainly on the
amount of RAM, but contrary to what some people insinuate, my goal is
not and never has been to build packages in "cheap" machines, nor I am
complaining that packages do not build ok in "cheap" machines.

My complain is that some packages do not build ok in machines which
are perfectly capable of building them, and yet we seem to be trying
to shift the blame and the responsability to the end user for not
having a clone of buildd.debian.org.


Russ Allbery wrote:
> I'm rather dubious that it makes sense to *require* multiple cores to
> build a package for exactly the reason that Santiago gave: single-core VMs
> are very common and a not-very-exotic environment in which someone may
> reasonably want to make changes to a package and rebuild it.  But maybe
> I'm missing something that would make that restriction make sense.

Thanks a lot for this. No, I don't think you are missing anything.

> And it's possible that multi-core may be a reasonable requirement
> for that "heavy package" tier.

How would that become a requirement? Big packages (as in "packages
requiring a lot of RAM or a lot of disk") do not really need more than
one CPU to build because of they being "big". In theory, using more
than one CPU should just make the build to go faster, that's all.

Ideally, it should be up to the end user to decide if they want the
package to build faster or not, I don't see it as something that needs
to be regulated by Policy.

A funny example which could be seen as a counter-example but it is not
in my opinion:

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

This is a Makefile bug in gcc-8-cross, a package which would qualify
as "big". Maintainer did not initially believe it was a real bug,
maybe because he built the package a lot of times in the past and the
bug never happened to him.

See what the maintainer did afterwards:

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

Would we say in this case that the package "requires" more than
one CPU to build?

To me it seems like a bug which may happen to anybody, and the fact
that it did not happen in buildd.debian.org yet is due to pure chance.

It must be noted that many of the bugs I found while building on
single-CPU systems are really like the one in gcc-8-cross, and not
like the one in p4est. A few more examples:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906623
  heimdal, FTBFS because of Makefile bug

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923476
  webkit2gtk, FTBFS because of Makefile bug


Thanks.


Reply to: