gobject introspection to oe-core

gobject introspection to oe-core

[Chris Trobridge]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

Hi,
I have done some testing of Alex's branch "akanavin/gobject-introspection-experimental", originally http://patchwork.openembedded.org/patch/107089/ 
I have built this successfully for x86 and x64 targets on an x64 build machine:
meta              meta-yocto        meta-yocto-bsp    = "akanavin/gobject-introspection-experimental:04c7746ce90abc14604dec3328b9472c53cccf98"meta-networking   meta-oe           meta-python       = "master:47f7d287a09329734629cb9d194ef4e077117d79"meta-haswell-wc   meta-intel        = "master:6e91701dcf68f9351db8bb0b92eb2d26af1b8f7f"meta-systemd      = "master:47f7d287a09329734629cb9d194ef4e077117d79"
Specifically, it built for the qemux86, qemux86-64 and hasell-wc machines.
I have successfully run my own python3 service, which uses python3 dbus and GObject from gi.repository.
I have also inherited gobject-introspection into modemmanager_1.4.2.bb from meta-oe, which fixed the recipe building and I have checked that the target executable runs but not tested its dbus interface yet.
Regards,Chris
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 2008 bytes --]

Re: gobject introspection to oe-core

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 258 bytes --]

On 17 December 2015 at 09:16, Chris Trobridge <christrobridge@hotmail.com>
wrote:

> I have successfully run my own python3 service, which uses python3 dbus
> and GObject from gi.repository.
>

Thanks for the feedback, it's much appreciated.

Ross

[-- Attachment #2: Type: text/html, Size: 632 bytes --]

Re: gobject introspection to oe-core

[Chris Trobridge]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

One thing I failed to mention when I reported on this previously is that I needed to patch polkit_0.113.bb:
-DEPENDS = "expat glib-2.0 intltool-native gobject-introspection-stub mozjs"+DEPENDS = "expat glib-2.0 intltool-native gobject-introspection mozjs"
This seems quite obvious, so I am sure you're aware of it.  That was all I needed but there are other references to gobject-introspection-stub in:
meta-gnome/recipes-gnome/libwnck/libwnck_2.31.0.bbmeta-multimedia/recipes-connectivity/gupnp/gupnp-igd_0.2.2.bbmeta-oe/recipes-devtools/libgee/libgee_0.16.1.bbmeta-oe/recipes-gnome/gtkextra/gtkextra_3.0.5.bbmeta-oe/recipes-support/upower/upower_0.9.14.bb
Regards,Chris
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 1370 bytes --]

Re: gobject introspection to oe-core

[Alexander Kanavin]

On 02/09/2016 12:30 PM, Chris Trobridge wrote:
> One thing I failed to mention when I reported on this previously is that
> I needed to patch polkit_0.113.bb:
>
> -DEPENDS = "expat glib-2.0 intltool-native gobject-introspection-stub mozjs"
> +DEPENDS = "expat glib-2.0 intltool-native gobject-introspection mozjs"
>
> This seems quite obvious, so I am sure you're aware of it.  That was all
> I needed but there are other references to gobject-introspection-stub in:
>
> meta-gnome/recipes-gnome/libwnck/libwnck_2.31.0.bb
> meta-multimedia/recipes-connectivity/gupnp/gupnp-igd_0.2.2.bb
> meta-oe/recipes-devtools/libgee/libgee_0.16.1.bb
> meta-oe/recipes-gnome/gtkextra/gtkextra_3.0.5.bb
> meta-oe/recipes-support/upower/upower_0.9.14.bb

Those recipes are all in meta-oe - fixing them is not in scope at the 
moment. For now the introspection patchset is strictly for oe-core.

You are welcome to develop and maintain a companion meta-oe patchset though.

Alex

Re: [OE-core] gobject introspection to oe-core

[alexander.kanavin]

>> meta-gnome/recipes-gnome/libwnck/libwnck_2.31.0.bb
>> meta-multimedia/recipes-connectivity/gupnp/gupnp-igd_0.2.2.bb
>> meta-oe/recipes-devtools/libgee/libgee_0.16.1.bb
>> meta-oe/recipes-gnome/gtkextra/gtkextra_3.0.5.bb
>> meta-oe/recipes-support/upower/upower_0.9.14.bb
>
> Those recipes are all in meta-oe - fixing them is not in scope at the
moment. For now the introspection patchset is strictly for oe-core.
>
> You are welcome to develop and maintain a companion meta-oe patchset
though.

Actually, scratch that. I realized that I'm probably the most qualified to
do this, and if I don't, there will be maintainer fury when introspection
lands in oe-core and dozens of recipes in meta-oe break. So without
further ado, here's the initial introspection patchset for meta-oe, which
you are welcome to try and test:
http://git.openembedded.org/meta-openembedded-contrib/log/?h=akanavin/gobject-introspection-fixes

Cheers,
Alex

Re: gobject introspection to oe-core

[alexander.kanavin]

>> meta-gnome/recipes-gnome/libwnck/libwnck_2.31.0.bb
>> meta-multimedia/recipes-connectivity/gupnp/gupnp-igd_0.2.2.bb
>> meta-oe/recipes-devtools/libgee/libgee_0.16.1.bb
>> meta-oe/recipes-gnome/gtkextra/gtkextra_3.0.5.bb
>> meta-oe/recipes-support/upower/upower_0.9.14.bb
>
> Those recipes are all in meta-oe - fixing them is not in scope at the
moment. For now the introspection patchset is strictly for oe-core.
>
> You are welcome to develop and maintain a companion meta-oe patchset
though.

Actually, scratch that. I realized that I'm probably the most qualified to
do this, and if I don't, there will be maintainer fury when introspection
lands in oe-core and dozens of recipes in meta-oe break. So without
further ado, here's the initial introspection patchset for meta-oe, which
you are welcome to try and test:
http://git.openembedded.org/meta-openembedded-contrib/log/?h=akanavin/gobject-introspection-fixes

Cheers,
Alex

gobject introspection - distccd?

[Chris Trobridge]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

Hi,
I was analysing a target system with gobject-introspection enabled and noticed that it is running 4 instances of distccd.

I can't work out why distcc should be running on the target but it occurred to me that gobject introspection requires target native compilation (using qemu) and that this might be the cause.
I will test this out more thoroughly when I can build yocto again, but is it possible the gobject-introspection recipe is somehow causing distcc to be added to the target?
Regards,Chris
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 1088 bytes --]

Re: gobject introspection - distccd?

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

On 4 January 2016 at 11:50, Chris Trobridge <christrobridge@hotmail.com>
wrote:

> I will test this out more thoroughly when I can build yocto again, but is
> it possible the gobject-introspection recipe is somehow causing distcc to
> be added to the target?
>

More likely some of the existing packagegroups which add distcc for
convenience, such as packagegroup-self-hosted or
packagegroup-core-device-devel.

Ross

[-- Attachment #2: Type: text/html, Size: 795 bytes --]

Re: gobject introspection - distccd?

[Chris Trobridge]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]




That's what I was thinking: gobject-introspection doesn't call it in directly but it does require compilation to be performed on the 'target' system and that could pull it in indirectly.
distcc (and hence avahi) are not required, so is this a general problem or just something I should explicitly remove from my image?
Chris

From: ross.burton@intel.comDate: Mon, 4 Jan 2016 12:03:44 +0000Subject: Re: [OE-core] gobject introspection - distccd?To: christrobridge@hotmail.comCC: openembedded-core@lists.openembedded.org

On 4 January 2016 at 11:50, Chris Trobridge <christrobridge@hotmail.com> wrote:I will test this out more thoroughly when I can build yocto again, but is it possible the gobject-introspection recipe is somehow causing distcc to be added to the target?
More likely some of the existing packagegroups which add distcc for convenience, such as packagegroup-self-hosted or packagegroup-core-device-devel.
Ross
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 2388 bytes --]

Re: gobject introspection - distccd?

[Alexander Kanavin]

On 01/04/2016 02:24 PM, Chris Trobridge wrote:
> That's what I was thinking: gobject-introspection doesn't call it in
> directly but it does require compilation to be performed on the 'target'
> system and that could pull it in indirectly.

g-introspection does not require compilation to be performed on the 
target. It requires running binaries that were cross-compiled for the 
target architecture, which is achieved by running them using qemu.

> distcc (and hence avahi) are not required, so is this a general problem
> or just something I should explicitly remove from my image?

I think it's a problem of your local setup; the g-o patchset definitely 
doesn't involve distcc at any point. You can build against a clean 
directory with only basic poky layers to verify that.


Alex

Re: gobject introspection - distccd?

[Chris Trobridge]

[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

Problem solved - nothing to do with gobject introspection but from the other change I had made, to build for qemu.
packagegroup-core-device-devel is pulled in for qemu targets in poky.conf and packagegroup-core-device-devel rdepends on distcc-config.
> To: openembedded-core@lists.openembedded.org> From: alexander.kanavin@linux.intel.com
> Date: Mon, 4 Jan 2016 14:49:13 +0200
> Subject: Re: [OE-core] gobject introspection - distccd?
> 
> On 01/04/2016 02:24 PM, Chris Trobridge wrote:
> > That's what I was thinking: gobject-introspection doesn't call it in
> > directly but it does require compilation to be performed on the 'target'
> > system and that could pull it in indirectly.
> 
> g-introspection does not require compilation to be performed on the 
> target. It requires running binaries that were cross-compiled for the 
> target architecture, which is achieved by running them using qemu.

That's what I meant to imply by putting target in quotes.
> > distcc (and hence avahi) are not required, so is this a general problem
> > or just something I should explicitly remove from my image?
> 
> I think it's a problem of your local setup; the g-o patchset definitely 
> doesn't involve distcc at any point. You can build against a clean 
> directory with only basic poky layers to verify that.
> 
> 
> Alex

Thanks,Chris
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 1980 bytes --]

Re: gobject introspection to oe-core

[Carlos Rafael Giani]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

This is very interesting. Once gobject introspection is in place, vala 
based software like Rygel can finally be compiled directly from the vala 
source, which makes it much easier to apply patches against it.
Also, I think the GStreamer 1.0 Python bindings need GIR. This recipe 
could then be reintroduced (it was there, but got removed).

On 2015-12-17 10:16, Chris Trobridge wrote:
> Hi,
>
> I have done some testing of Alex's branch 
> "akanavin/gobject-introspection-experimental", originally 
> http://patchwork.openembedded.org/patch/107089/ 
> <http://patchwork.openembedded.org/patch/107089/%0A><http://patchwork.openembedded.org/patch/107089/%0A>
>
> I have built this successfully for x86 and x64 targets on an x64 build 
> machine:
>
> meta
> meta-yocto
> meta-yocto-bsp    = 
> "akanavin/gobject-introspection-experimental:04c7746ce90abc14604dec3328b9472c53cccf98"
> meta-networking
> meta-oe
> meta-python       = "master:47f7d287a09329734629cb9d194ef4e077117d79"
> meta-haswell-wc
> meta-intel        = "master:6e91701dcf68f9351db8bb0b92eb2d26af1b8f7f"
> meta-systemd      = "master:47f7d287a09329734629cb9d194ef4e077117d79"
>
> Specifically, it built for the qemux86, qemux86-64 and hasell-wc machines.
>
> I have successfully run my own python3 service, which uses python3 
> dbus and GObject from gi.repository.
>
> I have also inherited gobject-introspection into modemmanager_1.4.2.bb 
> from meta-oe, which fixed the recipe building and I have checked that 
> the target executable runs but not tested its dbus interface yet.
>
> Regards,
> Chris
>
>
>


[-- Attachment #2: Type: text/html, Size: 3322 bytes --]

Re: gobject introspection to oe-core

[Alexander Kanavin]

On 02/09/2016 12:52 PM, Carlos Rafael Giani wrote:
> This is very interesting. Once gobject introspection is in place, vala
> based software like Rygel can finally be compiled directly from the vala
> source, which makes it much easier to apply patches against it.
> Also, I think the GStreamer 1.0 Python bindings need GIR. This recipe
> could then be reintroduced (it was there, but got removed).

Gstreamer Python bindings are not real bindings as such - they are a few 
tweaks and overrides on top of standard Python's support for 
introspection (which provided by pygobject), and they also add support 
for writing gstreamer elements in python.

Generally, nowadays any support for GLib-based software in language 
environments other than C or C++ is provided only through introspection.

If you want to write your software in anything else than C or C++, and 
you want to use gstreamer, webkit, gtk, glib's dbus support, etc., you 
have to have introspection working:
https://wiki.gnome.org/Projects/GObjectIntrospection/Users


Alex