linaro-validation

linaro-validation@lists.linaro.org

818 discussions

by Michael Hope

The Validation lab is shifting to a new location this week so I've started a graceful shutdown of the tcpanda boards. Merge requests will continue to queue and run on x86 but will back up until the lab comes online at the end of this week. If the backlog gets too big then I'll re-enable an ursa board or two. Please work as normal but expect the builds results to take longer to come through. -- Michael

14 years

rootfs/hwpacks used to create master images

by Fathi Boudra

Hi, Which rootfs/hwpacks are used to create master images? Are they document somewhere? Cheers -- Fathi Boudra Linaro Release Manager | Validation Project Manager Linaro.org | Open source software for ARM SoCs

14 years

ARMHF test ARMEL master

by Zygmunt Krynicki

Hi. I've just realized that we'll likely see issues when test images start showing up as armhf. Our master image compiler that builds a few of the tests is going to target armel. I'd like to propose that we re-purpose the master image. I'd like to _stop_ using it for building software. That is: all lava-test install steps will be invoked in the _test_ image. We can apply this without requesting our users to rewrite their test scenario definitions. I'd like to propose rewriting the scenario file to invoke any lava-test-install _after_ the boot test image step. Thanks ZK -- Zygmunt Krynicki Linaro Validation Team

14 years

Vexpress boards now supported

by Paul Larson

Dave, I deployed the latest version of lava-dispatcher yesterday, which included your changes to support vexpress. If you have a chance, could you run a test job through it and make sure it's all working well? Thanks, Paul Larson

14 years

Using ip=dhpc is evil

by Zygmunt Krynicki

Hi I'm trying to use my snowball for development testing. It seems that having kernel command line specify ip=dhpc is evil as that makes all of the userspace network configuration not to happen. When this happens ifup scripts are not executed and ntpdate is never invoked. I have not debugged this correctly yet but that seems to be the case for me. Thanks ZK -- Zygmunt Krynicki Linaro Validation Team

14 years

Shining panda

by Zygmunt Krynicki

Integrated CI solution with python focus: https://www.shiningpanda.com/ More food for thought ZK -- Zygmunt Krynicki Linaro Validation Team

14 years, 1 month

What can we learn from Travis CI

by Zygmunt Krynicki

Hi I've looked at this blog announcement [1] and found it interesting. Travis seems to be a build service optimized to work with, and understand a load of dynamic languages. What I really like about it how it makes the effort required to add CI to $my_pet_project very very low. I like how they provide HTML snippets that show if your project builds or not. I like how they display stats [2]. I like how they are integrated with github (it probably makes sense for them but the idea is that you loose another "config" mess - no separate login, no separate repo setup). I like their UI [3]. They seem to support building and testing branches of the single repo from github which is also nice [4]. I know they are focused on CI (build and yes-or-no testing) but is there anything else we could learn from them? Thanks ZK [1] http://about.travis-ci.org/blog/announcing_python_and_perl_support_on_travi… [2] http://travis-ci.org/stats [3] http://travis-ci.org/#!/ruby/ruby [4] http://travis-ci.org/#!/ruby/ruby/branch_summary

14 years, 1 month

Re: [Linaro-validation] coremark + android + lava

by Paul Larson

Looping in the linaro-validation mailing list. Nothing private here and would like to get input from others as well. On Mon, Mar 5, 2012 at 11:12 AM, Andy Doan <andy.doan(a)linaro.org> wrote: > On 03/02/2012 11:50 PM, Paul Larson wrote: > >> On Thu, Mar 1, 2012 at 4:54 PM, Andy Doan <andy.doan(a)linaro.org >> <mailto:andy.doan@linaro.org>> wrote: >> >> This email spans 3 areas and I wasn't sure who'd be interested. Feel >> free to add people if you'd like. >> >> I just spent the day getting the coremark benchmark to run under >> lava-android-test and wanted to share my findings and methodology. >> >> Neat! >> >> The key obstacle is that coremark requires a registered download. ie >> - you can't just throw this in the Android build and let the world >> use it. This is what makes the whole process trickier than normal >> "androidify + lavaitize" something. >> >> Well, hopefully not too much. A couple of observations here. First off, >> feel free to tell the LAVA team that you have a tarball you want to host >> for download into lava, inside the lava infrastructure so that it will >> be available to LAVA, but not outside. We have a similar situation with >> the binary drivers needed for panda builds. The scripts that the >> Android team put together were useful for getting started, but certainly >> not something we'd want to work with since it required interaction. >> What we ended up doing was building a tarball of everything it >> installed, and hosting it inside the lab. We could do a similar thing >> with coremark so that it's available for lava jobs, but not for public >> download. >> >> We could merge something like this in lava-android-test, but if so, we >> should include instructions in case anyone outside linaro wants to use >> it. To use it, they would have to host coremark themselves since we >> can't provide it. Another option is to do it out of tree, but while >> lava-test supports out-of-tree tests, it so far hasn't been a priority >> to push this feature in to lava-android-test since the current push from >> Zach's team has been to include all their tests. I've expected that >> there will eventually be some things like this where that's not really >> possible though, and we have a blueprint to add out-of-tree support to >> lava-android-test. If this is a model you would need, just let me know >> and I can bump the priority on that. >> > > My current code was done for maximum flexibility. It could be checked into > lava-android-test, or we could keep it out-of-tree to avoid confusion for > people who'd think they could easily run it. I'm leaning to out of tree, > but don't really care. > > The question I'm thinking about now is about the job submission to LAVA. > I'm thinking of an approach where we create a new dispatcher command that > would be semi-generic for all restricted tests and look like: > > { > "command": "lava_android_test_install_**restricted", > "parameters": { > "tests": ["coremark"], > "install_options": ["coremark_url=http://user:**pass@1.1.1 > /coremark-linaro4.6"**] > } > }, > > Why would it need a _restricted version of the command? I don't think that's necessary. > I have one security concern with this approach: Do we enforce any type of > security about who can view the job definitions in LAVA? ie - if anyone > could see the job definition then they'd be able to see how they could > download the restricted file. > I don't think that's a problem. In fact, what I'm suggesting is to simply have it available as a download from our NAS system in the lab, that is behind the firewall and not exposed. You'll need to get us to put the file there, but then it wouldn't need to be behind yet another layer of security. In fact, as I'm thinking about this, I don't even see a need for an out-of-tree test support in lava-android-test. The out-of-tree support is needed in lava-test because it's getting reinstalled every time. With lava-android-test, it could simply be a python module that we install one time and update as needed, then that test would be available on our server. If anyone else wanted to use it, they could, but would need to specify their own location for getting the coremark binaries. Thanks, Paul Larson

14 years, 1 month

Re: [Linaro-validation] Getting output from DUT through lava-dispatch

by Zygmunt Krynicki

On 02/27/2012 09:02 PM, Mustafa Faraj wrote: > Hi Andy and Zygmunt, > > I am working with lava-dispatch and trying to write my own test > commands. For my use case, I would like to get the full output of the > tests that run on the DUT (Overo board), as opposed to only the lines > matching the self.proc.pexpect(pattern). I dug a bit through the code > and saw that the proc's logfile is defined as a SerialIO class, but I am > not sure how to get the full output through that. How do you recommend > that I go about that? I'm CC-ing this to linaro-validation. Normally after the test is done you can see both the per-test command and full serial log. Is that what you need? Thanks ZK

14 years, 1 month

Should we use Travis for LAVA

by Zygmunt Krynicki

Hi. A poke in the eye, should we try using travis to test lava? http://about.travis-ci.org/docs/user/languages/python/ Thanks ZK

14 years, 1 month

← Newer
1
...
75
76
77
78
79
80
81
82
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation