Control: severity -1 important On 01.02.2018 06:06, Sean Whitton wrote: > 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 tried running these in a chroot created with debootstrap, and manually entering the chroot. [sid] type=directory description=debian (sid) directory=/srv/chroot/sid users=doko groups=sbuild so this should be on an ordinary file system? unless the testsuite uses /tmp mounted on a /tmpfs? > 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. well, it's a new one, two cores. > 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. which only runs on amd64 afaik. > 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. I'm not sure about that. I dislike packages like the whole KDE which disables testing during the build and then rebuilds and runs tests in the autopkg tests. It doesn't hinder broken packages into the archive. > (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.) I'm a bit biased here, because I saw the autopkg test failures first in launchpad: http://autopkgtest.ubuntu.com/packages/o/ocrmypdf/bionic/amd64 https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/o/ocrmypdf/20180130_155249_1faa5@/log.gz but yes, there seem to be less failures > 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. well, looking at the changelog is the way to see what is changed, and sometimes why. I didn't see that in 2). But yes, I was feeling that you didn't tell everything. Now reduced the severity. Feel free to close it if you think that any tests during the build is not necessary.
