Re: Help requested: Packages which FTBFS randomly
On Mon, Feb 20, 2017 at 12:05:42AM +0100, Vincent Bernat wrote:
> More and more packages come with test suites to help developers and
> packagers ensure things are working as expected. It would be great if
> test suites didn't have failures of their own but it's better to have
> them and it's understandable that most packagers don't want to blindly
> disable them.
Well, I don't advocate for doing anything "blindly", I just expect
individual tests to be disabled when it's abundantly clear that they
are wrongly designed.
> Your chosen build environment is not common and fixing build failures
> for uncommon environment may seem a waste of the "Debian-allocated time"
> for some people (including me).
Wait a moment. How we do define "common" when applied to a "build
environment"? Number of packages built? Number of people building with
such build environment? What if somebody has a build environment and
builds packages 100 times as often as it's done on buildd.debian.org?
Does such build environment becomes "common" then? I think it should.
I would say, for example, that the build environment used by Lucas
Nussbaum in his archive rebuilds, or the one in reproducible builds
could easily be more "common" than buildd.debian.org, considering
that the same packages are built over and over again.
My own autobuilders take 7-10 days to build all packages, and they are
running all the time. For Arch:all packages I build them a lot more
often than buildd.debian.org, who only build them once when the
maintainer uploads them, or even zero times when the maintainer does
not upload in source-only form.
> The policy doesn't state that a package
> must build when there is not enough disk space or memory.
It would not be reasonable to have a policy for that. Each package
needs what it needs. I think you are comparing apples and oranges here.
> Maybe it would be far simpler to allow packages to fail to build
> if there is not enough CPUs.
The mere concept of "not enough CPUs" is just flawed and wrong.
This is basic Computer Science: Everything you can do with two or more
CPUs, you can do it as well with only one CPU (even if slower).
Thanks.
Reply to: