Bug#932795: How to handle FTBFS bugs in release architectures
On Wed, Jul 24, 2019 at 12:05:45PM +0100, Simon McVittie wrote:
> Do I understand correctly that you are asking the TC to exercise our
> power to overrule developers, in order to overrule the maintainer's
> and/or the release team's judgement about the severity of (bugs like)
> #907829?
Not yet.
> Or are you asking the TC for advice, or are you asking us to use a
> different one of the TC's powers?
Advice first.
> There are many aspects of a build environment that might be considered
> reasonable and might not, and they are generally evaluated on a
> case-by-case basis. A working build environment needs "enough" RAM (a
> lot more for gcc or WebKit than for hello); it needs "enough" disk space
> (likewise); it needs a writeable /tmp; it needs a correctly-installed
> Debian toolchain (I hope you wouldn't argue that it's RC if a package
> FTFBS with a patched gcc in /usr/local/bin); it needs to be on a
> case-sensitive filesystem (I hope you wouldn't argue that FTBFS on
> FAT/NTFS/SMB would be release-critical); it needs to not have weird
> LD_PRELOAD hacks subverting its expectations; and so on.
Ok, my build environment:
* Had enough RAM.
* Had enough disk.
* Had a writeable /tmp.
* Had build-essential installed and it's dependencies (I'm using sbuild).
* Had a case sensitive filesystem (ext4).
* Did not have LD_PRELOAD hacks (I use eatmydata as much as I can, but
I never report "FTBFS with eatmydata" as serious)
* Did not try to build the package as uid 0.
The only thing it did not have was more than one CPU, but AFAIK that's
not something that may be considered as a misconfiguration.
> For the specific question of whether a single CPU core is a "reasonable"
> build environment, my answer at the moment is "I don't know".
That's basically the first question I'd like to have answered by
the TC, yes. I would express it this way:
Does "build-essential" imply multi-core?
I believe there is a wide consensus that a package which does not
build with one CPU is a bug (I'm *not* talking about severity here).
Even if we ever wanted to allow packages to "need" more than one CPU
for building, I'd like to believe that we would do so by introducing a
new control field for that, say, Build-CPU, instead of making
multi-core mandatory for all packages.
The great paradox of all this is that we would be better by having
this stupid Build-CPU field and enforcing it than not having anything
at all. Fixing a Makefile bug may take time and effort, but it may not
be argued that adding a "Build-CPU: 2" line to debian/control would be
an unbearable burden for maintainers.
At least that way Debian Policy would say the truth again. It will be
possible again to build a package on a system having build-essential,
the build-dependencies and the number of CPUs in the Build-CPU field.
Thanks.
Reply to: