Hello Sean, Quoting Sean Whitton (2018-12-21 11:56:55) > On Thu 20 Dec 2018 at 08:37pm +0100, Johannes Schauer wrote: > > Quoting Sean Whitton (2018-12-20 15:30:12) > >> sbuild in stretch unconditionally invokes autopkgtest even if the file > >> debian/tests/control is not present in the source package. Newer sbuild > >> does not invoke autopkgtest unless that file is present. > >> > >> Many packages do not have debian/tests/control, and simply have a > >> Testsuite: field, which causes autopkgtest to invoke autodep8 to > >> generate an appropriate debian/tests/control. Under stretch, such > >> packages test suites would be run by sbuild, but now they are not. > >> > >> This seems like a regression since stretch. Perhaps, at least, there > >> could be an option to revert to always invoking autopkgtest when > >> --run-autopkgtest is passed? --definitely-run-autopkgtest? > > why not instead also check for the Testsuite field in debian/control and > > never run autopkgtest if both the field is missing and debian/tests/control > > is missing. > > > > Would that fix this problem? > Unfortunately, not fully. autodep8 chooses whether to generate a > debian/tests/control based on arbitrary shell code; this may check for a > Testsuite: field, but it may go ahead and generate a debian/tests/control > even if there is no Testsuite: field. > > For example, for elpa packages, I believe that autodep8 will trigger if > the package has the right build-deps, even if it lacks a Testsuite: field.
okay, but now I'm confused how autodep8 gets triggered at all. Isn't autodep8 wrapping autopkgtest and not the other way round? Because sbuild only executes autopkgtest itself which will fail if debian/tests/control is missing. So how does the machinery involing autodep8 work? Can you explain in a bit more detail? Thanks! cheers, josch
signature.asc
Description: signature
