[Python-modules-team] Bug#851722: Bug#851722: django-pipeline: FTBFS randomly (failing tests)

[Santiago Vila]

On Sun, 22 Jan 2017, Brian May wrote:

> Are you able to reproduce with the following patch? This will show what
> order the tests are being run in:
> [...]
> 
> diff --git a/debian/rules b/debian/rules
> index dc35e19..f53ec96 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -21,4 +21,4 @@ override_dh_installchangelogs:
>         dh_installchangelogs -- HISTORY.rst
>  
>  override_dh_auto_test:
> -       PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="PYTHONPATH=. python{version} /usr/bin/django-admin test --settings=tests.settings" dh_auto_test
> +       PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="PYTHONPATH=. python{version} /usr/bin/django-admin test -v3 --settings=tests.settings" dh_auto_test

Sorry for the late reply.

I built this package 200 times yesterday, on eight different virtual
machines, and this time it never failed.

Unfortunately, a recent build in one of the reproducible builds
autobuilders failed with the same error message I got in the past:

https://tests.reproducible-builds.org/debian/rbuild/testing/armhf/django-pipeline_1.6.8-2.rbuild.log

which means the bug is most likely not fixed.


In cases like this one there are basically two ways of approaching the
problem:

The difficult one is to build the package many times and expect it to
fail in your system. This may or may not happen.

The alternate way (maybe not so difficult, but it depends) is to
carefully examine the code and the build log and try to guess how it
may happen. This is not necessarily easier than the first method, but
I would recommend giving this method a try at least.


Because in my case it always failed in one machine and never in the
others, I suspect that the problem may be related with filesystem
ordering.


> I am reluctant to forward upstream a bug I cannot personally reproduce.

That's usually the right thing to do, because we don't want to bother
upstream with problems which are not real bugs.

In this case, however, the problem happened in one of my autobuilders,
a single-cpu machine using sbuild, but also in one of the reproducible
builds autobuilders, which are multi-core machines using pbuilder.

Because those autobuilders are completely independent and unrelated,
I really believe this is a bug in the package and not a misconfiguration
in any of the autobuilders.

So I think forwarding the bug would make sense. Just tell upstream the
truth, namely, that you have received a bug saying the package fails
to build randomly.

Maybe the author can try the "second method" to debug this (examine
the code and the build log and try to guess how it may happen).

Thanks.