On 29 Sep 2014, at 22:59, Burton, Ross ross.bur...@intel.com wrote:
On 29 September 2014 22:36, Chris Tapp opensou...@keylevel.com wrote:
How would the fetcher handle the file changing after it had already been
downloaded and passed a checksum test? Would the change have been detected?
On Tuesday 30 September 2014 08:53:08 Chris Tapp wrote:
On 29 Sep 2014, at 22:59, Burton, Ross ross.bur...@intel.com wrote:
On 29 September 2014 22:36, Chris Tapp opensou...@keylevel.com wrote:
How would the fetcher handle the file changing after it had already been
downloaded and passed a
On 30 September 2014 08:53, Chris Tapp opensou...@keylevel.com wrote:
I'm not sure this is quite the same - in this case the (downloaded) file and
checksum would have matched but the remote file has changed.
When upstream change a file we normally hear about it fairly quickly,
and fix the
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
---
From: California Sullivan california.l.sulli...@intel.com
This script takes a fresh debian VM, completely sets up software and disks,
starts an autobuilder worker, and then connects it to the controller. It is to
be used by the ProvisionGoogleVMs build step.
Signed-off-by: California Sullivan
From: California Sullivan california.l.sulli...@intel.com
The password and address fields in the worker init script need to
be set up.
Signed-off-by: California Sullivan california.l.sulli...@intel.com
---
yocto-autobuilder-setup | 5 +
1 file changed, 5 insertions(+)
diff --git
From: California Sullivan california.l.sulli...@intel.com
Goes over some limitations and gives an example of how to use it.
Signed-off-by: California Sullivan california.l.sulli...@intel.com
---
README-GOOGLE-CLOUD | 68 +
1 file changed, 68
From: California Sullivan california.l.sulli...@intel.com
Signed-off-by: California Sullivan california.l.sulli...@intel.com
---
.../autobuilder/buildsteps/ProvisionGoogleVM.py| 85 -
.../autobuilder/buildsteps/ProvisionGoogleVMs.py | 86 ++
2 files
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
---
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
You forgot the fourth question:
- Who reads the docs? ;)
In all seriousness, the YP has some of the best docs I've ever seen come
out of an open source project.
My only comment: make it easier to build the latest docs from git. I seem
to always hit errors, and I've seen other posts about
Sounds like a make problem on the mega-manual fail. I will look at that file
and make sure that I have or at least am checking for all the various other
manuals in HTML form that must exist in order for mega-manual to make.
Regarding the dev-manual failure I would be interested in seeing what
Note: The plugin works on a different project in the same Eclipse
workspace. I am attempting to create some Project-specific settings, and
point the Toolchain and Sysroot to a different directory, and I'm getting
this error.
Full output here:http://pastebin.com/CkGfWspY
Running Kepler 4.3.2
Any
I could not replicate the failure here. I cloned the latest poky and then
checked out a branch based on the 'yocto-1.6' tag. I was able to 'make
DOC=mega-manual' and 'make DOC=dev-manual' with no issues. If you want, you
can email me directly with more details of how it is failing on your
I noticed that if I update the SRCREV value in a recipe to a newer rev for a GIT repository, OE does not think it needs to run the fetch step unless I force it. In other wordsbitbake -c fetch foobardoes not pick up that the SRCREV it was downloaded for is no longer correct.bitbake -f -c fetch
On 2014-09-30 17:00, ezek...@sanborndeasis.net wrote:
I noticed that if I update the SRCREV value in a recipe to a newer rev for a
GIT repository, OE does not think it needs to run the fetch step unless I force
it. In other words
bitbake -c fetch foobar
does not pick up that the SRCREV it
16 matches
Mail list logo