[Patch v3] gconf: enable gtk+ 2.0 support to build gconf-sanity-check-2

[Patch v3] gconf: enable gtk+ 2.0 support to build gconf-sanity-check-2

[Koen Kooi]

This is needed for e.g. gnome-session:

gnome-session[424]: WARNING: Failed to run gconf-sanity-check-2: Failed to execute child process "/usr/libexec/gconf-sanity-check-2" (No such file or directory)

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
 meta/recipes-gnome/gnome/gconf_3.2.3.bb |   20 +++++++++++---------
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/meta/recipes-gnome/gnome/gconf_3.2.3.bb b/meta/recipes-gnome/gnome/gconf_3.2.3.bb
index f7d3594..412f01c 100644
--- a/meta/recipes-gnome/gnome/gconf_3.2.3.bb
+++ b/meta/recipes-gnome/gnome/gconf_3.2.3.bb
@@ -3,10 +3,10 @@ SECTION = "x11/gnome"
 LICENSE = "LGPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=55ca817ccb7d5b5b66355690e9abc605"
 
-DEPENDS = "glib-2.0 dbus dbus-glib libxml2 intltool-native polkit"
+DEPENDS = "glib-2.0 gtk+ dbus dbus-glib libxml2 intltool-native polkit"
 DEPENDS_virtclass-native = "glib-2.0-native dbus-native dbus-glib-native libxml2-native intltool-native gnome-common-native"
 
-PR = "r3"
+PR = "r5"
 
 inherit gnomebase
 
@@ -21,8 +21,10 @@ S = "${WORKDIR}/GConf-${PV}"
 
 POLKIT_OECONF = "--enable-defaults-service"
 POLKIT_OECONF_virtclass-native = "--disable-defaults-service"
-EXTRA_OECONF = "--disable-gtk-doc --disable-gtk --enable-shared --disable-static --enable-debug=yes \
-                --disable-introspection --disable-orbit --with-openldap=no ${POLKIT_OECONF}"
+GTKOECONF = "--with-gtk=2.0 --enable-gtk"
+GTKOECONF_virtclass-native = "--disable-gtk"
+EXTRA_OECONF = "--disable-gtk-doc --enable-shared --disable-static --enable-debug=yes \
+                --disable-introspection --disable-orbit --with-openldap=no ${POLKIT_OECONF} ${GTKOECONF}"
 
 do_configure_prepend () {
 	touch gtk-doc.make
@@ -42,11 +44,11 @@ RDEPENDS_${PN} += "${@base_contains('DISTRO_FEATURES', 'x11', 'dbus-x11', '', d)
 RDEPENDS_${PN}_virtclass-native = ""
 
 FILES_${PN} += "${libdir}/GConf/* \
-	        ${libdir}/gio/*/*.so \
-		${datadir}/polkit* \
-	       	${datadir}/dbus-1/services/*.service \
-	       	${datadir}/dbus-1/system-services/*.service \
-	        "
+                ${libdir}/gio/*/*.so \
+                ${datadir}/polkit* \
+                ${datadir}/dbus-1/services/*.service \
+                ${datadir}/dbus-1/system-services/*.service \
+               "
 FILES_${PN}-dbg += "${libdir}/*/*/.debug"
 FILES_${PN}-dev += "${datadir}/sgml/gconf/gconf-1.0.dtd"
 
-- 
1.7.2.5

Re: [Patch v3] gconf: enable gtk+ 2.0 support to build gconf-sanity-check-2

[Steve Sakoman]

On Thu, Jan 12, 2012 at 11:17 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> This is needed for e.g. gnome-session:
>
> gnome-session[424]: WARNING: Failed to run gconf-sanity-check-2: Failed to execute child process "/usr/libexec/gconf-sanity-check-2" (No such file or directory)
>
> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

Tested-by: Steve Sakoman <steve@sakoman.com>

Re: [Patch v3] gconf: enable gtk+ 2.0 support to build gconf-sanity-check-2

[Richard Purdie]

On Thu, 2012-01-12 at 20:17 +0100, Koen Kooi wrote:
> This is needed for e.g. gnome-session:
> 
> gnome-session[424]: WARNING: Failed to run gconf-sanity-check-2: Failed to execute child process "/usr/libexec/gconf-sanity-check-2" (No such file or directory)
> 
> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> ---
>  meta/recipes-gnome/gnome/gconf_3.2.3.bb |   20 +++++++++++---------
>  1 files changed, 11 insertions(+), 9 deletions(-)

Merged to master, thanks.

Richard

Re: [Patch v3] gconf: enable gtk+ 2.0 support to build gconf-sanity-check-2

[Richard Purdie]

On Thu, 2012-01-12 at 20:17 +0100, Koen Kooi wrote:
> This is needed for e.g. gnome-session:
> 
> gnome-session[424]: WARNING: Failed to run gconf-sanity-check-2:
> Failed to execute child process
> "/usr/libexec/gconf-sanity-check-2" (No such file or directory)
> 
> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> ---
>  meta/recipes-gnome/gnome/gconf_3.2.3.bb |   20 +++++++++++---------
>  1 files changed, 11 insertions(+), 9 deletions(-)

This broke OE-Core since gtk+ depends on pango, pango depends on gconf
and gconf depends on gtk+.

Why wasn't this tested? I can only assume there are things in meta-oe
masking pieces of OE-Core and this shows how harmful they can be. 

Since this was breaking things for pretty much everyone who does use
OE-Core, I pushed a patch changing pango to inherit gnomebase instead of
gnome.bbclass which resolves the circular dependency.

Cheers,

Richard

Re: [Patch v3] gconf: enable gtk+ 2.0 support to build gconf-sanity-check-2

[Steve Sakoman]

On Mon, Jan 16, 2012 at 10:06 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Thu, 2012-01-12 at 20:17 +0100, Koen Kooi wrote:
>> This is needed for e.g. gnome-session:
>>
>> gnome-session[424]: WARNING: Failed to run gconf-sanity-check-2:
>> Failed to execute child process
>> "/usr/libexec/gconf-sanity-check-2" (No such file or directory)
>>
>> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
>> ---
>>  meta/recipes-gnome/gnome/gconf_3.2.3.bb |   20 +++++++++++---------
>>  1 files changed, 11 insertions(+), 9 deletions(-)
>
> This broke OE-Core since gtk+ depends on pango, pango depends on gconf
> and gconf depends on gtk+.
>
> Why wasn't this tested? I can only assume there are things in meta-oe
> masking pieces of OE-Core and this shows how harmful they can be.

My tested-by was indeed performed with the meta-oe layer enabled.

In the future I will make clear what layers were used in my testing.

I fear that this kind of thing is going to bite us repeatedly :-(

> Since this was breaking things for pretty much everyone who does use
> OE-Core, I pushed a patch changing pango to inherit gnomebase instead of
> gnome.bbclass which resolves the circular dependency.

This seems like a reasonable fix.

Steve

Re: [Patch v3] gconf: enable gtk+ 2.0 support to build gconf-sanity-check-2

[Phil Blundell]

On Mon, 2012-01-16 at 10:19 -0800, Steve Sakoman wrote:
> My tested-by was indeed performed with the meta-oe layer enabled.
> 
> In the future I will make clear what layers were used in my testing.
> 
> I fear that this kind of thing is going to bite us repeatedly :-(

It's never been entirely clear to me why meta-oe needs to override quite
so many bits of oe-core as it does.  I think you're probably right that,
as long as it continues to do so, and people enable meta-oe during
testing, this sort of issue probably is going to continue to occur.

We had some discussion a while back about making the layer priority be a
user-configurable thing, which would enable you to sink meta-oe beneath
oe-core in the priority stack.  This would allow you to use the recipes
which are in meta-oe but not oe-core, without overriding the bits that
do exist in oe-core itself.  I think I lost that argument at the time
but I still feel this would be an improvement.

(Actually, right now what I am doing is just cherry-picking the few
recipes that I need from meta-oe into a local layer and not adding
meta-oe itself to bblayers.conf at all.)

p.

Re: [Patch v3] gconf: enable gtk+ 2.0 support to build gconf-sanity-check-2

[Philip Balister]

On 01/16/2012 01:45 PM, Phil Blundell wrote:
> On Mon, 2012-01-16 at 10:19 -0800, Steve Sakoman wrote:
>> My tested-by was indeed performed with the meta-oe layer enabled.
>>
>> In the future I will make clear what layers were used in my testing.
>>
>> I fear that this kind of thing is going to bite us repeatedly :-(
> 
> It's never been entirely clear to me why meta-oe needs to override quite
> so many bits of oe-core as it does.  I think you're probably right that,
> as long as it continues to do so, and people enable meta-oe during
> testing, this sort of issue probably is going to continue to occur.

It sounds like we need to collect a list of bits of oe-core that meta-oe
overrides and work out a plan to resolve these differences.
This sort of thing creates a lot of confusion for people (like me) that
are primarily concerned with getting work done using OE, and are less
concerned with the inner workings of layers.

Does anyone have suggestions for identifying these cases and explaining
why they are that way?

I see no sense in forcing people to basically fork layers due to
unresolved issues between OE-Core and meta-oe.

Philip

> 
> We had some discussion a while back about making the layer priority be a
> user-configurable thing, which would enable you to sink meta-oe beneath
> oe-core in the priority stack.  This would allow you to use the recipes
> which are in meta-oe but not oe-core, without overriding the bits that
> do exist in oe-core itself.  I think I lost that argument at the time
> but I still feel this would be an improvement.
> 
> (Actually, right now what I am doing is just cherry-picking the few
> recipes that I need from meta-oe into a local layer and not adding
> meta-oe itself to bblayers.conf at all.)
> 
> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 

Re: [Patch v3] gconf: enable gtk+ 2.0 support to build gconf-sanity-check-2

[Joshua Lock]

On 17/01/12 08:30, Philip Balister wrote:
> On 01/16/2012 01:45 PM, Phil Blundell wrote:
>> On Mon, 2012-01-16 at 10:19 -0800, Steve Sakoman wrote:
>>> My tested-by was indeed performed with the meta-oe layer enabled.
>>>
>>> In the future I will make clear what layers were used in my testing.
>>>
>>> I fear that this kind of thing is going to bite us repeatedly :-(
>>
>> It's never been entirely clear to me why meta-oe needs to override quite
>> so many bits of oe-core as it does.  I think you're probably right that,
>> as long as it continues to do so, and people enable meta-oe during
>> testing, this sort of issue probably is going to continue to occur.
>
> It sounds like we need to collect a list of bits of oe-core that meta-oe
> overrides and work out a plan to resolve these differences.

Agreed! There have been a couple of efforts for specific recipes, most 
recently udev work from Otavio.

I'd definitely like to see the differences resolved, or at least 
reduced, and will be happy to help work through some of the issues.

Cheers,
Joshua
-- 
Joshua Lock
         Yocto Project "Johannes factotum"
         Intel Open Source Technology Centre

Re: [Patch v3] gconf: enable gtk+ 2.0 support to build gconf-sanity-check-2

[Khem Raj]

On (17/01/12 11:30), Philip Balister wrote:
> On 01/16/2012 01:45 PM, Phil Blundell wrote:
> > On Mon, 2012-01-16 at 10:19 -0800, Steve Sakoman wrote:
> >> My tested-by was indeed performed with the meta-oe layer enabled.
> >>
> >> In the future I will make clear what layers were used in my testing.
> >>
> >> I fear that this kind of thing is going to bite us repeatedly :-(
> > 
> > It's never been entirely clear to me why meta-oe needs to override quite
> > so many bits of oe-core as it does.  I think you're probably right that,
> > as long as it continues to do so, and people enable meta-oe during
> > testing, this sort of issue probably is going to continue to occur.
> 
> It sounds like we need to collect a list of bits of oe-core that meta-oe
> overrides and work out a plan to resolve these differences.
> This sort of thing creates a lot of confusion for people (like me) that
> are primarily concerned with getting work done using OE, and are less
> concerned with the inner workings of layers.
> 
> Does anyone have suggestions for identifying these cases and explaining
> why they are that way?

We need to bean out the recipes e.g.

1. Dont exist in oe-core ( they are harmless)
2. Are existing in oe-core but older/newer versions ( find reasons )
3. config changes. Are they common or distro specific can they be moved
   to other appropriate layers

overall look at if some of the recipe differences can be merged into say
oe-core

> 
> I see no sense in forcing people to basically fork layers due to
> unresolved issues between OE-Core and meta-oe.

true

> 
> Philip
>