Date   

Re: Packaging ROS for Yocto-Linux

Stefan Herbrechtsmeier <sherbrec@...>
 

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: [Draft] From Bitbake Hello World To an Image

Eren Türkay <eren@...>
 

On Thu, Dec 13, 2012 at 05:26:29PM -0500, Trevor Woerner wrote:
I'm not sure if there's something about my system that is different
than what you expect, but I had to delete my 'tmp' folder before
invoking './bin/bitbake firstrecipe -vDD' after inheriting the
"autotool" versions in order to get the new, overridden tasks to run
(since there's no 'clean' tasks).
Thank you for your feedback. I am glad you like it.

You are right that 'tmp' directory needs to be removed after changing
the recipe (adding inherit, or removing it). I guess we are hitting
bitbake cache. Since clean tasks don't exist, 'tmp' needs to be removed
to make changes take effect.

I must have removed 'tmp' and missed adding it while writing. I will add
the explanation.

Regards,
Eren

--
. 73! DE TA1AET
http://linkedin.com/in/erenturkay


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

Bruce Ashfield <bruce.ashfield@...>
 

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 ?

Br,
David

Sent from my Android phone using TouchDown (www.nitrodesk.com)

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


Signed-off-by: Robert P. J. Day <rpjday@...>

---

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

Cheers,

Bruce


[meta-ivi][PATCH 2/2] qt4-embedded: Sync bbappend version with oe-core

Andrei Gherzan
 

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
..._4.8.3.bbappend => qt4-embedded_4.8.4.bbappend} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename recipes-qt/qt4/{qt4-embedded_4.8.3.bbappend => qt4-embedded_4.8.4.bbappend} (100%)

diff --git a/recipes-qt/qt4/qt4-embedded_4.8.3.bbappend b/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
similarity index 100%
rename from recipes-qt/qt4/qt4-embedded_4.8.3.bbappend
rename to recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
--
1.7.9.5


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

Andrei Gherzan
 

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
...-dri_8.0.4.bbappend => mesa-dri_8.0.5.bbappend} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename recipes-graphics/mesa/{mesa-dri_8.0.4.bbappend => mesa-dri_8.0.5.bbappend} (100%)

diff --git a/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend b/recipes-graphics/mesa/mesa-dri_8.0.5.bbappend
similarity index 100%
rename from recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
rename to recipes-graphics/mesa/mesa-dri_8.0.5.bbappend
--
1.7.9.5


Re: libva failing for mp4 using gstreamer under 'danny' with cedartrail BSP

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

On 13 December 2012 23:23, Chris Tapp <opensource@...> wrote:
Unfortunately, adding xvimagesink hasn't helped. I also still don't really understand why webm and flv work ok.
They're probably using ximagesink, but depending on your pipeline
you're probably doing the decode for mp4 using VAAPI, which has
special requirements on sinks.

I'd throw in some debugging to inspect the pipelines constructed for flv vs mp4.

Ross


Re: libva failing for mp4 using gstreamer under 'danny' with cedartrail BSP

Chris Tapp
 

On 13 Dec 2012, at 22:50, Chris Tapp wrote:


On 13 Dec 2012, at 22:38, Ross Burton wrote:

On Thursday, 13 December 2012 at 22:22, Chris Tapp wrote:
Good catch. This shows there is no video/x-surface decoder available. Off to find which plugin I need...

I should have thought of trying that. Thanks! I'll have to find out why my gstreamer error handler isn't spotting the problem!
Yeah… that's a bug I meant to fix in danny-next but failed. Install gst-plugins-xvimagesink (or something like that, not at my work machines right now).
Thanks, I'll give that a try.
Unfortunately, adding xvimagesink hasn't helped. I also still don't really understand why webm and flv work ok.

It's possible that you've got some horrible GLES/VA interaction, specifically the download from VA-land to however you're getting the video into the textures. Speaking of which, how are you getting from frames to textures?
I'm using appsink to give me access to the raw pixel data which I then glTexSubImage into a texture. I'm using appsink as I've got legacy code that uses it for an SDL app. I may try and switch to gstreamer GL plugin support when I find the best option ;-)
There'll be a better way - gstreamer-gl is worth a look at if you can assume VAAPI you should be able to construct a fairly efficient vaapi-gl pipeline (with gstreamer 1.0 I believe you'll be able to get zero-copy)
I had a quick scan of that the other day and thought it looked like it would be worth a try. I'm hoping to be able to stick with the DN2800MT board for a while, so VAAPI will be available. Zero-copy would be really nice :-)

Ross

Chris Tapp

opensource@...
www.keylevel.com



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

opensource@...
www.keylevel.com


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

Gary Thomas
 

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 ?

Br,
David

Sent from my Android phone using TouchDown (www.nitrodesk.com)

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


Signed-off-by: Robert P. J. Day <rpjday@...>

---

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.

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------


Re: libva failing for mp4 using gstreamer under 'danny' with cedartrail BSP

Chris Tapp
 

On 13 Dec 2012, at 22:38, Ross Burton wrote:

On Thursday, 13 December 2012 at 22:22, Chris Tapp wrote:
Good catch. This shows there is no video/x-surface decoder available. Off to find which plugin I need...

I should have thought of trying that. Thanks! I'll have to find out why my gstreamer error handler isn't spotting the problem!
Yeah… that's a bug I meant to fix in danny-next but failed. Install gst-plugins-xvimagesink (or something like that, not at my work machines right now).
Thanks, I'll give that a try.

It's possible that you've got some horrible GLES/VA interaction, specifically the download from VA-land to however you're getting the video into the textures. Speaking of which, how are you getting from frames to textures?
I'm using appsink to give me access to the raw pixel data which I then glTexSubImage into a texture. I'm using appsink as I've got legacy code that uses it for an SDL app. I may try and switch to gstreamer GL plugin support when I find the best option ;-)
There'll be a better way - gstreamer-gl is worth a look at if you can assume VAAPI you should be able to construct a fairly efficient vaapi-gl pipeline (with gstreamer 1.0 I believe you'll be able to get zero-copy)
I had a quick scan of that the other day and thought it looked like it would be worth a try. I'm hoping to be able to stick with the DN2800MT board for a while, so VAAPI will be available. Zero-copy would be really nice :-)

Ross

Chris Tapp

opensource@...
www.keylevel.com


Re: libva failing for mp4 using gstreamer under 'danny' with cedartrail BSP

Ross Burton <ross.burton@...>
 

On Thursday, 13 December 2012 at 22:22, Chris Tapp wrote:
Good catch. This shows there is no video/x-surface decoder available. Off to find which plugin I need...

I should have thought of trying that. Thanks! I'll have to find out why my gstreamer error handler isn't spotting the problem!
Yeah… that's a bug I meant to fix in danny-next but failed. Install gst-plugins-xvimagesink (or something like that, not at my work machines right now).

It's possible that you've got some horrible GLES/VA interaction, specifically the download from VA-land to however you're getting the video into the textures. Speaking of which, how are you getting from frames to textures?
I'm using appsink to give me access to the raw pixel data which I then glTexSubImage into a texture. I'm using appsink as I've got legacy code that uses it for an SDL app. I may try and switch to gstreamer GL plugin support when I find the best option ;-)
There'll be a better way - gstreamer-gl is worth a look at if you can assume VAAPI you should be able to construct a fairly efficient vaapi-gl pipeline (with gstreamer 1.0 I believe you'll be able to get zero-copy)

Ross


Weekly Test Report for Yocto 1.4 M1 RC2 20121205 Build

Palalau, AlexandruX <alexandrux.palalau@...>
 

Hello,


Here is the weekly test report for Yocto 1.4 M1 RC2 20121205 build.

We have anew bug for non-GPLv3 image build(3546). Other than that, the multilib with ipk still fails for the CoreBuildSystem Weekly tests.

ADT toolchain fails with autoconf and automake (3338).

Attached the weekly test report.


Test Summary
-------------------------

Test Result Summary

Component

Target

Status

Comments

QEMU

qemux86

GOOD

RTLDLIST path check fails for sato-sdk

 

qemux86-64

GOOD

Everything runs well

qemuarm

GOOD

Everything runs well

Core Build System

BUGGY

lib32 connman-gnome built for qemux86-64 – ipk fails
non GPLv3 build fails

ADT Toolchain

BUGGY

iptables-1.4.15: autoreconf run failed on gmae-toolchain

HOB

 

GOOD

Everything runs well

 

BLOCK

Critical bugs, more than 50% test cases are blocked

GOOD

Only Normal, Minor or Enhancement bugs, less than 10% test cases failed

BUGGY

Normal, Major and Critical bugs, more than 10% test cases failed

 

Detailed Test Result for each component

Target

Total TCs

Not Run

Passed

Failed

Not testable (Blocked)

Qemux86 Sato

29

0

29

0

0

Qemux86 Sato-SDK

34

0

33

1

0

Qemux86-64 Sato

29

0

29

0

0

Qemux86-64 Sato-SDK

34

0

34

0

0

Qemuarm Sato

29

0

29

0

0

Qemuarm Sato-SDK

34

0

34

0

0

Core Build System

35

0

33

2(3546,3453,3440)

0

ADT Toolchain

53

0

52

1(3338)

0

HOB

38

0

38

0

0

Total

315

0

311

4

0


* You can check the detailed test result in attachment for each target.
** The failed/blocked case number is listed with failed cases’ bug number.


Commit information
--------------------------------
Location: http://autobuilder.yoctoproject.org/pub/nightly/20121205-3
Tree/Branch: poky/1.4_M1
Commit:
381c4b69c7e8b452f4d3de2f8214e6e5f6a9abe7

Issue Summary
-----------------------------------

Component

Bug Number

Target Milestone

Core Build System

New! Non GPLv3 build fails

Bugs 3453/3440 lib32 connman-gnome built for qemux86-64 - ipk

1.4M2
1.4

ADT Toolchain

Bug 3338 iptables-1.4.15: autoreconf run failed on gmae-toolchain

1.4 M1

 

Best Regards,


--

Alexandru Palalau

QA Contractor @ Yocto Project

Open-source Technology Center Romania

System Software Division




Re: [Draft] From Bitbake Hello World To an Image

Trevor Woerner
 

I'm not sure if there's something about my system that is different
than what you expect, but I had to delete my 'tmp' folder before
invoking './bin/bitbake firstrecipe -vDD' after inheriting the
"autotool" versions in order to get the new, overridden tasks to run
(since there's no 'clean' tasks).


Re: libva failing for mp4 using gstreamer under 'danny' with cedartrail BSP

Chris Tapp
 

On 13 Dec 2012, at 21:55, Ross Burton wrote:

On Thursday, 13 December 2012 at 21:10, Chris Tapp wrote:
I've got an X application that uses gstreamer to capture frames from video files and display them using GLES textures.

This works fine for webm and flv files, but if I try and use mp4 (or avi) then I get no frames. I'm not seeing any gstreamer errors, but the console shows:

libva: VA_API version 0.32.1
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/dri/pvr_drv_video.so
libva: va_openDriver() returns 0

1) I'm building under 'danny' for cedartrail with PVR.
2) The pvr_drv_video.so file mentioned above exists.
3) The same gstreamer pipeline works fine on my host build system.
4) I'm fairly sure the required gstreamer plugins are present.
To verify (4) which is obviously fairly important, can you confirm that a simple playbin will play the videos correctly on the CedarTrail?
Good catch. This shows there is no video/x-surface decoder available. Off to find which plugin I need...

I should have thought of trying that. Thanks! I'll have to find out why my gstreamer error handler isn't spotting the problem!


It's possible that you've got some horrible GLES/VA interaction, specifically the download from VA-land to however you're getting the video into the textures. Speaking of which, how are you getting from frames to textures?
I'm using appsink to give me access to the raw pixel data which I then glTexSubImage into a texture. I'm using appsink as I've got legacy code that uses it for an SDL app. I may try and switch to gstreamer GL plugin support when I find the best option ;-)

Ross

Chris Tapp

opensource@...
www.keylevel.com


Re: [Draft] From Bitbake Hello World To an Image

Trevor Woerner
 

Thank you, I enjoyed reading your document. I especially liked the top
part which talked about creating your own tasks (which 'turned the
light on' for how OE/Yocto use bitbake). I also wasn't aware of the
vim helpers which come as part of bitbake.


Re: libva failing for mp4 using gstreamer under 'danny' with cedartrail BSP

Ross Burton <ross.burton@...>
 

On Thursday, 13 December 2012 at 21:10, Chris Tapp wrote:
I've got an X application that uses gstreamer to capture frames from video files and display them using GLES textures.

This works fine for webm and flv files, but if I try and use mp4 (or avi) then I get no frames. I'm not seeing any gstreamer errors, but the console shows:

libva: VA_API version 0.32.1
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/dri/pvr_drv_video.so
libva: va_openDriver() returns 0

1) I'm building under 'danny' for cedartrail with PVR.
2) The pvr_drv_video.so file mentioned above exists.
3) The same gstreamer pipeline works fine on my host build system.
4) I'm fairly sure the required gstreamer plugins are present.
To verify (4) which is obviously fairly important, can you confirm that a simple playbin will play the videos correctly on the CedarTrail?

It's possible that you've got some horrible GLES/VA interaction, specifically the download from VA-land to however you're getting the video into the textures. Speaking of which, how are you getting from frames to textures?

Ross


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

Robert P. J. Day
 

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 ?

Br,
David

Sent from my Android phone using TouchDown (www.nitrodesk.com)

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


Signed-off-by: Robert P. J. Day <rpjday@...>

---

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?

rday

--

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

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


libva failing for mp4 using gstreamer under 'danny' with cedartrail BSP

Chris Tapp
 

I've got an X application that uses gstreamer to capture frames from video files and display them using GLES textures.

This works fine for webm and flv files, but if I try and use mp4 (or avi) then I get no frames. I'm not seeing any gstreamer errors, but the console shows:

libva: VA_API version 0.32.1
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/dri/pvr_drv_video.so
libva: va_openDriver() returns 0

1) I'm building under 'danny' for cedartrail with PVR.
2) The pvr_drv_video.so file mentioned above exists.
3) The same gstreamer pipeline works fine on my host build system.
4) I'm fairly sure the required gstreamer plugins are present.

Does anyone have an idea as to what might be causing this?

Chris Tapp

opensource@...
www.keylevel.com


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

David Nyström <David.Nystrom@...>
 

Hi,

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

Br,
David

Sent from my Android phone using TouchDown (www.nitrodesk.com)

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


Signed-off-by: Robert P. J. Day <rpjday@...>

---

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"


--

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

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


[PATCH] MIPS {{=machine}}.conf: For consistency, use "+=" for setting IMAGE_FSTYPES.

Robert P. J. Day
 

Signed-off-by: Robert P. J. Day <rpjday@...>

---

diff --git a/scripts/lib/bsp/substrate/target/arch/mips/conf/machine/{{=machine}}.conf b/scripts/lib/bsp/substrate/target/arch/mips/conf/machine/{{=machine}}.conf
index 4dd5940..a2abcb4 100644
--- a/scripts/lib/bsp/substrate/target/arch/mips/conf/machine/{{=machine}}.conf
+++ b/scripts/lib/bsp/substrate/target/arch/mips/conf/machine/{{=machine}}.conf
@@ -32,4 +32,4 @@ SERIAL_CONSOLE = "115200 ttyS0"

MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"

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

--

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

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


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

Robert P. J. Day
 

Signed-off-by: Robert P. J. Day <rpjday@...>

---

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"


--

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

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