Hello, 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 regression) 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 https://buildd.debian.org/status/package.php?p=sthibault%40debian.org&comaint=yes&compact=compact 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? Samuel
