Bug#987327: Bug#986984: Bug#987327: autopkgtests for debian-edu-doc binary packages
Hi, Just to be sure, I love autopkgtest, but I have a few comments. On 21-04-2021 23:09, Wolfgang Schweer wrote: > [ Holger Levsen, 2021-04-21 ] >> we should add autopkgtests to debian-edu-doc to ensure each document >> has been built for the three formats pdf, epub and html. To be honest, I'm wondering if what you're envisioning here shouldn't be (also) done as BUILD test. I mean, if some documentation goes missing, it's good to fail the build and prevent a broken package in unstable. Very often, build tests are used as autopkgtests too, but checking for existence of files in the binary package only needs to be done once, not with every dependency change. > In some cases, verifying the format would have revealed the cause for > missing files/internal issues, i.e would have allowed one to locate the > broken XML syntax (most cases) more easily. > > src:desktop-base has an autopkgtest to validate XML files, xmllint from > libxml2-utils is used. Maybe xmllint could also be used to check HTML > files. That's also a great test during build. Realize however that if you do this during autopkgtest there's a risk that you'll *block* a new version of the checker because of a bug in *your* package. Obviously that has to be weighted against catching bugs in the checker, so it goes both ways, but *most* of the autopkgtest failures that I've seen that involved checkers, the checkers actually got better and found an issue in the reverse dependency. It's obviously a choice you'll have to make and there's much value in having an autopkgtest, but I just wanted to point out it's not a free lunch. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#986984: Bug#987327: autopkgtests for debian-edu-doc binary packages
[ Holger Levsen, 2021-04-21 ] > we should add autopkgtests to debian-edu-doc to ensure each document > has been built for the three formats pdf, epub and html. > > another condition is that every debian-edu-doc-* package should > contain at least one document, unless the package has 'transitional' > in it's description. sounds good. > On Wed, Apr 21, 2021 at 09:20:38PM +0200, Petter Reinholdtsen wrote: > > [Holger Levsen] > > > I'll guess I'll invent something myself then... > > What about looking for selected keywords like 'Debian Edu', 'Skolelinux, > > "$(lsb_release -c -s)" or similar by grepping the documentation files, > > thanks, grepping for known strings is indeed a good idea, though > we should choose those few untranslated english ones... > > > to ensure the content is somewhat relevant? And perhaps linting the > > HTML (weblint-perl?) and epub (epubcheck?) files to verify the format is > > correct? > > I was thinking of just using /usr/bin/file... IIRC, we had all sorts of problems in the past, some of them unnoticed for some time: - missing files of some format due to wrong XML syntax in PO files - missing PDF files for a specific language - problems with non-ascii language PDF files - HTML files with somehow broken markup - invalid EPUB files In some cases, verifying the format would have revealed the cause for missing files/internal issues, i.e would have allowed one to locate the broken XML syntax (most cases) more easily. src:desktop-base has an autopkgtest to validate XML files, xmllint from libxml2-utils is used. Maybe xmllint could also be used to check HTML files. Besides checking EPUB files, epubcheck has also been useful in the past to detect HTML markup errors caused by XML tag mismatch (which xmllint failed to detect). And 'qpdf --check ' could be used to validate PDF files. Wolfgang signature.asc Description: PGP signature
