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

[Sébastien Villemot]

On Fri, Sep 01, 2017 at 03:29:03PM +0200, Rafael Laboissière wrote:
> * Sébastien Villemot <sebastien at 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 at 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).

Let me know if this sounds good to you.

-- 
⢀⣴⠾⠻⢶⣦⠀  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/d99900dd/attachment.sig>