Getting python-dbusmock into the SDK

Getting python-dbusmock into the SDK

[Mardegan, Alberto]

Hi there :-)
  I want to add python-dbusmock (which has a recipe in oe/meta-python)
to our SDK. So, I added

  TOOLCHAIN_HOST_TASK_append = " nativesdk-python-dbusmock"

to our image recipe and made a bbappend for python-dbusmock containing
this line:

  BBCLASSEXTEND += " nativesdk"

When I ran bitbake with the populate-sdk task I got an error about a
nativesdk-python-pygobject, which was not provided by any package. So I
added the same BBCLASSEXTEND trick to its bbappend, and I did the same
for nativesdk-python-dbus which was also declared as missing.

At this point (after adding the BBCLASSEXTEND to python-dbus) I got this
error:

============
ERROR: Nothing PROVIDES 'nativesdk-dbus-glib' (but
virtual:nativesdk:/home/mardy/pelux/build/../sources/meta-openembedded/meta-python/recipes-devtools/python/python-dbus_1.2.4.bb
DEPENDS on or otherwise requires it). Close matches:
  nativesdk-dbus
  nativesdk-json-glib
  nativesdk-glibc
============

Do I need to continue adding BBCLASSEXTEND+=" nativesdk" to the packages
as I get new failures, or am I doing something wrong?
I became suspicious when I saw "nativesdk-glib" appearing in the logs
above; I guess we can safely assume that glibc is available in the host
system, so the need to add it as a native SDK package got me puzzled.

Should I continue down this road, or is it a dead end?

Ciao,
  Alberto

________________________________

This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.

Re: Getting python-dbusmock into the SDK

[Burton, Ross]

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

On 24 January 2018 at 13:31, Mardegan, Alberto <AMardegan@luxoft.com> wrote:

> ============
> ERROR: Nothing PROVIDES 'nativesdk-dbus-glib' (but
> virtual:nativesdk:/home/mardy/pelux/build/../sources/meta-
> openembedded/meta-python/recipes-devtools/python/python-dbus_1.2.4.bb
> DEPENDS on or otherwise requires it). Close matches:
>   nativesdk-dbus
>   nativesdk-json-glib
>   nativesdk-glibc
> ============
>
> Do I need to continue adding BBCLASSEXTEND+=" nativesdk" to the packages
> as I get new failures, or am I doing something wrong?
> I became suspicious when I saw "nativesdk-glib" appearing in the logs
> above; I guess we can safely assume that glibc is available in the host
> system, so the need to add it as a native SDK package got me puzzled.
>

Those are close matches on the assumption that maybe you did a typo.

Yes, you need to add BBCLASSEXTEND as appropriate.  Once you've verified
that the recipes actually build correctly in nativesk please send those
additions to oe-core.

Ross

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

Re: Getting python-dbusmock into the SDK

[Mardegan, Alberto]

On 24/01/2018 16:40, Burton, Ross wrote:
> Those are close matches on the assumption that maybe you did a typo.

Right, I had completely misread the error message :-)

> Yes, you need to add BBCLASSEXTEND as appropriate.  Once you've verified
> that the recipes actually build correctly in nativesk please send those
> additions to oe-core.

OK. FYI, there's another change that was needed: the dbus recipe has:

  OLDPKGNAME = "dbus-x11"
  OLDPKGNAME_class-nativesdk = ""

I had to change the second line and set the value to "dbus-x11" there as
well, or I would get an unsolved dependency (dbus-glib requires it).

Ciao,
  Alberto

________________________________

This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.

Re: Getting python-dbusmock into the SDK

[Richard Purdie]

On Thu, 2018-01-25 at 10:36 +0000, Mardegan, Alberto wrote:
> On 24/01/2018 16:40, Burton, Ross wrote:
> > 
> > Those are close matches on the assumption that maybe you did a
> > typo.
> Right, I had completely misread the error message :-)
> 
> > 
> > Yes, you need to add BBCLASSEXTEND as appropriate.  Once you've
> > verified
> > that the recipes actually build correctly in nativesk please send
> > those
> > additions to oe-core.
> OK. FYI, there's another change that was needed: the dbus recipe has:
> 
>   OLDPKGNAME = "dbus-x11"
>   OLDPKGNAME_class-nativesdk = ""
> 
> I had to change the second line and set the value to "dbus-x11" there
> as
> well, or I would get an unsolved dependency (dbus-glib requires it).

Installing dbus in the sdk makes very little sense so you may want to
rethink that (or tell the sdk its a system provided dependency).

Cheers,

Richard

Re: Getting python-dbusmock into the SDK

[Mardegan, Alberto]

On 25/01/2018 14:34, Richard Purdie wrote:
>
> Installing dbus in the sdk makes very little sense so you may want to
> rethink that (or tell the sdk its a system provided dependency).

Good point (the latter)!

Ciao,
  Alberto

________________________________

This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.

Error building python-gobject for nativeSDK (was: Getting python-dbusmock into the SDK)

[Mardegan, Alberto]

Hi!
  I made a little progress, but now I'm stuck with this error while
building python-gobject for nativesdk:

  https://paste.ubuntu.com/26463423/

In short, the gobject-introspection-1.0 pkg-config file is not found. I
see that python-gobjecty inherits from the gobject-introspection class,
which has these two lines:

 DEPENDS_append_class-native = " gobject-introspection-native"
 DEPENDS_append_class-nativesdk = " gobject-introspection-native"

Assuming that the second one was a typo, I changed the dependency to
point at "nativesdk-gobject-introspection", and added "nativesdk" to
BBCLASS_EXTENDS in the gobject-introspection recipe.
This helped to get a bit further, and now I get this:

  https://paste.ubuntu.com/26463458/

( /usr/bin/env:
‘/home/mardy/pelux/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-gobject-introspection/1.50.0-r0/recipe’:
No such file or directory )

which looks a bit weird... Any hints on what could be causing this?

Ciao,
  Alberto

________________________________

This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.

Re: Error building python-gobject for nativeSDK

[Alexander Kanavin]

On 01/26/2018 12:59 PM, Mardegan, Alberto wrote:
>    I made a little progress, but now I'm stuck with this error while
> building python-gobject for nativesdk:
> 
>    https://paste.ubuntu.com/26463423/
> 
> In short, the gobject-introspection-1.0 pkg-config file is not found. I
> see that python-gobjecty inherits from the gobject-introspection class,
> which has these two lines:
> 
>   DEPENDS_append_class-native = " gobject-introspection-native"
>   DEPENDS_append_class-nativesdk = " gobject-introspection-native"
> 
> Assuming that the second one was a typo, I changed the dependency to
> point at "nativesdk-gobject-introspection", and added "nativesdk" to
> BBCLASS_EXTENDS in the gobject-introspection recipe.
> This helped to get a bit further, and now I get this:
> 
>    https://paste.ubuntu.com/26463458/
> 
> ( /usr/bin/env:
> ‘/home/mardy/pelux/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-gobject-introspection/1.50.0-r0/recipe’:
> No such file or directory )
> 
> which looks a bit weird... Any hints on what could be causing this?

To reproduce this I'd have to enable nativesdk in a whole bunch of 
recipes and maybe do other fixes. It's better if you share the point 
where you're stuck.

Can you please:
1) set up plain poky (no pelux layers :) with all the modifications you 
made to oe-core, preferably *not* squashed together into a single commit;
2) publish your changes so I can pull them in?


Alex

Re: Error building python-gobject for nativeSDK

[Alexander Kanavin]

On 01/26/2018 12:59 PM, Mardegan, Alberto wrote:
> Hi!
>    I made a little progress, but now I'm stuck with this error while
> building python-gobject for nativesdk:
> 
>    https://paste.ubuntu.com/26463423/
> 
> In short, the gobject-introspection-1.0 pkg-config file is not found. I
> see that python-gobjecty inherits from the gobject-introspection class,
> which has these two lines:
> 
>   DEPENDS_append_class-native = " gobject-introspection-native"
>   DEPENDS_append_class-nativesdk = " gobject-introspection-native"
> 
> Assuming that the second one was a typo, I changed the dependency to
> point at "nativesdk-gobject-introspection", and added "nativesdk" to
> BBCLASS_EXTENDS in the gobject-introspection recipe.

Note that at the moment we explicitly disable g-i for nativesdk in g-i 
class:

EXTRA_OECONF_prepend_class-nativesdk = "--disable-introspection "

So you're effectively working on a new feature, and it's not surprising 
there are weird errors :) Gobject-introspection is a notoriously tricky, 
delicate thing that was never designed for cross-compilation or 
sysroots, and you only need to look at the g-i recipe to see how much 
effort went into making it work right when building for the target.

I did reproduce the

"| ./g-ir-compiler: line 117: 
/home/mardy/pelux/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-gobject-introspection/1.50.0-r0/build/.libs/lt-g-ir-compiler: 
No such file or directory"

stuff, so no need to publish anything :). I can't promise I'll find time 
to look into it very soon though - this is a new feature development, 
not a bug.


Alex

Re: Error building python-gobject for nativeSDK

[Mardegan, Alberto]

On 26/01/2018 19:38, Alexander Kanavin wrote:
> I did reproduce the
>
> "| ./g-ir-compiler: line 117:
> /home/mardy/pelux/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-gobject-introspection/1.50.0-r0/build/.libs/lt-g-ir-compiler:
> No such file or directory"
>
> stuff, so no need to publish anything :). I can't promise I'll find time
> to look into it very soon though - this is a new feature development,
> not a bug.

Thanks Alex! Indeed this looks tricky... Anyway, according to the
documentation it would looks like the GI typelib files should be
architecture independent:
  https://developer.gnome.org/gi/unstable/gi-GITypelib.html
So I guess the problem here is that g-ir-compiler is being built for the
target architecture, while it's something that can be built natively?

Ciao,
  Alberto

________________________________

This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.

Re: Error building python-gobject for nativeSDK

[Alexander Kanavin]

On 01/29/2018 08:44 AM, Mardegan, Alberto wrote:
>> I did reproduce the
>>
>> "| ./g-ir-compiler: line 117:
>> /home/mardy/pelux/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-gobject-introspection/1.50.0-r0/build/.libs/lt-g-ir-compiler:
>> No such file or directory"
>>
>> stuff, so no need to publish anything :). I can't promise I'll find time
>> to look into it very soon though - this is a new feature development,
>> not a bug.
> 
> Thanks Alex! Indeed this looks tricky... Anyway, according to the
> documentation it would looks like the GI typelib files should be
> architecture independent:
>    https://developer.gnome.org/gi/unstable/gi-GITypelib.html
> So I guess the problem here is that g-ir-compiler is being built for the
> target architecture, while it's something that can be built natively?

Typelib files are essentially a memory dump of internal g-i C structures 
to disk. They might be the same on every architecture, or they might not 
(endiannness, alignment). I'm not trusting that they are. So to produce 
them for target we build a target g-ir-compiler and run it under qemu.

In this case, the produced typelib files are not intended for the 
target, they are intended for the nativesdk package. The error is 
probably some simple mismatch between the binary name and what the build 
configuration expects to run. I have a hunch that's not the only issue 
to sort though :)

Alex