[Pkg-octave-devel] New upload of octave-pkg-dev with autopkgtest capabilites

[Sébastien Villemot]

On Fri, Sep 01, 2017 at 04:52:41PM +0200, Rafael Laboissière wrote:
> * Sébastien Villemot <sebastien at debian.org> [2017-09-01 15:55]:
> 
> > 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).
> 
> Thanks for the extensive explanation.  Indeed, I was not aware that
> autopkgtest calls autodep8 everytime it is run.
> 
> > 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);
> 
> It should be easy to recognize the Octave-Forge packages, so that the other
> octave add-ons will be normally excluded.

Yes indeed. I did not check that autodep8 provides an easy way of implementing
such a test, but I guess it does. 

> > - 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).
> 
> Ok, this means that, in order to have things going, for each one of our
> packages we have to do a "manual" action, either asking for whitelisting or
> uploading a new version with the "Testsuite: autopkgtest" header.

Indeed, and I was not aware of that before starting this discussion. This makes
the autodep8 approach a little less appealing, but I think it is still better
than adding a debian/tests/control to all our files, because it means less
duplicated code, and if for some reason we want to change the test
infrastructure, it will be possible to do it in a single place.

Alsoe note that this manual action is only needed for having our packages
tested by ci.debian.net. It is not needed for locally testing our packages
(an updated autodep8 is enough).

> > Let me know if this sounds good to you.
> 
> Yes, this a undoubtedly a better approach, but it will take an extra time
> until I (or someone else) make autodep8 Octave-aware.

Hopefully this should be straightforward, given that you already implemented
most of the infrastructure.

The only downside IMO is that we are now dependent on the reactivity of the
autodep8 maintainers (but I guess they will be happy to integrate our patch).

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-octave-devel/attachments/20170901/ccb1b8d4/attachment.sig>