* Antonio Terceiro <terceiro@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=98f0332758023a2d61e5099cc697c6ba12b62dceyes, 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@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-octave-devel