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

packages expected to fail on some archs


We have been discussing a bit on #debian-ports about packages that fail
to build on less-mainstream architectures.

The issue we see is that some DDs end up setting a hardcoded list in
the "Architecture" field, rather than just letting builds keep failing
on these archs (and then possibly succeeding after some time whenever
somebody contributes a fix upstream that gets propagated to Debian).

First, perhaps it's worth reminding to DDs is that it's fine for a
package to show up as FTBFS on the buildd status for some archs: that's
not RC if the binary packages for that arch are not in testing (and
even then, an RM request can fix that, to just express the unfortunate

That said, I guess DDs would still set a manual Arch list so as to get
the red flags away from their sight on the buildd page status, e.g. from
so that they can easily notice which build failures are actually not
expected, to be able to efficiently work on those.

So perhaps what is missing is a way to express that an FTBFS is
expected, so that the buildd page status represents it differently, e.g.
in orange rather than red?  The idea would be that it should be really
easy to set (as easy as setting an Architecture list) so that we can
easily recommend it.

We could for instance:
- Add an Architecture-FTBFS field to debian/control
- Add an environment variable to debian/rules so that on these archs dh
  fails with a different exit code that buildds would notice.
- Add a Architecture-FTBFS field in the wb database that DDs can set

The tricky part I see is that AIUI the buildd status page doesn't
have direct access to debian/control, only to the wb database, so the
first solution is not immediate to implement. The third option would
be the most obvious from the buildd point of view, but that's not very
convenient for DDs. Possibly such field could be automatically set
according to the Packages entry when a newer upload is done?


Reply to: