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.