gimp cage tool - fix in 16.04?

[Colin Watson]

On Mon, Sep 26, 2016 at 05:28:26PM -0500, Simon Quigley wrote:
> Hello Robert,
> 
> I'm doing some casual poking around at the moment to see how easy it
> would be for this patch to be applied.
> 
> > The cage tool in 2.8.16-1ubuntu1.1 is broken. Details can be found here:
> > https://bugzilla.gnome.org/show_bug.cgi?id=678085
> > 
> > If I am not mistaken 2.8.18 does not fix the issue. At least the
> > changelog at [1] does not indicate anything about a fix and target
> > milestone of the bug is 2.10. Do you see any chance that the fix for
> > this issue will be made available via patch in 16.04?
> 
> I think otherwise. Look at when this Git tag was set upstream:
> https://git.gnome.org/browse/gimp/tag/?h=GIMP_2_8_18
> 
> tag date	2016-07-13 20:27:19 (GMT)
> 
> This is the date for 2.8.16:
> 
> tag date	2015-11-21 18:04:13 (GMT)
> 
> Let's look at the timestamps on the two commits that were done to fix
> this problem:
> 
> 2016-02-02 11:21:15 (GMT)
> 
> 2016-02-07 17:50:11 (GMT)
> 
> So unless there is some magical way to ensure commits don't land in a
> Git tag (which I highly doubt they would even WANT to do either way), it
> should be fixed.

That isn't quite how it works: it depends on which branch the tag was
made from.  A more accurate approach is to clone the repository and use
"git describe --contains":

  $ git describe --contains b5546ac0ac4a30bfd31ccc75c22f722a1c38dee1
  GIMP_2_9_4~880

In other words, it was only committed to master after the gimp-2-8
branch was made; and there's no evidence that this was cherry-picked
onto the gimp-2-8 branch (from a quick log inspection).  It indeed does
not appear that this commit is in 2.8.18, although it should be in 2.9.4
(an unstable-series release).  It might be worth asking upstream whether
it can be fixed in the 2.8 series.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]