Re: Exclicitly or "implicitly" mark architectures a packages does not build
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
Reply to: