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

[Sébastien Villemot]

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 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).

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
-------------- 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/3eaf514b/attachment.sig>