Hi Guillem,

Guillem Jover wrote:
> On Tue, 2016-03-08 at 08:27:32 +0100, Axel Beckert wrote:
> > There was a time where gnudatalanguage didn't build on exactly one
> > architecture (arm64): See https://bugs.debian.org/803552 and
> > https://anonscm.debian.org/cgit/debian-astro/packages/gnudatalanguage.git/commit/?id=638bc9c3be31a4e5bd747f6c0f985da1afbc26ba
> > 
> > The full architecture list reads:
> > 
> > Architecture: any-alpha any-amd64 any-armeb any-arm any-avr32 any-hppa
> > any-i386 any-ia64 any-m32r any-m68k any-mips any-mips64 any-mips64el
> > any-mipsel any-or1k any-powerpc any-powerpcel any-ppc64 any-ppc64el
> > any-s390 any-s390x any-sh3 any-sh3eb any-sh4 any-sh4eb any-sparc
> > any-sparc64 mipsn32 mipsn32el powerpcspe x32
> > 
> > I had to write small script to get it done properly and found that
> > line/commit rather tedious. And if the bug wouldn't have been fixed
> > properly soon afterwards, I'd have had to keep that field uptodate or
> > at least check it everytime a new architectures pops up, e.g. on
> > Debian Ports.
> 
> This falls into one of the cases I mentioned in my previous mail. Here
> I think to correct course of action would have been to request the
> removal of the offending binaries for the broken arch. That makes that
> FTBFS non-serious as it's not a regression (anymore).

I did that, but it wasn't executed in time.

> And the buildds will be able to build it with a simple retry
> (automatic or manual), and no new upload is required.

And I also think that's a more unfriendly variant towards buildd
admins and porters.

> If the problem would have been, say, a misbuild instead of a FTBFS,
> I'd probably have opted for adding instead a '$(error )' call in
> debian/rules on arm64, which is a hack, but a temporary one in any
> case, and certainly more manegable.

Urgh, that's quite ugly IMHO.

> There's a very relevant thread on debian-devel started by
> Steve Chamberlain, precisely about the underlying issue caused by
> using exclusions instead of inclusions in Architecture fields which
> I think also is spot on.

Thanks for that pointer. Will eventually have a look.

                Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Reply via email to