Re: [yocto] How to include static library and headers in sdk
On Monday 22 September 2014 18:57:03 Matt Schuckmann wrote: I've got a custom image and 2 custom recipes both very simple libraries that use cmake. I included the libraries into my image by adding EXTRA_IMAGEDEPENDS += simple1 EXTRA_IMAGEDEPENDS += simple2 To my image recipe. Except this doesn't actually add those things into your image, it only ensures they are built alongside it. To actually add them to the image you need to ensure you add them to IMAGE_INSTALL; see: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage When I build my image (i.e. bitbake custom-image ) I can see that the library header files and .a files are placed in the correct place in the sysroot directory. However when I try to create an sdk (i.e. bitbake custom-image -c populate_sdk) and then install the SDK the headers and .a files are nowhere to be found in the installed sysroot. If you want all -staticdev packages in the SDK for the libraries in your image, add the following to your local.conf (or the image recipe, doesn't matter which): SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs staticdev-pkgs If you want a single staticdev package in the SDK you'd need to add the following instead: TOOLCHAIN_HOST_TASK_append = simple1-staticdev Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/5] spdx.bbclass:Add SPDX-specific source tree variable.
Add SPDX-specific source tree variable for recipes where $S is a subdirectory
of the source tree.
Signed-off-by: leimaohui leimao...@cn.fujitsu.com
---
meta/classes/spdx.bbclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/classes/spdx.bbclass b/meta/classes/spdx.bbclass
index 55ce3af..27169f0 100644
--- a/meta/classes/spdx.bbclass
+++ b/meta/classes/spdx.bbclass
@@ -18,13 +18,15 @@
SPDXOUTPUTDIR = ${WORKDIR}/spdx_output_dir
SPDXSSTATEDIR = ${WORKDIR}/spdx_sstate_dir
+SPDX_S ?= ${S}
+
python do_spdx () {
import os, sys
import json
info = {}
info['workdir'] = (d.getVar('WORKDIR', True) or )
-info['sourcedir'] = (d.getVar('S', True) or )
+info['sourcedir'] = (d.getVar('SPDX_S', True) or )
info['pn'] = (d.getVar( 'PN', True ) or )
info['pv'] = (d.getVar( 'PV', True ) or )
info['src_uri'] = (d.getVar( 'SRC_URI', True ) or )
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 5/5] squashfs-tools_4.3: modify SPDX_S variable
Modify SPDX_S to the source tree of squashfs instead of ${S}.
Signed-off-by: leimaohui leimao...@cn.fujitsu.com
---
meta/recipes-devtools/squashfs-tools/squashfs-tools_4.3.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/squashfs-tools/squashfs-tools_4.3.bb
b/meta/recipes-devtools/squashfs-tools/squashfs-tools_4.3.bb
index e3783fd..d36f0fe 100644
--- a/meta/recipes-devtools/squashfs-tools/squashfs-tools_4.3.bb
+++ b/meta/recipes-devtools/squashfs-tools/squashfs-tools_4.3.bb
@@ -19,6 +19,7 @@ SRC_URI[lzma.md5sum] = 29d5ffd03a5a3e51aef6a74e9eafb759
SRC_URI[lzma.sha256sum] =
c935fd04dd8e0e8c688a3078f3675d699679a90be81c12686837e0880aa0fa1e
S = ${WORKDIR}/squashfs${PV}/squashfs-tools
+SPDX_S = ${WORKDIR}/squashfs${PV}
# EXTRA_OEMAKE is typically: -e MAKEFLAGS=
# the -e causes problems as CFLAGS is modified in the Makefile, so
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 4/5] icu.inc: modify SPDX_S variable
Modify SPDX_S to the source tree of icu instead of ${S}.
Signed-off-by: leimaohui leimao...@cn.fujitsu.com
---
meta/recipes-support/icu/icu.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-support/icu/icu.inc b/meta/recipes-support/icu/icu.inc
index 7732107..15d002d 100644
--- a/meta/recipes-support/icu/icu.inc
+++ b/meta/recipes-support/icu/icu.inc
@@ -7,6 +7,7 @@ DEPENDS = icu-native
DEPENDS_class-native =
S = ${WORKDIR}/icu/source
+SPDX_S = ${WORKDIR}/icu
STAGING_ICU_DIR_NATIVE = ${STAGING_DATADIR_NATIVE}/${BPN}/${PV}
PARALLEL_MAKE =
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Forcing fetch task when source changes
Perhaps I misunderstood your suggestion or I am missing
something obvious, but this doesn't work either.
If I point to my source with SRC_URI, the source does get
copied over to ${S} but changing the source doesn't trigger
a new fetch/unpack.
This is cleaner than what I was doing, but doesn't address
my issue of having to manually force a fetch/unpack every
time the source changes.
Perhaps due to my old versions: Poky 1.2 and bitbake 1.15.1?
MV
-Original Message-
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: September 22, 2014 7:34 AM
To: Vuille, Martin (Martin)
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Forcing fetch task when source changes
On 22 September 2014 12:25, Vuille, Martin (Martin) vmar...@avaya.com
wrote:
I have defined a class with a customized fetch task (that
copies files from a local read-only directory to the ${S}
directory).
I am looking for a way to cause the fetch task to run
again whenever the contents of the local directory
change w.r.t. what was last fetched/copied to ${S}.
Why not just use local URIs in the SRC_URI:
SRC_URI=file:///home/foo/bar/flob.c
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Forcing fetch task when source changes
On 23 September 2014 13:46, Vuille, Martin (Martin) vmar...@avaya.com wrote: Perhaps due to my old versions: Poky 1.2 and bitbake 1.15.1? Yes. http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/conf/bitbake.conf?id=eaf54b8dbf9371965b4ccf18609edeb8eee16144 is where the hashing was introduced to rebuild automatically when inputs change, but that landed in 1.3 onwards. The support was there in 1.2 so you could try setting BB_SIGNATURE_HANDLER in your distribution configuration to see if it works... Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Forcing fetch task when source changes
I was afraid of that... Another good reason to upgrade. Will try the work-around. Thanks again! MV -Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: September 23, 2014 9:33 AM To: Vuille, Martin (Martin) Cc: yocto@yoctoproject.org Subject: Re: [yocto] Forcing fetch task when source changes On 23 September 2014 13:46, Vuille, Martin (Martin) vmar...@avaya.com wrote: Perhaps due to my old versions: Poky 1.2 and bitbake 1.15.1? Yes. http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/conf/bitbake.conf?i d=eaf54b8dbf9371965b4ccf18609edeb8eee16144 is where the hashing was introduced to rebuild automatically when inputs change, but that landed in 1.3 onwards. The support was there in 1.2 so you could try setting BB_SIGNATURE_HANDLER in your distribution configuration to see if it works... Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, September 9, 2014 8:00 AM US Pacific Time
Attendees: Armin, Stephen, Joe, Alex V., Paul, Tom, Belen, Ross, Matthew, Bruce, Michael, Alex, Richard, Saul, Benjamin, Anibal, Sona, * Opens collection - 5 min (Stephen) * Yocto Project status - 5 min (Stephen/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.7_Status https://wiki.yoctoproject.org/wiki/Yocto_1.7_Schedule https://wiki.yoctoproject.org/wiki/Yocto_1.7_Features YP 1.7 M3 rc2 is ready for release - to be released this week. We are in m4 the stabilization milestone for 1.7. 1.7 is on track for October release. YP 1.6.2 will be release shortly after 1.7 is completed YP 1.5.4 will be release shortly after 1.7 is completed Beginning planning for 1.8 - If there are features you would like to have or contribute, get enhancement bug requests into bugzilla for them. * SWAT team rotation: Nitin - Beth https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team * Opens - 10 min Richard - There have been changes to the tool chain/SDK/ADT environment scripts to fix bugs, testing in that area would be appreciated * Team Sharing - 10 min Michael - Doing some server work today. It shouldn't interfere with anything. Sona - Willing to help on Security for Yocto. Would like to contribute Yocto. Suggestions are welcome on where to help. Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * Work Telephone: (503) 712-0534 *Cell:(208) 244-4460 * Email: stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Forcing fetch task when source changes
Very odd. Our BSP vendor has configured BB_SIGNATURE_HANDLER to use OEBasicHash, I see hashes in the stamp file names, if I change the metadata itself the change is detected and the tasks are run again, but changing the content of a file named in a file:// SRC_URI has no effect. Any ideas? MV -Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: September 23, 2014 9:33 AM To: Vuille, Martin (Martin) Cc: yocto@yoctoproject.org Subject: Re: [yocto] Forcing fetch task when source changes On 23 September 2014 13:46, Vuille, Martin (Martin) vmar...@avaya.com wrote: Perhaps due to my old versions: Poky 1.2 and bitbake 1.15.1? Yes. http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/conf/bitbake.conf?i d=eaf54b8dbf9371965b4ccf18609edeb8eee16144 is where the hashing was introduced to rebuild automatically when inputs change, but that landed in 1.3 onwards. The support was there in 1.2 so you could try setting BB_SIGNATURE_HANDLER in your distribution configuration to see if it works... Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Specified toolchain directory does not contain a toolchain generated with meta-ide-support.
Ok, after much strife, here's what I've gotten working. I installed the Plugin via Install New Software through Eclipse: 1. While configuring the ADT Plugin for Eclipse, instead of Build system derived toolchain I select Standalone Pre-Built Toolchain. 2. Instead of BUILD as the top directory, I use build/tmp (the location of the environment-setup script that gets created with bitbake meta-ide-support) 3. Open Eclipse in a shell where I've already sourced that environment-setup script -- not sure if that's actually necessary. Thanks to everyone for their help.. hope this helps someone else! On Fri, Sep 12, 2014 at 9:15 PM, Bob Cochran yo...@mindchasers.com wrote: I hope one of the Intel ADT developers will jump in to help you out. Here are a few other long shots (things that I'm doing, and it works good for me): i) Make sure you set your environment before you start eclipse. In other words, invoke eclipse from a shell with the proper paths set up. ii) Use at least Poky 1.6 (I'm currently using master with success). iii) Use the pre-built plugin There's also an ADT installer script, but I have never tried it. I do everything working from git build everything from scratch (except the Yocto ADT Eclipse plugin). Good luck! Bob On 09/12/2014 08:57 PM, Nemicolopterus Crypticus wrote: Yes - I can source the script, and I do successfully get my path updated. That's unfortunate. I can run the toolchain on the command line, but the developers I am working with need to use Eclipse. The plug-in seems like the right solution, so I would very much like to get this to work. It occurred to me that these issues might be because I'm using an older version of bitbake: $ bitbake --version BitBake Build Tool Core version 1.20.0, bitbake version 1.20.0 Could that have something to do with the failure? On Fri, Sep 12, 2014 at 12:24 PM, Bob Cochran yo...@mindchasers.com mailto:yo...@mindchasers.com wrote: On 09/12/2014 12:57 PM, Nemicolopterus Crypticus wrote: Just double checking that you are specifying the toolchain root location as your top level build directory (the one above /conf/local.conf - the directory where you run bitbake). Yes that occurred to me too, since the phrasing is a bit unclear. I tried both. Here's a depiction of my directory structure: oe-core | build | conf (including local.conf) | downloads | tmp-eglibc | environment-setup-blahblah | etc. | etcc | bitbake | gcc-toolchain | meta | etc. lots more I tried with the root at build, and in build/tmp-eglibc with no luck. Is it possible the toolchain didn't get built? What happens when you source your environment script? You should have your path set up to find your cross toolchain. If that's the case, you should be able to run the toolchain on the command line. I work with the powerpc toolchain, so I can cross-compile a simple test app after sourcing my env script: powerpc64-poky-linux-gcc main.c -o tst and verify I have generated a 64-bit powerpc ELF executable with file tst I'm just wondering since that's what the error claims. Is there any way to confirm that the toolchain did indeed get built? I ran bitbake meta-ide-toolchain, but our system is large and I'm not familiar with every aspect of it. Is it possible some other settings elsewhere got changed in a way that would prevent the toolchain from building? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to include static library and headers in sdk
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: Tuesday, September 23, 2014 2:10 AM
To: Matt Schuckmann
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to include static library and headers in sdk
On Monday 22 September 2014 18:57:03 Matt Schuckmann wrote:
I've got a custom image and 2 custom recipes both very simple
libraries that use cmake. I included the libraries into my image by
adding EXTRA_IMAGEDEPENDS += simple1
EXTRA_IMAGEDEPENDS += simple2
To my image recipe.
Except this doesn't actually add those things into your image, it only
ensures they are built alongside it. To actually add them to the image
you need to ensure you add them to IMAGE_INSTALL; see:
If I add my simple1 and simple2 recipes to IMAGE_INSTALL I get the following
error in the do_rootfs task:
* opkg_install_cmd: Cannot install package simple1.
I assumed that this is because there really is nothing to install in the image
as this is a static library with nothing that should go in the image.
http://www.yoctoproject.org/docs/current/dev-manual/dev-
manual.html#usingpoky-extend-customimage
When I build my image (i.e. bitbake custom-image ) I can see that the
library header files and .a files are placed in the correct place in
the sysroot directory.
However when I try to create an sdk (i.e. bitbake custom-image -c
populate_sdk) and then install the SDK the headers and .a files are
nowhere to be found in the installed sysroot.
If you want all -staticdev packages in the SDK for the libraries in
your image, add the following to your local.conf (or the image recipe,
doesn't matter which):
SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs staticdev-pkgs
If you want a single staticdev package in the SDK you'd need to add the
following instead:
TOOLCHAIN_HOST_TASK_append = simple1-staticdev
Again if I try adding this to my image recipe I get a similar error
* opkg_install_cmd: Cannot install package simple1-staticdev.
For reference here is my simple1 recipe, maybe I'm missing something in there.
DESCRIPTION = Simple library 1.
LICENSE = CLOSED
LIC_FILES_CHKSUM =
SRC_URI = git://g...@gitlab.work.net/libs/simple1.git;protocol=ssh
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
inherit pkgconfig cmake
Thanks,
Matt S.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 09/13] ProvisionGoogleVM.py: Fix metadata's input name.
From: California Sullivan california.l.sulli...@intel.com Signed-off-by: California Sullivan california.l.sulli...@intel.com --- lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py b/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py index cd35759..e7f488f 100644 --- a/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py @@ -65,7 +65,7 @@ class ProvisionGoogleVM(ShellCommand): if self.startupscript is not None and self.startupscript != : self.command += --metadata-from-file startup-script=+YOCTO_ABBASE+/bin/+self.startupscript if self.metadata is not None and self.metadata != : -self.command += --metadata + self.scriptargs +self.command += --metadata + self.metadata self.command += 1 /dev/null; # Timeout needs to be passed to LoggingBuildStep as a kwarg -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 10/13] DeleteGoogleVM.py: Rename to DeleteGoogleVMs.py
From: California Sullivan california.l.sulli...@intel.com It can delete multiple at once if multiple were created at once. Signed-off-by: California Sullivan california.l.sulli...@intel.com --- .../autobuilder/buildsteps/DeleteGoogleVM.py | 52 -- .../autobuilder/buildsteps/DeleteGoogleVMs.py | 52 ++ 2 files changed, 52 insertions(+), 52 deletions(-) delete mode 100644 lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVM.py create mode 100644 lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVMs.py diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVM.py b/lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVM.py deleted file mode 100644 index 29b45a4..000 --- a/lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVM.py +++ /dev/null @@ -1,52 +0,0 @@ -''' -Created on Aug 13, 2014 - -__author__ = California Sullivan -__copyright__ = Copyright 2014, Intel Corp. -__credits__ = [California Sullivan] -__license__ = GPL -__version__ = 2.0 -__maintainer__ = Elizabeth Flanagan -__email__ = elizabeth.flana...@intel.com -''' - -from buildbot.steps.shell import ShellCommand - -class DeleteGoogleVM(ShellCommand): -haltOnFailure = True -flunkOnFailure = True -name = Delete Google VM -def __init__(self, factory, argdict=None, **kwargs): - -self.factory = factory -self.description = Deleting Google VMs -for k, v in argdict.iteritems(): -if type(v) is bool: -setattr(self, k, str(v)) -else: -setattr(self, k, v) -# Timeout needs to be passed to LoggingBuildStep as a kwarg -self.timeout = 1000 -kwargs['timeout']=self.timeout -ShellCommand.__init__(self, **kwargs) - - -def start(self): -self.vmnames = self.getProperty(vmnames) -self.vmcount = self.getProperty(vmcount) -self.zone = self.getProperty(zone) - -if self.vmnames is not None and self.vmnames != : -self.command = gcloud compute instances delete -self.command += + self.vmnames - -if self.zone is not None and self.zone in [us-central1-a, us-central1-b, us-central1-f, europe-west1-a, europe-west1-b, asia-east1-a, asia-east1-b, asia-east1-b]: -self.command += --zone + self.zone -else: -self.command += --zone us-central1-a -self.command += --quiet -ShellCommand.start(self) - -def describe(self, done=False): -description = ShellCommand.describe(self,done) -return description diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVMs.py b/lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVMs.py new file mode 100644 index 000..b0071cf --- /dev/null +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVMs.py @@ -0,0 +1,52 @@ +''' +Created on Aug 13, 2014 + +__author__ = California Sullivan +__copyright__ = Copyright 2014, Intel Corp. +__credits__ = [California Sullivan] +__license__ = GPL +__version__ = 2.0 +__maintainer__ = Elizabeth Flanagan +__email__ = elizabeth.flana...@intel.com +''' + +from buildbot.steps.shell import ShellCommand + +class DeleteGoogleVMs(ShellCommand): +haltOnFailure = True +flunkOnFailure = True +name = Delete Google VMs +def __init__(self, factory, argdict=None, **kwargs): + +self.factory = factory +self.description = Deleting Google VMs +for k, v in argdict.iteritems(): +if type(v) is bool: +setattr(self, k, str(v)) +else: +setattr(self, k, v) +# Timeout needs to be passed to LoggingBuildStep as a kwarg +self.timeout = 1000 +kwargs['timeout']=self.timeout +ShellCommand.__init__(self, **kwargs) + + +def start(self): +self.vmnames = self.getProperty(vmnames) +self.vmcount = self.getProperty(vmcount) +self.zone = self.getProperty(zone) + +if self.vmnames is not None and self.vmnames != : +self.command = gcloud compute instances delete +self.command += + self.vmnames + +if self.zone is not None and self.zone in [us-central1-a, us-central1-b, us-central1-f, europe-west1-a, europe-west1-b, asia-east1-a, asia-east1-b, asia-east1-b]: +self.command += --zone + self.zone +else: +self.command += --zone us-central1-a +self.command += --quiet +ShellCommand.start(self) + +def describe(self, done=False): +description = ShellCommand.describe(self,done) +return description -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 12/13] REAMDE-GOOGLE-CLOUD: Update documentation to be more specific.
From: California Sullivan california.l.sulli...@intel.com
Signed-off-by: California Sullivan california.l.sulli...@intel.com
---
README-GOOGLE-CLOUD | 46 ++
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/README-GOOGLE-CLOUD b/README-GOOGLE-CLOUD
index 30bf5b6..34c80a9 100644
--- a/README-GOOGLE-CLOUD
+++ b/README-GOOGLE-CLOUD
@@ -6,7 +6,7 @@ limitations.
First of all, Google's gcloud command line tool is required for
all functions (see https://developers.google.com/cloud/sdk/gcloud/).
-Next, the controller system is required to be authenticated with Google's cloud
+Next, the controller machine is required to be authenticated with Google's
cloud
system (see https://developers.google.com/cloud/sdk/gcloud/reference/auth/).
Third, the workers must be on a network which has the worker port
@@ -21,19 +21,29 @@ gcloud compute firewall-rules autobuilder-allow --network
autobuilder-network \
This sets up a network that is suitable for both controllers and workers, as
it allows all default autobuilder connections, as well as ssh and http. The
key:value pair 'network':'autobuilder-network' can then be added to your
-ProvisionGoogleVM buildstep for use.
+ProvisionGoogleVMs buildstep, allowing provisioned machines to connect to
+controllers.
Fourth, additional workers must be added to yocto-controller/controller.cfg
with the format:
BuildWorker(workerN, WORKER-PASSWORD, max_builds=3)
where N is 0...however many workers you want and WORKER-PASSWORD is the default
-password.
+password. For example, if I wanted to add three workers for the cloud builder:
+
+c['workers'] = [BuildWorker(example-worker, eeieHim8V, max_builds=3),]
+
+would be changed to this:
+
+c['workers'] = [BuildWorker(example-worker, eeieHim8V, max_builds=3),
+BuildWorker(worker0, eeieHim8V, max_builds=3),
+BuildWorker(worker1, eeieHim8V, max_builds=3),
+BuildWorker(worker2, eeieHim8V, max_builds=3),]
Finally, the worker-init script is only an example and has a couple
-limitations. It has only been tested for debian VMs and will likely not work
-on others. Also, the HOST_ADDR and PASS fields will need to be manually
-edited in it if your autobuilder was created before the addition of the
-GoogleVM buildsteps or if the controller machine is behind a firewall.
+limitations itself. It has only been tested for debian VMs and will likely not
+work on others. Also, the HOST_ADDR and PASS fields will need to be
+manually edited in it if your autobuilder was created before the addition of
+the GoogleVM buildsteps or if the controller machine is behind a firewall.
HowTo
--
@@ -41,14 +51,18 @@ HowTo
Assuming that the limitations above have been dealt with, this will provision
one new VM and completely set it up, including connections
-{'ProvisionGoogleVM':{
-'vmname':'autobuilder-worker-startup-test',
-'vmcount':1,
-'zone':'us-central1-a',
-'machine':'n1-standard-4',
-'disksize':'230GB',
-'startupscript':'/home/autobuilder/yocto-autobuilder/bin/worker-init',
-'network':'autobuilder-network'}}
+{'ProvisionGoogleVMs':{
+'vmname':'autobuilder-worker-startup-test',
+'vmcount':1,
+'zone':'us-central1-a',
+'machine':'n1-standard-4',
+'disksize':'230GB',
+'startupscript':'/path/to/yocto-autobuilder/bin/worker-init',
+'network':'autobuilder-network'}}
+
+And this will delete the entire VM when you are finished with it:
+{'DeleteGoogleVMs': {}}
-{'DeleteGoogleVM': {}}
+Note that the current implementation of DeleteGoogleVM requires that its in the
+same buildset as CreateGoogleVM.
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 13/13] ProvisionGoogleVMs.py: Delete VM before trying to provision it.
From: California Sullivan california.l.sulli...@intel.com In the case that somebody turned off a build before it completed, the buildstep would attempt and fail to procure a new VM, failing the build. Signed-off-by: California Sullivan california.l.sulli...@intel.com --- .../autobuilder/buildsteps/ProvisionGoogleVMs.py | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVMs.py b/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVMs.py index d0bc6eb..262526f 100644 --- a/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVMs.py +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVMs.py @@ -19,6 +19,7 @@ class ProvisionGoogleVMs(ShellCommand): name = Provision Google VMs def __init__(self, factory, argdict=None, **kwargs): self.vmname=None +self.vmnames= self.vmcount=1 self.startupscript=None self.metadata=None @@ -38,15 +39,18 @@ class ProvisionGoogleVMs(ShellCommand): if self.vmname is None or self.vmname == : self.finished(FAILURE) else: -self.command = gcloud compute instances create -self.vmnames = +self.command = +if self.zone is None or self.zone not in [us-central1-a, us-central1-b, us-central1-f, europe-west1-a, europe-west1-b, asia-east1-a, asia-east1-b, asia-east1-b]: +self.zone = us-central1-a for x in range(0, self.vmcount): self.vmnames += + self.vmname + - + str(x) +self.command += gcloud compute instances delete self.command += self.vmnames -if self.zone is not None and self.zone in [us-central1-a, us-central1-b, us-central1-f, europe-west1-a, europe-west1-b, asia-east1-a, asia-east1-b, asia-east1-b]: -self.command += --zone + self.zone -else: -self.command += --zone us-central1-a +self.command += --zone + self.zone + --quiet; +self.command += gcloud compute instances create +self.command += self.vmnames +self.command += --zone + self.zone + if self.disksize is not None and self.disksize != : self.command += --boot-disk-size + self.disksize else: -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to include static library and headers in sdk
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: Tuesday, September 23, 2014 9:54 AM
To: Matt Schuckmann
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to include static library and headers in sdk
On Tuesday 23 September 2014 09:43:55 Matt Schuckmann wrote:
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: Tuesday, September 23, 2014 2:10 AM
To: Matt Schuckmann
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to include static library and headers in
sdk
On Monday 22 September 2014 18:57:03 Matt Schuckmann wrote:
I've got a custom image and 2 custom recipes both very simple
libraries that use cmake. I included the libraries into my image
by adding EXTRA_IMAGEDEPENDS += simple1
EXTRA_IMAGEDEPENDS += simple2
To my image recipe.
Except this doesn't actually add those things into your image, it
only ensures they are built alongside it. To actually add them to
the image
you need to ensure you add them to IMAGE_INSTALL; see:
If I add my simple1 and simple2 recipes to IMAGE_INSTALL I get the
following error in the do_rootfs task: * opkg_install_cmd: Cannot
install package simple1.
I assumed that this is because there really is nothing to install in
the image as this is a static library with nothing that should go in
the image.
http://www.yoctoproject.org/docs/current/dev-manual/dev-
manual.html#usingpoky-extend-customimage
When I build my image (i.e. bitbake custom-image ) I can see that
the library header files and .a files are placed in the correct
place in the sysroot directory.
However when I try to create an sdk (i.e. bitbake custom-image -c
populate_sdk) and then install the SDK the headers and .a files
are nowhere to be found in the installed sysroot.
If you want all -staticdev packages in the SDK for the libraries in
your image, add the following to your local.conf (or the image
recipe,
doesn't matter which):
SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs staticdev-pkgs
If you want a single staticdev package in the SDK you'd need to add
the
following instead:
TOOLCHAIN_HOST_TASK_append = simple1-staticdev
Again if I try adding this to my image recipe I get a similar error
* opkg_install_cmd: Cannot install package simple1-staticdev.
For reference here is my simple1 recipe, maybe I'm missing something
in there.
DESCRIPTION = Simple library 1.
LICENSE = CLOSED
LIC_FILES_CHKSUM =
SRC_URI = git://g...@gitlab.work.net/libs/simple1.git;protocol=ssh
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
inherit pkgconfig cmake
So is your recipe actually producing any packages at all? i.e. are any
of the directories under packages-split within the workdir for the
recipe non-empty?
At the moment it looks like it isn't producing anything.
Yes the simple1-dev directory contains the include files and the library file
under usr/include and usr/lib respectively.
The simple1-staticdev directory contains only the library file under usr/lib.
My understanding, limited as it is, is that the cmake class handles identifying
what goes in what package automagicaly assuming some basic conventions about
where things get installed. Note if I run:
bitbake -e simple1
and search for FILES_simple1-staticdev I find:
# $FILES_simple1-staticdev
# rename from FILES_${PN}-staticdev data.py:170 [expandKeys]
FILES_simple1-staticdev=/usr/lib/*.a /lib/*.a /usr/lib/simple1/*.a
Or search for FILES_simple1-dev
#
# $FILES_simple1-dev
# rename from FILES_${PN}-dev data.py:170 [expandKeys]
# ${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la ${libdir}/*.o
${libdir}/pkgconfig ${datadir}/pkgconfig ${datadir}/aclocal ${base_libdir}/*.o
${libdir}/${BPN}/*.la ${base_libdir}/*.la
FILES_jsoncpp-dev=/usr/include /lib/lib*.so /usr/lib/lib*.so /usr/lib/*.la
/usr/lib/*.o /usr/lib/pkgconfig /usr/share/pkgconfig /usr/share/aclocal
/lib/*.o /usr/lib/simple1/*.la /lib/*.la
If my understanding is wrong then that's totally understandable as I'm new to
this as there really isn't much of any documentation on how the cmake class
works.
Thanks,
Matt S.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 01/13] buildsteps: Add ProvisionGoogleVM.py
From: California Sullivan california.l.sulli...@intel.com This build step provisions a Google VM using the gcloud command line tool. Signed-off-by: California Sullivan california.l.sulli...@intel.com --- .../autobuilder/buildsteps/ProvisionGoogleVM.py| 85 ++ 1 file changed, 85 insertions(+) create mode 100644 lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py b/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py new file mode 100644 index 000..fb667dd --- /dev/null +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py @@ -0,0 +1,85 @@ +''' +Created on Aug 13, 2014 + +__author__ = California Sullivan +__copyright__ = Copyright 2014, Intel Corp. +__credits__ = [California Sullivan] +__license__ = GPL +__version__ = 2.0 +__maintainer__ = Elizabeth Flanagan +__email__ = elizabeth.flana...@intel.com +''' + +from buildbot.steps.shell import ShellCommand + +class ProvisionGoogleVM(ShellCommand): +haltOnFailure = True +flunkOnFailure = True +name = Provision Google VM +def __init__(self, factory, argdict=None, **kwargs): +self.vmname=None +self.vmcount=1 +self.startupscript=None +self.metadata=None +self.zone=us-central1-a +self.image=None +self.machine=None +self.network=None +self.disksize=None +self.factory = factory +self.description = Provision Google VM +for k, v in argdict.iteritems(): +if type(v) is bool: +setattr(self, k, str(v)) +else: +setattr(self, k, v) + +if self.vmname is None or self.vmname == : +self.finished(FAILURE) +else: +self.command = gcloud compute instances create +self.vmnames = +for x in range(0, self.vmcount): +self.vmnames += + self.vmname + - + str(x) +self.command += self.vmnames +if self.zone is not None and self.zone in [us-central1-a, us-central1-b, us-central1-f, europe-west1-a, europe-west1-b, asia-east1-a, asia-east1-b, asia-east1-b]: +self.command += --zone + self.zone +else: +self.command += --zone us-central1-a +if self.disksize is not None and self.disksize != : +self.command += --boot-disk-size + self.disksize +else: +self.command += --boot-disk-size 200GB +if self.image is None: +self.command += --image debian-7 +else: +self.command += --image + self.image + +if self.machine is not None and self.machine in [g1-small, f1-micro, n1-standard-1, n1-standard-2, n1-standard-4, n1-standard-8, n1-standard-16, n1-highmem-2, n1-highmem-4]: +self.command += --machine-type + self.machine +else: +self.command += --machine-type n1-standard-1 +if self.network is not None and self.network != : +self.command += --network + self.network +if self.startupscript is not None and self.startupscript != : +self.command += --metadata-from-file startup-script= + self.startupscript +if self.metadata is not None and self.metadata != : +self.command += --metadata + self.scriptargs +self.command += 1 /dev/null; + +# Timeout needs to be passed to LoggingBuildStep as a kwarg +self.timeout = 1000 +kwargs['timeout']=self.timeout +ShellCommand.__init__(self, **kwargs) + +def describe(self, done=False): +description = ShellCommand.describe(self,done) +return description + +def commandComplete(self, cmd): +if not cmd.didFail(): +self.setProperty(vmnames, self.vmnames) +self.setProperty(zone, self.zone) +self.setProperty(vmcount, self.vmcount) + + -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 02/13] buildsteps: add DeleteGoogleVM.py build step.
From: California Sullivan california.l.sulli...@intel.com This build step deletes the Google VMs created in the previous ProvisionGoogleVM build step using Google's gcloud command line tool. Signed-off-by: California Sullivan california.l.sulli...@intel.com --- .../autobuilder/buildsteps/DeleteGoogleVM.py | 52 ++ 1 file changed, 52 insertions(+) create mode 100644 lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVM.py diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVM.py b/lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVM.py new file mode 100644 index 000..29b45a4 --- /dev/null +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVM.py @@ -0,0 +1,52 @@ +''' +Created on Aug 13, 2014 + +__author__ = California Sullivan +__copyright__ = Copyright 2014, Intel Corp. +__credits__ = [California Sullivan] +__license__ = GPL +__version__ = 2.0 +__maintainer__ = Elizabeth Flanagan +__email__ = elizabeth.flana...@intel.com +''' + +from buildbot.steps.shell import ShellCommand + +class DeleteGoogleVM(ShellCommand): +haltOnFailure = True +flunkOnFailure = True +name = Delete Google VM +def __init__(self, factory, argdict=None, **kwargs): + +self.factory = factory +self.description = Deleting Google VMs +for k, v in argdict.iteritems(): +if type(v) is bool: +setattr(self, k, str(v)) +else: +setattr(self, k, v) +# Timeout needs to be passed to LoggingBuildStep as a kwarg +self.timeout = 1000 +kwargs['timeout']=self.timeout +ShellCommand.__init__(self, **kwargs) + + +def start(self): +self.vmnames = self.getProperty(vmnames) +self.vmcount = self.getProperty(vmcount) +self.zone = self.getProperty(zone) + +if self.vmnames is not None and self.vmnames != : +self.command = gcloud compute instances delete +self.command += + self.vmnames + +if self.zone is not None and self.zone in [us-central1-a, us-central1-b, us-central1-f, europe-west1-a, europe-west1-b, asia-east1-a, asia-east1-b, asia-east1-b]: +self.command += --zone + self.zone +else: +self.command += --zone us-central1-a +self.command += --quiet +ShellCommand.start(self) + +def describe(self, done=False): +description = ShellCommand.describe(self,done) +return description -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 06/13] yocto-autobuilder-setup: add host address to worker-init setup script
From: California Sullivan california.l.sulli...@intel.com Signed-off-by: California Sullivan california.l.sulli...@intel.com --- yocto-autobuilder-setup | 1 + 1 file changed, 1 insertion(+) diff --git a/yocto-autobuilder-setup b/yocto-autobuilder-setup index a71bda0..615deb4 100644 --- a/yocto-autobuilder-setup +++ b/yocto-autobuilder-setup @@ -60,6 +60,7 @@ export OPTIMIZED_GIT_CLONE=False export OGIT_TRASH_DIR=/tmp/yocto-autobuilder/git/trash export OGIT_TRASH_CRON_TIME=0 0 * * * export OGIT_TRASH_NICE_LEVEL=19 +HOST_ADDR=$(hostname -I) ## # -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 04/13] yocto-autobuilder-setup: Add address and host replacement for worker-init
From: California Sullivan california.l.sulli...@intel.com
The first time the config is successfully ran the worker-init script will also
be fixed to use info from this host and autobuilder instance.
Signed-off-by: California Sullivan california.l.sulli...@intel.com
---
yocto-autobuilder-setup | 4
1 file changed, 4 insertions(+)
diff --git a/yocto-autobuilder-setup b/yocto-autobuilder-setup
index aee71ce..a74d033 100644
--- a/yocto-autobuilder-setup
+++ b/yocto-autobuilder-setup
@@ -153,6 +153,10 @@ if [ -n ${config_check:+x} ]; then
sed -i s/USER/$username/g ${PWD}/yocto-worker/buildbot.tac
sed -i s/PASS/$password/g ${PWD}/yocto-worker/buildbot.tac
echo
+echo Updating worker-init script used for google cloud building.
+sed -i s/HOST_ADDR/$HOST_ADDR/' ${PWD}/bin/worker-init
+sed -i s/PASS/$password/' ${PWD}/bin/worker-init
+echo
echo If you wish to use your own generated username and password please
echo modify the above files as needed. Please see the README for more
echo information.
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 05/13] yocto-autobuilder-setup: Fix quotes in worker-init setup
From: California Sullivan california.l.sulli...@intel.com
Mixed single and double quotes on accident. Fixed.
Signed-off-by: California Sullivan california.l.sulli...@intel.com
---
yocto-autobuilder-setup | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/yocto-autobuilder-setup b/yocto-autobuilder-setup
index a74d033..a71bda0 100644
--- a/yocto-autobuilder-setup
+++ b/yocto-autobuilder-setup
@@ -154,8 +154,8 @@ if [ -n ${config_check:+x} ]; then
sed -i s/PASS/$password/g ${PWD}/yocto-worker/buildbot.tac
echo
echo Updating worker-init script used for google cloud building.
-sed -i s/HOST_ADDR/$HOST_ADDR/' ${PWD}/bin/worker-init
-sed -i s/PASS/$password/' ${PWD}/bin/worker-init
+sed -i s/HOST_ADDR/$HOST_ADDR/ ${PWD}/bin/worker-init
+sed -i s/PASS/$password/ ${PWD}/bin/worker-init
echo
echo If you wish to use your own generated username and password please
echo modify the above files as needed. Please see the README for more
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 11/13] ProvisionGoogleVM.py: Rename to ProvisionGoogleVMs.py
From: California Sullivan california.l.sulli...@intel.com This can provision multiple VMs at once. Signed-off-by: California Sullivan california.l.sulli...@intel.com --- .../autobuilder/buildsteps/ProvisionGoogleVM.py| 86 -- .../autobuilder/buildsteps/ProvisionGoogleVMs.py | 86 ++ 2 files changed, 86 insertions(+), 86 deletions(-) delete mode 100644 lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py create mode 100644 lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVMs.py diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py b/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py deleted file mode 100644 index e7f488f..000 --- a/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py +++ /dev/null @@ -1,86 +0,0 @@ -''' -Created on Aug 13, 2014 - -__author__ = California Sullivan -__copyright__ = Copyright 2014, Intel Corp. -__credits__ = [California Sullivan] -__license__ = GPL -__version__ = 2.0 -__maintainer__ = Elizabeth Flanagan -__email__ = elizabeth.flana...@intel.com -''' - -from autobuilder.config import * -from buildbot.steps.shell import ShellCommand - -class ProvisionGoogleVM(ShellCommand): -haltOnFailure = True -flunkOnFailure = True -name = Provision Google VM -def __init__(self, factory, argdict=None, **kwargs): -self.vmname=None -self.vmcount=1 -self.startupscript=None -self.metadata=None -self.zone=us-central1-a -self.image=None -self.machine=None -self.network=None -self.disksize=None -self.factory = factory -self.description = Provision Google VM -for k, v in argdict.iteritems(): -if type(v) is bool: -setattr(self, k, str(v)) -else: -setattr(self, k, v) - -if self.vmname is None or self.vmname == : -self.finished(FAILURE) -else: -self.command = gcloud compute instances create -self.vmnames = -for x in range(0, self.vmcount): -self.vmnames += + self.vmname + - + str(x) -self.command += self.vmnames -if self.zone is not None and self.zone in [us-central1-a, us-central1-b, us-central1-f, europe-west1-a, europe-west1-b, asia-east1-a, asia-east1-b, asia-east1-b]: -self.command += --zone + self.zone -else: -self.command += --zone us-central1-a -if self.disksize is not None and self.disksize != : -self.command += --boot-disk-size + self.disksize -else: -self.command += --boot-disk-size 200GB -if self.image is None: -self.command += --image debian-7 -else: -self.command += --image + self.image - -if self.machine is not None and self.machine in [g1-small, f1-micro, n1-standard-1, n1-standard-2, n1-standard-4, n1-standard-8, n1-standard-16, n1-highmem-2, n1-highmem-4]: -self.command += --machine-type + self.machine -else: -self.command += --machine-type n1-standard-1 -if self.network is not None and self.network != : -self.command += --network + self.network -if self.startupscript is not None and self.startupscript != : -self.command += --metadata-from-file startup-script=+YOCTO_ABBASE+/bin/+self.startupscript -if self.metadata is not None and self.metadata != : -self.command += --metadata + self.metadata -self.command += 1 /dev/null; - -# Timeout needs to be passed to LoggingBuildStep as a kwarg -self.timeout = 1000 -kwargs['timeout']=self.timeout -ShellCommand.__init__(self, **kwargs) - -def describe(self, done=False): -description = ShellCommand.describe(self,done) -return description - -def commandComplete(self, cmd): -if not cmd.didFail(): -self.setProperty(vmnames, self.vmnames) -self.setProperty(zone, self.zone) -self.setProperty(vmcount, self.vmcount) - - diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVMs.py b/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVMs.py new file mode 100644 index 000..d0bc6eb --- /dev/null +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVMs.py @@ -0,0 +1,86 @@ +''' +Created on Aug 13, 2014 + +__author__ = California Sullivan +__copyright__ = Copyright 2014, Intel Corp. +__credits__ = [California Sullivan] +__license__ = GPL +__version__ = 2.0 +__maintainer__ = Elizabeth Flanagan +__email__ = elizabeth.flana...@intel.com +''' + +from autobuilder.config import * +from buildbot.steps.shell import
Re: [yocto] [PATCH 01/13] buildsteps: Add ProvisionGoogleVM.py
See https://bugzilla.yoctoproject.org/show_bug.cgi?id=5975 On Tue, Sep 23, 2014 at 10:13 AM, californialsulli...@gmail.com wrote: From: California Sullivan california.l.sulli...@intel.com This build step provisions a Google VM using the gcloud command line tool. Signed-off-by: California Sullivan california.l.sulli...@intel.com --- .../autobuilder/buildsteps/ProvisionGoogleVM.py| 85 ++ 1 file changed, 85 insertions(+) create mode 100644 lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py b/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py new file mode 100644 index 000..fb667dd --- /dev/null +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py @@ -0,0 +1,85 @@ +''' +Created on Aug 13, 2014 + +__author__ = California Sullivan +__copyright__ = Copyright 2014, Intel Corp. +__credits__ = [California Sullivan] +__license__ = GPL +__version__ = 2.0 +__maintainer__ = Elizabeth Flanagan +__email__ = elizabeth.flana...@intel.com +''' + +from buildbot.steps.shell import ShellCommand + +class ProvisionGoogleVM(ShellCommand): +haltOnFailure = True +flunkOnFailure = True +name = Provision Google VM +def __init__(self, factory, argdict=None, **kwargs): +self.vmname=None +self.vmcount=1 +self.startupscript=None +self.metadata=None +self.zone=us-central1-a +self.image=None +self.machine=None +self.network=None +self.disksize=None +self.factory = factory +self.description = Provision Google VM +for k, v in argdict.iteritems(): +if type(v) is bool: +setattr(self, k, str(v)) +else: +setattr(self, k, v) + +if self.vmname is None or self.vmname == : +self.finished(FAILURE) +else: +self.command = gcloud compute instances create +self.vmnames = +for x in range(0, self.vmcount): +self.vmnames += + self.vmname + - + str(x) +self.command += self.vmnames +if self.zone is not None and self.zone in [us-central1-a, us-central1-b, us-central1-f, europe-west1-a, europe-west1-b, asia-east1-a, asia-east1-b, asia-east1-b]: +self.command += --zone + self.zone +else: +self.command += --zone us-central1-a +if self.disksize is not None and self.disksize != : +self.command += --boot-disk-size + self.disksize +else: +self.command += --boot-disk-size 200GB +if self.image is None: +self.command += --image debian-7 +else: +self.command += --image + self.image + +if self.machine is not None and self.machine in [g1-small, f1-micro, n1-standard-1, n1-standard-2, n1-standard-4, n1-standard-8, n1-standard-16, n1-highmem-2, n1-highmem-4]: +self.command += --machine-type + self.machine +else: +self.command += --machine-type n1-standard-1 +if self.network is not None and self.network != : +self.command += --network + self.network +if self.startupscript is not None and self.startupscript != : +self.command += --metadata-from-file startup-script= + self.startupscript +if self.metadata is not None and self.metadata != : +self.command += --metadata + self.scriptargs +self.command += 1 /dev/null; + +# Timeout needs to be passed to LoggingBuildStep as a kwarg +self.timeout = 1000 +kwargs['timeout']=self.timeout +ShellCommand.__init__(self, **kwargs) + +def describe(self, done=False): +description = ShellCommand.describe(self,done) +return description + +def commandComplete(self, cmd): +if not cmd.didFail(): +self.setProperty(vmnames, self.vmnames) +self.setProperty(zone, self.zone) +self.setProperty(vmcount, self.vmcount) + + -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to include static library and headers in sdk
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: Tuesday, September 23, 2014 10:26 AM
To: Matt Schuckmann
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to include static library and headers in sdk
On Tuesday 23 September 2014 10:21:44 Matt Schuckmann wrote:
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: Tuesday, September 23, 2014 9:54 AM
To: Matt Schuckmann
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to include static library and headers in
sdk
On Tuesday 23 September 2014 09:43:55 Matt Schuckmann wrote:
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: Tuesday, September 23, 2014 2:10 AM
To: Matt Schuckmann
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to include static library and headers
in sdk
On Monday 22 September 2014 18:57:03 Matt Schuckmann wrote:
I've got a custom image and 2 custom recipes both very simple
libraries that use cmake. I included the libraries into my
image by adding EXTRA_IMAGEDEPENDS += simple1
EXTRA_IMAGEDEPENDS += simple2
To my image recipe.
Except this doesn't actually add those things into your image,
it only ensures they are built alongside it. To actually add
them to the image
you need to ensure you add them to IMAGE_INSTALL; see:
If I add my simple1 and simple2 recipes to IMAGE_INSTALL I get
the
following error in the do_rootfs task: * opkg_install_cmd: Cannot
install package simple1.
I assumed that this is because there really is nothing to install
in the image as this is a static library with nothing that should
go in
the image.
http://www.yoctoproject.org/docs/current/dev-manual/dev-
manual.html#usingpoky-extend-customimage
When I build my image (i.e. bitbake custom-image ) I can see
that the library header files and .a files are placed in the
correct place in the sysroot directory.
However when I try to create an sdk (i.e. bitbake custom-
image
-c
populate_sdk) and then install the SDK the headers and .a
files are nowhere to be found in the installed sysroot.
If you want all -staticdev packages in the SDK for the
libraries
in your image, add the following to your local.conf (or the
image recipe,
doesn't matter which):
SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs staticdev-pkgs
If you want a single staticdev package in the SDK you'd need to
add the
following instead:
TOOLCHAIN_HOST_TASK_append = simple1-staticdev
Again if I try adding this to my image recipe I get a similar
error
* opkg_install_cmd: Cannot install package simple1-staticdev.
For reference here is my simple1 recipe, maybe I'm missing
something in there.
DESCRIPTION = Simple library 1.
LICENSE = CLOSED
LIC_FILES_CHKSUM =
SRC_URI =
git://g...@gitlab.work.net/libs/simple1.git;protocol=ssh
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
inherit pkgconfig cmake
So is your recipe actually producing any packages at all? i.e. are
any of the directories under packages-split within the workdir for
the recipe non-empty?
At the moment it looks like it isn't producing anything.
Yes the simple1-dev directory contains the include files and the
library file under usr/include and usr/lib respectively. The
simple1-staticdev directory contains only the library file under
usr/lib.
My understanding, limited as it is, is that the cmake class handles
identifying what goes in what package automagicaly assuming some
basic
conventions about where things get installed. Note if I run: bitbake
-e
simple1
and search for FILES_simple1-staticdev I find:
# $FILES_simple1-staticdev
# rename from FILES_${PN}-staticdev data.py:170 [expandKeys]
FILES_simple1-staticdev=/usr/lib/*.a /lib/*.a /usr/lib/simple1/*.a
Or search for FILES_simple1-dev
#
# $FILES_simple1-dev
# rename from FILES_${PN}-dev data.py:170 [expandKeys]
# ${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la ${libdir}/*.o
${libdir}/pkgconfig ${datadir}/pkgconfig ${datadir}/aclocal
${base_libdir}/*.o ${libdir}/${BPN}/*.la ${base_libdir}/*.la
FILES_jsoncpp-dev=/usr/include /lib/lib*.so /usr/lib/lib*.so
/usr/lib/*.la /usr/lib/*.o /usr/lib/pkgconfig /usr/share/pkgconfig
/usr/share/aclocal /lib/*.o /usr/lib/simple1/*.la /lib/*.la
If my understanding is wrong then that's totally understandable as
I'm
new to this as there really isn't much of any documentation on how
the
cmake class works.
That sounds correct to me.
Actually I realised I made a mistake above that might explain why the
second suggestion didn't work as expected. I think you need to add to
TOOLCHAIN_TARGET_TASK rather
Re: [yocto] Update recipe file to avoid conflict with other dependant packages
Thanks I got the variable in congiguration file On 22 Sep 2014 15:02, Burton, Ross ross.bur...@intel.com wrote: On 22 September 2014 07:52, harsh jain harshjai...@gmail.com wrote: Given below logs message when I tried with python 2.7.4 NOTE: Resolving any missing task queue dependencies NOTE: preferred version 2.7.3 of python not available (for item python-core) NOTE: versions of python available: 2.7.4 NOTE: preferred version 2.7.3 of python not available (for item python-2to3) NOTE: versions of python available: 2.7.4 NOTE: preferred version 2.7.3 of python not available (for item python-audio) NOTE: versions of python available: 2.7.4 NOTE: preferred version 2.7.3 of python not available (for item python-bsddb) NOTE: versions of python available: 2.7.4 NOTE: preferred version 2.7.3 of python not available (for item python-codecs) NOTE: versions of python available: 2.7.4 NOTE: preferred version 2.7.3 of python not available (for item python-compile) NOTE: versions of python available: 2.7.4 NOTE: preferred version 2.7.3 of python not available (for item python-compiler) NOTE: versions of python available: 2.7.4 NOTE: preferred version 2.7.3 of python not available (for item plython-compression) NOTE: versions of python available: 2.7.4 Your distro configuration has a preferred provider for Python, and it's set to 2.7.3. I can't seem to see anything in oe-core that sets this, so it's possibly your own distribution (or another layer). Grep your layers or use bitbake -e python to find out where the PREFERRED_PROVIDER is being set, and change it. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to include static library and headers in sdk
On Tuesday 23 September 2014 10:57:21 Matt Schuckmann wrote:
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: Tuesday, September 23, 2014 10:26 AM
To: Matt Schuckmann
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to include static library and headers in sdk
On Tuesday 23 September 2014 10:21:44 Matt Schuckmann wrote:
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: Tuesday, September 23, 2014 9:54 AM
To: Matt Schuckmann
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to include static library and headers in
sdk
On Tuesday 23 September 2014 09:43:55 Matt Schuckmann wrote:
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: Tuesday, September 23, 2014 2:10 AM
To: Matt Schuckmann
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to include static library and headers
in sdk
On Monday 22 September 2014 18:57:03 Matt Schuckmann wrote:
I've got a custom image and 2 custom recipes both very simple
libraries that use cmake. I included the libraries into my
image by adding EXTRA_IMAGEDEPENDS += simple1
EXTRA_IMAGEDEPENDS += simple2
To my image recipe.
Except this doesn't actually add those things into your image,
it only ensures they are built alongside it. To actually add
them to the image
you need to ensure you add them to IMAGE_INSTALL; see:
If I add my simple1 and simple2 recipes to IMAGE_INSTALL I get
the
following error in the do_rootfs task: * opkg_install_cmd: Cannot
install package simple1.
I assumed that this is because there really is nothing to install
in the image as this is a static library with nothing that should
go in
the image.
http://www.yoctoproject.org/docs/current/dev-manual/dev-
manual.html#usingpoky-extend-customimage
When I build my image (i.e. bitbake custom-image ) I can see
that the library header files and .a files are placed in the
correct place in the sysroot directory.
However when I try to create an sdk (i.e. bitbake custom-
image
-c
populate_sdk) and then install the SDK the headers and .a
files are nowhere to be found in the installed sysroot.
If you want all -staticdev packages in the SDK for the
libraries
in your image, add the following to your local.conf (or the
image recipe,
doesn't matter which):
SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs staticdev-pkgs
If you want a single staticdev package in the SDK you'd need to
add the
following instead:
TOOLCHAIN_HOST_TASK_append = simple1-staticdev
Again if I try adding this to my image recipe I get a similar
error
* opkg_install_cmd: Cannot install package simple1-staticdev.
For reference here is my simple1 recipe, maybe I'm missing
something in there.
DESCRIPTION = Simple library 1.
LICENSE = CLOSED
LIC_FILES_CHKSUM =
SRC_URI =
git://g...@gitlab.work.net/libs/simple1.git;protocol=ssh
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
inherit pkgconfig cmake
So is your recipe actually producing any packages at all? i.e. are
any of the directories under packages-split within the workdir for
the recipe non-empty?
At the moment it looks like it isn't producing anything.
Yes the simple1-dev directory contains the include files and the
library file under usr/include and usr/lib respectively. The
simple1-staticdev directory contains only the library file under
usr/lib.
My understanding, limited as it is, is that the cmake class handles
identifying what goes in what package automagicaly assuming some
basic
conventions about where things get installed. Note if I run: bitbake
-e
simple1
and search for FILES_simple1-staticdev I find:
# $FILES_simple1-staticdev
# rename from FILES_${PN}-staticdev data.py:170 [expandKeys]
FILES_simple1-staticdev=/usr/lib/*.a /lib/*.a /usr/lib/simple1/*.a
Or search for FILES_simple1-dev
#
# $FILES_simple1-dev
# rename from FILES_${PN}-dev data.py:170 [expandKeys]
# ${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la ${libdir}/*.o
${libdir}/pkgconfig ${datadir}/pkgconfig ${datadir}/aclocal
${base_libdir}/*.o ${libdir}/${BPN}/*.la ${base_libdir}/*.la
FILES_jsoncpp-dev=/usr/include /lib/lib*.so /usr/lib/lib*.so
/usr/lib/*.la /usr/lib/*.o /usr/lib/pkgconfig /usr/share/pkgconfig
/usr/share/aclocal /lib/*.o /usr/lib/simple1/*.la /lib/*.la
If my understanding is wrong then that's totally understandable as
I'm
new to this as there really isn't much of any
Re: [yocto] How to include static library and headers in sdk
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: Tuesday, September 23, 2014 11:12 AM
To: Matt Schuckmann
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to include static library and headers in sdk
On Tuesday 23 September 2014 10:57:21 Matt Schuckmann wrote:
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: Tuesday, September 23, 2014 10:26 AM
To: Matt Schuckmann
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to include static library and headers in
sdk
On Tuesday 23 September 2014 10:21:44 Matt Schuckmann wrote:
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: Tuesday, September 23, 2014 9:54 AM
To: Matt Schuckmann
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to include static library and headers
in sdk
On Tuesday 23 September 2014 09:43:55 Matt Schuckmann wrote:
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: Tuesday, September 23, 2014 2:10 AM
To: Matt Schuckmann
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to include static library and
headers in sdk
On Monday 22 September 2014 18:57:03 Matt Schuckmann wrote:
I've got a custom image and 2 custom recipes both very
simple libraries that use cmake. I included the libraries
into my image by adding EXTRA_IMAGEDEPENDS += simple1
EXTRA_IMAGEDEPENDS += simple2
To my image recipe.
Except this doesn't actually add those things into your
image, it only ensures they are built alongside it. To
actually add them to the image
you need to ensure you add them to IMAGE_INSTALL; see:
If I add my simple1 and simple2 recipes to IMAGE_INSTALL I
get
the
following error in the do_rootfs task: * opkg_install_cmd:
Cannot install package simple1.
I assumed that this is because there really is nothing to
install in the image as this is a static library with nothing
that should go in
the image.
http://www.yoctoproject.org/docs/current/dev-manual/dev-
manual.html#usingpoky-extend-customimage
When I build my image (i.e. bitbake custom-image ) I can
see that the library header files and .a files are placed
in the correct place in the sysroot directory.
However when I try to create an sdk (i.e. bitbake custom-
image
-c
populate_sdk) and then install the SDK the headers and .a
files are nowhere to be found in the installed sysroot.
If you want all -staticdev packages in the SDK for the
libraries
in your image, add the following to your local.conf (or the
image recipe,
doesn't matter which):
SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs staticdev-pkgs
If you want a single staticdev package in the SDK you'd
need
to add the
following instead:
TOOLCHAIN_HOST_TASK_append = simple1-staticdev
Again if I try adding this to my image recipe I get a similar
error
* opkg_install_cmd: Cannot install package simple1-staticdev.
For reference here is my simple1 recipe, maybe I'm missing
something in there.
DESCRIPTION = Simple library 1.
LICENSE = CLOSED
LIC_FILES_CHKSUM =
SRC_URI =
git://g...@gitlab.work.net/libs/simple1.git;protocol=ssh
SRCREV = ${AUTOREV}
S = ${WORKDIR}/git
inherit pkgconfig cmake
So is your recipe actually producing any packages at all? i.e.
are any of the directories under packages-split within the
workdir for the recipe non-empty?
At the moment it looks like it isn't producing anything.
Yes the simple1-dev directory contains the include files and the
library file under usr/include and usr/lib respectively. The
simple1-staticdev directory contains only the library file under
usr/lib.
My understanding, limited as it is, is that the cmake class
handles identifying what goes in what package automagicaly
assuming some
basic
conventions about where things get installed. Note if I run:
bitbake -e
simple1
and search for FILES_simple1-staticdev I find:
# $FILES_simple1-staticdev
# rename from FILES_${PN}-staticdev data.py:170 [expandKeys]
FILES_simple1-staticdev=/usr/lib/*.a /lib/*.a
/usr/lib/simple1/*.a
Or search for FILES_simple1-dev
#
# $FILES_simple1-dev
# rename from FILES_${PN}-dev data.py:170 [expandKeys]
# ${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la
${libdir}/*.o
${libdir}/pkgconfig ${datadir}/pkgconfig ${datadir}/aclocal
${base_libdir}/*.o
[yocto] [PATCH 13/13] ProvisionGoogleVMs.py: Delete VM before trying to provision it.
From: California Sullivan california.l.sulli...@intel.com In the case that somebody turned off a build before it completed, the buildstep would attempt and fail to procure a new VM, failing the build. Signed-off-by: California Sullivan california.l.sulli...@intel.com --- .../autobuilder/buildsteps/ProvisionGoogleVMs.py | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVMs.py b/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVMs.py index d0bc6eb..262526f 100644 --- a/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVMs.py +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVMs.py @@ -19,6 +19,7 @@ class ProvisionGoogleVMs(ShellCommand): name = Provision Google VMs def __init__(self, factory, argdict=None, **kwargs): self.vmname=None +self.vmnames= self.vmcount=1 self.startupscript=None self.metadata=None @@ -38,15 +39,18 @@ class ProvisionGoogleVMs(ShellCommand): if self.vmname is None or self.vmname == : self.finished(FAILURE) else: -self.command = gcloud compute instances create -self.vmnames = +self.command = +if self.zone is None or self.zone not in [us-central1-a, us-central1-b, us-central1-f, europe-west1-a, europe-west1-b, asia-east1-a, asia-east1-b, asia-east1-b]: +self.zone = us-central1-a for x in range(0, self.vmcount): self.vmnames += + self.vmname + - + str(x) +self.command += gcloud compute instances delete self.command += self.vmnames -if self.zone is not None and self.zone in [us-central1-a, us-central1-b, us-central1-f, europe-west1-a, europe-west1-b, asia-east1-a, asia-east1-b, asia-east1-b]: -self.command += --zone + self.zone -else: -self.command += --zone us-central1-a +self.command += --zone + self.zone + --quiet; +self.command += gcloud compute instances create +self.command += self.vmnames +self.command += --zone + self.zone + if self.disksize is not None and self.disksize != : self.command += --boot-disk-size + self.disksize else: -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 10/13] DeleteGoogleVM.py: Rename to DeleteGoogleVMs.py
From: California Sullivan california.l.sulli...@intel.com It can delete multiple at once if multiple were created at once. Signed-off-by: California Sullivan california.l.sulli...@intel.com --- .../autobuilder/buildsteps/DeleteGoogleVM.py | 52 -- .../autobuilder/buildsteps/DeleteGoogleVMs.py | 52 ++ 2 files changed, 52 insertions(+), 52 deletions(-) delete mode 100644 lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVM.py create mode 100644 lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVMs.py diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVM.py b/lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVM.py deleted file mode 100644 index 29b45a4..000 --- a/lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVM.py +++ /dev/null @@ -1,52 +0,0 @@ -''' -Created on Aug 13, 2014 - -__author__ = California Sullivan -__copyright__ = Copyright 2014, Intel Corp. -__credits__ = [California Sullivan] -__license__ = GPL -__version__ = 2.0 -__maintainer__ = Elizabeth Flanagan -__email__ = elizabeth.flana...@intel.com -''' - -from buildbot.steps.shell import ShellCommand - -class DeleteGoogleVM(ShellCommand): -haltOnFailure = True -flunkOnFailure = True -name = Delete Google VM -def __init__(self, factory, argdict=None, **kwargs): - -self.factory = factory -self.description = Deleting Google VMs -for k, v in argdict.iteritems(): -if type(v) is bool: -setattr(self, k, str(v)) -else: -setattr(self, k, v) -# Timeout needs to be passed to LoggingBuildStep as a kwarg -self.timeout = 1000 -kwargs['timeout']=self.timeout -ShellCommand.__init__(self, **kwargs) - - -def start(self): -self.vmnames = self.getProperty(vmnames) -self.vmcount = self.getProperty(vmcount) -self.zone = self.getProperty(zone) - -if self.vmnames is not None and self.vmnames != : -self.command = gcloud compute instances delete -self.command += + self.vmnames - -if self.zone is not None and self.zone in [us-central1-a, us-central1-b, us-central1-f, europe-west1-a, europe-west1-b, asia-east1-a, asia-east1-b, asia-east1-b]: -self.command += --zone + self.zone -else: -self.command += --zone us-central1-a -self.command += --quiet -ShellCommand.start(self) - -def describe(self, done=False): -description = ShellCommand.describe(self,done) -return description diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVMs.py b/lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVMs.py new file mode 100644 index 000..b0071cf --- /dev/null +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/DeleteGoogleVMs.py @@ -0,0 +1,52 @@ +''' +Created on Aug 13, 2014 + +__author__ = California Sullivan +__copyright__ = Copyright 2014, Intel Corp. +__credits__ = [California Sullivan] +__license__ = GPL +__version__ = 2.0 +__maintainer__ = Elizabeth Flanagan +__email__ = elizabeth.flana...@intel.com +''' + +from buildbot.steps.shell import ShellCommand + +class DeleteGoogleVMs(ShellCommand): +haltOnFailure = True +flunkOnFailure = True +name = Delete Google VMs +def __init__(self, factory, argdict=None, **kwargs): + +self.factory = factory +self.description = Deleting Google VMs +for k, v in argdict.iteritems(): +if type(v) is bool: +setattr(self, k, str(v)) +else: +setattr(self, k, v) +# Timeout needs to be passed to LoggingBuildStep as a kwarg +self.timeout = 1000 +kwargs['timeout']=self.timeout +ShellCommand.__init__(self, **kwargs) + + +def start(self): +self.vmnames = self.getProperty(vmnames) +self.vmcount = self.getProperty(vmcount) +self.zone = self.getProperty(zone) + +if self.vmnames is not None and self.vmnames != : +self.command = gcloud compute instances delete +self.command += + self.vmnames + +if self.zone is not None and self.zone in [us-central1-a, us-central1-b, us-central1-f, europe-west1-a, europe-west1-b, asia-east1-a, asia-east1-b, asia-east1-b]: +self.command += --zone + self.zone +else: +self.command += --zone us-central1-a +self.command += --quiet +ShellCommand.start(self) + +def describe(self, done=False): +description = ShellCommand.describe(self,done) +return description -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 11/13] ProvisionGoogleVM.py: Rename to ProvisionGoogleVMs.py
From: California Sullivan california.l.sulli...@intel.com This can provision multiple VMs at once. Signed-off-by: California Sullivan california.l.sulli...@intel.com --- .../autobuilder/buildsteps/ProvisionGoogleVM.py| 86 -- .../autobuilder/buildsteps/ProvisionGoogleVMs.py | 86 ++ 2 files changed, 86 insertions(+), 86 deletions(-) delete mode 100644 lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py create mode 100644 lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVMs.py diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py b/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py deleted file mode 100644 index e7f488f..000 --- a/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVM.py +++ /dev/null @@ -1,86 +0,0 @@ -''' -Created on Aug 13, 2014 - -__author__ = California Sullivan -__copyright__ = Copyright 2014, Intel Corp. -__credits__ = [California Sullivan] -__license__ = GPL -__version__ = 2.0 -__maintainer__ = Elizabeth Flanagan -__email__ = elizabeth.flana...@intel.com -''' - -from autobuilder.config import * -from buildbot.steps.shell import ShellCommand - -class ProvisionGoogleVM(ShellCommand): -haltOnFailure = True -flunkOnFailure = True -name = Provision Google VM -def __init__(self, factory, argdict=None, **kwargs): -self.vmname=None -self.vmcount=1 -self.startupscript=None -self.metadata=None -self.zone=us-central1-a -self.image=None -self.machine=None -self.network=None -self.disksize=None -self.factory = factory -self.description = Provision Google VM -for k, v in argdict.iteritems(): -if type(v) is bool: -setattr(self, k, str(v)) -else: -setattr(self, k, v) - -if self.vmname is None or self.vmname == : -self.finished(FAILURE) -else: -self.command = gcloud compute instances create -self.vmnames = -for x in range(0, self.vmcount): -self.vmnames += + self.vmname + - + str(x) -self.command += self.vmnames -if self.zone is not None and self.zone in [us-central1-a, us-central1-b, us-central1-f, europe-west1-a, europe-west1-b, asia-east1-a, asia-east1-b, asia-east1-b]: -self.command += --zone + self.zone -else: -self.command += --zone us-central1-a -if self.disksize is not None and self.disksize != : -self.command += --boot-disk-size + self.disksize -else: -self.command += --boot-disk-size 200GB -if self.image is None: -self.command += --image debian-7 -else: -self.command += --image + self.image - -if self.machine is not None and self.machine in [g1-small, f1-micro, n1-standard-1, n1-standard-2, n1-standard-4, n1-standard-8, n1-standard-16, n1-highmem-2, n1-highmem-4]: -self.command += --machine-type + self.machine -else: -self.command += --machine-type n1-standard-1 -if self.network is not None and self.network != : -self.command += --network + self.network -if self.startupscript is not None and self.startupscript != : -self.command += --metadata-from-file startup-script=+YOCTO_ABBASE+/bin/+self.startupscript -if self.metadata is not None and self.metadata != : -self.command += --metadata + self.metadata -self.command += 1 /dev/null; - -# Timeout needs to be passed to LoggingBuildStep as a kwarg -self.timeout = 1000 -kwargs['timeout']=self.timeout -ShellCommand.__init__(self, **kwargs) - -def describe(self, done=False): -description = ShellCommand.describe(self,done) -return description - -def commandComplete(self, cmd): -if not cmd.didFail(): -self.setProperty(vmnames, self.vmnames) -self.setProperty(zone, self.zone) -self.setProperty(vmcount, self.vmcount) - - diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVMs.py b/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVMs.py new file mode 100644 index 000..d0bc6eb --- /dev/null +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/ProvisionGoogleVMs.py @@ -0,0 +1,86 @@ +''' +Created on Aug 13, 2014 + +__author__ = California Sullivan +__copyright__ = Copyright 2014, Intel Corp. +__credits__ = [California Sullivan] +__license__ = GPL +__version__ = 2.0 +__maintainer__ = Elizabeth Flanagan +__email__ = elizabeth.flana...@intel.com +''' + +from autobuilder.config import * +from buildbot.steps.shell import
[yocto] [PATCH] ARM: Headfull JVM added.
I've added the headful version of the JVM. Also, I'm suggesting a new
way of fetching. Since Oracle forces it's users to go to its website
and accept the aggrement, non-human fetching is aways hack and error
prone. What I sugest is that the build system ask for the user to
visit the website, download the package and put it on right place, if
isn't already there.
---
...le-jse-ejre-arm-vfp-hflt-client-headful_1.7.0.bb | 21 +
1 file changed, 21 insertions(+)
create mode 100644
recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headful_1.7.0.bb
diff --git
a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headful_1.7.0.bb
b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headful_1.7.0.bb
new file mode 100644
index 000..e3030a6
--- /dev/null
+++
b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headful_1.7.0.bb
@@ -0,0 +1,21 @@
+PV_UPDATE = 60
+BUILD_NUMBER = 19
+
+require oracle-jse-ejre.inc
+
+# ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headful-07_may_2014.tar.gz
+DL_FILE =
ejre-7u${PV_UPDATE}-fcs-b${BUILD_NUMBER}-linux-arm-vfp-hflt-client_headful-07_may_2014.tar.gz
+SRC_URI =
http://download.oracle.com/otn/java/ejre/7u${PV_UPDATE}-b${BUILD_NUMBER}/${DL_FILE};
+
+SRC_URI[md5sum] = b72400960629e7403c4b579dada2a804
+SRC_URI[sha256sum] =
c4a64be693e0e27ca95ffe3036c56156e3d75e07f620fd913308eb03cdf86779
+
+do_fetch() {
+if ! test -f ${DL_DIR}/${DL_FILE}; then
+echo Please accept the License Agreement, download the ${DL_FILE}
and put it on ${DL_DIR}
+echo The download link can be found at
http://www.oracle.com/technetwork/java/embedded/embedded-se/downloads/javase-embedded-downloads-2209751.html;
+return 1
+else
+return 0
+fi
+}
\ No newline at end of file
--
2.1.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] ARM: Headfull JVM added.
On 09/23/2014 04:43 PM, Daniel Hilst SellI wrote:
I've added the headful version of the JVM. Also, I'm suggesting a new
way of fetching. Since Oracle forces it's users to go to its website
and accept the aggrement, non-human fetching is aways hack and error
prone. What I sugest is that the build system ask for the user to
visit the website, download the package and put it on right place, if
isn't already there.
---
...le-jse-ejre-arm-vfp-hflt-client-headful_1.7.0.bb | 21 +
1 file changed, 21 insertions(+)
create mode 100644
recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headful_1.7.0.bb
diff --git
a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headful_1.7.0.bb
b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headful_1.7.0.bb
new file mode 100644
index 000..e3030a6
--- /dev/null
+++
b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headful_1.7.0.bb
@@ -0,0 +1,21 @@
+PV_UPDATE = 60
+BUILD_NUMBER = 19
+
+require oracle-jse-ejre.inc
+
+# ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headful-07_may_2014.tar.gz
+DL_FILE =
ejre-7u${PV_UPDATE}-fcs-b${BUILD_NUMBER}-linux-arm-vfp-hflt-client_headful-07_may_2014.tar.gz
+SRC_URI =
http://download.oracle.com/otn/java/ejre/7u${PV_UPDATE}-b${BUILD_NUMBER}/${DL_FILE};
+
+SRC_URI[md5sum] = b72400960629e7403c4b579dada2a804
+SRC_URI[sha256sum] =
c4a64be693e0e27ca95ffe3036c56156e3d75e07f620fd913308eb03cdf86779
+
+do_fetch() {
+if ! test -f ${DL_DIR}/${DL_FILE}; then
+echo Please accept the License Agreement, download the ${DL_FILE} and
put it on ${DL_DIR}
+echo The download link can be found at
http://www.oracle.com/technetwork/java/embedded/embedded-se/downloads/javase-embedded-downloads-2209751.html;
+return 1
+else
+return 0
+fi
+}
\ No newline at end of file
Sorry, I forgot to mention that this is for meta-oracle-java layer,
Cheers,
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH][meta-selinux] dhcp: remove the unrecognised without-selinux configuration warning
From: Roy.Li rongqing...@windriver.com
dhcp 4.3 has no selinux related configuration options, but it needs the
correct initscript when SELinux is enabled, so inherit selinux, not
inherit with-selinux
Signed-off-by: Roy.Li rongqing...@windriver.com
---
recipes-connectivity/dhcp/dhcp_4.3.0.bbappend |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-connectivity/dhcp/dhcp_4.3.0.bbappend
b/recipes-connectivity/dhcp/dhcp_4.3.0.bbappend
index 900c2aa..2d2232c 100644
--- a/recipes-connectivity/dhcp/dhcp_4.3.0.bbappend
+++ b/recipes-connectivity/dhcp/dhcp_4.3.0.bbappend
@@ -1,3 +1,3 @@
-inherit with-selinux
+inherit selinux
FILESEXTRAPATHS_prepend := ${@target_selinux(d, '${THISDIR}/files:')}
--
1.7.10.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Integration of custom recipe with SDK
I corrected FILES_${PN} and added following in my image recipe-
QTNAME = qte
QT_DIR_NAME = qtopia
require recipes-qt/meta/meta-toolchain-qt.bb
but that didn't make any difference related to SDK integration. On
executing 'bitbake -v MyImageName', it is generating rootfs and sdk, in
which contains rootfs contains qjson libraries but sdk doesn't integrate
anything.
On Tue, Sep 23, 2014 at 11:24 AM, Khem Raj raj.k...@gmail.com wrote:
On Mon, Sep 22, 2014 at 9:26 PM, Navani Srivastava
navani.srivast...@gmail.com wrote:
Please find the recipe attached herewith for qjson. This recipe is
helpful
to work with qt4-embedded as qt4 doesn't have qjson feature in built.
I tried 'bitbake -c populate_sdk myimage' but it has not integrated
qjson
package along. I am suspecting qjson recipe now. Am i missing anything in
attached recipe which is blocking me to integrate qjson in SDK?
Have you made sure that qjson is otherwise included into your image ?
I see that FILES_${PN} is being overwritten twice may be you want +=
in second place.
Navani
On Mon, Sep 22, 2014 at 2:48 PM, Navani Srivastava
navani.srivast...@gmail.com wrote:
I will follow the suggestion given by you and will update the result.
However in case if I want to integrate custom recipe with
meta-toolchain-qte, is there any example existing which can help me in
understanding?
Right now I am following the procedure given by Randy but some example
could be of a great help!!
Regards
Navani
On Mon, Sep 22, 2014 at 2:21 PM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
On Monday 22 September 2014 14:06:26 Navani Srivastava wrote:
On Mon, Sep 22, 2014 at 1:45 PM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
On Sunday 21 September 2014 09:26:07 Navani Srivastava wrote:
We are not using populatesdk ... we need to generate it through
meta-toolchain-qte only so i am trying with the solution provided
by
randy..
Can I ask why? I'd like to understand where -c populate_sdk needs
further
improvement.
I have to generate toolchain which contain qt related tools also like
qmake
and qjson, so we are using meta-toolchain-qte to generate the
toolchain..
Do you suggest it's better to integrate meta-toolchain-qte somehow
with
populate_sdk so that we can make life easier?
It is possible to integrate the two - all you need to do is ensure the
extra
qte tools get added to the SDK. One way to achieve this would be to add
the
following to your image recipe:
QTNAME = qte
QT_DIR_NAME = qtopia
require recipes-qt/meta/meta-toolchain-qt.inc
(I haven't tested this so I'm not 100% sure if it will work, but it
should.)
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
