[ Note: this is a reply to a message from reproducible-commits,
  trimming the subject just a little bit ]

On Fri, Jun 03, 2016 at 04:49:10PM +0000, Holger Levsen wrote:
> +ftbfs_build-indep_not_build_on_armhf:
> +  description: |
> +    Package build-indep target will fail on armhf.
> +  deterministic: True
>  ftbfs_environment:
>    description: |
>      FTBFS with some unrelated values of the environment variables (lang, 
> timezone, ...)
> diff --git a/packages.yml b/packages.yml
> index 362d7b7..d417fcb 100644
> --- a/packages.yml
> +++ b/packages.yml
> @@ -1006,6 +1006,10 @@ bobcat:
>    version: 4.01.04-1
>    issues:
>      - random_order_in_static_libraries
> +bochs:
> +  version: 2.6-5
> +  issues:
> +    - ftbfs_build-indep_not_build_on_armhf

Hello Holger.

This new issue is a little bit surprising.

Sometimes, packages generating "Arch: all" binary packages have good
reasons to require that those packages are built only under certain

In the case of "bochs", there are some hints about the reasons in
Bug #481147 (which I closed recently because, well, it seemed "as
fixed as it can be" to me).

A similar case also happens with the "aboot" package, which generates an
"Arch: all" package which apparently may only be generated under the
alpha architecture (see Bug #805988).

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

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

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?

(Or maybe your plan was to make the autobuilder to be aware of packages
having this issue precisely to avoid the build?)


Reproducible-builds mailing list

Reply via email to