Fails to launch the hob

Fails to launch the hob

[Biao]

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

Hi all, 


I can not launch hob on my ubun-10.04, it seems saying "no PyGobject" whereas python-object has already been installed. Can anyone kindly give a help?


$ hob
FATAL: Gtk+, PyGtk and PyGobject are required to use Hob,
You have Gtk+ 2.20.1 and PyGtk 2.17.0.


$ sudo apt-get install python-gobject
Reading package lists... Done
Building dependency tree       
Reading state information... Done
python-gobject is already the newest version.


$ uname -a
Linux zb-d 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC 2011 x86_64 GNU/Linux


Thanks,
Biao

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

Re: Fails to launch the hob

[Mihai Lindner]

On Mon, 2012-12-24 at 15:37 +0800, Biao wrote:
> Hi all, 
> 
> 
> I can not launch hob on my ubun-10.04, it seems saying "no PyGobject" whereas python-object has already been installed. Can anyone kindly give a help?
> 
> 
> $ hob
> FATAL: Gtk+, PyGtk and PyGobject are required to use Hob,
> You have Gtk+ 2.20.1 and PyGtk 2.17.0.
> 
> 
> $ sudo apt-get install python-gobject
> Reading package lists... Done
> Building dependency tree       
> Reading state information... Done
> python-gobject is already the newest version.
> 
Python-gobject seems fine, Gtk seems fine (you have 2.20.1, Hob wants
higher than 2.20.0), which leaves python-gtk2 version 2.17.0 on your
system. Hob wants a version higher than 2.21.0.

--Mihai
> 
> $ uname -a
> Linux zb-d 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC 2011 x86_64 GNU/Linux
> 
> 
> Thanks,
> Biao
> _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto

Re: Fails to launch the hob

[Mihai Lindner]

On Mon, 2012-12-24 at 14:23 +0200, Mihai Lindner wrote:
> On Mon, 2012-12-24 at 15:37 +0800, Biao wrote:
> > Hi all, 
> > 
> > 
> > I can not launch hob on my ubun-10.04, it seems saying "no PyGobject" whereas python-object has already been installed. Can anyone kindly give a help?
> > 
Oh, forgot to mention here, that you should probably be using Denzil,
instead of Danny or 'master'.
> > 
> > $ hob
> > FATAL: Gtk+, PyGtk and PyGobject are required to use Hob,
> > You have Gtk+ 2.20.1 and PyGtk 2.17.0.
> > 
> > 
> > $ sudo apt-get install python-gobject
> > Reading package lists... Done
> > Building dependency tree       
> > Reading state information... Done
> > python-gobject is already the newest version.
> > 
> Python-gobject seems fine, Gtk seems fine (you have 2.20.1, Hob wants
> higher than 2.20.0), which leaves python-gtk2 version 2.17.0 on your
> system. Hob wants a version higher than 2.21.0.
> 
> --Mihai
> > 
> > $ uname -a
> > Linux zb-d 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC 2011 x86_64 GNU/Linux
> > 
> > 
> > Thanks,
> > Biao
> > _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Fails to launch the hob

[Biao]

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


At 2012-12-24 20:37:26,"Mihai Lindner" <mihaix.lindner@linux.intel.com> wrote:
>On Mon, 2012-12-24 at 14:23 +0200, Mihai Lindner wrote:
>> On Mon, 2012-12-24 at 15:37 +0800, Biao wrote:
>> > Hi all, 
>> > 
>> > 
>> > I can not launch hob on my ubun-10.04, it seems saying "no PyGobject" whereas python-object has already been installed. Can anyone kindly give a help?
>> > 
>Oh, forgot to mention here, that you should probably be using Denzil,
>instead of Danny or 'master'.
Thanks for the kindly reminder.
>> > 
>> > $ hob
>> > FATAL: Gtk+, PyGtk and PyGobject are required to use Hob,
>> > You have Gtk+ 2.20.1 and PyGtk 2.17.0.
>> > 
>> > 
>> > $ sudo apt-get install python-gobject
>> > Reading package lists... Done
>> > Building dependency tree       
>> > Reading state information... Done
>> > python-gobject is already the newest version.
>> > 
>> Python-gobject seems fine, Gtk seems fine (you have 2.20.1, Hob wants
>> higher than 2.20.0), which leaves python-gtk2 version 2.17.0 on your
>> system. Hob wants a version higher than 2.21.0.
Thanks for this information, it seems the prompt message on the environment checking is not so clear.  Where are the hob users supposed to get such kind of information from?
I did not found this information from the hob manual.
>> 
>> --Mihai
>> > 
>> > $ uname -a
>> > Linux zb-d 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC 2011 x86_64 GNU/Linux
>> > 
>> > 
>> > Thanks,
>> > Biao
>> > _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
>> 
>> 
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto

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

Re: Fails to launch the hob

[Barros Pena, Belen]

Any chance we could change the content of the error message to provide better indication of what the problem is? The idea would be adding version numbers and printing only what's causing trouble.

So, from:

$ hob
FATAL: Gtk+, PyGtk and PyGobject are required to use Hob,
You have Gtk+ 2.20.1 and PyGtk 2.17.0.

To something like:

$ hob
FATAL: Hob requires Gtk+ 2.20.0 or higher, PyGtk 2.21.0 or higher and PyGobject [insert minimum version here] or higher
You have PyGtk 2.17.0.

Would this be possible?

We should probably also add a paragraph listing essential packages to the Hob manual page on the website (https://www.yoctoproject.org/documentation/hob-manual). If someone tells me what's the minimum version of PyGobject required I could probably edit the page myself.

Thanks!

Belen



From: Biao <huanmateme@163.com<mailto:huanmateme@163.com>>
Date: Tuesday, 25 December 2012 06:16
To: Mihai Lindner <mihaix.lindner@linux.intel.com<mailto:mihaix.lindner@linux.intel.com>>
Cc: "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>" <yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>>
Subject: Re: [yocto] Fails to launch the hob


At 2012-12-24 20:37:26,"Mihai Lindner" <mihaix.lindner@linux.intel.com<mailto:mihaix.lindner@linux.intel.com>> wrote:
>On Mon, 2012-12-24 at 14:23 +0200, Mihai Lindner wrote:
>> On Mon, 2012-12-24 at 15:37 +0800, Biao wrote:
>> > Hi all,
>> >
>> >
>> > I can not launch hob on my ubun-10.04, it seems saying "no PyGobject" whereas python-object has already been installed. Can anyone kindly give a help?
>> >
>Oh, forgot to mention here, that you should probably be using Denzil,
>instead of Danny or 'master'.

Thanks for the kindly reminder.
>> >
>> > $ hob
>> > FATAL: Gtk+, PyGtk and PyGobject are required to use Hob,
>> > You have Gtk+ 2.20.1 and PyGtk 2.17.0.
>> >
>> >
>> > $ sudo apt-get install python-gobject
>> > Reading package lists... Done
>> > Building dependency tree
>> > Reading state information... Done
>> > python-gobject is already the newest version.
>> >
>> Python-gobject seems fine, Gtk seems fine (you have 2.20.1, Hob wants
>> higher than 2.20.0), which leaves python-gtk2 version 2.17.0 on your
>> system. Hob wants a version higher than 2.21.0.

Thanks for this information, it seems the prompt message on the environment checking is not so clear.  Where are the hob users supposed to get such kind of information from?

I did not found this information from the hob manual.

>>
>> --Mihai
>> >
>> > $ uname -a
>> > Linux zb-d 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC 2011 x86_64 GNU/Linux
>> >
>> >
>> > Thanks,
>> > Biao
>> > _______________________________________________ yocto mailing list yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
>https://lists.yoctoproject.org/listinfo/yocto

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: Fails to launch the hob

[Zhang, Jessica]

Hi Belen,

I'll modify the error message per suggestion.  By looking at the existing code, seems we only check for GTK+ and PyGtk version, so probably I'll drop PyGobject in the error message.  So you probably can update the hob info on the web-site accordingly.

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Barros Pena, Belen
Sent: Thursday, January 03, 2013 8:48 AM
To: Biao; Mihai Lindner
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Fails to launch the hob

Any chance we could change the content of the error message to provide better indication of what the problem is? The idea would be adding version numbers and printing only what's causing trouble.

So, from:

$ hob
FATAL: Gtk+, PyGtk and PyGobject are required to use Hob, You have Gtk+ 2.20.1 and PyGtk 2.17.0.

To something like:

$ hob
FATAL: Hob requires Gtk+ 2.20.0 or higher, PyGtk 2.21.0 or higher and PyGobject [insert minimum version here] or higher You have PyGtk 2.17.0.

Would this be possible?

We should probably also add a paragraph listing essential packages to the Hob manual page on the website (https://www.yoctoproject.org/documentation/hob-manual). If someone tells me what's the minimum version of PyGobject required I could probably edit the page myself.

Thanks!

Belen



From: Biao <huanmateme@163.com<mailto:huanmateme@163.com>>
Date: Tuesday, 25 December 2012 06:16
To: Mihai Lindner <mihaix.lindner@linux.intel.com<mailto:mihaix.lindner@linux.intel.com>>
Cc: "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>" <yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>>
Subject: Re: [yocto] Fails to launch the hob


At 2012-12-24 20:37:26,"Mihai Lindner" <mihaix.lindner@linux.intel.com<mailto:mihaix.lindner@linux.intel.com>> wrote:
>On Mon, 2012-12-24 at 14:23 +0200, Mihai Lindner wrote:
>> On Mon, 2012-12-24 at 15:37 +0800, Biao wrote:
>> > Hi all,
>> >
>> >
>> > I can not launch hob on my ubun-10.04, it seems saying "no PyGobject" whereas python-object has already been installed. Can anyone kindly give a help?
>> >
>Oh, forgot to mention here, that you should probably be using Denzil,
>instead of Danny or 'master'.

Thanks for the kindly reminder.
>> >
>> > $ hob
>> > FATAL: Gtk+, PyGtk and PyGobject are required to use Hob, You have
>> > Gtk+ 2.20.1 and PyGtk 2.17.0.
>> >
>> >
>> > $ sudo apt-get install python-gobject Reading package lists... Done
>> > Building dependency tree Reading state information... Done
>> > python-gobject is already the newest version.
>> >
>> Python-gobject seems fine, Gtk seems fine (you have 2.20.1, Hob wants
>> higher than 2.20.0), which leaves python-gtk2 version 2.17.0 on your
>> system. Hob wants a version higher than 2.21.0.

Thanks for this information, it seems the prompt message on the environment checking is not so clear.  Where are the hob users supposed to get such kind of information from?

I did not found this information from the hob manual.

>>
>> --Mihai
>> >
>> > $ uname -a
>> > Linux zb-d 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC
>> > 2011 x86_64 GNU/Linux
>> >
>> >
>> > Thanks,
>> > Biao
>> > _______________________________________________ yocto mailing list
>> > yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
>> > https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
>https://lists.yoctoproject.org/listinfo/yocto

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: Fails to launch the hob

[Barros Pena, Belen]

Thanks, Jessica! I'll update the webpage.

Belen

On 03/01/2013 23:11, "Zhang, Jessica" <jessica.zhang@intel.com> wrote:

>Hi Belen,
>
>I'll modify the error message per suggestion.  By looking at the existing
>code, seems we only check for GTK+ and PyGtk version, so probably I'll
>drop PyGobject in the error message.  So you probably can update the hob
>info on the web-site accordingly.
>
>Thanks,
>Jessica
>
>-----Original Message-----
>From: yocto-bounces@yoctoproject.org
>[mailto:yocto-bounces@yoctoproject.org] On Behalf Of Barros Pena, Belen
>Sent: Thursday, January 03, 2013 8:48 AM
>To: Biao; Mihai Lindner
>Cc: yocto@yoctoproject.org
>Subject: Re: [yocto] Fails to launch the hob
>
>Any chance we could change the content of the error message to provide
>better indication of what the problem is? The idea would be adding
>version numbers and printing only what's causing trouble.
>
>So, from:
>
>$ hob
>FATAL: Gtk+, PyGtk and PyGobject are required to use Hob, You have Gtk+
>2.20.1 and PyGtk 2.17.0.
>
>To something like:
>
>$ hob
>FATAL: Hob requires Gtk+ 2.20.0 or higher, PyGtk 2.21.0 or higher and
>PyGobject [insert minimum version here] or higher You have PyGtk 2.17.0.
>
>Would this be possible?
>
>We should probably also add a paragraph listing essential packages to the
>Hob manual page on the website
>(https://www.yoctoproject.org/documentation/hob-manual). If someone tells
>me what's the minimum version of PyGobject required I could probably edit
>the page myself.
>
>Thanks!
>
>Belen
>
>
>
>From: Biao <huanmateme@163.com<mailto:huanmateme@163.com>>
>Date: Tuesday, 25 December 2012 06:16
>To: Mihai Lindner 
><mihaix.lindner@linux.intel.com<mailto:mihaix.lindner@linux.intel.com>>
>Cc: "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>"
><yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>>
>Subject: Re: [yocto] Fails to launch the hob
>
>
>At 2012-12-24 20:37:26,"Mihai Lindner"
><mihaix.lindner@linux.intel.com<mailto:mihaix.lindner@linux.intel.com>>
>wrote:
>>On Mon, 2012-12-24 at 14:23 +0200, Mihai Lindner wrote:
>>> On Mon, 2012-12-24 at 15:37 +0800, Biao wrote:
>>> > Hi all,
>>> >
>>> >
>>> > I can not launch hob on my ubun-10.04, it seems saying "no
>>>PyGobject" whereas python-object has already been installed. Can anyone
>>>kindly give a help?
>>> >
>>Oh, forgot to mention here, that you should probably be using Denzil,
>>instead of Danny or 'master'.
>
>Thanks for the kindly reminder.
>>> >
>>> > $ hob
>>> > FATAL: Gtk+, PyGtk and PyGobject are required to use Hob, You have
>>> > Gtk+ 2.20.1 and PyGtk 2.17.0.
>>> >
>>> >
>>> > $ sudo apt-get install python-gobject Reading package lists... Done
>>> > Building dependency tree Reading state information... Done
>>> > python-gobject is already the newest version.
>>> >
>>> Python-gobject seems fine, Gtk seems fine (you have 2.20.1, Hob wants
>>> higher than 2.20.0), which leaves python-gtk2 version 2.17.0 on your
>>> system. Hob wants a version higher than 2.21.0.
>
>Thanks for this information, it seems the prompt message on the
>environment checking is not so clear.  Where are the hob users supposed
>to get such kind of information from?
>
>I did not found this information from the hob manual.
>
>>>
>>> --Mihai
>>> >
>>> > $ uname -a
>>> > Linux zb-d 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC
>>> > 2011 x86_64 GNU/Linux
>>> >
>>> >
>>> > Thanks,
>>> > Biao
>>> > _______________________________________________ yocto mailing list
>>> > yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
>>> > https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>_______________________________________________
>>yocto mailing list
>>yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
>>https://lists.yoctoproject.org/listinfo/yocto
>
>---------------------------------------------------------------------
>Intel Corporation (UK) Limited
>Registered No. 1134945 (England)
>Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
>
>This e-mail and any attachments may contain confidential material for the
>sole use of the intended recipient(s). Any review or distribution by
>others is strictly prohibited. If you are not the intended recipient,
>please contact the sender and delete all copies.
>
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: Fails to launch the hob

[Barros Pena, Belen]

We have updated the Hob Manual to include the required packages and
screenshots of the 1.3 Hob

https://www.yoctoproject.org/documentation/hob-manual

Belen

On 03/01/2013 23:11, "Zhang, Jessica" <jessica.zhang@intel.com> wrote:

>Hi Belen,
>
>I'll modify the error message per suggestion.  By looking at the existing
>code, seems we only check for GTK+ and PyGtk version, so probably I'll
>drop PyGobject in the error message.  So you probably can update the hob
>info on the web-site accordingly.
>
>Thanks,
>Jessica
>
>-----Original Message-----
>From: yocto-bounces@yoctoproject.org
>[mailto:yocto-bounces@yoctoproject.org] On Behalf Of Barros Pena, Belen
>Sent: Thursday, January 03, 2013 8:48 AM
>To: Biao; Mihai Lindner
>Cc: yocto@yoctoproject.org
>Subject: Re: [yocto] Fails to launch the hob
>
>Any chance we could change the content of the error message to provide
>better indication of what the problem is? The idea would be adding
>version numbers and printing only what's causing trouble.
>
>So, from:
>
>$ hob
>FATAL: Gtk+, PyGtk and PyGobject are required to use Hob, You have Gtk+
>2.20.1 and PyGtk 2.17.0.
>
>To something like:
>
>$ hob
>FATAL: Hob requires Gtk+ 2.20.0 or higher, PyGtk 2.21.0 or higher and
>PyGobject [insert minimum version here] or higher You have PyGtk 2.17.0.
>
>Would this be possible?
>
>We should probably also add a paragraph listing essential packages to the
>Hob manual page on the website
>(https://www.yoctoproject.org/documentation/hob-manual). If someone tells
>me what's the minimum version of PyGobject required I could probably edit
>the page myself.
>
>Thanks!
>
>Belen
>
>
>
>From: Biao <huanmateme@163.com<mailto:huanmateme@163.com>>
>Date: Tuesday, 25 December 2012 06:16
>To: Mihai Lindner 
><mihaix.lindner@linux.intel.com<mailto:mihaix.lindner@linux.intel.com>>
>Cc: "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>"
><yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>>
>Subject: Re: [yocto] Fails to launch the hob
>
>
>At 2012-12-24 20:37:26,"Mihai Lindner"
><mihaix.lindner@linux.intel.com<mailto:mihaix.lindner@linux.intel.com>>
>wrote:
>>On Mon, 2012-12-24 at 14:23 +0200, Mihai Lindner wrote:
>>> On Mon, 2012-12-24 at 15:37 +0800, Biao wrote:
>>> > Hi all,
>>> >
>>> >
>>> > I can not launch hob on my ubun-10.04, it seems saying "no
>>>PyGobject" whereas python-object has already been installed. Can anyone
>>>kindly give a help?
>>> >
>>Oh, forgot to mention here, that you should probably be using Denzil,
>>instead of Danny or 'master'.
>
>Thanks for the kindly reminder.
>>> >
>>> > $ hob
>>> > FATAL: Gtk+, PyGtk and PyGobject are required to use Hob, You have
>>> > Gtk+ 2.20.1 and PyGtk 2.17.0.
>>> >
>>> >
>>> > $ sudo apt-get install python-gobject Reading package lists... Done
>>> > Building dependency tree Reading state information... Done
>>> > python-gobject is already the newest version.
>>> >
>>> Python-gobject seems fine, Gtk seems fine (you have 2.20.1, Hob wants
>>> higher than 2.20.0), which leaves python-gtk2 version 2.17.0 on your
>>> system. Hob wants a version higher than 2.21.0.
>
>Thanks for this information, it seems the prompt message on the
>environment checking is not so clear.  Where are the hob users supposed
>to get such kind of information from?
>
>I did not found this information from the hob manual.
>
>>>
>>> --Mihai
>>> >
>>> > $ uname -a
>>> > Linux zb-d 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC
>>> > 2011 x86_64 GNU/Linux
>>> >
>>> >
>>> > Thanks,
>>> > Biao
>>> > _______________________________________________ yocto mailing list
>>> > yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
>>> > https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>_______________________________________________
>>yocto mailing list
>>yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
>>https://lists.yoctoproject.org/listinfo/yocto
>
>---------------------------------------------------------------------
>Intel Corporation (UK) Limited
>Registered No. 1134945 (England)
>Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
>
>This e-mail and any attachments may contain confidential material for the
>sole use of the intended recipient(s). Any review or distribution by
>others is strictly prohibited. If you are not the intended recipient,
>please contact the sender and delete all copies.
>
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Bitbake and task offloading onto multiple cloud-based servers

[Alex J Lennon]

Can anybody advise on whether bitbake currently supports offloading of
build tasks onto multiple systems? Perhaps cloud based?

I'm thinking that it would be more efficient for me if I could bring up
a number of Amazon EC2 servers (or similar) then have bitbake
parallelise the build onto those servers to significantly reduce my
build times?

I see bitbake supports a level of task parallelisation on a single box.

Can parallelisation of build onto multiple systems be achieved?

Is it something that should even be a goal?

Cheers,

Alex

Re: Bitbake and task offloading onto multiple cloud-based servers

[Chris Larson]

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

On Fri, Jan 4, 2013 at 1:56 PM, Alex J Lennon <ajlennon@dynamicdevices.co.uk
> wrote:

> Can anybody advise on whether bitbake currently supports offloading of
> build tasks onto multiple systems? Perhaps cloud based?
>
> I'm thinking that it would be more efficient for me if I could bring up
> a number of Amazon EC2 servers (or similar) then have bitbake
> parallelise the build onto those servers to significantly reduce my
> build times?
>
> I see bitbake supports a level of task parallelisation on a single box.
>
> Can parallelisation of build onto multiple systems be achieved?
>
> Is it something that should even be a goal?
>

It's not supported today. It could be implemented, but nobody has made it a
priority and done so.
-- 
Christopher Larson

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

Re: Bitbake and task offloading onto multiple cloud-based servers

[Alex J Lennon]

On 04/01/2013 21:08, Chris Larson wrote:
> 
> 
> On Fri, Jan 4, 2013 at 1:56 PM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk <mailto:ajlennon@dynamicdevices.co.uk>>
> wrote:
> 
>     Can anybody advise on whether bitbake currently supports offloading of
>     build tasks onto multiple systems? Perhaps cloud based?
> 
>     I'm thinking that it would be more efficient for me if I could bring up
>     a number of Amazon EC2 servers (or similar) then have bitbake
>     parallelise the build onto those servers to significantly reduce my
>     build times?
> 
>     I see bitbake supports a level of task parallelisation on a single box.
> 
>     Can parallelisation of build onto multiple systems be achieved?
> 
>     Is it something that should even be a goal?
> 
> 
> It's not supported today. It could be implemented, but nobody has made
> it a priority and done so.

Do you have any feeling for the level of difficulty of such an
implementation / what would have to change / how invasive it would be to
the codebase ?

I'm wondering if it could be along the lines of creating a "remote task"
class and then, say, having that class ssh into one of a pool of servers
(running a standard image with all tools preinstalled maybe) then
bitbaking the recipes for the particular and waiting on completion
before pulling back the output rpm/deb/ipkg ?

Things are usually more complex than expected when you get into the
nitty gritty though. What would the challenges be do you think?

Where would one start to look in the bitbake code to add this kind of
support in?

Thanks,

Alex


> -- 
> Christopher Larson

Re: Bitbake and task offloading onto multiple cloud-based servers

[Chris Larson]

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

On Fri, Jan 4, 2013 at 2:17 PM, Alex J Lennon <ajlennon@dynamicdevices.co.uk
> wrote:

> Where would one start to look in the bitbake code to add this kind of
> support in?
>

See the subclasses of RunQueueExecute in bb.runqueue, this is what executes
the tasks. For an idea of how to implement opting in to a different class,
see how BB_SCHEDULER is implemented.
-- 
Christopher Larson

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

Re: Bitbake and task offloading onto multiple cloud-based servers

[Tom Zanussi]

On Fri, 2013-01-04 at 21:17 +0000, Alex J Lennon wrote:
> On 04/01/2013 21:08, Chris Larson wrote:
> > 
> > 
> > On Fri, Jan 4, 2013 at 1:56 PM, Alex J Lennon
> > <ajlennon@dynamicdevices.co.uk <mailto:ajlennon@dynamicdevices.co.uk>>
> > wrote:
> > 
> >     Can anybody advise on whether bitbake currently supports offloading of
> >     build tasks onto multiple systems? Perhaps cloud based?
> > 
> >     I'm thinking that it would be more efficient for me if I could bring up
> >     a number of Amazon EC2 servers (or similar) then have bitbake
> >     parallelise the build onto those servers to significantly reduce my
> >     build times?
> > 
> >     I see bitbake supports a level of task parallelisation on a single box.
> > 
> >     Can parallelisation of build onto multiple systems be achieved?
> > 
> >     Is it something that should even be a goal?
> > 
> > 
> > It's not supported today. It could be implemented, but nobody has made
> > it a priority and done so.
> 
> Do you have any feeling for the level of difficulty of such an
> implementation / what would have to change / how invasive it would be to
> the codebase ?
> 
> I'm wondering if it could be along the lines of creating a "remote task"
> class and then, say, having that class ssh into one of a pool of servers
> (running a standard image with all tools preinstalled maybe) then
> bitbaking the recipes for the particular and waiting on completion
> before pulling back the output rpm/deb/ipkg ?
> 
> Things are usually more complex than expected when you get into the
> nitty gritty though. What would the challenges be do you think?
> 
> Where would one start to look in the bitbake code to add this kind of
> support in?
> 

Hi, just catching up on my vacation e-mail and saw this...

In the 1.1 timeframe I proposed something similar for a demo/research
project - I'll just copy the proposal verbatim below in case any of the
ideas could be of any value.  At the time, it was proposed in the
context of creating a demo that would use java in a new
'machine-to-machine' layer, thus the references to 'm2m' and java in the
writeup.

I never got past the proposal phase - not enough time, etc, but I still
think it could make for an interesting research project.

The initial comments that were made that made me think it would be a
bigger job than I'd assumed and kind of made me drop the idea for the
time being were that because of build-time dependencies, an overall
build of a complete image is still pretty linear - if throwing a
40-processor system at a build doesn't really help much it's not likely
to be of much help either to distribute the individual pieces out to the
'cloud'.

The other barrier at the time was that we didn't have any self-hosting
Yocto images that could themselves be used to build Yocto images, but
that's no longer the case.

Probably the first step in making something like this feasible would be
to increase the granularity of parallelization and also decrease the
size of the build-time dependencies.  I have no concrete idea at the
moment on how to actually do that, but in general the more you can break
down the problem into separate pieces that can be built in parallel, the
more opportunity you'd have to move those pieces into the cloud.
Combine that with the other resource considerations you'd need to track
such as network bandwidth, etc, I guess you'd have all the pieces you'd
need and the whole thing becomes a continuously-updating dynamic
optimization problem.

Well, enough handwaving - I do think it's an interesting problem and is
still worth at least investigating - feel free to use or expand on any
of the ideas below, if they're of any value for what you're thinking
of...

----

capybara: Cloud Assembly Protocol for Yocto Build And Runtime Arrays

The basic idea is that you have a 'cloud' of Yocto build machines, each
of course running Yocto, that use a smart but simple protocol to
coordinate the building of a new Yocto image by farming out portions of
the overall build to each machine in the cloud, each according to its
capacity.  In other words, extending the parallel build across machines
and assembling it into a final image somewhere in the cloud.  The whole
process is completely peer-to-peer with no single node in charge - in
that context, a more appropriate name for it might be 'BuildTorrent'.

From the user's perspective, simply turning on a machine running an
'm2m' yocto image immediately, automatically, and seamlessly adds the
horsepower of that machine to the build - there's nothing else to do,
since the protocol automatically discovers the new build machine and
enlists it into the network.  Theoretically, adding enough machines to
the cloud would allow a new image to be built instantaneously (actually,
having a trivially easy-to-use system like this, and a way to monitor
the protocol and dynamically tweak tunables would allow for a lot of
experimentation with the build system parameters and immediate
observation of the results, and could provide some good insights into
the build system dynamics, which in the end just might allow approaching
that goal).

To accomplish this, it should be possible to design and implement a
simple protocol that would basically split the build up into a number of
independent 'work units' e.g. recipes, and match those up with whichever
machines in the cloud have the best currently available capacity for
building a given recipe.  The 'currently available capacity' metric
would change dynamically for any given machine, and would be essentially
a metric or set of metrics culled from dynamically-generated performance
data available on that machine (from e.g. the numerous tracing and
performance tools we have in Yocto).  The machine with the 'best'
currently available capacity for a given recipe would be chosen by
combining the current capacity metric for a given machine with other
factors such as network bandwidth to the image destination, etc. and
matching that up with the 'weight' of the recipe, essentially a
statically defined relative cost value associated with building that
recipe.  When a recipe completes, it sends that info out into the cloud,
which removes it from the list of remaining work (while building, it's
'pending').

Implementation-wise, each peer in the cloud would be running a Yocto
image containing a Java Virtual Machine instance running the 'capybara'
service.  The capybara service would itself be layered on top of some
basic and simple m2m-enabling messaging code.  Presumably, all of this
would be included in the 'meta-m2m' layer and would make it easy to add
as a feature to any Yocto image.

That's the basic idea in a nutshell.  If we combine that (JVM, meta-m2m
layer containing capybara on top of basic m2m messaging), the new Chrome
browser with JVM plugin support, and some minimal hooks into the build
system, I think we might have the basis for a pretty interesting demo
that actually uses Yocto to build Yocto and more importantly should
actually be useful in its own right for analyzing the build system and
speeding up builds for anyone with idle hardware.

Part of the reason I'd like to see this happen too is that I have a
bunch of hardware here that sits idle, and some of it actually pretty
powerful that shouldn't be going unused - it would be great to just kick
off a build and do nothing more than switch on these machines whenever I
wanted to make use of them, without having to actually set anything up
or type a command to do that (which is actually what prevents me from
making use of that hardware as it stands - may be laziness, but really I
don't have time to be bothered with being derailed by small tasks like
that all the time).

I don't think the full-fledged idea can be implemented in the 1.1 demo
timeframe, but I think a sufficiently interesting subset can.  So, I've
broken it into a couple phases, Phase I, which I think can be done in
the 1.1 demo timeframe, and Phase II, the follow-on:

Phase I: simply implement the 'work unit' breakup and the capacity
monitoring side of the protocol, but build on only a single machine
(i.e. only one machine would 'accept' work).  The protocol and m2m stack
would be running on any number of machines, each one actually reporting
capacity metrics into the cloud, and each one also monitoring the
protocol e.g. recipe-pending and -completion messages, and using that
information to display the overall build progress on each machine, in
the Java-enabled Chrome browser running on each machine (or maybe
modifying the demo from last ELC that showed Yocto commits graphically
to show completed recipes by machine or something instead).

We already have all the basic componentry we need, but it would require
some modest amount of Java development work to enable a minimal portion
of the protocol, some minimal hooks into the build system to at least
emit recipe-completion and -pending messages, and some minimal work to
extract and packetize the performance metrics that each machine sends
out (note that the performance data for Phase I would mainly be for demo
purposes and not actually used in the single-machine build (but they
would be real in the sense that they would provide real information over
the real protocol being monitored, and could be relatively simple-minded
at this point).  All of the above should be doable within the 1.1 demo
timeframe.

Phase II:

Everything else.


Well, I'll flesh out Phase II if/when it makes sense.  Just thought I'd
throw the basic idea out there as a possibility - if it doesn't make
sense as a demo, I still think it would be worthwhile as a side project,
so any comments would be welcome regardless...

----

Thanks,

Tom

> Thanks,
> 
> Alex
> 
> 
> > -- 
> > Christopher Larson
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Bitbake and task offloading onto multiple cloud-based servers

[Alex J Lennon]

> In the 1.1 timeframe I proposed something similar for a demo/research
> project - I'll just copy the proposal verbatim below in case any of the
> ideas could be of any value.  

Very interesting Tom. Thanks for your thoughts.


> if throwing a
> 40-processor system at a build doesn't really help much it's not likely
> to be of much help either to distribute the individual pieces out to the
> 'cloud'.

Are there any figures for build time versus increase in processor cores?
It would be interesting to see what the immediate performance gain is
for a build with a low number of additional cores and then where it tops
out?

> The whole
> process is completely peer-to-peer with no single node in charge - in
> that context, a more appropriate name for it might be 'BuildTorrent'.

A "BuildTorrent". I like it!

Cheers,

Alex

Re: Bitbake and task offloading onto multiple cloud-based servers

[Tom Zanussi]

On Wed, 2013-01-09 at 11:58 +0000, Alex J Lennon wrote:
> > In the 1.1 timeframe I proposed something similar for a demo/research
> > project - I'll just copy the proposal verbatim below in case any of the
> > ideas could be of any value.  
> 
> Very interesting Tom. Thanks for your thoughts.
> 
> 
> > if throwing a
> > 40-processor system at a build doesn't really help much it's not likely
> > to be of much help either to distribute the individual pieces out to the
> > 'cloud'.
> 
> Are there any figures for build time versus increase in processor cores?
> It would be interesting to see what the immediate performance gain is
> for a build with a low number of additional cores and then where it tops
> out?

These threads have some hard data:

https://lists.yoctoproject.org/pipermail/poky/2011-July/006802.html
https://lists.yoctoproject.org/pipermail/yocto/2012-April/008293.html

Some of which is summarized here:

https://wiki.yoctoproject.org/wiki/Build_Performance

Other people may have pointers to more data or summaries..

Tom

> 
> > The whole
> > process is completely peer-to-peer with no single node in charge - in
> > that context, a more appropriate name for it might be 'BuildTorrent'.
> 
> A "BuildTorrent". I like it!
> 
> Cheers,
> 
> Alex
> 

Re: Bitbake and task offloading onto multiple cloud-based servers

[Mark Hatle]

On 1/4/13 2:56 PM, Alex J Lennon wrote:
>
> Can anybody advise on whether bitbake currently supports offloading of
> build tasks onto multiple systems? Perhaps cloud based?

I see Chris Larson has already answer the main question here.. but I've got some 
additional insight I can add.

> I'm thinking that it would be more efficient for me if I could bring up
> a number of Amazon EC2 servers (or similar) then have bitbake
> parallelise the build onto those servers to significantly reduce my
> build times?

In the past I've had people ask me questions about remote builds, parallel 
building packages, etc.  In the past when I've attempted to figure out if it 
would be useful, the cost of the data transfer time always comes into play.  How 
long does it take to simply perform the task locally vs go to the remote 
machine, perform the task, and get the data back.  For a lot of the tasks that 
OE does, the remote tasks will end up being slower on a reasonably modern i7 (or 
similar Xeon) machine.  I'm not sure using something like a cloud server would 
end up helping due to this.

 From experience I'd say that if anything you'd likely want to modify the 
bitbake scheduler with some type of locality information.  I.e. if you extract 
the sources on a node, you most likely want to patch, configure, compile, 
install, QA and package on that node as well.... but that also means a way to 
establish node specific tmp/work space is needed for performance as well.

> I see bitbake supports a level of task parallelisation on a single box.
>
> Can parallelisation of build onto multiple systems be achieved?

All of the above are possible, but I suspect there is a lot of design and 
refactoring required to come up with a system that is both efficient and fast.

> Is it something that should even be a goal?

It's not currently a goal.  But it does get asked about every now and then.  It 
would be nice to have something more then anecdotal information about if it 
would be a good idea or not.  This is the type of thing that I think would make 
an excellent research project.  (Hey and if it makes things able to be built for 
more people, faster, and cheaper great!  If not, we'd have a more informed 
response to questions like this.)

--Mark

> Cheers,
>
> Alex
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: Bitbake and task offloading onto multiple cloud-based servers

[Alex J Lennon]

On 04/01/2013 22:43, Mark Hatle wrote:
> On 1/4/13 2:56 PM, Alex J Lennon wrote:
>>
>> Can anybody advise on whether bitbake currently supports offloading of
>> build tasks onto multiple systems? Perhaps cloud based?
> 
> I see Chris Larson has already answer the main question here.. but I've got some 
> additional insight I can add.
> 
>> I'm thinking that it would be more efficient for me if I could bring up
>> a number of Amazon EC2 servers (or similar) then have bitbake
>> parallelise the build onto those servers to significantly reduce my
>> build times?
> 
> In the past I've had people ask me questions about remote builds, parallel 
> building packages, etc.  In the past when I've attempted to figure out if it 
> would be useful, the cost of the data transfer time always comes into play.  How 
> long does it take to simply perform the task locally vs go to the remote 
> machine, perform the task, and get the data back.  For a lot of the tasks that 
> OE does, the remote tasks will end up being slower on a reasonably modern i7 (or 
> similar Xeon) machine.  I'm not sure using something like a cloud server would 
> end up helping due to this.
> 

Thanks for your thoughts Mark.

Another idea that occurred was that it might be interesting if there
were some metrics available somewhere on recipe build times (are timing
metrics currently generated in any detail?).

Using that as a starting point it might then be possible to determine
how best to parallelise tasks?

>  From experience I'd say that if anything you'd likely want to modify the 
> bitbake scheduler with some type of locality information.  I.e. if you extract 
> the sources on a node, you most likely want to patch, configure, compile, 
> install, QA and package on that node as well.... but that also means a way to 
> establish node specific tmp/work space is needed for performance as well.
> 
>> I see bitbake supports a level of task parallelisation on a single box.
>>
>> Can parallelisation of build onto multiple systems be achieved?
> 
> All of the above are possible, but I suspect there is a lot of design and 
> refactoring required to come up with a system that is both efficient and fast.
> 
>> Is it something that should even be a goal?
> 
> It's not currently a goal.  But it does get asked about every now and then.  It 
> would be nice to have something more then anecdotal information about if it 
> would be a good idea or not.  This is the type of thing that I think would make 
> an excellent research project.  (Hey and if it makes things able to be built for 
> more people, faster, and cheaper great!  If not, we'd have a more informed 
> response to questions like this.)
> 
> --Mark
> 
>> Cheers,
>>
>> Alex
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 

Re: Bitbake and task offloading onto multiple cloud-based servers

[Flanagan, Elizabeth]

On Fri, Jan 4, 2013 at 2:47 PM, Alex J Lennon
<ajlennon@dynamicdevices.co.uk> wrote:
> On 04/01/2013 22:43, Mark Hatle wrote:
>> On 1/4/13 2:56 PM, Alex J Lennon wrote:
>>>
>>> Can anybody advise on whether bitbake currently supports offloading of
>>> build tasks onto multiple systems? Perhaps cloud based?
>>
>> I see Chris Larson has already answer the main question here.. but I've got some
>> additional insight I can add.
>>
>>> I'm thinking that it would be more efficient for me if I could bring up
>>> a number of Amazon EC2 servers (or similar) then have bitbake
>>> parallelise the build onto those servers to significantly reduce my
>>> build times?
>>
>> In the past I've had people ask me questions about remote builds, parallel
>> building packages, etc.  In the past when I've attempted to figure out if it
>> would be useful, the cost of the data transfer time always comes into play.  How
>> long does it take to simply perform the task locally vs go to the remote
>> machine, perform the task, and get the data back.  For a lot of the tasks that
>> OE does, the remote tasks will end up being slower on a reasonably modern i7 (or
>> similar Xeon) machine.  I'm not sure using something like a cloud server would
>> end up helping due to this.
>>
>
> Thanks for your thoughts Mark.
>
> Another idea that occurred was that it might be interesting if there
> were some metrics available somewhere on recipe build times (are timing
> metrics currently generated in any detail?).

Yes, they're generated by buildstats.bbclass and should be available
within TMPDIR/buildstats. You can also use scripts/pybootchartgui.py
to get a visual representation of the timeline of a build.

-b

>
> Using that as a starting point it might then be possible to determine
> how best to parallelise tasks?
>
>>  From experience I'd say that if anything you'd likely want to modify the
>> bitbake scheduler with some type of locality information.  I.e. if you extract
>> the sources on a node, you most likely want to patch, configure, compile,
>> install, QA and package on that node as well.... but that also means a way to
>> establish node specific tmp/work space is needed for performance as well.
>>
>>> I see bitbake supports a level of task parallelisation on a single box.
>>>
>>> Can parallelisation of build onto multiple systems be achieved?
>>
>> All of the above are possible, but I suspect there is a lot of design and
>> refactoring required to come up with a system that is both efficient and fast.
>>
>>> Is it something that should even be a goal?
>>
>> It's not currently a goal.  But it does get asked about every now and then.  It
>> would be nice to have something more then anecdotal information about if it
>> would be a good idea or not.  This is the type of thing that I think would make
>> an excellent research project.  (Hey and if it makes things able to be built for
>> more people, faster, and cheaper great!  If not, we'd have a more informed
>> response to questions like this.)
>>
>> --Mark
>>
>>> Cheers,
>>>
>>> Alex
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
Elizabeth Flanagan
Yocto Project
Build and Release