On 12/14/12 3:57 PM, Brian Hutchinson wrote:

On Fri, Dec 14, 2012 at 4:09 PM, Zhang, Jessica <jessica.zhang@...> wrote:

Actually I talked with Richard regarding retiring the toolchain targets (meta-toolchain and meta-toolchain-gmae) as Mark mentioned that now we can build a toolchain matching the >image. Also, we're continue improving adt-installer which also allows you to setup sysroot using the target image as well. Richard's concern is there maybe some legacy user that >preferred the toolchain target. With the latest changes in toolchain generation which really maps to target images, probably we should unplug to legacy ones to make the toolchain generation more streamline. Thoughts or concerns?

I'm one of the users that is stuck using Edison 6.0. I'm desperate
for the ability to generate a toolchain and sysroot that matches our
target. Right now I have to build meta-toolchain and then manually
look in the tmp for sysroot-destdir related stuff from our build and
copy it to the sysroot in /opt/poky and hand that out to developers.
When our sister group overseas makes a change that effects the sysroot
it breaks our build and I have to figure out what happened and
manually adjust our sysroot to fix the problem. I sure would like to
be able to just do an update and then bitbake the toolchain to pick up
the changes. I figure we are stuck with Edison for a while ... can I
back port these toolchain features you all are talking about to
Edison?

There are changes to both bitbake and oe-core required. You'll have to look back at the oe-core mailing list to find the right set to backport.

We have backported the items to our 1.2 (7.0 Denzil) based system, but I'm not aware of anyone who is using it in 1.1 (6.0 Edison).

--Mark

Regards,

Brian

On 12/14/12 4:12 PM, Tim Bird wrote:

On 12/14/2012 12:45 PM, Mark Hatle wrote:

On 12/14/12 1:46 PM, Burton, Ross wrote:

On 14 December 2012 19:43, Tim Bird <tim.bird@...> wrote:

"If you need GMAE, you should use the bitbake meta-toolchain-gmae command. The resulting installation script when run will support such development. However, if you are not concerned with GMAE, you
can generate the toolchain installer using bitbake meta-toolchain."

After googling a bit, I figured out that GMAE stands for Gnome Mobile and Embedded.

It might be good to put this acronym somewhere in the manual.
(I'm still not sure if I need GMAE or not...)

Basically, GMAE means GTK+ 2 and bits of the GNOME stack.

A stealth plan of mine is to remove every trace of GMAE from Yocto.
It was an initiative Poky was involved with back in the OpenedHand
days that didn't really take off, and we're still carrying pieces of
it.

I get this question a lot. With the ability (new in 1.3) to build an SDK based
on the contents of any arbitrary image.. the meta-toolchain-gmae is simply not
necessary.

bitbake -c populate_sdk <image recipe>

Aha. Thanks very much.

Is this the preferred way to get a toolchain out of yocto?
That's exactly what I'm working on at the moment (well, after
fixing up some toolchain build issues I've encountered after
messing around a bit with the toolchain recipes...;-)

I don't know if it's the preferred "Yocto Project" way.. but it's the only way I do it.

The code was implemented in the middle of the 1.3 process and does work in 1.3. (However multilib support may not be there. There are a series of patches pending for master that do enable the multilib support as part of the rpm/smart work.)

--Mark

-- Tim


=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

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

Hi Timo,

Sorry for the delay, but finally got a chance to look into these patches. I like how it automate the docgen and integrate them into eclipse. The concern that I'm having is, it seems converting all the Yocto Project Docs, originally I thought only for ADT manual. So to view these doc in eclipse are nice, but since we don't have some corresponding feature support in eclipse plug-in, it'll look awkward to combine these docs with ADT plugin. BTW, to support our bitbake commander plug-in running on windows usage, we recently split the plug-in into 2 features: ADT and bitbake commander and the doc plug-in is part of ADT feature. So I'd suggest, if we want to show all the docs, probably create a separate Yocto Doc Feature. If we want to combine with ADT plug-in, then probably only covert the ADT manual content generation and integration. Make sense?

Thanks,
Jessica

So instead of back port, have you looked into adt-installer to address your need. It's sysroot is based on target images. The only downside is it's based on opkg and ipk if that's not your default package format.

On 12/14/2012 12:45 PM, Mark Hatle wrote:

On 12/14/12 1:46 PM, Burton, Ross wrote:

On 14 December 2012 19:43, Tim Bird <tim.bird@...> wrote:

"If you need GMAE, you should use the bitbake meta-toolchain-gmae command. The resulting installation script when run will support such development. However, if you are not concerned with GMAE, you
can generate the toolchain installer using bitbake meta-toolchain."

After googling a bit, I figured out that GMAE stands for Gnome Mobile and Embedded.

It might be good to put this acronym somewhere in the manual.
(I'm still not sure if I need GMAE or not...)

Basically, GMAE means GTK+ 2 and bits of the GNOME stack.

A stealth plan of mine is to remove every trace of GMAE from Yocto.
It was an initiative Poky was involved with back in the OpenedHand
days that didn't really take off, and we're still carrying pieces of
it.

I get this question a lot. With the ability (new in 1.3) to build an SDK based
on the contents of any arbitrary image.. the meta-toolchain-gmae is simply not
necessary.

bitbake -c populate_sdk <image recipe>

Aha. Thanks very much.

Is this the preferred way to get a toolchain out of yocto?
That's exactly what I'm working on at the moment (well, after
fixing up some toolchain build issues I've encountered after
messing around a bit with the toolchain recipes...;-)

-- Tim


=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

On Fri, Dec 14, 2012 at 4:09 PM, Zhang, Jessica <jessica.zhang@...> wrote:

Actually I talked with Richard regarding retiring the toolchain targets (meta-toolchain and meta-toolchain-gmae) as Mark mentioned that now we can build a toolchain matching the >image. Also, we're continue improving adt-installer which also allows you to setup sysroot using the target image as well. Richard's concern is there maybe some legacy user that >preferred the toolchain target. With the latest changes in toolchain generation which really maps to target images, probably we should unplug to legacy ones to make the toolchain generation more streamline. Thoughts or concerns?

I'm one of the users that is stuck using Edison 6.0. I'm desperate
for the ability to generate a toolchain and sysroot that matches our
target. Right now I have to build meta-toolchain and then manually
look in the tmp for sysroot-destdir related stuff from our build and
copy it to the sysroot in /opt/poky and hand that out to developers.
When our sister group overseas makes a change that effects the sysroot
it breaks our build and I have to figure out what happened and
manually adjust our sysroot to fix the problem. I sure would like to
be able to just do an update and then bitbake the toolchain to pick up
the changes. I figure we are stuck with Edison for a while ... can I
back port these toolchain features you all are talking about to
Edison?

Regards,

Brian

Actually I talked with Richard regarding retiring the toolchain targets (meta-toolchain and meta-toolchain-gmae) as Mark mentioned that now we can build a toolchain matching the image. Also, we're continue improving adt-installer which also allows you to setup sysroot using the target image as well. Richard's concern is there maybe some legacy user that preferred the toolchain target. With the latest changes in toolchain generation which really maps to target images, probably we should unplug to legacy ones to make the toolchain generation more streamline. Thoughts or concerns?

Thanks,
Jessica

On 12/14/12 1:46 PM, Burton, Ross wrote:

On 14 December 2012 19:43, Tim Bird <tim.bird@...> wrote:

"If you need GMAE, you should use the bitbake meta-toolchain-gmae command. The resulting installation script when run will support such development. However, if you are not concerned with GMAE, you
can generate the toolchain installer using bitbake meta-toolchain."

After googling a bit, I figured out that GMAE stands for Gnome Mobile and Embedded.

It might be good to put this acronym somewhere in the manual.
(I'm still not sure if I need GMAE or not...)

Basically, GMAE means GTK+ 2 and bits of the GNOME stack.

A stealth plan of mine is to remove every trace of GMAE from Yocto.
It was an initiative Poky was involved with back in the OpenedHand
days that didn't really take off, and we're still carrying pieces of
it.

I get this question a lot. With the ability (new in 1.3) to build an SDK based on the contents of any arbitrary image.. the meta-toolchain-gmae is simply not necessary.

bitbake -c populate_sdk <image recipe>

--Mark

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

On Fri, 14 Dec 2012, Martin Jansa wrote:

On Fri, Dec 14, 2012 at 02:43:08PM -0500, Robert P. J. Day wrote:

from https://wiki.yoctoproject.org/wiki/Distro_Tracking

"The Distro Tracking Fields
(meta/conf/distro/include/distro_tracking_fields.inc) is a location
for sharing information about the status of recipes and tracking
version information. Not all of this information can be generated
automatically (yet), so the manual editing is needed."

i don't see that file so what's the story?

Why don't you use git log if you're interested in stories?

git log -- meta/conf/distro/include/distro_tracking_fields.inc
commit e8808c85a6bba8422cd82631b2bbc367543e4cdd
Author: Saul Wold <sgw@...>
Date: Tue Jun 12 07:03:27 2012 -0700

distro_tracking_fields: move to meta-yocto as seperate files

We are going to take a phased approach of breaking up the
distro_tracking_fields, first is to remove it from oe-core,
then create new files in meta-yocto. We are doing this because
the distro_tracking_fields is getting unweildly and some of
the data can be part of a burn down list instead continually
stored, thus it will get split up.

Signed-off-by: Saul Wold <sgw@...>
...

./meta-yocto/conf/distro/include/upstream_tracking.inc

ah, quite right, my fault for not poking further. in any event, it
would seem that that wiki page could use some updating.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

On Fri, Dec 14, 2012 at 02:43:08PM -0500, Robert P. J. Day wrote:

from https://wiki.yoctoproject.org/wiki/Distro_Tracking

"The Distro Tracking Fields
(meta/conf/distro/include/distro_tracking_fields.inc) is a location
for sharing information about the status of recipes and tracking
version information. Not all of this information can be generated
automatically (yet), so the manual editing is needed."

i don't see that file so what's the story?

Why don't you use git log if you're interested in stories?

git log -- meta/conf/distro/include/distro_tracking_fields.inc
commit e8808c85a6bba8422cd82631b2bbc367543e4cdd
Author: Saul Wold <sgw@...>
Date: Tue Jun 12 07:03:27 2012 -0700

distro_tracking_fields: move to meta-yocto as seperate files

We are going to take a phased approach of breaking up the
distro_tracking_fields, first is to remove it from oe-core,
then create new files in meta-yocto. We are doing this because
the distro_tracking_fields is getting unweildly and some of
the data can be part of a burn down list instead continually
stored, thus it will get split up.

Signed-off-by: Saul Wold <sgw@...>
...

./meta-yocto/conf/distro/include/upstream_tracking.inc

Cheers,

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

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
.../layer-management/layer-management_0.9.9.bb | 4 ++--
.../layer-management/layer-management_git.bb | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/recipes-graphics/layer-management/layer-management_0.9.9.bb b/recipes-graphics/layer-management/layer-management_0.9.9.bb
index eb6ceaf..81b8fd0 100644
--- a/recipes-graphics/layer-management/layer-management_0.9.9.bb
+++ b/recipes-graphics/layer-management/layer-management_0.9.9.bb
@@ -5,9 +5,9 @@ SECTION = "environment/base"
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=071e6b9a5eb9fc5868edf57ce153e5b9"

-DEPENDS = "virtual/libgl dbus libxcomposite"
+DEPENDS = "virtual/egl dbus libxcomposite"

-PR = "r0"
+PR = "r1"

SRC_URI = " \
git://git.projects.genivi.org/layer_management.git;protocol=git;tag=ivi-layer-management_version_0_9_9 \
diff --git a/recipes-graphics/layer-management/layer-management_git.bb b/recipes-graphics/layer-management/layer-management_git.bb
index 7be26c1..9af452d 100644
--- a/recipes-graphics/layer-management/layer-management_git.bb
+++ b/recipes-graphics/layer-management/layer-management_git.bb
@@ -6,9 +6,9 @@ SECTION = "environment/base"
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=249d3578d6bba1bb946148d367a28080"

-DEPENDS = "virtual/libgl dbus libxcomposite"
+DEPENDS = "virtual/egl dbus libxcomposite"

-PR = "r2"
+PR = "r3"

SRCREV = "86c2dc9ef367b52fd5d05b53cbad5e21b9ab042f"

--
1.7.9.5

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
.../xorg-xserver/xserver-xorg_1.13.0.bbappend | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/recipes-graphics/xorg-xserver/xserver-xorg_1.13.0.bbappend b/recipes-graphics/xorg-xserver/xserver-xorg_1.13.0.bbappend
index c43684e..51573f6 100644
--- a/recipes-graphics/xorg-xserver/xserver-xorg_1.13.0.bbappend
+++ b/recipes-graphics/xorg-xserver/xserver-xorg_1.13.0.bbappend
@@ -1,6 +1,4 @@
-PRINC := "${@int(PRINC) + 3}"
-
-LIB_DEPS += "virtual/libgl"
+PRINC := "${@int(PRINC) + 4}"

FILESEXTRAPATHS := "${THISDIR}/${PN}"

--
1.7.9.5

On Fri, 14 Dec 2012, Burton, Ross wrote:

On 14 December 2012 19:43, Tim Bird <tim.bird@...> wrote:

"If you need GMAE, you should use the bitbake meta-toolchain-gmae command. The resulting installation script when run will support such development. However, if you are not concerned with GMAE, you
can generate the toolchain installer using bitbake meta-toolchain."

After googling a bit, I figured out that GMAE stands for Gnome Mobile and Embedded.

It might be good to put this acronym somewhere in the manual.
(I'm still not sure if I need GMAE or not...)

Basically, GMAE means GTK+ 2 and bits of the GNOME stack.

A stealth plan of mine is to remove every trace of GMAE from Yocto.

a good place to start would be to remove the "gmae" component from
the name of the toolchains themselves:

http://downloads.yoctoproject.org/releases/yocto/yocto-1.2/toolchain/x86-64/

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

On 14 December 2012 19:43, Tim Bird <tim.bird@...> wrote:

"If you need GMAE, you should use the bitbake meta-toolchain-gmae command. The resulting installation script when run will support such development. However, if you are not concerned with GMAE, you
can generate the toolchain installer using bitbake meta-toolchain."

After googling a bit, I figured out that GMAE stands for Gnome Mobile and Embedded.

It might be good to put this acronym somewhere in the manual.
(I'm still not sure if I need GMAE or not...)

Basically, GMAE means GTK+ 2 and bits of the GNOME stack.

A stealth plan of mine is to remove every trace of GMAE from Yocto.
It was an initiative Poky was involved with back in the OpenedHand
days that didn't really take off, and we're still carrying pieces of
it.

Ross

I was reading in the adt manual about using the cross-toochain tarball,
and I came across this sentence:

"If you need GMAE, you should use the bitbake meta-toolchain-gmae command. The resulting installation script when run will support such development. However, if you are not concerned with GMAE, you
can generate the toolchain installer using bitbake meta-toolchain."

After googling a bit, I figured out that GMAE stands for Gnome Mobile and Embedded.

It might be good to put this acronym somewhere in the manual.
(I'm still not sure if I need GMAE or not...)

-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

from https://wiki.yoctoproject.org/wiki/Distro_Tracking

"The Distro Tracking Fields
(meta/conf/distro/include/distro_tracking_fields.inc) is a location
for sharing information about the status of recipes and tracking
version information. Not all of this information can be generated
automatically (yet), so the manual editing is needed."

i don't see that file so what's the story?

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

Hi Stefan,

the packaging of ROS is quite tricky and we have not solved all issues yet. We are in the process of preparing to publish our current achievements publicly and I would be very happy if you would join our effort. I suggest we discuss further details off-list.


Lukas


-----Ursprüngliche Nachricht-----
Von: Stefan Herbrechtsmeier [mailto:sherbrec@...]
Gesendet: Freitag, 14. Dezember 2012 11:58
An: Lukas Bulwahn
Cc: yocto@...
Betreff: Re: [yocto] Packaging ROS for Yocto-Linux

Hi Lukas,

I have interest in a ROS layer for Yocto. We are already using Yocto for your mini robot platforms but with the older player framework and our own framework. Last time I checked ROS they only support cross compiling via a native ROS installation and hide a lot of the compiling and installation process behind their own tools / scripts.

Kind regards,
Stefan

Am 13.12.2012 09:32, schrieb Lukas Bulwahn:

Hi all,

To my previous question, I have not received any feedback here. If anyone knows someone who might be interested in packaging ROS, please contact us. We're looking for collaborators and users.

Lukas

-----Ursprüngliche Nachricht-----
Von: yocto-bounces@...
[mailto:yocto-bounces@...] Im Auftrag von Lukas Bulwahn
Gesendet: Dienstag, 4. Dezember 2012 16:08
An: yocto@...
Betreff: [yocto] Packaging ROS for Yocto-Linux

Hi all,

we are interested in setting up a computing platform for our
development using Yocto-Linux and the robotic operating system ROS
(http://www.ros.org/). We are currently at the very beginning of this
development: As a first step, we want to package ROS for our own needs, but we are open to contribute this to the community if there are others that need this as well.

Has someone in the community already packaged ROS for Yocto? Are there others that also interested in a ROS package for Yocto?

We are happy about any feedback.


Lukas Bulwahn
BMW Car IT GmbH
Petuelring 116
D-80809 Muenchen
Germany
Mail: lukas.bulwahn@...
Web: http://www.bmw-carit.de
-------------------------------------------------------------
BMW Car IT GmbH
Geschäftsführer: Harald Heinecke
Sitz und Registergericht: München HRB134810
-------------------------------------------------------------

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

--
Dipl.-Ing. Stefan Herbrechtsmeier

Universität Bielefeld
AG Kognitronik & Sensorik
Exzellenzcluster Cognitive Interaction Technology (CITEC) Universitätsstraße 21-23
D-33615 Bielefeld (Germany)

office : M6-117
phone : +49 521-106-67370
fax : +49 521-106-12348
mailto : sherbrec@...
www : http://www.ks.cit-ec.uni-bielefeld.de/

On Fri, Dec 14, 2012 at 1:07 PM, Burton, Ross <ross.burton@...> wrote:

Hi,

That append just does:

PACKAGECONFIG_append_vexpressa9 = " gles egl"

But 8.0.5 (and actually some of the 8.0.4 releases) have:

PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'x11', 'x11',
'', d)} egl gles"

So you can drop the bbappend entirely on your master branch.

Ross

On Thu, 13 Dec 2012, Bruce Ashfield wrote:

On 12-12-13 5:51 PM, Gary Thomas wrote:

On 2012-12-13 14:45, Robert P. J. Day wrote:

On Thu, 13 Dec 2012, David Nyström wrote:

Hi,

Hmm,
This will lead to these variables beeing append:able but
non-overridable in image layer, as an(un?)intended consequence,
right ?

-----Original Message-----
From: Robert P. J. Day [rpjday@...]
Received: Thursday, 13 Dec 2012, 20:59
To: Yocto discussion list [yocto@...]
Subject: [yocto] [PATCH] Use "+=" consistently when setting
IMAGE_FSTYPES in Yocto machine conf files.

diff --git a/meta-yocto-bsp/conf/machine/atom-pc.conf
b/meta-yocto-bsp/conf/machine/atom-pc.conf
index 77dd7fb..fbde1d3 100644
--- a/meta-yocto-bsp/conf/machine/atom-pc.conf
+++ b/meta-yocto-bsp/conf/machine/atom-pc.conf
@@ -25,7 +25,7 @@ XSERVER ?= "xserver-xorg \

MACHINE_EXTRA_RRECOMMENDS = "kernel-modules eee-acpi-scripts"

-IMAGE_FSTYPES ?= "ext3 cpio.gz live"
+IMAGE_FSTYPES += "ext3 cpio.gz live"

APPEND += "usbcore.autosuspend=1"

diff --git a/meta-yocto-bsp/conf/machine/routerstationpro.conf
b/meta-yocto-bsp/conf/machine/routerstationpro.conf
index e5e4d1a..c7a5ad5 100644
--- a/meta-yocto-bsp/conf/machine/routerstationpro.conf
+++ b/meta-yocto-bsp/conf/machine/routerstationpro.conf
@@ -22,5 +22,5 @@ USE_VT ?= "0"

MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"

-IMAGE_FSTYPES ?= "jffs2 tar.bz2"
+IMAGE_FSTYPES += "jffs2 tar.bz2"

please don't top post. and i'll have to take a look at this to see
what the potential problem is here. can anyone else see a potential
issue with this patch?

Yes, as David said, it eliminates the possibility of overriding
the variable. IMO, all of these should be ?= which lets there
be a useful default, but can still be [completely] overridden
by the user.

I'd agree that if we were shooting for consistency, I'd go with
?= and not the +=.

if someone thinks that's a cleanup worth making and wants to take
it, help yourself to it, i'm going to be buried in ADT stuff all day.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================