On 2017-12-20 15:51, Holger Levsen wrote: > On Wed, Dec 20, 2017 at 02:31:42PM +0000, Wookey wrote: >> As a porter I notice quite a few packages where the maintainer has >> made things 'tidy' by giving an explicit architecture list when really >> the unlisted ones were really just 'doesn't build there yet, or arch >> is new since I made the list', so making such a list was >> unhelpful. Often they really wanted to make a 'doesn't build on arch >> foo' list but we didn't have a mechanism for that (that's still not >> fixed SFAIK). So not giving a list at all is good if it can be >> avoided. > > It would be really good to have such a list, this would ease QA work on > "uncommon" archs. Background: for reproducible builds we're rebuilding > all sid/main packages on amd64, i386, arm64 and armel. And thankfully > people actually look at all these results, both for plain old ftbfs bugs > as well as for reproducible builds issues. > > Thus it would be great to mark such packages as "currently ftbfs on > $arch, we know that, it's not great, but expected". >
but isn't this something that can be detected automatically? e.g. if <<package>> on <<arch>> is not available in unstable and/or testing, exclude it from the rebuilds. gfaksdr IOhannes