Date   

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

Chris Larson <clarson@...>
 



On Fri, Jan 4, 2013 at 1:56 PM, Alex J Lennon <ajlennon@...> 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


Bitbake and task offloading onto multiple cloud-based servers

Alex J Lennon <ajlennon@...>
 

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: Raspberry Pi do_fetch failure

Alex J Lennon <ajlennon@...>
 

On 01/01/2013 17:34, ed nelson wrote:
I am getting a do_fetch failure on raspberrypi kernel. Is anyone else
having this problem?

Build Configuration:
BB_VERSION = "1.16.0"
TARGET_ARCH = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE = "raspberrypi"
DISTRO = "poky"
DISTRO_VERSION = "1.3"
TUNE_FEATURES = "armv6 vfp"
TARGET_FPU = "vfp"
meta
meta-yocto
meta-yocto-bsp = "danny:bf909b267498dbab4d7695c26b0dce903ac8b6b0"
meta-raspberrypi = "master:305c5259e24eaa9fb285ca983dc4f9454743fa0c"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: Failed to fetch URL
git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27,
attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command failed with exit code 128, output:
Cloning into bare repository
'/home/ed/oe/poky-danny/rasperryPiBuild/downloads/git2/github.com.raspberrypi.linux.git'...

fatal: read error: Connection reset by peer
fatal: early EOF
fatal: index-pack failed

ERROR: Function failed: Fetcher failure for URL:
'git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27'.
Unable to fetch URL from any source.

Thanks
I'm rebuilding an RPi image from scratch here now for some testing and I
see the same issue, which looks to be a GitHub hiccup.

I do have a cached download of the RPi linux GitHub repository from a
previous build, which you're welcome to use if it'll help you move
forward whilst GitHub has this issue.

I've tarred it up as github.com.raspberrypi.linux.git.tgz. You can
extract this into the Yocto downloads directory and I believe it'll be
picked up by the build tool, e.g.

cd /path/to/yoctoProject/raspberryPiBuild/downloads
tar xzf /path/to/github.com.raspberrypi.linux.git.tgz

You should see it go into a "git2" folder in downloads.

It's currently uploading to a DropBox public link at

https://dl.dropbox.com/u/12130167/rpi/github.com.raspberrypi.linux.git.tgz

(It's around 620MB so it'll be about an hour before it's up. I'll
probably leave it up there over the weekend but it may disappear next week!)

Cheers,

Alex




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


Re: cairo failed on openSUSE

Martin Jansa
 

On Thu, Jan 03, 2013 at 01:48:15PM +0100, Ronan Le Martret wrote:
- add libpng version 15 to configure.ac of cairo. (libpng12 confict.)
Please follow:
http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

And this belongs to oe-core ML.

Cheers,

--
Martin 'JaMa' Jansa jabber: Martin.Jansa@...


Re: Fails to launch the hob

Barros Pena, Belen <belen.barros.pena@...>
 

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@...> 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@...
[mailto:yocto-bounces@...] On Behalf Of Barros Pena, Belen
Sent: Thursday, January 03, 2013 8:48 AM
To: Biao; Mihai Lindner
Cc: yocto@...
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@...<mailto:huanmateme@...>>
Date: Tuesday, 25 December 2012 06:16
To: Mihai Lindner
<mihaix.lindner@...<mailto:mihaix.lindner@...>>
Cc: "yocto@...<mailto:yocto@...>"
<yocto@...<mailto:yocto@...>>
Subject: Re: [yocto] Fails to launch the hob


At 2012-12-24 20:37:26,"Mihai Lindner"
<mihaix.lindner@...<mailto:mihaix.lindner@...>>
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@...<mailto:yocto@...>
https://lists.yoctoproject.org/listinfo/yocto

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

_______________________________________________
yocto mailing list
yocto@...<mailto:yocto@...>
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@...
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: [PATCH] latencytop: add sudo as runtime dependency

Maxin B. John <Maxin.John@...>
 

Hi Richard,
On Fri, Jan 04, 2013 at 02:27:42PM +0000, Richard Purdie wrote:
On Fri, 2013-01-04 at 12:30 +0100, Maxin B. John wrote:
From: "Maxin B. John" <maxin.john@...>

Latencytop needs superuser privileges. The latencytop plugin in
eclipse invokes it as 'sudo latencytop'. So, it will be good to
include sudo as a runtime dependency.

Signed-off-by: Maxin B. John <maxin.john@...>
---
meta/recipes-kernel/latencytop/latencytop_0.5.bb | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/meta/recipes-kernel/latencytop/latencytop_0.5.bb b/meta/recipes-kernel/latencytop/latencytop_0.5.bb
index 3e35bf9..a148a47 100644
--- a/meta/recipes-kernel/latencytop/latencytop_0.5.bb
+++ b/meta/recipes-kernel/latencytop/latencytop_0.5.bb
@@ -7,6 +7,9 @@ LIC_FILES_CHKSUM = "file://latencytop.c;endline=23;md5=ee9ea9b1415356e5734adad4a

DEPENDS = "virtual/libintl ncurses glib-2.0 ${@base_contains('DISTRO_FEATURES', 'x11', 'gtk+', '', d)}"

+# latencytop and it's eclipse support need sudo
+RDEPENDS_${PN} = "sudo"
+
PR = "r3"
Shouldn't the eclipse support RDEPEND on sudo, not latencytop? There are
several ways you could run latencytop without sudo...
I agree. We can run latencytop without sudo. However, it is possible
to install the Eclipse Yocto Plug-in from the downloads.yoctoproject.org.
So, it may not be necessary to build the Eclipse Yocto Plug-in
support in-order to use it.

In that case, when we use the latencytop plugin from Eclipse by
connecting to a target board running linux, it will fail with the
following output:
# sudo : command not found

It is because of this line in 'LatencytopHandler.java':
private static String initCmd="export
PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin; cd; sudo latencytop\r";

This line 'assumes' that every target board with latencytop also have
sudo. Please correct me if I am wrong.

Following this logic, we'd add an RDEPENDS on sudo for every app that
could possibly need root privs.
I didn't mean that :)
This is a special case for latencytop. Please let me know your comments.

Cheers,

Richard
Best Regards,
Maxin


Re: [PATCH] latencytop: add sudo as runtime dependency

Richard Purdie
 

On Fri, 2013-01-04 at 12:30 +0100, Maxin B. John wrote:
From: "Maxin B. John" <maxin.john@...>

Latencytop needs superuser privileges. The latencytop plugin in
eclipse invokes it as 'sudo latencytop'. So, it will be good to
include sudo as a runtime dependency.

Signed-off-by: Maxin B. John <maxin.john@...>
---
meta/recipes-kernel/latencytop/latencytop_0.5.bb | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/meta/recipes-kernel/latencytop/latencytop_0.5.bb b/meta/recipes-kernel/latencytop/latencytop_0.5.bb
index 3e35bf9..a148a47 100644
--- a/meta/recipes-kernel/latencytop/latencytop_0.5.bb
+++ b/meta/recipes-kernel/latencytop/latencytop_0.5.bb
@@ -7,6 +7,9 @@ LIC_FILES_CHKSUM = "file://latencytop.c;endline=23;md5=ee9ea9b1415356e5734adad4a

DEPENDS = "virtual/libintl ncurses glib-2.0 ${@base_contains('DISTRO_FEATURES', 'x11', 'gtk+', '', d)}"

+# latencytop and it's eclipse support need sudo
+RDEPENDS_${PN} = "sudo"
+
PR = "r3"
Shouldn't the eclipse support RDEPEND on sudo, not latencytop? There are
several ways you could run latencytop without sudo...

Following this logic, we'd add an RDEPENDS on sudo for every app that
could possibly need root privs.

Cheers,

Richard


[meta-ivi][PATCH 4/4] node-startup-controller: Use public repository

Andrei Gherzan
 

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
.../node-startup-controller_1.0.1.bb | 4 ++--
.../node-startup-controller_git.bb | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/recipes-extended/node-startup-controller/node-startup-controller_1.0.1.bb b/recipes-extended/node-startup-controller/node-startup-controller_1.0.1.bb
index 814760e..396c7ce 100644
--- a/recipes-extended/node-startup-controller/node-startup-controller_1.0.1.bb
+++ b/recipes-extended/node-startup-controller/node-startup-controller_1.0.1.bb
@@ -13,9 +13,9 @@ LICENSE = "MPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=815ca599c9df247a0c7f619bab123dad"

# tag 1.0.1 : f109eab4393fcb55ecbb0a21d68436a5057a6b82
-SRC_URI = "git://git.genivi.org/srv/git/${PN};protocol=git;tag=f109eab4393fcb55ecbb0a21d68436a5057a6b82 \
+SRC_URI = "git://git.projects.genivi.org/lifecycle/node-startup-controller.git;protocol=git;tag=f109eab4393fcb55ecbb0a21d68436a5057a6b82 \
file://use-systemd-unit-dir.patch"
-PR = "r1"
+PR = "r2"

DEPENDS = "glib-2.0 dlt-daemon systemd"

diff --git a/recipes-extended/node-startup-controller/node-startup-controller_git.bb b/recipes-extended/node-startup-controller/node-startup-controller_git.bb
index 9c02572..0d3b90c 100644
--- a/recipes-extended/node-startup-controller/node-startup-controller_git.bb
+++ b/recipes-extended/node-startup-controller/node-startup-controller_git.bb
@@ -14,11 +14,11 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=815ca599c9df247a0c7f619bab123dad"

SRCREV = "958e5ab2bc93ac0d885ca75f4f33988cbdd3e758"
PV = "1.0.0+git${SRCPV}"
-PR = "r1"
+PR = "r2"

DEFAULT_PREFERENCE = "-1"

-SRC_URI = "git://git.genivi.org/srv/git/${PN};protocol=git"
+SRC_URI = "git://git.projects.genivi.org/lifecycle/node-startup-controller.git;protocol=git"

DEPENDS = "glib-2.0 dlt-daemon systemd"

--
1.7.9.5


[meta-ivi][PATCH 3/4] xserver-xorg: Sync version with oe-core

Andrei Gherzan
 

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
....13.0.bbappend => xserver-xorg_1.13.1.bbappend} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename recipes-graphics/xorg-xserver/{xserver-xorg_1.13.0.bbappend => xserver-xorg_1.13.1.bbappend} (100%)

diff --git a/recipes-graphics/xorg-xserver/xserver-xorg_1.13.0.bbappend b/recipes-graphics/xorg-xserver/xserver-xorg_1.13.1.bbappend
similarity index 100%
rename from recipes-graphics/xorg-xserver/xserver-xorg_1.13.0.bbappend
rename to recipes-graphics/xorg-xserver/xserver-xorg_1.13.1.bbappend
--
1.7.9.5


[meta-ivi][PATCH 2/4] ofono: Sync version with oe-core

Andrei Gherzan
 

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
.../{ofono_1.10.bbappend => ofono_1.12.bbappend} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename recipes-connectivity/ofono/{ofono_1.10.bbappend => ofono_1.12.bbappend} (100%)

diff --git a/recipes-connectivity/ofono/ofono_1.10.bbappend b/recipes-connectivity/ofono/ofono_1.12.bbappend
similarity index 100%
rename from recipes-connectivity/ofono/ofono_1.10.bbappend
rename to recipes-connectivity/ofono/ofono_1.12.bbappend
--
1.7.9.5


[meta-ivi][PATCH 1/4] MAINTAINERS: Add info about patch subject

Andrei Gherzan
 

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4149537..373bdd1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2,6 +2,7 @@ This file contains a list of maintainers for the meta-ivi layer.

Please submit any patches against meta-ivi to the maintainers
(cc:ing the Yocto Project mailing list (yocto@...))
+with '[meta-ivi]' in subject

You may also contact the maintainers directly in case you have any questions
on a particular meta-ivi topic, but please try to do the following first:
--
1.7.9.5


Re: Where does the 'PN' is set.

Burton, Ross <ross.burton@...>
 

On 4 January 2013 11:34, Bill Traynor <wmat@...> wrote:
I would like to know where does the so-called 'gather' exactly happens?
For example, does it mean the bitbake core get the 'PN = u-boot' by
cutting of the name of 'u-boot_2011.03.bb'?
If you want to know exactly where it happens, see bitbake.conf:

PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[0] or
'defaultpkgname'}"
PV = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[1] or '1.0'}"
PR = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[2] or 'r0'}"

Ross


Re: Where does the 'PN' is set.

Bill Traynor <wmat@...>
 

On Fri, Jan 4, 2013 at 1:53 AM, Biao <huanmateme@...> wrote:
Hi,

In meta/conf/documentation.conf
PN[doc] = "PN holds the name of the package (Package Name). It is gathered from the bitbake-file filename"

I would like to know where does the so-called 'gather' exactly happens?
For example, does it mean the bitbake core get the 'PN = u-boot' by cutting of the name of 'u-boot_2011.03.bb'?

Yes, within the context of the build process, PN refers to the Package Name that is extracted from the recipe file name.  So your example is correct.

For reference, see the PN variable description in the Yocto Project Reference manual:  http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#var-P

The "gathering" occurs during the Bitbake parsing step.  Roughly, parsing occurs in the following order:  configuration files, classes, bbfiles.

 

Thanks,
Biao 

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



[meta-ivi][PATCH] layer.conf: Use .= for adding to BBPATH and += to BBFILES

Andrei Gherzan
 

Fixes parsing errors which is appearing after this commit to
meta-openembedded

http://cgit.openembedded.org/meta-openembedded/commit/?id=3c21a46020bd0816579648f684c41dbd6333583e

This triggers
exception NameError: name 'base_contains' is not defined
without this change

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
conf/layer.conf | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 1a90791..346cc0e 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -1,9 +1,10 @@
BBPATH ?= ""
# We add conf directory to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"

# We have a recipes directory containing .bb and .bbappend files, add to BBFILES
-BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
+ ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "ivi"
BBFILE_PATTERN_ivi := "^${LAYERDIR}/"
--
1.7.9.5


Re: Raspberry Pi do_fetch failure

Andrei Gherzan
 

Please submit a bug / contact github with the problem you found. And if you are so kind, please keep me posted.





Andrei Gherzan

mobile +40.744.478.414  fax +40.31.816.28.12
Email: andrei@...
Email: andrei.gherzan@...
Romania


On Thu, Jan 3, 2013 at 4:49 PM, ed nelson <enelson1000@...> wrote:
On 01/02/2013 01:52 AM, Andrei Gherzan wrote:
On Wed, Jan 2, 2013 at 6:12 AM, ed nelson <enelson1000@...> wrote:
On 01/01/2013 06:50 PM, Andrei Gherzan wrote:
On Tue, Jan 1, 2013 at 7:34 PM, ed nelson <enelson1000@...> wrote:
I am getting a do_fetch failure on raspberrypi kernel.  Is anyone else having this problem?

Build Configuration:
BB_VERSION        = "1.16.0"
TARGET_ARCH       = "arm"
TARGET_OS         = "linux-gnueabi"
MACHINE           = "raspberrypi"
DISTRO            = "poky"
DISTRO_VERSION    = "1.3"
TUNE_FEATURES     = "armv6 vfp"
TARGET_FPU        = "vfp"
meta
meta-yocto
meta-yocto-bsp    = "danny:bf909b267498dbab4d7695c26b0dce903ac8b6b0"
meta-raspberrypi  = "master:305c5259e24eaa9fb285ca983dc4f9454743fa0c"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: Failed to fetch URL git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27, attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command failed with exit code 128, output:
Cloning into bare repository '/home/ed/oe/poky-danny/rasperryPiBuild/downloads/git2/github.com.raspberrypi.linux.git'...

fatal: read error: Connection reset by peer
fatal: early EOF
fatal: index-pack failed

ERROR: Function failed: Fetcher failure for URL: 'git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27'. Unable to fetch URL from any source.

 
So this error hits again. 

It's something related  to github. I've seen this on other repos and solved it with a ticket to github - strangely I can't reproduce your issue now on my host. As i recall the clone would fail if "--quiet" was used. Can you confirm? Are you able to clone that repo manually? WIth "--quiet" too?

Andrei

When I manually try:
$ git clone --quiet git://github.com/raspberrypi/linux.git
The process hangs
 
Wait a while and check if this fails after a while. 

Andrei

It failed the same as the build.

ed@ed-Aspire-5560:~/temp$ git clone --quiet git://github.com/raspberrypi/linux.git

fatal: read error: Connection reset by peer
fatal: early EOF
fatal: index-pack failed

Any suggestions?

Thanks









Re: Fails to launch the hob

Barros Pena, Belen <belen.barros.pena@...>
 

Thanks, Jessica! I'll update the webpage.

Belen

On 03/01/2013 23:11, "Zhang, Jessica" <jessica.zhang@...> 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@...
[mailto:yocto-bounces@...] On Behalf Of Barros Pena, Belen
Sent: Thursday, January 03, 2013 8:48 AM
To: Biao; Mihai Lindner
Cc: yocto@...
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@...<mailto:huanmateme@...>>
Date: Tuesday, 25 December 2012 06:16
To: Mihai Lindner
<mihaix.lindner@...<mailto:mihaix.lindner@...>>
Cc: "yocto@...<mailto:yocto@...>"
<yocto@...<mailto:yocto@...>>
Subject: Re: [yocto] Fails to launch the hob


At 2012-12-24 20:37:26,"Mihai Lindner"
<mihaix.lindner@...<mailto:mihaix.lindner@...>>
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@...<mailto:yocto@...>
https://lists.yoctoproject.org/listinfo/yocto

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

_______________________________________________
yocto mailing list
yocto@...<mailto:yocto@...>
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@...
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.


[meta-mono][PATCH] layer.conf: Use .= for adding to BBPATH and += to BBFILES

Khem Raj
 

Fixes parsing errors which is appearing after this commit to
meta-openembedded

http://cgit.openembedded.org/meta-openembedded/commit/?id=3c21a46020bd0816579648f

This triggers
exception NameError: name 'base_contains' is not defined
without this change

Signed-off-by: Khem Raj <raj.khem@...>
---
conf/layer.conf | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 6bcf70e..d8cc797 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -1,8 +1,8 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-mono/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-mono/*/*.bb \
${LAYERDIR}/recipes-mono/*/*.bbappend"

BBFILE_COLLECTIONS += "mono"
--
1.7.9.5


Where does the 'PN' is set.

Biao <huanmateme@...>
 

Hi,

In meta/conf/documentation.conf
PN[doc] = "PN holds the name of the package (Package Name). It is gathered from the bitbake-file filename"

I would like to know where does the so-called 'gather' exactly happens?
For example, does it mean the bitbake core get the 'PN = u-boot' by cutting of the name of 'u-boot_2011.03.bb'?

Thanks,
Biao 


[meta-intel][PATCH] layer.conf: Use .= for adding to BBPATH and += to BBFILES

Khem Raj
 

Fixes parsing errors which is appearing after this commit to
meta-openembedded

http://cgit.openembedded.org/meta-openembedded/commit/?id=3c21a46020bd0816579648f684c41dbd6333583e

This triggers
exception NameError: name 'base_contains' is not defined
without this change

Signed-off-by: Khem Raj <raj.khem@...>
---
conf/layer.conf | 4 ++--
meta-cedartrail/conf/layer.conf | 4 ++--
meta-chiefriver/conf/layer.conf | 4 ++--
meta-crownbay/conf/layer.conf | 4 ++--
meta-crystalforest/conf/layer.conf | 4 ++--
meta-emenlow/conf/layer.conf | 4 ++--
meta-fri2/conf/layer.conf | 4 ++--
meta-jasperforest/conf/layer.conf | 4 ++--
meta-n450/conf/layer.conf | 4 ++--
meta-nuc/conf/layer.conf | 4 ++--
meta-romley/conf/layer.conf | 4 ++--
meta-sugarbay/conf/layer.conf | 4 ++--
meta-sys940x/conf/layer.conf | 4 ++--
meta-tlk/conf/layer.conf | 4 ++--
14 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index e9c2b10..31132ab 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -1,8 +1,8 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"

# We have recipes-* directories, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/common/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/common/recipes-*/*/*.bb \
${LAYERDIR}/common/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "intel"
diff --git a/meta-cedartrail/conf/layer.conf b/meta-cedartrail/conf/layer.conf
index c19c4c1..0166b35 100644
--- a/meta-cedartrail/conf/layer.conf
+++ b/meta-cedartrail/conf/layer.conf
@@ -1,8 +1,8 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "cedartrail"
diff --git a/meta-chiefriver/conf/layer.conf b/meta-chiefriver/conf/layer.conf
index 5dc3c02..6164f99 100644
--- a/meta-chiefriver/conf/layer.conf
+++ b/meta-chiefriver/conf/layer.conf
@@ -1,8 +1,8 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "chiefriver"
diff --git a/meta-crownbay/conf/layer.conf b/meta-crownbay/conf/layer.conf
index cb17298..e6cc2a0 100644
--- a/meta-crownbay/conf/layer.conf
+++ b/meta-crownbay/conf/layer.conf
@@ -1,8 +1,8 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "crownbay"
diff --git a/meta-crystalforest/conf/layer.conf b/meta-crystalforest/conf/layer.conf
index 6b802d6..daa2ba7 100644
--- a/meta-crystalforest/conf/layer.conf
+++ b/meta-crystalforest/conf/layer.conf
@@ -1,8 +1,8 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "crystalforest"
diff --git a/meta-emenlow/conf/layer.conf b/meta-emenlow/conf/layer.conf
index a49ec47..b5832e4 100644
--- a/meta-emenlow/conf/layer.conf
+++ b/meta-emenlow/conf/layer.conf
@@ -1,8 +1,8 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"

# We have recipes-* directories, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "emenlow"
diff --git a/meta-fri2/conf/layer.conf b/meta-fri2/conf/layer.conf
index 4d140f9..0bb29a1 100644
--- a/meta-fri2/conf/layer.conf
+++ b/meta-fri2/conf/layer.conf
@@ -1,8 +1,8 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "fri2"
diff --git a/meta-jasperforest/conf/layer.conf b/meta-jasperforest/conf/layer.conf
index 09f1647..b539733 100644
--- a/meta-jasperforest/conf/layer.conf
+++ b/meta-jasperforest/conf/layer.conf
@@ -1,8 +1,8 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES .= "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "jasperforest"
diff --git a/meta-n450/conf/layer.conf b/meta-n450/conf/layer.conf
index 4481121..ee53e54 100644
--- a/meta-n450/conf/layer.conf
+++ b/meta-n450/conf/layer.conf
@@ -1,8 +1,8 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"

# We have recipes-* directories, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "n450"
diff --git a/meta-nuc/conf/layer.conf b/meta-nuc/conf/layer.conf
index fb5b58a..174411f 100644
--- a/meta-nuc/conf/layer.conf
+++ b/meta-nuc/conf/layer.conf
@@ -1,8 +1,8 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "nuc"
diff --git a/meta-romley/conf/layer.conf b/meta-romley/conf/layer.conf
index 8ce1a4d..7b6a5bc 100644
--- a/meta-romley/conf/layer.conf
+++ b/meta-romley/conf/layer.conf
@@ -1,8 +1,8 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "romley"
diff --git a/meta-sugarbay/conf/layer.conf b/meta-sugarbay/conf/layer.conf
index eb8ec45..9576330 100644
--- a/meta-sugarbay/conf/layer.conf
+++ b/meta-sugarbay/conf/layer.conf
@@ -1,8 +1,8 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "sugarbay"
diff --git a/meta-sys940x/conf/layer.conf b/meta-sys940x/conf/layer.conf
index 5d588ad..b14be6d 100644
--- a/meta-sys940x/conf/layer.conf
+++ b/meta-sys940x/conf/layer.conf
@@ -1,8 +1,8 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "sys940x"
diff --git a/meta-tlk/conf/layer.conf b/meta-tlk/conf/layer.conf
index fc0da61..38b0e0c 100644
--- a/meta-tlk/conf/layer.conf
+++ b/meta-tlk/conf/layer.conf
@@ -1,6 +1,6 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"

# We have recipes-* directories, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
--
1.7.9.5


Re: configuration management on remote target

Mark Hatle <mark.hatle@...>
 

On 1/3/13 5:43 PM, Ilya Dmitrichenko wrote:
Hi,

As my day job mostly involves configuring servers using puppet configuration
management system, I had been thinking of what sort of tool would be best to use
on an embedded devices where on some occasions one would want to update a couple
of config files and scripts. Perhaps this can be limited just to the `/etc`
direcotry...

So the best I could come up with so far is to implement it as cron job that
would pull a git repository, perhaps it would also run a script (git hook) that
would restart a daemon or do something of that kind.

I suppose that some people will suggest to just use packages, but I'm not very
keen on maintaining a package repository on some sever out in the internet that
would be one big single point of failure. Although, perhaps, on some occasion,
this may be the only way.
Another reason why I wouldn't like to use git to manage configuration, as that
way all configs are going to be at hand from one directory tree, which is, IMO,
much quicker to manage and validate rather then a recipes spread across
subdirectories.
There are different systems out there that need to be managed (as well as different philosophies of how to manage them.) Solving all of the problems isn't going to work. Solving a specific problem has a chance. :)

It's fairly typical that a device can be maintained as files, packages, or filesystem images. Each of those approaches requires a very different upgrade/maintenance mechanism. In addition since embedded systems do not have an admin console, if they fail during the upgrade process you can brick a user, so a fail safe is almost always required!

In each of the above methods, you can do things like transfer an individual file (or files) and related reset commands after an upgrade has occurred.. send up a package (or packages) and automate that -- or even upgrade the filesystem, but in each of these cases bandwidth may be at a premium. Most field upgrade systems want a "delta" (diff) based system, where only the changes have to be sent, not the whole file.

Firstly, I'd appreciate any feedback on this!

And I do have a few rather more specific questions ;)
a) How often OE users do not implement any system updates over the wire in their
products, although the product is able to access the internet?
Due to the complexity of upgrading, this is fairly typical on embedded systems in my experience...but it's being tolerated less and less over time. (They usually have some kind of an upgrade mechanism, they just don't do it over the internet.)

b) Has anyone here use the configuration tools like puppet, chef or cfendgine
and understands the benefits?

c) Has anyone succeeded building git without having to include perl on the
target? I'd probably get ways with just a subset of git commands.
I have also had a look at libgit2, but not sure if I'd be able to implement
something as robust as git itself with libgit2...
Last time I looked (a few months back) it was not possible to build a functional git system w/o perl -- or at least I wasn't able to. I hope this continues to get better, as perl is -very- heavy weight for an embedded system.


So if you want the ultimate works for everyone system.. it really needs to be a field upgrade tool of some kind. Basically providing the infrastructure to push/pull the update, a way to use a delta of the update to what is already installed on the device to construct the "file" to save bandwidth, a way to apply the update and control the associated behavior. Then people can use that to implement file, package or image based upgrades... fail safe behavior is also usually device specific and would be implemented based on the toolkit.


Cheers,
--
Ilya



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