Web lists-archives.com

Re: Exclicitly or "implicitly" mark architectures a packages does not build

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".

One of way of marking this is certainly to have a bug open, though I can
see how maintainers do not want such bugs to clutter their views of the BTS.

Hmm. Something certainly *is* buggy, if "only" debian/control for not
having a better way to express this. :-)


Attachment: signature.asc
Description: PGP signature