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

Re: Help requested: Packages which FTBFS randomly

Santiago Vila <sanvila@unex.es> writes:

> The following packages FTBFS for me randomly. First column is the bug
> number, second column is the estimated probability of failure in my
> build environment, which is described here:

> https://people.debian.org/~sanvila/my-building-environment.txt

> Before I ask the Release Managers that they make the bugs at the top
> of this list serious again (using some kind of threshold, as discussed
> in Bug #844264), I would appreciate if somebody else could double check
> that those packages have indeed very flaky tests (or buggy Makefiles,
> in some cases).

> [ Please report any findings to the nnnnnn@bugs.debian.org address ].

> While I agree that none of those individual bugs is more important
> than a bug of "FTBFS-always" type, some packages have a failure ratio
> so high that if we accepted that they "build from source" with such a
> high failure rate, they would effectively honor policy if we had it
> reversed, as in "packages must *not* build from source". I call this
> "the FTBFS-randomly Schrödinger paradox".

To say my opinion explicitly, since there's been a lot of discussion here,
some of which I've been involved in somewhat ambiguously:

I think this is a reasonably short and workable list of bugs, and I think
the *default* assumption should be that any FTBFS, even intermittant, is
RC.  This is both for fundamental reasons for what we're trying to achieve
as a free software distribution that's modifyable and rebuildable by our
users, and for practical reasons to support further development of our
packages (including security fixes).

We already have an exception mechanism for handling bugs that shouldn't be
RC for the current release because the actual impact of the bug turns out
to be minor for some reason, or because they would have too negative of an
impact on the release.  Normally, how we handle this is to mark the bugs
with an RC severity (serious in this case), and then, if the release team
feels this package warrants a special exception, mark it as ignored for
the current release.

To me, that seems like the obvious approach to take here, and given the
reasonably short list of bugs, I don't feel like that would cause
unreasonable disruption.  In the cases where the build failures are from
flaky tests, I think disabling the test is a perfectly reasonable fix.  If
there is some significant merit to a test that fails in Santiago's
environment but doesn't on the buildd network for some reason *and* has
significant value in catching regressions on release architectures, that's
an obvious case for an exception and could be handled like any other RC
bug exception.

I think we're going to keep getting lost in the weeds when we try to
discuss this in general hypotheticals.  If individual package maintainers
request individual RC exceptions for their specific cases, the discussion
can be far more concrete and in most cases will have an obvious outcome.

So, to be explicit, my opinion (as just a Debian Developer, with no
special ability to decide this, so just take this as another of the
contributions to the thread) is that all of these bugs should be set to
Severity: serious, and the maintainers can ask for stretch-ignore tags (or
downgrades for their specific bug if that seems more correct for specific
reasons related to their packge, whatever those may be) if they feel that
is appropriate.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: