Bug#848063: fixed in ri-li 2.0.1+ds-4

[Santiago Vila]

On Sat, Dec 24, 2016 at 03:05:54PM +0100, Markus Koschany wrote:

> Thanks for working on the reproducible build project.

Please note that I'm not filing this bug in the name of
the reproducible builds project.

The build log I attached was created with sbuild in my own
autobuilder. Autobuilders in the reproducible builds project
use pbuilder.

> However this is
> not a release critical issue because the last version builds fine on all
> release architectures. [1]

Sorry, but the theory that a bug is "not RC if it didn't happen in
buildd.debian.org" may simply not be true.

We have already discussed about this in the past. As an example,
packages which rely on gnupg or tzdata being present during the build
must declare them in the build-depends. Failure to do so is RC even if
those packages are installed by default in the official buildds.

So please stop saying that a bug needs to happen in buildd.debian.org
to be RC. This example clearly invalidates such theory.

In this case, the failure happens in the reproducible builds
autobuilders:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ri-li.html

but also (randomly) in my own autobuilders, which are completely independent.

> It would be useful to know in which way the reproducible builds
> environments differs from the official buildd servers. Apparently the
> build cannot open a display server but xvfb-run should ensure that they
> are automatically found and used. So this is probably a regression in
> xvfb-run or some kind of race condition because nothing has changed in
> ri-li for a long time.

Yes, it would be indeed useful to know how my building environment
differs from yours. I was asked about this in another bug report so I
wrote this:

https://people.debian.org/~sanvila/my-building-environment.txt

Please try to use sbuild in a single-CPU virtual machine as I do.
Maybe then this package will FTBFS (randomly) for you as well.

Thanks.