Patchwork [0/2] Remove older GTK+ versions

login
register
mail settings
Submitter Ross Burton
Date Aug. 17, 2012, 11:35 a.m.
Message ID <cover.1345203203.git.ross.burton@intel.com>
Download mbox
Permalink /patch/34805/
State New
Headers show

Pull-request

git://git.yoctoproject.org/poky-contrib ross/gtk2

Comments

Ross Burton - Aug. 17, 2012, 11:35 a.m.
Remove the very old versions of GTK+ 2.x that we don't build.  They were
kept for their patches, but the patches don't apply anymore because the
relevant code has changed dramatically.

If someone still wants to use them, meta-oe is a better place for them to
live.

Ross

The following changes since commit af847d36375aa53f0c1ee2a00c97ba9f38837d1b:

  bitbake: bitbake: build.py: Add stampdir argument to cached_mtime_noerror (2012-08-16 12:27:41 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib ross/gtk2

for you to fetch changes up to f6cf7bda28c1ae5f9033863f70657e1970b6bdc9:

  gtk+ remove 2.16.6 (2012-08-17 12:29:59 +0100)

----------------------------------------------------------------
Ross Burton (2):
      gtk+: remove 2.12.7
      gtk+ remove 2.16.6

 .../gtk+/gtk+-2.12.7/cellrenderer-cairo.patch      |   34 -
 .../gtk+/gtk+-2.12.7/combo-arrow-size.patch        |   69 -
 .../gtk+/gtk+-2.12.7/disable-print.patch           |   28 -
 .../gtk+/gtk+-2.12.7/entry-cairo.patch             |  105 -
 .../gtk+/gtk+-2.12.7/filechooser-default.patch     | 9523 --------------------
 .../gtk+/gtk+-2.12.7/filechooser-props.patch       |   59 -
 .../gtk+/gtk+-2.12.7/filechooser-sizefix.patch     |   37 -
 .../gtk+/gtk+-2.12.7/filesystem-volumes.patch      |  200 -
 .../gtk+/gtk+-2.12.7/gtklabel-resize-patch         |   12 -
 .../gtk+/gtk+-2.12.7/hardcoded_libtool.patch       |   31 -
 .../gtk+/gtk+-2.12.7/menu-deactivate.patch         |   53 -
 meta/recipes-gnome/gtk+/gtk+-2.12.7/no-demos.patch |   12 -
 .../gtk+/gtk+-2.12.7/pangoxft2.10.6.diff           | 2458 -----
 .../gtk+/gtk+-2.12.7/range-no-redraw.patch         |  130 -
 .../gtk+/gtk+-2.12.7/run-iconcache.patch           |   21 -
 .../gtk+/gtk+-2.12.7/scrolled-placement.patch      |   24 -
 .../gtk+/gtk+-2.12.7/toggle-font.diff              |  102 -
 .../recipes-gnome/gtk+/gtk+-2.12.7/xsettings.patch |   18 -
 ...Duplicate-the-exec-string-returned-by-gtk.patch |   33 -
 .../gtk+/gtk+-2.16.6/cellrenderer-cairo.patch      |   34 -
 .../gtk+-2.16.6/disable-gio-png-sniff-test.diff    |   99 -
 .../gtk+/gtk+-2.16.6/entry-cairo.patch             |  105 -
 .../gtk+/gtk+-2.16.6/hardcoded_libtool.patch       |   33 -
 meta/recipes-gnome/gtk+/gtk+-2.16.6/no-demos.patch |   12 -
 .../gtk+/gtk+-2.16.6/run-iconcache.patch           |   21 -
 .../gtk+/gtk+-2.16.6/toggle-font.diff              |  102 -
 .../recipes-gnome/gtk+/gtk+-2.16.6/xsettings.patch |   18 -
 meta/recipes-gnome/gtk+/gtk+_2.12.7.bb             |   49 -
 meta/recipes-gnome/gtk+/gtk+_2.16.6.bb             |   49 -
 29 files changed, 13471 deletions(-)
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/cellrenderer-cairo.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/combo-arrow-size.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/disable-print.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/entry-cairo.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/filechooser-default.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/filechooser-props.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/filechooser-sizefix.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/filesystem-volumes.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/gtklabel-resize-patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/hardcoded_libtool.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/menu-deactivate.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/no-demos.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/pangoxft2.10.6.diff
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/range-no-redraw.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/run-iconcache.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/scrolled-placement.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/toggle-font.diff
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/xsettings.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/0001-bgo-584832-Duplicate-the-exec-string-returned-by-gtk.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/cellrenderer-cairo.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/disable-gio-png-sniff-test.diff
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/entry-cairo.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/hardcoded_libtool.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/no-demos.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/run-iconcache.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/toggle-font.diff
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/xsettings.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+_2.12.7.bb
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+_2.16.6.bb

Ross Burton (2):
  gtk+: remove 2.12.7
  gtk+ remove 2.16.6

 .../gtk+/gtk+-2.12.7/cellrenderer-cairo.patch      |   34 -
 .../gtk+/gtk+-2.12.7/combo-arrow-size.patch        |   69 -
 .../gtk+/gtk+-2.12.7/disable-print.patch           |   28 -
 .../gtk+/gtk+-2.12.7/entry-cairo.patch             |  105 -
 .../gtk+/gtk+-2.12.7/filechooser-default.patch     | 9523 --------------------
 .../gtk+/gtk+-2.12.7/filechooser-props.patch       |   59 -
 .../gtk+/gtk+-2.12.7/filechooser-sizefix.patch     |   37 -
 .../gtk+/gtk+-2.12.7/filesystem-volumes.patch      |  200 -
 .../gtk+/gtk+-2.12.7/gtklabel-resize-patch         |   12 -
 .../gtk+/gtk+-2.12.7/hardcoded_libtool.patch       |   31 -
 .../gtk+/gtk+-2.12.7/menu-deactivate.patch         |   53 -
 meta/recipes-gnome/gtk+/gtk+-2.12.7/no-demos.patch |   12 -
 .../gtk+/gtk+-2.12.7/pangoxft2.10.6.diff           | 2458 -----
 .../gtk+/gtk+-2.12.7/range-no-redraw.patch         |  130 -
 .../gtk+/gtk+-2.12.7/run-iconcache.patch           |   21 -
 .../gtk+/gtk+-2.12.7/scrolled-placement.patch      |   24 -
 .../gtk+/gtk+-2.12.7/toggle-font.diff              |  102 -
 .../recipes-gnome/gtk+/gtk+-2.12.7/xsettings.patch |   18 -
 ...Duplicate-the-exec-string-returned-by-gtk.patch |   33 -
 .../gtk+/gtk+-2.16.6/cellrenderer-cairo.patch      |   34 -
 .../gtk+-2.16.6/disable-gio-png-sniff-test.diff    |   99 -
 .../gtk+/gtk+-2.16.6/entry-cairo.patch             |  105 -
 .../gtk+/gtk+-2.16.6/hardcoded_libtool.patch       |   33 -
 meta/recipes-gnome/gtk+/gtk+-2.16.6/no-demos.patch |   12 -
 .../gtk+/gtk+-2.16.6/run-iconcache.patch           |   21 -
 .../gtk+/gtk+-2.16.6/toggle-font.diff              |  102 -
 .../recipes-gnome/gtk+/gtk+-2.16.6/xsettings.patch |   18 -
 meta/recipes-gnome/gtk+/gtk+_2.12.7.bb             |   49 -
 meta/recipes-gnome/gtk+/gtk+_2.16.6.bb             |   49 -
 29 files changed, 13471 deletions(-)
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/cellrenderer-cairo.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/combo-arrow-size.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/disable-print.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/entry-cairo.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/filechooser-default.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/filechooser-props.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/filechooser-sizefix.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/filesystem-volumes.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/gtklabel-resize-patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/hardcoded_libtool.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/menu-deactivate.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/no-demos.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/pangoxft2.10.6.diff
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/range-no-redraw.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/run-iconcache.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/scrolled-placement.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/toggle-font.diff
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.12.7/xsettings.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/0001-bgo-584832-Duplicate-the-exec-string-returned-by-gtk.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/cellrenderer-cairo.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/disable-gio-png-sniff-test.diff
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/entry-cairo.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/hardcoded_libtool.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/no-demos.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/run-iconcache.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/toggle-font.diff
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+-2.16.6/xsettings.patch
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+_2.12.7.bb
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+_2.16.6.bb
Richard Purdie - Aug. 17, 2012, 12:05 p.m.
On Fri, 2012-08-17 at 12:35 +0100, Ross Burton wrote:
> Remove the very old versions of GTK+ 2.x that we don't build.  They were
> kept for their patches, but the patches don't apply anymore because the
> relevant code has changed dramatically.
> 
> If someone still wants to use them, meta-oe is a better place for them to
> live.
> 
> Ross
> 
> The following changes since commit af847d36375aa53f0c1ee2a00c97ba9f38837d1b:
> 
>   bitbake: bitbake: build.py: Add stampdir argument to cached_mtime_noerror (2012-08-16 12:27:41 +0100)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/poky-contrib ross/gtk2
> 
> for you to fetch changes up to f6cf7bda28c1ae5f9033863f70657e1970b6bdc9:
> 
>   gtk+ remove 2.16.6 (2012-08-17 12:29:59 +0100)
> 
> ----------------------------------------------------------------
> Ross Burton (2):
>       gtk+: remove 2.12.7
>       gtk+ remove 2.16.6

Merged to master, thanks.

Richard
Paul Eggleton - Aug. 17, 2012, 12:27 p.m.
On Friday 17 August 2012 12:35:07 Ross Burton wrote:
> If someone still wants to use them, meta-oe is a better place for them to
> live.

As a general note, personally I'd rather that no more alternative versions of 
anything be added to meta-oe.

Cheers,
Paul
Martin Jansa - Aug. 17, 2012, 12:30 p.m.
On Fri, Aug 17, 2012 at 01:27:20PM +0100, Paul Eggleton wrote:
> On Friday 17 August 2012 12:35:07 Ross Burton wrote:
> > If someone still wants to use them, meta-oe is a better place for them to
> > live.
> 
> As a general note, personally I'd rather that no more alternative versions of 
> anything be added to meta-oe.

Yes especially with DEFAULT_PREFERRENCE not working between layers.. so
everyone with meta-oe and without P_V set, would get this old version..

Cheers,
Paul Eggleton - Aug. 17, 2012, 12:32 p.m.
On Friday 17 August 2012 14:30:17 Martin Jansa wrote:
> On Fri, Aug 17, 2012 at 01:27:20PM +0100, Paul Eggleton wrote:
> > On Friday 17 August 2012 12:35:07 Ross Burton wrote:
> > > If someone still wants to use them, meta-oe is a better place for them
> > > to
> > > live.
> > 
> > As a general note, personally I'd rather that no more alternative versions
> > of anything be added to meta-oe.
> 
> Yes especially with DEFAULT_PREFERRENCE not working between layers.. so
> everyone with meta-oe and without P_V set, would get this old version..

The best plan it would seem to me would be to have a separate meta-archive or 
meta-attic or similar named layer for these older recipes, and set its layer 
priority to the same as OE-Core.

Cheers,
Paul
Martin Jansa - Aug. 17, 2012, 12:39 p.m.
On Fri, Aug 17, 2012 at 01:32:59PM +0100, Paul Eggleton wrote:
> On Friday 17 August 2012 14:30:17 Martin Jansa wrote:
> > On Fri, Aug 17, 2012 at 01:27:20PM +0100, Paul Eggleton wrote:
> > > On Friday 17 August 2012 12:35:07 Ross Burton wrote:
> > > > If someone still wants to use them, meta-oe is a better place for them
> > > > to
> > > > live.
> > > 
> > > As a general note, personally I'd rather that no more alternative versions
> > > of anything be added to meta-oe.
> > 
> > Yes especially with DEFAULT_PREFERRENCE not working between layers.. so
> > everyone with meta-oe and without P_V set, would get this old version..
> 
> The best plan it would seem to me would be to have a separate meta-archive or 
> meta-attic or similar named layer for these older recipes, and set its layer 
> priority to the same as OE-Core.

Should I file a but to fix DEFAULT_PREFERENCE between layers? 

Because there is also use case when newer development version is added 
to e.g. meta-oe with negative D_P and only users who decide to test/use
that version should get it, if they define P_V for this new version.

Currently it would became default version for all meta-oe users without
P_V specified, which isn't very intuitive.

Cheers,
Paul Eggleton - Aug. 17, 2012, 12:48 p.m.
On Friday 17 August 2012 14:39:16 Martin Jansa wrote:
> Should I file a but to fix DEFAULT_PREFERENCE between layers?

We've discussed this problem before - the trouble is we would have to change 
the way the version preference calculation works, and I'm not sure we will be 
able to do that without breaking assumptions that people currently rely upon 
in the process. By all means file a bug, but I think coming up with a practical 
solution is going to be tricky.
 
> Because there is also use case when newer development version is added
> to e.g. meta-oe with negative D_P and only users who decide to test/use
> that version should get it, if they define P_V for this new version.

This is also undesirable for meta-oe IMHO - as a general principle, meta-oe 
shouldn't be trying to both add additional recipes *and* provide newer/older 
versions of recipes that are in OE-Core. Please, let's get the new versions 
into OE-Core or if they're too risky/broken for some use cases for that, then 
they belong in people's distro layers. (Practically I don't think there are 
that many instances of new versions of OE-Core recipes that people want to use 
that would be actually rejected by OE-Core).
 
Cheers,
Paul
Martin Jansa - Aug. 17, 2012, 12:54 p.m.
On Fri, Aug 17, 2012 at 01:48:45PM +0100, Paul Eggleton wrote:
> On Friday 17 August 2012 14:39:16 Martin Jansa wrote:
> > Should I file a but to fix DEFAULT_PREFERENCE between layers?
> 
> We've discussed this problem before - the trouble is we would have to change 
> the way the version preference calculation works, and I'm not sure we will be 
> able to do that without breaking assumptions that people currently rely upon 
> in the process. By all means file a bug, but I think coming up with a practical 
> solution is going to be tricky.
>  
> > Because there is also use case when newer development version is added
> > to e.g. meta-oe with negative D_P and only users who decide to test/use
> > that version should get it, if they define P_V for this new version.
> 
> This is also undesirable for meta-oe IMHO - as a general principle, meta-oe 
> shouldn't be trying to both add additional recipes *and* provide newer/older 
> versions of recipes that are in OE-Core. Please, let's get the new versions 
> into OE-Core or if they're too risky/broken for some use cases for that, then 
> they belong in people's distro layers. (Practically I don't think there are 
> that many instances of new versions of OE-Core recipes that people want to use 
> that would be actually rejected by OE-Core).

What if newer version is needed for recipe which exists only in meta-oe?

I had this in meta-efl where webkit-efl was sometimes segfaulting when
older stable version of libsoup2.4 was used, upstream solved that by
recommending development version of libsoup2.4, but as soon as I've
added it to meta-efl everybody (including users which don't use
webkit-efl from meta-efl - don't need this libsoup2.4) got it as
default.

Yes I could have added this libsoup2.4 only to meta-shr (where I had
P_V for that) and keep webkit-efl broken for everyone else, or try to
add developement version of libsoup2.4 to oe-core..

Cheers,
Martin Jansa - Aug. 17, 2012, 12:56 p.m.
On Fri, Aug 17, 2012 at 02:54:27PM +0200, Martin Jansa wrote:
> On Fri, Aug 17, 2012 at 01:48:45PM +0100, Paul Eggleton wrote:
> > On Friday 17 August 2012 14:39:16 Martin Jansa wrote:
> > > Should I file a but to fix DEFAULT_PREFERENCE between layers?
> > 
> > We've discussed this problem before - the trouble is we would have to change 
> > the way the version preference calculation works, and I'm not sure we will be 
> > able to do that without breaking assumptions that people currently rely upon 
> > in the process. By all means file a bug, but I think coming up with a practical 
> > solution is going to be tricky.
> >  
> > > Because there is also use case when newer development version is added
> > > to e.g. meta-oe with negative D_P and only users who decide to test/use
> > > that version should get it, if they define P_V for this new version.
> > 
> > This is also undesirable for meta-oe IMHO - as a general principle, meta-oe 
> > shouldn't be trying to both add additional recipes *and* provide newer/older 
> > versions of recipes that are in OE-Core. Please, let's get the new versions 
> > into OE-Core or if they're too risky/broken for some use cases for that, then 
> > they belong in people's distro layers. (Practically I don't think there are 
> > that many instances of new versions of OE-Core recipes that people want to use 
> > that would be actually rejected by OE-Core).
> 
> What if newer version is needed for recipe which exists only in meta-oe?
> 
> I had this in meta-efl where webkit-efl was sometimes segfaulting when
> older stable version of libsoup2.4 was used, upstream solved that by
> recommending development version of libsoup2.4, but as soon as I've
> added it to meta-efl everybody (including users which don't use
> webkit-efl from meta-efl - don't need this libsoup2.4) got it as
> default.
> 
> Yes I could have added this libsoup2.4 only to meta-shr (where I had
> P_V for that) and keep webkit-efl broken for everyone else, or try to
> add developement version of libsoup2.4 to oe-core..

https://bugzilla.yoctoproject.org/show_bug.cgi?id=2964
Paul Eggleton - Aug. 17, 2012, 1:08 p.m.
On Friday 17 August 2012 14:54:27 Martin Jansa wrote:
> On Fri, Aug 17, 2012 at 01:48:45PM +0100, Paul Eggleton wrote:
> > This is also undesirable for meta-oe IMHO - as a general principle,
> > meta-oe
> > shouldn't be trying to both add additional recipes *and* provide
> > newer/older versions of recipes that are in OE-Core. Please, let's get
> > the new versions into OE-Core or if they're too risky/broken for some use
> > cases for that, then they belong in people's distro layers. (Practically
> > I don't think there are that many instances of new versions of OE-Core
> > recipes that people want to use that would be actually rejected by
> > OE-Core).
> 
> What if newer version is needed for recipe which exists only in meta-oe?
> 
> I had this in meta-efl where webkit-efl was sometimes segfaulting when
> older stable version of libsoup2.4 was used, upstream solved that by
> recommending development version of libsoup2.4, but as soon as I've
> added it to meta-efl everybody (including users which don't use
> webkit-efl from meta-efl - don't need this libsoup2.4) got it as
> default.
>
> Yes I could have added this libsoup2.4 only to meta-shr (where I had
> P_V for that) and keep webkit-efl broken for everyone else, or try to
> add developement version of libsoup2.4 to oe-core..

That is an unfortunate situation - surely one possible solution though would 
be to backport the actual patch that fixes the problem to the version of the 
library in OE-Core until the development version of the library gets released? 
Alternatively, in certain cases of poorly maintained upstreams where releases 
are infrequent, we have just switched to the development version at a chosen 
revision in OE-Core (after sufficient testing, naturally).
 
I appreciate there are going to be outliers, but I think the majority of 
situations could be handled without making meta-oe introduce unexpected 
changes when it is enabled on top of OE-Core.

Cheers,
Paul