[Pkg-octave-devel] Adding Octave support
rafael at debian.org
Sun Sep 3 23:18:36 UTC 2017
* Antonio Terceiro <terceiro at debian.org> [2017-09-03 16:57]:
> On Sat, Sep 02, 2017 at 06:48:11PM +0200, Rafael Laboissière wrote:
>> I could write a pkg-octave-autopkgtest, but I am really not willing to do
>> it, because it would represent an extra maintenance burden.
> You don't need to create a new source package, you can just move the
> testing part to a new binary from the same source as octave-pkg-dev,
> and make the binary package octave-pkg-dev depend on it, then make the
> code that calls the tests during the build and the autopkgtest control
> file use the same test helper tool, perhaps with different options.
I followed your suggestion and prepared a new version of octave-pkg-dev
in the Git repository  that moves the check-pkg script into a separate
package, called octave-autopkgtest, which is very thin (contains only
that script) and has no dependencies.
I also made the corresponding changes in the octave branch of the Git
repository for autodep8 . Please, review my changes. Also, please,
tell me whether I should file a wishlist bug report against autodep8
regarding my patch.
@DOG_Developers: If there are no objections, I will upload version 1.5.1
of octave-pkg-dev to unstable.
I think that, since this upload includes a new binary package, it will
have to go through the NEW queue.
> for example gem2deb-test-runner, the Ruby test helper, is called with
> the `--autopkgtest` option under autopkgtest, what makes it ensure that
> no code from the source package will be loaded .
>>>> I have two questions:
>>>> a) Should I just include the octave section into examples.md or
>>>> should I run examples.sh to generate it?
>>> it's better to run `make update-examples` to do that for you.
>> Yes, but this changes the entries in example.md for go and python. I
>> accidentally committed this change:
>> but I revert it later, because I am not sure what to do in this case.
> the point of generating the examples automatically is exactly to make
> sure that the examples contain _exactly_ what autodep8 would generate
> in reality, so you didn't need to revert those.
>>>> b) I am unsure what should go into test/octave_test.sh file. Could
>>>> you please give me some hints here, please?
>>> it should contain "unit"-style tests for your language, i.e. tests that
>>> produce sample minimal source packages that should be handled by your
>>> support and then checks if the package is correcly detected, and that he
>>> test control content generated is the correct one. There are several
>>> examples in the tests for languages that are already supported.
>> It took me some time to figure out, but I came out with (what I think are)
>> the appropriate unit tests:
> yes, those tests makes sense. However I would still like to not depend
> on the build infrastructure for running the tests.
> Pkg-octave-devel mailing list
> Pkg-octave-devel at lists.alioth.debian.org
More information about the autopkgtest-devel