[Pkg-octave-devel] Adding Octave support

[Rafael Laboissière]

* 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 [1] 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 [2].  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.

Best,

Rafael

 1. https://anonscm.debian.org/cgit/pkg-octave/octave-pkg-dev.git/commit/?id=f0eb134e0ca73482871bb2070ed7a4146e3bc48b
 2. https://anonscm.debian.org/cgit/collab-maint/autodep8.git/commit/?h=octave&id=a91ae53a39331fb0643a49fabc7a113d394f1555

> 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:
>>
>> https://anonscm.debian.org/cgit/collab-maint/autodep8.git/commit/?h=octave&id=409fb69056193957bdc804a9f5d2a0ba49e90aee
>>
>> 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:
>>
>> https://anonscm.debian.org/cgit/collab-maint/autodep8.git/commit/?h=octave&id=98f0332758023a2d61e5099cc697c6ba12b62dce
>
> 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 
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-octave-devel