Date   

Re: per-image ROOTFS sizes

Robert P. J. Day
 

On Thu, 13 Dec 2012, Saul Wold wrote:

meta-yocto-bsp/conf/machine/routerstationpro.conf:IMAGE_FSTYPES ?= "jffs2
tar.bz2"
meta-yocto-bsp/conf/machine/atom-pc.conf:IMAGE_FSTYPES ?= "ext3 cpio.gz
live"
I would think that += would be better here, I would welcome a patch!

scripts/lib/bsp/substrate/target/arch/mips/conf/machine/{{=machine}}.conf:IMAGE_FSTYPES
?= "jffs2 tar.bz2"
Looks like these followed the pattern of the base machine, but I think this
should be +=, a patch would be welcome!
ok, so those are the only cases that warrant tidying up? unless
there's an objection, i'll submit two patches, one for each of the
above.

rday

--

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

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


Re: Intel announces S1200 low power family, so when might we see a Yocto BSP....

Bodke, Kishore K <kishore.k.bodke@...>
 

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Tom Zanussi
Sent: Thursday, December 13, 2012 8:59 AM
To: Bob Cochran
Cc: Yocto discussion list
Subject: Re: [yocto] Intel announces S1200 low power family, so when might
we see a Yocto BSP....

On Thu, 2012-12-13 at 09:14 -0500, Bob Cochran wrote:
Hello,

As reported in Information Week (link below), Intel announced a new Atom
S1200 family for micro servers. I believe Yocto has applications for
this family of processors. Assuming this is true, when do we see a
Yocto BSP for this family?

I don't actually expect that there are plans already, but I'm assuming
the Intel team has a rough idea how long it takes to introduce a new BSP
for a new Atom family.

Any feedback will be greatly appreciated.
Hi Bob,

Let me check around and see if the Cedartrail guys have any plans for
this.

We can also accept new BSPs from anyone interested in submitting and
supporting one, which is another possibility...
Actually we have a Rangeley BSP, which will be hosted public early next year.
This is a micro server with Intel 2nd generation Atom.

Thanks
Kishore.


Re: per-image ROOTFS sizes

Saul Wold <sgw@...>
 

On 12/13/2012 05:03 AM, Robert P. J. Day wrote:
On Wed, 12 Dec 2012, Saul Wold wrote:

Some serious magic! It took me a while to reload my cache on this one.

All strapped in because here we go!

So you have selected the types of images you want to build by add
it's type to IMAGE_FSTYPES, of which you can have multiple types.
a minor nit but i used meta-yocto to configure for a beagle and used
bitbake-env to display the default value of IMAGE_FSTYPES:

$ bitbake-env IMAGE_FSTYPES
IMAGE_FSTYPES=" tar.bz2 jffs2"
$

so far, so good. but then i simply *assigned* (not added) in
local.conf:

IMAGE_FSTYPES = "vmdk"

and checked again ... ???

$ bitbake-env IMAGE_FSTYPES
IMAGE_FSTYPES="vmdk tar.bz2 jffs2"
$

um ... huh? which is explained by the following inconsistent
collection of assignments in poky:
Good catch, I think some make sense and other should be fixed.

$ grep -r "IMAGE_FSTYPES.*=" *
meta/conf/bitbake.conf:IMAGE_FSTYPES ?= "tar.gz"
Base assignment for default, of course it should ?=

meta/conf/machine/include/ia32-base.inc:IMAGE_FSTYPES += "ext3 cpio.gz live"
meta/conf/machine/include/qemu.inc:IMAGE_FSTYPES += "tar.bz2 ext3"
These make sense as += it allows the DISTRO and/or user to add more types.

meta/recipes-core/images/core-image-minimal-initramfs.bb:IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
initramfs will only need the cpio.gz there for set it directly

meta/recipes-core/images/build-appliance-image.bb:IMAGE_FSTYPES = "vmdk"
build appliance only needs 1 fs types so set it directly.

meta-yocto/conf/distro/poky-tiny.conf:IMAGE_FSTYPES = "ext2 cpio.gz"
again small custom image this is a DISTRO setting

meta-yocto-bsp/conf/machine/beagleboard.conf:IMAGE_FSTYPES += "tar.bz2 jffs2"
As the qemu and ia32 add correct fs types for beagleboard.

meta-yocto-bsp/conf/machine/routerstationpro.conf:IMAGE_FSTYPES ?= "jffs2 tar.bz2"
meta-yocto-bsp/conf/machine/atom-pc.conf:IMAGE_FSTYPES ?= "ext3 cpio.gz live"
I would think that += would be better here, I would welcome a patch!

scripts/lib/bsp/substrate/target/arch/mips/conf/machine/{{=machine}}.conf:IMAGE_FSTYPES ?= "jffs2 tar.bz2"
Looks like these followed the pattern of the base machine, but I think this should be +=, a patch would be welcome!


Sau!

scripts/lib/bsp/substrate/target/arch/arm/conf/machine/{{=machine}}.conf:IMAGE_FSTYPES += "tar.bz2 jffs2"
$

that appears to be a very confusing mix of "=" and "?=" and "+=".
is that really the effect you were going for?
rday


Re: Intel announces S1200 low power family, so when might we see a Yocto BSP....

Tom Zanussi <tom.zanussi@...>
 

On Thu, 2012-12-13 at 09:14 -0500, Bob Cochran wrote:
Hello,

As reported in Information Week (link below), Intel announced a new Atom
S1200 family for micro servers. I believe Yocto has applications for
this family of processors. Assuming this is true, when do we see a
Yocto BSP for this family?

I don't actually expect that there are plans already, but I'm assuming
the Intel team has a rough idea how long it takes to introduce a new BSP
for a new Atom family.

Any feedback will be greatly appreciated.
Hi Bob,

Let me check around and see if the Cedartrail guys have any plans for
this.

We can also accept new BSPs from anyone interested in submitting and
supporting one, which is another possibility...

Thanks,

Tom

Thanks,

Bob



http://www.informationweek.com/hardware/processors/intel-launches-low-power-atom-to-counter/240144257
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


AUTOREVing with legacy recipe fetching from cvs

Andrea Galbusera
 

In a custom layer I maintain, which is based on Yocto denzil, there is
a recipe that fetches sources from a cvs repository. Since there is
still some development of such a software, for testing reasons, I need
to be able to automate the generation of an image with the latest
revision of a given branch of such a repository (say a nightly build).

After reading the manual I understand that the ${AUTOREV} method is
not working with cvs. Is there an alternative approach to instruct the
fetcher to always perform an update/checkout from the repository?

At moment I can force re-fetching and re-building with:

bitbake -c cleansstate myrecipe && bitbake myrecipe

but I'm looking for a cleaner approach, if it does exist. The goal
being to simply run:

bitbake myimage

...and get the latest myrecipe sources fetched from cvs.

TIA,
Andrea


Re: bitbake user manual vs mega manual, and more info on local file fetcher?

Rifenbark, Scott M <scott.m.rifenbark@...>
 

Hey Robert,

Great questions... we are revising the BitBake manual as part of the YP 1.4 release. And, we are currently discussing exactly how to position it. So the answers to your questions are in the works.

Scott

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Robert P. J. Day
Sent: Thursday, December 13, 2012 6:09 AM
To: Yocto discussion list
Subject: [yocto] bitbake user manual vs mega manual, and more info on
local file fetcher?


first question -- is the bitbake user manual that comes bundled with
the bitbake source considered part of the yocto doc collection? as
in, if one wants detailed info on bitbake, does one read the bitbake
user manual (which is not mentioned on the yocto docs page), or is
bitbake user info assumed to now be scattered throughout the yocto
docs? i think it's important to identify the canonical location for
that documentation.

following on that, i'm asking since the bitbake user manual is
definitely a *little* deficient on info for the local file fetcher.
here's the sum total of its examples:

SRC_URI= "file://relativefile.patch"
SRC_URI= "file://relativefile.patch;this=ignored"
SRC_URI= "file:///Users/ich/very_important_software"

but there's no mention that (as i read it) that protocol accepts
wildcards:

meta-angstrom/recipes-angstrom/angstrom/angstrom-uboot-
scripts.bb:SRC_URI = "file://*.cmd"

i had no idea that was even true until i stumbled over the above (if
that's indeed what it means).

there's also no comprehensive coverage of how to define and use
patches in the yocto docs. the only mention i see is in the ref
manual, in the variable glossary under SRC_URI, which isn't even
complete (no mention of apply= or patchdir=).

so basic question -- is the bitbake user manual still under active
maintenance and is it considered part of the yocto docs collection?
since all that bitbake information should be *somewhere* but it's not
clear where.

rday


--

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


Intel announces S1200 low power family, so when might we see a Yocto BSP....

Bob Cochran
 

Hello,

As reported in Information Week (link below), Intel announced a new Atom S1200 family for micro servers. I believe Yocto has applications for this family of processors. Assuming this is true, when do we see a Yocto BSP for this family?

I don't actually expect that there are plans already, but I'm assuming the Intel team has a rough idea how long it takes to introduce a new BSP for a new Atom family.

Any feedback will be greatly appreciated.

Thanks,

Bob



http://www.informationweek.com/hardware/processors/intel-launches-low-power-atom-to-counter/240144257


bitbake user manual vs mega manual, and more info on local file fetcher?

Robert P. J. Day
 

first question -- is the bitbake user manual that comes bundled with
the bitbake source considered part of the yocto doc collection? as
in, if one wants detailed info on bitbake, does one read the bitbake
user manual (which is not mentioned on the yocto docs page), or is
bitbake user info assumed to now be scattered throughout the yocto
docs? i think it's important to identify the canonical location for
that documentation.

following on that, i'm asking since the bitbake user manual is
definitely a *little* deficient on info for the local file fetcher.
here's the sum total of its examples:

SRC_URI= "file://relativefile.patch"
SRC_URI= "file://relativefile.patch;this=ignored"
SRC_URI= "file:///Users/ich/very_important_software"

but there's no mention that (as i read it) that protocol accepts
wildcards:

meta-angstrom/recipes-angstrom/angstrom/angstrom-uboot-scripts.bb:SRC_URI = "file://*.cmd"

i had no idea that was even true until i stumbled over the above (if
that's indeed what it means).

there's also no comprehensive coverage of how to define and use
patches in the yocto docs. the only mention i see is in the ref
manual, in the variable glossary under SRC_URI, which isn't even
complete (no mention of apply= or patchdir=).

so basic question -- is the bitbake user manual still under active
maintenance and is it considered part of the yocto docs collection?
since all that bitbake information should be *somewhere* but it's not
clear where.

rday


--

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

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


Re: SRC_URI and appending and a "style guide"?

Robert P. J. Day
 

On Thu, 13 Dec 2012, Jerrod Peach wrote:

Robert,

For the specific topic of SRC_URI += vs. SRC_URI_append, I personally prefer the former over the latter, but I'm not an
expert by any means.
As for the topic of a style guide, such a thing already exists on the
Wiki: https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide.  That would be the obvious place to put such a
recommendation, if that is indeed the consensus.
oops, never mind that earlier comment, i just noticed that that page
encourages people to replace pnum= with striplevel=. definitely need
more sleep.

rday

--

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

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


Re: SRC_URI and appending and a "style guide"?

Robert P. J. Day
 

On Thu, 13 Dec 2012, Jerrod Peach wrote:

Robert,

For the specific topic of SRC_URI += vs. SRC_URI_append, I personally prefer the former over the latter, but I'm not an
expert by any means.
As for the topic of a style guide, such a thing already exists on the
Wiki: https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide.  That would be the obvious place to put such a
recommendation, if that is indeed the consensus.
heh. i just noticed that that wiki page still uses the old style of
"pnum=" as opposed to "striplevel=". no big deal. i'm just giddy
from not enough sleep.

but you're right -- that looks like the place, i didn't even realize
that existed.

rday

--

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

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


Re: SRC_URI and appending and a "style guide"?

Jerrod Peach <peachj@...>
 

Robert,

For the specific topic of SRC_URI += vs. SRC_URI_append, I personally prefer the former over the latter, but I'm not an expert by any means.

As for the topic of a style guide, such a thing already exists on the Wiki: https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide.  That would be the obvious place to put such a recommendation, if that is indeed the consensus.

Kind regards,

Jerrod


On Wed, Dec 12, 2012 at 3:12 PM, Robert P. J. Day <rpjday@...> wrote:

  it's a pedantry-laden day today so i'm going to continue to whine
about aesthetics.  what about a yocto style guide for coding style
recommendations?  for example, consider the variations:

poky/meta/recipes-support/libcroco/libcroco_0.6.3.bb:SRC_URI_append = " file://croco.patch;apply=yes \
poky/meta/recipes-support/attr/ea-acl.inc:SRC_URI += "file://relative-libdir.patch;striplevel=0 \
poky/meta/recipes-support/db/db_5.3.15.bb:SRC_URI += "file://arm-thumb-mutex_db5.patch;patchdir=.."
poky/meta/recipes-sato/leafpad/leafpad_0.8.18.1.bb:SRC_URI_append_poky = " file://owl-menu.patch;apply=yes "
poky/meta/recipes-sato/puzzles/oh-puzzles_git.bb:SRC_URI_append_poky = " file://oh-puzzles-owl-menu.patch;striplevel=0 "

  in the above, you have three different variations for appending to
SRC_URI.  i don't think it would be clear to a reader if there was any
difference between "+=" and "_append", other than that "_append"
forces you to add the space yourself while "+=" doesn't.  of course,
"_append_poky" is self-explanatory.

  so is there a *preferred* form for things like that?  is it written
down somewhere?  should it be?  just because it works for perl doesn't
always mean that "there's more than one way to do it" is a good idea.
:-)

rday

--

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


Re: per-image ROOTFS sizes

Robert P. J. Day
 

On Wed, 12 Dec 2012, Saul Wold wrote:

Some serious magic! It took me a while to reload my cache on this one.

All strapped in because here we go!

So you have selected the types of images you want to build by add
it's type to IMAGE_FSTYPES, of which you can have multiple types.
a minor nit but i used meta-yocto to configure for a beagle and used
bitbake-env to display the default value of IMAGE_FSTYPES:

$ bitbake-env IMAGE_FSTYPES
IMAGE_FSTYPES=" tar.bz2 jffs2"
$

so far, so good. but then i simply *assigned* (not added) in
local.conf:

IMAGE_FSTYPES = "vmdk"

and checked again ... ???

$ bitbake-env IMAGE_FSTYPES
IMAGE_FSTYPES="vmdk tar.bz2 jffs2"
$

um ... huh? which is explained by the following inconsistent
collection of assignments in poky:

$ grep -r "IMAGE_FSTYPES.*=" *
meta/conf/bitbake.conf:IMAGE_FSTYPES ?= "tar.gz"
meta/conf/machine/include/ia32-base.inc:IMAGE_FSTYPES += "ext3 cpio.gz live"
meta/conf/machine/include/qemu.inc:IMAGE_FSTYPES += "tar.bz2 ext3"
meta/recipes-core/images/core-image-minimal-initramfs.bb:IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
meta/recipes-core/images/build-appliance-image.bb:IMAGE_FSTYPES = "vmdk"
meta-yocto/conf/distro/poky-tiny.conf:IMAGE_FSTYPES = "ext2 cpio.gz"
meta-yocto-bsp/conf/machine/beagleboard.conf:IMAGE_FSTYPES += "tar.bz2 jffs2"
meta-yocto-bsp/conf/machine/routerstationpro.conf:IMAGE_FSTYPES ?= "jffs2 tar.bz2"
meta-yocto-bsp/conf/machine/atom-pc.conf:IMAGE_FSTYPES ?= "ext3 cpio.gz live"
scripts/lib/bsp/substrate/target/arch/mips/conf/machine/{{=machine}}.conf:IMAGE_FSTYPES ?= "jffs2 tar.bz2"
scripts/lib/bsp/substrate/target/arch/arm/conf/machine/{{=machine}}.conf:IMAGE_FSTYPES += "tar.bz2 jffs2"
$

that appears to be a very confusing mix of "=" and "?=" and "+=".
is that really the effect you were going for?

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


Re: [PATCH v3] [eclipse-poky-windows][branch:windows-build]Remove validate existing repository radio button

Zhang, Jessica
 

Hi Ioana,

I looked into the code and with the current implementation and your changes all of commands are execute via a BBSession->ShellSession's execute which has always been a synchronized function. The only difference is the current implementation, for each command it is using the local process and its output, as to your changes is via a remoteconnection helper. So the delay is caused by the output returned via the remote connection helper? If so, probably we need to look into why such a big different. Since I've been testing against local connection not even against a real remote connection yet. Or am I missing something here?

With the patch, we just shift the symptom since the project is still not fully utilized even though it shows up quickly.

Thanks,
Jessica

-----Original Message-----
From: Grigoropol, IoanaX
Sent: Wednesday, December 12, 2012 4:04 AM
To: Zhang, Jessica; yocto@...
Subject: RE: [yocto] [PATCH v3] [eclipse-poky-windows][branch:windows-build]Remove validate existing repository radio button

Hi Jessica,

I have sent a new patch that targets the downtime issue that you reported, against windows-build current branch.
The downtime that you noticed it is due to the fact that with the current implementation, the commands are ran synchronously, meaning that each command must wait for the previous one to finish.
In the past, this was done by creating a process for each command, and waiting for its output. At the moment, we have a shell per remote connection, and we need to know when a command has finished running.
In the case of the New Bitbake project, the downtime is caused by sourcing the environment, and retrieving the values outputted by "bitbake -e".
With the current patch, the output of this command, is silenced and the process is not blocking the new project wizard, but running in the background.
There is one scenario in which this implementation is not "safe", which is that where the user creates a new project from an existing directory, and soon after does some operation that uses the presumably already populated environment from bitbake, which may or may not be available, since it is sent in the background. One possible solution for this, is to show to the user that this operation is in progress, and he still needs to wait a bit for this to be done before performing any operations that might need this information.
What is your opinion on this matter?

Thanks,
Ioana

-----Original Message-----
From: Zhang, Jessica
Sent: Wednesday, December 12, 2012 12:44 AM
To: Grigoropol, IoanaX; yocto@...
Subject: RE: [yocto] [PATCH v3] [eclipse-poky-windows][branch:windows-build]Remove validate existing repository radio button

Hi Ioana,

I merged your patches up to this one to jzhang/windows-build branch of eclipse-poky. Please send out the final patches for Linux performance improvements that we've discussed. Also, many java files there's a comment section at the beginning, can you add some comments about your changes to those files? For example, plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/NewBitBakeFileRecipeWizardPage.java

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Ioana Grigoropol
Sent: Tuesday, December 11, 2012 6:04 AM
To: yocto@...
Subject: [yocto] [PATCH v3] [eclipse-poky-windows][branch:windows-build]Remove validate existing repository radio button

- remove radio button for validating existing repository but keep performing the validation in the back
- make 'clone' button a check button

Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@...>
---
.../yocto/bc/ui/wizards/install/OptionsPage.java | 30 ++++----------------
1 file changed, 6 insertions(+), 24 deletions(-)

diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
index 9e94aea..72aeec2 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/Option
+++ sPage.java
@@ -54,7 +54,6 @@ public class OptionsPage extends FiniteStateWizardPage {
private ValidationListener validationListener;
private Text txtProjectName;
private Button btnGit;
- private Button btnValidate;

private RemoteProjectContentsLocationArea locationArea;

@@ -67,7 +66,7 @@ public class OptionsPage extends FiniteStateWizardPage {
public void createControl(Composite parent) {
top = new Composite(parent, SWT.None);
top.setLayout(new GridLayout());
- top.setLayoutData(new GridData(GridData.FILL_BOTH));
+ top.setLayoutData(new GridData(GridData.FILL_HORIZONTAL));

GridData gdFillH = new GridData(GridData.FILL_HORIZONTAL);

@@ -97,25 +96,13 @@ public class OptionsPage extends FiniteStateWizardPage {

locationArea = new RemoteProjectContentsLocationArea(errorReporter, top, null);

- Group locationValidationGroup = new Group(top, SWT.NONE);
- locationValidationGroup.setText("Git repository");
- GridData gd = new GridData(GridData.VERTICAL_ALIGN_END | GridData.FILL_HORIZONTAL);
- locationValidationGroup.setLayoutData(gd);
- GridLayout gl = new GridLayout(1, false);
- locationValidationGroup.setLayout(gl);
-
- btnGit = new Button(locationValidationGroup, SWT.RADIO);
+ btnGit = new Button(top, SWT.CHECK);
btnGit.setText("Clone from Yocto Project &Git Repository into new location");
btnGit.setEnabled(true);
btnGit.setSelection(true);
btnGit.addSelectionListener(validationListener);
-
-
- btnValidate = new Button(locationValidationGroup, SWT.RADIO);
- btnValidate.setText("&Validate existing Git project location");
- btnValidate.setEnabled(true);
- btnValidate.setSelection(false);
- btnValidate.addSelectionListener(validationListener);
+ GridData gd = new GridData(GridData.VERTICAL_ALIGN_END | GridData.FILL_HORIZONTAL);
+ btnGit.setLayoutData(gd);

setControl(top);
}
@@ -165,16 +152,11 @@ public class OptionsPage extends FiniteStateWizardPage {
String projectPath = projectLoc + separator + getProjectName();
IHostFile repoDest = RemoteHelper.getRemoteHostFile(connection, projectPath, new NullProgressMonitor());

- if(btnValidate.getSelection()) {
+ if(!btnGit.getSelection()) {
if (repoDest == null || !repoDest.exists()) {
setErrorMessage("Directory " + projectPath + " does not exist, please select git clone.");
return false;
}
-// IHostFile gitDescr = RemoteHelper.getRemoteHostFile(connection, projectPath + "/.git", new NullProgressMonitor());
-// if (gitDescr == null || !gitDescr.exists()) {
-// setErrorMessage("Directory " + projectPath + " does not contain a git repository, please select git clone.");
-// return false;
-// }

IHostFile validationFile = RemoteHelper.getRemoteHostFile(connection, projectPath + URI_SEPARATOR + InstallWizard.VALIDATION_FILE, new NullProgressMonitor());
if (validationFile == null || !validationFile.exists()) { @@ -185,7 +167,7 @@ public class OptionsPage extends FiniteStateWizardPage {
if (repoDest.exists() && repoDest.isDirectory()) {
IHostFile gitDescr = RemoteHelper.getRemoteHostFile(connection, projectPath + "/.git", new NullProgressMonitor());
if (gitDescr != null && gitDescr.exists()) {
- setErrorMessage("Directory " + projectPath + " contains a repository, please select validate repository.");
+ setErrorMessage("Directory " + projectPath + " contains a
+repository, please choose another location or skip cloning the
+repository.");
return false;
}
}
--
1.7.9.5

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


Systemtap with Yocto Eclipse Plug-In

Björn Arnelid <Bjorn.Arnelid@...>
 

Hi,

I am trying to figure out how to use the systemtap tool in the Yocto Eclipse Plug-In.
Looking at the plugin it seems like i should compile a systemtap kernel module that i then could point out with my systemtap plugin.
The trouble is that i do not know how to do this, and i was not able to find any documentation on how to do it.

Could someone please point me to the right documentation page or explain how to do this?

regards,
Björn 


Re: per-image ROOTFS sizes

Saul Wold <sgw@...>
 

On 12/12/2012 03:16 PM, Robert P. J. Day wrote:
On Wed, 12 Dec 2012, Trevor Woerner wrote:

On Wed, Dec 12, 2012 at 3:46 PM, Robert P. J. Day <rpjday@...> wrote:
so what happens if you try to set the appropriate variables above?
When Yocto creates a VMDK, it creates 2 partitions:
- an MSDOS partition for the syslinux stuff
- the ext{3,4} partition of your root image

When it then shmushes these two together into 1 file, it has to make
sure all the sizes are set correctly as per the information in the
disk's partition table. That's what all these calculations are doing
(I recognize it from similar work in my own scripts).

Personally I have my own approach that can use either LILO or syslinux
for booting x86 (it can also create bootable ARM images with the
appropriate uboot/mlo); neither of the x86 solutions require a
separate MSDOS partition. Hopefully I'll find some time to examine how
Yocto is doing things and perhaps integrate my own findings into the
broader project(?).

(please see https://github.com/twoerner/qemu-image-builder)

I believe Yocto calculates the sizes (using IMAGE_ROOTFS_SIZE) from
code in poky/meta/classes/image_types.bbclass, which is also run for
the VMDK's calculations too.
and here's where i'm confused. i'm *assuming* that the
image-vmdk.bbclass file defines the creation of vmdk images, yes? but
that class file inherits directly only boot-directdisk.bbclass, and if
i look in that class file, i don't see any further inherits that might
process IMAGE_ROOTFS_SIZE. i just see hardcoded calculations that
build an image based on actual rootfs directory size.

so what am i missing?
Some serious magic! It took me a while to reload my cache on this one.

All strapped in because here we go!

So you have selected the types of images you want to build by add it's type to IMAGE_FSTYPES, of which you can have multiple types.

When the do_rootfs() is run for an image, there is a call into image_types.bbclass via the ${@get_imagecmds(d)}, which returns a list of cmds to execute to create the various images selected via the above IMAGE_FSTYPES. Of note here is that if vmdk or live is select, but not ext3 (soon to be ext4 we hope), then ext3 will be added to the types list, and vmdk and/or live will be removed.

in the get_imagecmds code, you can see that the OVERRIDES are updated locally to include the filesystem type, so that correct IMAGE_CMD can be selected via overrides and set into $cmd while the compressed version is set to $ccmd, then the runimagecmd is added to the cmds list (different than cmd, yes a little confusing).

runimagecmd is here the size computation occurs and the IMAGE_CMD is run via $cmd. Since we are not out side the get_imagecmds() context and do not have the localdata that set filesystem type overrides we won't seem them and beside runimagecmd will never get called for a vmdk or live image type! The underlying filesystem for those is the ext3 fs type.

Now that the rootfs has been created in the correct fs type (ext3) it mething to the TOTALSIZE and END3 computations in this code fragment:needs to be converted to vmdk, this is done via the image-vmdk.bbclass which is optionally inherited in image.bbclass. This class slips the do_vmdkimg() function after do_bootdirectdisk, which is needed to get the right disk leve partitioning. The image-vmdk.bbclass inherits boot-directdisk.bbclass to get it incorporated correctly. This is where Trevor correctly noted that that we are doing the multiple partition approach.

SO we cycle back to the initial question which is how to have 2 different sizes for ext3 vanilla images vs a fixed size for the vmdk, right now that's really hard! Since we create an ext3 (4) for including mething to the TOTALSIZE and END3 computations in this code fragment:into the vmdk, that's where the sizing occurs.

What I think you are asking for is create a default sized ext3 and then allow the partition to be resized in the boot-directdisk partitioning code, since that's where the extra space would get accounted for.

Possibly we could add something to the TOTALSIZE and END3 computations in this code fragment:

ROOTFSBLOCKS=`du -Lbks ${ROOTFS} | cut -f 1`
TOTALSIZE=`expr $BLOCKS + $ROOTFSBLOCKS`
END1=`expr $BLOCKS \* 1024`
END2=`expr $END1 + 512`
END3=`expr \( $ROOTFSBLOCKS \* 1024 \) + $END1`

That code feeds into the parted command, the dd that happens after that would have to change since we are dd'ing a ext3 and it does not know it has more space, this is the tricky part! More thought is required, maybe a single malt (yes I was jealous).

Anyway, I hope have I not thoroughly confused everyone at this point.


Sau!



rday


Re: per-image ROOTFS sizes

Robert P. J. Day
 

On Wed, 12 Dec 2012, Trevor Woerner wrote:

Hi Robert,

(we met at OLS last summer, I came and chatted with you briefly after
your presentation)

On Wed, Dec 12, 2012 at 5:03 PM, Robert P. J. Day <rpjday@...> wrote:
now i'm interested, so ... what are your config steps? i wouldn't
mind trying to reproduce this on my system.

My doodle layer can be found here:
https://github.com/twoerner/meta-trevor

My conf/bblayers.conf adds this and meta-openembedded/meta-oe.
My conf/local.conf currently looks like:

BB_NUMBER_THREADS = "4"
PARALLEL_MAKE = "-j 4"
MACHINE = "qemux86"
DL_DIR = "/home/trevor/devel/Downloads"
DISTRO = "poky"
PACKAGE_CLASSES = "package_ipk"
EXTRA_IMAGE_FEATURES = "debug-tweaks ssh-server-openssh"
USER_CLASSES = "buildstats image-mklibs image-prelink"
PATCHRESOLVE = "noop"

#
# Disk Space Monitoring during the build
#
# Monitor the disk space during the build. If there is less that
1GB of space or less
# than 100K inodes in any key build location (TMPDIR, DL_DIR,
SSTATE_DIR), gracefully
# shutdown the build. If there is less that 100MB or 1K inodes,
perform a hard abort
# of the build. The reason for this is that running completely out
of space can corrupt
# files and damages the build in ways which may not be easily recoverable.
BB_DISKMON_DIRS = "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K"

CONF_VERSION = "1"
BB_DANGLINGAPPENDS_WARNONLY = "yes"
IMAGE_FSTYPES = "vmdk"
IMAGE_ROOTFS_SIZE = "500000"

You can then either "bitbake bboverride" or "bitbake core-image-minimal".

To easily boot the resulting VMDK with qemu, you'll have to patch your
poky/scripts/runqemu and poky/scripts/runqemu-internal with my patch
here (unless by the time you read this, it has already been included):
https://lists.yoctoproject.org/pipermail/yocto/2012-December/013279.html

and then run:
$ runqemu tmp/deploy/images/<image>.vmdk

Currently I can't think of any nice/easy way to _flexibly_ specify the
eth0 IP address of the vmdk image, but the runqemu script does setup
your local tap interface for 192.168.7.1/24 as expected. You can then
manually configure eth0 once the VM boots and/or setup
'/etc/network/interfaces'.
i'll check all this out, either this eve or tomorrow. probably
tomorrow since i'm well into a bottle of 10-YO single malt ardbeg at
the moment. you're jealous. i know you are.

rday

--

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

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


Re: per-image ROOTFS sizes

Robert P. J. Day
 

On Wed, 12 Dec 2012, Trevor Woerner wrote:

On Wed, Dec 12, 2012 at 3:46 PM, Robert P. J. Day <rpjday@...> wrote:
so what happens if you try to set the appropriate variables above?
When Yocto creates a VMDK, it creates 2 partitions:
- an MSDOS partition for the syslinux stuff
- the ext{3,4} partition of your root image

When it then shmushes these two together into 1 file, it has to make
sure all the sizes are set correctly as per the information in the
disk's partition table. That's what all these calculations are doing
(I recognize it from similar work in my own scripts).

Personally I have my own approach that can use either LILO or syslinux
for booting x86 (it can also create bootable ARM images with the
appropriate uboot/mlo); neither of the x86 solutions require a
separate MSDOS partition. Hopefully I'll find some time to examine how
Yocto is doing things and perhaps integrate my own findings into the
broader project(?).

(please see https://github.com/twoerner/qemu-image-builder)

I believe Yocto calculates the sizes (using IMAGE_ROOTFS_SIZE) from
code in poky/meta/classes/image_types.bbclass, which is also run for
the VMDK's calculations too.
and here's where i'm confused. i'm *assuming* that the
image-vmdk.bbclass file defines the creation of vmdk images, yes? but
that class file inherits directly only boot-directdisk.bbclass, and if
i look in that class file, i don't see any further inherits that might
process IMAGE_ROOTFS_SIZE. i just see hardcoded calculations that
build an image based on actual rootfs directory size.

so what am i missing?

rday

--

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

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


Re: per-image ROOTFS sizes

Trevor Woerner
 

Hi Robert,

(we met at OLS last summer, I came and chatted with you briefly after
your presentation)

On Wed, Dec 12, 2012 at 5:03 PM, Robert P. J. Day <rpjday@...> wrote:
now i'm interested, so ... what are your config steps? i wouldn't
mind trying to reproduce this on my system.

My doodle layer can be found here:
https://github.com/twoerner/meta-trevor

My conf/bblayers.conf adds this and meta-openembedded/meta-oe.
My conf/local.conf currently looks like:

BB_NUMBER_THREADS = "4"
PARALLEL_MAKE = "-j 4"
MACHINE = "qemux86"
DL_DIR = "/home/trevor/devel/Downloads"
DISTRO = "poky"
PACKAGE_CLASSES = "package_ipk"
EXTRA_IMAGE_FEATURES = "debug-tweaks ssh-server-openssh"
USER_CLASSES = "buildstats image-mklibs image-prelink"
PATCHRESOLVE = "noop"

#
# Disk Space Monitoring during the build
#
# Monitor the disk space during the build. If there is less that
1GB of space or less
# than 100K inodes in any key build location (TMPDIR, DL_DIR,
SSTATE_DIR), gracefully
# shutdown the build. If there is less that 100MB or 1K inodes,
perform a hard abort
# of the build. The reason for this is that running completely out
of space can corrupt
# files and damages the build in ways which may not be easily recoverable.
BB_DISKMON_DIRS = "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K"

CONF_VERSION = "1"
BB_DANGLINGAPPENDS_WARNONLY = "yes"
IMAGE_FSTYPES = "vmdk"
IMAGE_ROOTFS_SIZE = "500000"

You can then either "bitbake bboverride" or "bitbake core-image-minimal".

To easily boot the resulting VMDK with qemu, you'll have to patch your
poky/scripts/runqemu and poky/scripts/runqemu-internal with my patch
here (unless by the time you read this, it has already been included):
https://lists.yoctoproject.org/pipermail/yocto/2012-December/013279.html

and then run:
$ runqemu tmp/deploy/images/<image>.vmdk

Currently I can't think of any nice/easy way to _flexibly_ specify the
eth0 IP address of the vmdk image, but the runqemu script does setup
your local tap interface for 192.168.7.1/24 as expected. You can then
manually configure eth0 once the VM boots and/or setup
'/etc/network/interfaces'.


Re: per-image ROOTFS sizes

Robert P. J. Day
 

On Wed, 12 Dec 2012, Trevor Woerner wrote:

On Wed, Dec 12, 2012 at 3:46 PM, Robert P. J. Day <rpjday@...> wrote:
so what happens if you try to set the appropriate variables above?
When Yocto creates a VMDK, it creates 2 partitions:
- an MSDOS partition for the syslinux stuff
- the ext{3,4} partition of your root image

When it then shmushes these two together into 1 file, it has to make
sure all the sizes are set correctly as per the information in the
disk's partition table. That's what all these calculations are doing
(I recognize it from similar work in my own scripts).

Personally I have my own approach that can use either LILO or syslinux
for booting x86 (it can also create bootable ARM images with the
appropriate uboot/mlo); neither of the x86 solutions require a
separate MSDOS partition. Hopefully I'll find some time to examine how
Yocto is doing things and perhaps integrate my own findings into the
broader project(?).

(please see https://github.com/twoerner/qemu-image-builder)

I believe Yocto calculates the sizes (using IMAGE_ROOTFS_SIZE) from
code in poky/meta/classes/image_types.bbclass, which is also run for
the VMDK's calculations too.
now i'm interested, so ... what are your config steps? i wouldn't
mind trying to reproduce this on my system.

rday

--

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

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