Source: vcsh
Version: 2.0.10-0.1
Severity: serious
X-Debbugs-CC: hibby@debian.org

vcsh 2.0.10-0.1 fails its autopkgtests on all architectures,
preventing migration to testing. Example on amd64: https://ci.debian.net/packages/v/vcsh/testing/amd64/60170831/

39s autopkgtest [01:06:39]: test command1: make test
39s autopkgtest [01:06:39]: test command1: [-----------------------
39s make: *** No rule to make target 'test'. Stop.
40s autopkgtest [01:06:40]: test command1: -----------------------]
40s autopkgtest [01:06:40]: test command1: - - - - - - - - - - results - - - - - - - - - -
40s command1 FAIL non-zero exit status 2
40s autopkgtest [01:06:40]: @@@@@@@@@@@@@@@@@@@@ summary
40s command1 FAIL non-zero exit status 2

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Chris Hofstaedtler <zeha@debian.org> writes:

Source: vcsh
Version: 2.0.10-0.1
Severity: serious
X-Debbugs-CC: hibby@debian.org

vcsh 2.0.10-0.1 fails its autopkgtests on all architectures,
preventing migration to testing. Example on amd64: https://ci.debian.net/packages/v/vcsh/testing/amd64/60170831/

39s autopkgtest [01:06:39]: test command1: make test
39s autopkgtest [01:06:39]: test command1: [-----------------------
39s make: *** No rule to make target 'test'. Stop.
40s autopkgtest [01:06:40]: test command1: -----------------------]
40s autopkgtest [01:06:40]: test command1: - - - - - - - - - - results - - - - - - - - - -
40s command1 FAIL non-zero exit status 2
40s autopkgtest [01:06:40]: @@@@@@@@@@@@@@@@@@@@ summary
40s command1 FAIL non-zero exit status 2

I have a quick look at this and "make test" doesn't work in an unpacked
source package either (via dgit clone in my case). It seems there is a Makefile.am but no Makefile, so I guess some autotools hoops need to be
jumped through. Perhaps running "prove" directly would be easier?
That would require some efforts to run the installed vcsh though. That
seems to apply to running via make as well, so I'm not sure how this
worked before.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dave Hibberd <hibby@debian.org> writes:

Spent an hour or so trying to do some autotools magic to get compilation to a stage where it won't compile as `ronn` is required.

the previous version did not use autotools, so that is at least part of
the mystery solved. The autopkgtests were not updated when the upstream
build system was.

In my opinion, adding lots
of dependencies to entirely rebuild the application so we can "test" it seems way beyond the scope of any testing.
We can also see the tests run during build [1]. Is there value in repeating them?

It is a common practice to make sure the installed version is actually installed properly

Running prove appears easier on the face of it, but I ran into a wall there too: all the tests as shipped seem to be hardcoded to `.././vcsh` or `./vcsh`,
not calling the shipped binary. Is that normal?

yes, for build time tests

Copying them to d/tests and updating d/tests/control has so far not proved fruitful for me either, missing files errors and other things.

This is probably the path I would try. You could replace some tests as
long as you end up testing roughly the same functionality.

Any hints or tips, can I even drop the whole d/tests folder to avoid having tests happen to clear the bug?

It's not usually acceptable to drop autopkgtests in order to avoid
failures.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)