[Reproducible-builds] ftbfs_build-indep_not_build_on_armhf, and add bochs to it
mattia at debian.org
Sat Jun 4 07:32:41 UTC 2016
On Fri, Jun 03, 2016 at 09:13:29PM +0000, Santiago Vila wrote:
> On Fri, Jun 03, 2016 at 04:49:10PM +0000, Holger Levsen wrote:
> > +ftbfs_build-indep_not_build_on_armhf:
> > + description: |
> > + - ftbfs_build-indep_not_build_on_armhf
probably this tag name should lose the 'armhf' word in it, anyway.
> Sometimes, packages generating "Arch: all" binary packages have good
> reasons to require that those packages are built only under certain
yes, it's an annoying thing, but it's true. I'd like to see
https://bugs.launchpad.net/launchpad/+bug/217427 for that.
> An "issue" suggests to me "something which has eventually to be fixed",
> but frankly, I don't think we should really require that those
> packages generate their "Arch: all" binary packages from any other
that was not the idea of this issue at all. It's called "issue", but
it's better read as "tag" in these occasion.
> So, instead of "this package needs to be fixed", those packages would
> maybe deserve a "this package should not be built on such architecture
> because it is simply not supposed to work".
This issue, coupled with a change in jenkins code, makes possible for us
to not export the failure notice towards tracker.d.o/DDPO, so
maintainers should not be bothered with the "FTBFS" notice.
> Do you think it would be possible to achieve the same result with a
> "banned packages" list which is architecture-specific instead of this
> funny issue?
nobody likes blacklisting packages :(
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the Reproducible-builds