control: tag -1 +moreinfo Dear Matthias,
On Wed, Jan 31 2018, Matthias Klose wrote: > The recent changelog reads: > > * Disable test suite at package build time. > It now takes a prohibitively long time to run, so we are relying on > autopkgtest instead. > > Sorry, but this is one of the most lame excuses I have ever seen. Trying to > run > it on my laptop in unstable needs 30 seconds. However re-enabling it and > running it reveals > > =========== 122 failed, 24 passed, 4 skipped in 33.92 seconds ============ > > these results are after adding tesseract-ocr qpdf unpaper as build > dependencies. Looking at the errors, I strongly suspect that this is because you are running the test suite on a tmpfs -- we have seen these permission errors before under those conditions. Could you try running the test suite on a totally ordinary file system, please? I further suspect that the test suite took 30 seconds only because so many tests failed early. In recent upstream versions, the test suite has never finished running on my laptop after leaving it for multiple hours. When you run the test suite on a totally ordinary file system, please report how long it takes, and whether your laptop is very new/high spec. I note that Policy does not require that a package be buildable under a tmpfs, and certainly does not require that its test suite run under a tmpfs. > doubting that the primary reason for this change was build time ... Several things: 1) I ran the test suite using deb-o-matic[1] before uploading. Needless to say, I would not have uploaded had there been failures. 2) I should have mentioned in the changelog that another reason for this change was to reduce the number of heavy build dependencies. A further reason is that it reduces the amount of fragile code in d/rules needed to get the test suite running -- upstream's test suite is designed to be run on the installed package. 3) I am of the view that very heavy test suites are better run under autopkgtest. We will soon have testing migration gating on autopkgtest, and it is not clear to me that it makes sense for the process of stitching the .deb to abort when a single integration test fails. (Ideally tests would be separated into those that should abort the build and those that should not, but in the absence of this work being done, it is reasonable not to run any of them.) 4) Your implicit comment that I lied in the changelog and disabled the test suite because I knew it would fail is entirely uncalled for. Please do not treat fellow package maintainers like that. [1] http://debomatic-amd64.debian.net/ -- Sean Whitton
signature.asc
Description: PGP signature
