logging.info() writes to the terminal by default, so do not use it in
such a common place. Library code shouln't write to the terminal except
by request of the caller.
I'm not sure what the logic of the check was before, but it didn't work
(false negatives), so I've rewritten it. All I do is run
update-maintainer and check that it changes nothing. Since
update-maintainer is idempotent, this should always work as far as I can
see.
I'm still dubious about the clobbering of the working tree when
generating the tree object that corresponds to an update-maintainer run,
but this is not a regression and can be fixed in a future commit.
We haven't agreed the best pattern to use for this yet. But currently
the return value of GitUbuntuLint.do_change_lint() is outright wrong,
returning only the status of the final check instead of all the checks
processed.
Fix this, at least for now, by correctly combining the results.
In the case that a proposed SRU is the first update for a given stable
series, the previous changelog entry will list a Debian codename such as
"unstable". versioning.next_sru_version against "unstable" has no
meaning. The call to it failed with a StopIteration when
GitUbuntuLint._next_sru_version() tried to find a matching Ubuntu series
object in Launchpad called "unstable".
Instead, ditch GitUbuntuLint._next_sru_version() and just use the series
derived from the debian/changelog target to determine which series the
proposer is targeting for the SRU. versioning.next_sru_version will look
the appropriate current series' versions from Launchpad to determine the
answer, so there is no need for us to do it.
