Hi! [ Mostly to summarize the status re dpkg. ]
On Sun, 2022-09-11 at 17:08:57 +0200, Samuel Thibault wrote: > 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). > 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. Yes, I agree that this seems like a problem with representing state, where people feel the need to move from the red to green. I think the proposals that have been mentioned elsethread are nice, where a regression would be red but whenever a package was not previously built (because it never has or it got removed) for an arch, that is shown in a way consistent with how testing transitions would take it (orange or another non-red color seems good). Something else to consider is that, for packages that make sense porting, deny-listing them from building means we do not have build failure logs, so deciding what to port or trying to check for patterns becomes more costly for humans, of course at the cost of potentially throwing at it buildd resources. > 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? While these might be worth it on their own, it feels (as has been covered elsethread) to be a bit of a workaround for lack of better expressiveness in our Architecture declarations, and build state representation. But see my reply to #807263 about how I see the different cases. Also for the third we already had something similar with the Packages-arch-specific file, but my understanding is that we are moving away from it? The common mentioned omissions are: * Lack of negated architectures in the field. As mentioned on #807264 this is kind of supported already by dpkg, but it would need to be accepted by the project, and the actual syntax and semantics documented. (Personally I think this should not generally be used, and there are very few cases where this seems legitimate?) * Lack of bits/endianness arch "aliases" (#962848). The main problem with this one is that we cannot simply add such aliases, as then those would silently be considered as regular arches, and they do not map into the current naming convention at all. These would need to be added with a breaking syntax (say with some non-accepted char, such as % or whatever) so that they do not introduce silent breakage. This would then need to be supported by anything handling arch restrictions (field and dependencies) which can be a rather large surface. Then there is the problem that architectures are evaluated as ORed lists, and the bits/endianness might require to be treated as ANDed lists some times (of course the latter could be handled by combining them into single aliases, but meh). Thanks, Guillem
