Comment 29 for bug 1490611

On 17.08.2016 [10:20:26 -0700], Nish Aravamudan wrote:
> On 17.08.2016 [13:12:19 -0000], Chris J Arges wrote:
> > Can you rebase your fix on 1:2.5+dfsg-5ubuntu10.4 (due to the
> > regression fix mentioned in #25)?
>
> Will do!

Done.

> > Another thing about your backport is that it dropped the qem2 bits
> > from the patch. Is there a reason for this? If so please mention it in
> > the debian/patch file.
>
> Ah yes, those sections of the upstream fix do not apply cleanly due to
> differing context (not even present).

The latest update includes the relevant context...

> That does bring up another question, though:
>
> @smkbot or anyone else that might know. It seems the original series was
> 4 patches
> (http://lists.nongnu.org/archive/html/qemu-devel/2016-02/msg06037.html),
> and there was a follow-on of 7 patches that fixed a regression in that
> series
> (http://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg05424.html).
> Do we need to backport all 11 patches? In the first series, at least,
> there is mention that patch 1/4 fixes an issue for reading VHD images.
> While I realize that this particular bug is just for creating/converting
> images, would it also be appropriate to backport the full set of fixes
> for VHD/VPC?

On my own review, I believe we want to backport the 1 and 3 patch from
the first series, so that qemu-img is self-consistent, in terms of
reading and writing the new 'qem2' images. The second series does
include fixes, but not related to this bug, so if we were to include
them in a SRU, I'd rather they come in from a related bug report.

@Stephen or anyone else affected, I've submitted an updated build at
https://launchpad.net/~nacc/+archive/ubuntu/lp1490611 for qemu
1:2.5+dfsg-5ubuntu10.5~ppa1 which should include the relevant. Please
test once it has finished building.