Testing/feedback wanted: Using dpkg-mergechangelogs in bzr-builddeb

[James Westby]

On Wed, 6 Jul 2011 17:27:34 +1000, Andrew Bennetts <andrew.bennetts at canonical.com> wrote:
> <https://bugs.launchpad.net/bzr-builddeb/+bug/718944> proposes replacing the
> existing changelog merge logic with dpkg-mergechangelogs' implementation.  I've
> done that in <lp:~spiv/bzr-builddeb/use-dpkg-mergechangelogs> (simply by
> shelling out to it), but it changes the existing output enough that the existing
> tests fail.
> 
> So here's where I'd like help: tell me, is the new output better (or at least no
> worse) for you?
> 
> If so, we can adjust the tests accordingly and land it.  If not, we can try to
> figure out what to do instead.

Hi,

I had three failures:

bzrlib.plugins.builddeb.tests.test_merge_changelog.TestMergeChangelog.test_unsorted

This one is asserting that it will sort the changelog, which I think is
the root of why the bug was filed, so the failure would be expected.

bzrlib.plugins.builddeb.tests.test_merge_changelog.TestMergeChangelog.test_not_valid_changelog

This is testing what happens with an invalid changelog. I'm not sure
what the effect of returning "not_applicable" versus "success" with the
invalid text would be. I don't think it's a particularly important case
though.

bzrlib.plugins.builddeb.tests.test_merge_changelog.TestMergeChangelog.test_3way_conflicted

Getting success back in this case seems wrong.

The text it returns is:

 psuedo-prog (1.1.1-2) unstable; urgency=low

   * New upstream release.
   * Yet another content for 1.1.1-2
   * But more is better

  -- Joe Foo <joe at example.com>  Thu, 28 Jan 2010 10:45:44 +0000

and I'm not sure that's correct as it's discarding a line.

If it's the desired behaviour of dpkg-mergechangelog then it may be what
we want, but it seems odd to me.

Thanks,

James