On Fri, Sep 01, 2017 at 03:55:03PM +0200, Sébastien Villemot wrote: > On Fri, Sep 01, 2017 at 03:29:03PM +0200, Rafael Laboissière wrote: > > * Sébastien Villemot <sebastien@debian.org> [2017-09-01 15:03]: > > > > > On Fri, Sep 01, 2017 at 01:15:35PM +0200, Rafael Laboissière wrote: > > > > * Sébastien Villemot <sebastien@debian.org> [2017-09-01 12:20]: > > > > > > > > I did not investigate autodep8 in depth, but the current version of > > > > the make-octave-forge-debpkg script in Git does a similar job. This > > > > avoids adding "manually" the debian/tests/* files. And it works > > > > also on already debianized packages. > > > > > > Maybe I wasn’t clear, but by "manually" I meant that we would need to > > > make a new upload of all octave-* packages to add autopkgtests to them. > > > > > > A single upload of autodep8 would achieve the same result. So it may be > > > much less effort. > > > > According to the man page of autodep8, this tool just "prints the suggested > > contents of debian/tests/control to the standard output". This is pretty > > similar to what the current version of make-octave-forge-debpkg in the Git > > repository does. > > > > At any rate, new uploads of the octave-* packages would be needed anyway if > > we used an Octave-aware version of autodep8. > > > > I am perhaps missing something here. Did you mean another tool that is > > associated with autodep8 that can better automate the process? > > Indeed the documentation of autodep8 may not be totally clear and therefore you > did not fully grasp the scope of the tool. > > Basically autopkgtest calls autodep8 everytime it is run. Then if autodep8 > recognize that the package belongs to certain categories (currently R, Python, > Perl… packages), it dynamically creates a debian/tests/control file, that will > then be used by autopkgtest. > > Said otherwise, if we add support for Octave packages within autodep8, then > there is no need to create a debian/tests/control file in our octave-* > packages. > > However, I just realized that, if we want ci.debian.net to automatically test > our packages, then we still need to add a "Testsuite: autopkgtest" header in > debian/control (note that this header is automatically added by dpkg when a > debian/tests/control file is present). However, it is possible to ask the CI > team to whitelist all our packages before they get uploaded with the new > header. See the part about autodep8 in: > > https://lists.debian.org/debian-devel-announce/2015/12/msg00002.html > > You can verify the autodep8 stuff by yourself by running autopkgtest on the > r-cran-rsdmx package. It has no debian/tests/control, but still autopkgtest > will check that it correctly loads in R (however I forgot to add the > "Testsuite: autopkgtest" header, which means it is not tested by ci.debian.net; > I am going to fix that). > > > So to summarize, I think we should: > > - add support for octave-* in autodep8 (at least for all those packages that > are built with octave-pkg-dev; we may have to exclude other octave add-ons); > - then talk to the CI team so that they whitelist all the corresponding > packages; > - and add the "Testsuite: autopkgtest" header in all the git repositories (but > no need to upload the packages right now). Just an element of clarification: after having talked with the CI team on #debian-qa, it turns out that the header to be added in the source stanza of debian/control will be: Testsuite: autopkgtest-pkg-octave (and not "Testsuite: autopkgtest", which would be filtered out by dpkg-source since there is no debian/tests/control; similarly the header to be added for R packages is "Testsuite: autopkgtest-pkg-r"). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
Attachment:
signature.asc
Description: PGP signature