Date   

Re: What is GMAE?

Mark Hatle <mark.hatle@...>
 

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


Re: What is GMAE?

Mark Hatle <mark.hatle@...>
 

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


Re: [RFCv3 0/7][eclipse-poky] Integrate yocto documentation into eclipse

Zhang, Jessica
 

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

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Timo Müller
Sent: Wednesday, December 12, 2012 5:10 AM
To: yocto@...
Cc: Timo Mueller
Subject: Re: [yocto] [RFCv3 0/7][eclipse-poky] Integrate yocto documentation into eclipse

Hi,

mail@... wrote, On 06.12.2012 16:48:
From: Timo Mueller <timo.mueller@...>

Hi,

since the last proposal some things have changed:
1. Eclipse help generation is now part of the yocto-docs project
(currently available in the origin/timo branch) 2. We agreed that the
plugin should be licensed under the EPL v1.0 instead of having a
separate documentation plugin licensed under the CCA-SA 2.0 UK.

The last patch set was adding generated eclipse help files (html) to
the repository. One major change in this patch series is that I
extended the plugin build system to integrate the generation into the
build process. Thus keeping the eclipse help and the official
documentation in sync is now automated.
Also the eclipse help is now part of the user.doc plugin and no longer
contained in a separate plugin/feature.

Rational from the original patch:
<snip>
the documentation of the yocto project can currently be viewed online
or as a separate pdf. When using the eclipse ide to develop software
on base of a yocto sysroot and toolchain it would be convenient to
access the relevant parts of the documentation from within the ide.
</snip>
<snip>
I have intergrated this
documentation in the ide and it can now be accessed through the
eclipse help center (Help -> Help Contents).
</snip>

Best regards
Timo

Timo Mueller (7):
plugins/sdk.ide.doc.user: Add empty eclipse help
plugins/sdk.ide.doc.user: Add about.html to prepare addition of yocto
documentation
scripts/generate_doc.sh: Add script to handle eclipse help generation
plugins/sdk.ide.doc.user: Add yocto documentation to the table of
contents
scripts/generat-doc.sh: Copy generated eclipse help into the user.doc
plugin
scripts/build.sh: Add documentation generation to the default build
(TEMPORARY): Use origin/timo branch of yocto docs project

.../META-INF/MANIFEST.MF | 3 +-
plugins/org.yocto.sdk.ide.doc.user/about.html.in | 166 ++++++++++++++++++++
.../org.yocto.sdk.ide.doc.user/build.properties | 9 +-
plugins/org.yocto.sdk.ide.doc.user/html/book.css | 1 +
plugins/org.yocto.sdk.ide.doc.user/plugin.xml | 31 ++++
plugins/org.yocto.sdk.ide.doc.user/toc.xml | 21 +++
scripts/build.sh | 7 +
scripts/generate_doc.sh | 91 +++++++++++
8 files changed, 326 insertions(+), 3 deletions(-)
create mode 100644 plugins/org.yocto.sdk.ide.doc.user/about.html.in
create mode 100644 plugins/org.yocto.sdk.ide.doc.user/html/book.css
create mode 100644 plugins/org.yocto.sdk.ide.doc.user/toc.xml
create mode 100755 scripts/generate_doc.sh
The name of the poky-ref-manual will be changed to ref-manual. This change has an impact on this patch series, since the name is used in the generate-doc shell script.
But with the temporary fix in patch 7, the timo branch is used, which will for the time being remain unaffected by the name changes. This way you can test the documentation integration proposed in this patch set.
I would like to get your opinion on the general approach to integrate the documentation into eclipse. If it fits into the eclipse-poky project in general, I will rewrite this patch series to reflect the changes. The rewrite will also remove the "the" from the different help chapters (as Scott pointed out to me).
I also agreed with Scott that once this approach is agreed on I will provide the necessary patches to the timo branch of the yocto-docs project and he will merge the eclipse generation into the master of the project.

Best regards,
Timo

PS: I also apologize for not signing off the patch series. I will make up for that in the reworked patches.
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: What is GMAE?

Zhang, 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.

-----Original Message-----
From: Brian Hutchinson [mailto:b.hutchman@...]
Sent: Friday, December 14, 2012 1:58 PM
To: Zhang, Jessica
Cc: Mark Hatle; yocto@...
Subject: Re: [yocto] What is GMAE?

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


Re: What is GMAE?

Tim Bird <tim.bird@...>
 

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
=============================


Re: What is GMAE?

Brian Hutchinson <b.hutchman@...>
 

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


Re: What is GMAE?

Zhang, Jessica
 

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

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Mark Hatle
Sent: Friday, December 14, 2012 12:46 PM
To: yocto@...
Subject: Re: [yocto] What is GMAE?

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
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: What is GMAE?

Mark Hatle <mark.hatle@...>
 

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


Re: is distro_tracking_fields.inc actually used?

Robert P. J. Day
 

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
========================================================================


Re: is distro_tracking_fields.inc actually used?

Martin Jansa
 

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@...


[meta-ivi][PATCH 2/2] layer-management: Replace dependency of libgl with egl

Andrei Gherzan
 

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


[meta-ivi][PATCH 1/2] xserver-xorg: Remove dependency to libgl

Andrei Gherzan
 

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


Re: What is GMAE?

Robert P. J. Day
 

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
========================================================================


Re: What is GMAE?

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

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


What is GMAE?

Tim Bird <tim.bird@...>
 

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
=============================


is distro_tracking_fields.inc actually used?

Robert P. J. Day
 

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
========================================================================


Re: Packaging ROS for Yocto-Linux

Lukas Bulwahn <Lukas.Bulwahn@...>
 

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/


Re: [meta-ivi][PATCH 1/2] mesa-dri: Sync bbappend version with oe-core

Andrei Gherzan
 

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.

Will do but right now we need a fast solution to fix build. 
Soon I will cleanup master.

ag


Re: [meta-ivi][PATCH 1/2] mesa-dri: Sync bbappend version with oe-core

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

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


Re: [PATCH] Use "+=" consistently when setting IMAGE_FSTYPES in Yocto machine conf files.

Robert P. J. Day
 

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
========================================================================