linaro-validation June 2012

linaro-validation@lists.linaro.org

26 participants
41 discussions

by Michael Hudson-Doyle

Hi all, I've spent a couple of hours hacking together a script that generates a report around which versions of each LAVA component is deployed, and also how many revisions have not been released. You can see it here: http://validation.linaro.org/deployment-report.xhtml It's updated every hour from cron, or you can run bin/make-deployment-report as instance-manager on control to update it. It's a bit held together with sticky tape in places, but I hope it will be useful. Cheers, mwh

13 years

Re: [Linaro-validation] Can we use mmcblk0p8?

by Paul Larson

On Mon, Jun 18, 2012 at 8:32 AM, Marcin Juszkiewicz < marcin.juszkiewicz(a)linaro.org> wrote: > W dniu 18.06.2012 15:02, YongQin Liu pisze: > > Hi, Saugata > > > > We have a problem to use the mmcblk0p8 partition, do you know if we > > can use it, and how can we use it? > > > > I created the 8th partition with fdisk command and the 8th partition > > is listed in the output of fdisk -l command but it is not listed in > > /proc/partitions file, even after reboot And also I can't use > > mkfs.vfat -n sdcard /dev/mmcblk0p8 to format. > > > > Could you give me some help about this? > > Check /dev/mmcblk1p0 node number for answer. IIRC there is limited > amount of partitions on MMC cards which Linux handles (a bit stupid > limit imho). > Yes it is stupid, and it's bit us before [1]. The better thing is to rethink your partitioning and see if you can come up with a better way to lay it out. It's worked for us so far, but it's been tight on the lava side due to the number of partitions that android wants, and especially with the annoying hardcoded partition numbers that android uses. The max partitions can be changed but requires rebuilding your kernel MMC_BLOCK_MINORS on *every* machine that you will ever need to mess with that mmc card on. So if you are building a master image on your laptop, you'll need to rebuild that one, the kernels for all platform images you want to boot on it, etc. [1] http://linuxtesting.blogspot.com/2011/03/max-partitions-on-mmc.html Thanks, Paul Larson

13 years

The future of lava core

by Zygmunt Krynicki

Hi. I'd like to ask about the future of the lava-core project. There are some branches that are waiting for review, that are not being reviewed. Recently my membership in the linaro-validation team was canceled and I cannot even land them myself. Since from what I've heard lava-core is not of active interest to the validation team I'd like to ask for a way to continue hacking on the project in my spare time that would not require and interaction from Linaro. I see a few options: 1) We could create lava-core-hackers team that I would be a member of, so that I can continue merging the code as I see fit 2) We could change the ownership of the project so that is is a non-Linaro project (technically I would own it but I'm open to any community participation as I cannot work on anything full time) 3) I could fork lava-core and do 2) myself (we could vote on a name if anyone is interested) I'd like to know what is your input in this. Thanks -- Zygmunt Krynicki Linaro Validation Team s/Validation/Android/

13 years

Can we use mmcblk0p8?

by YongQin Liu

Hi, Saugata We have a problem to use the mmcblk0p8 partition, do you know if we can use it, and how can we use it? I created the 8th partition with fdisk command and the 8th partition is listed in the output of fdisk -l command but it is not listed in /proc/partitions file, even after reboot And also I can't use mkfs.vfat -n sdcard /dev/mmcblk0p8 to format. Could you give me some help about this? Thanks, Yongqin Liu

13 years

sorry what i can do to add a job

by novello

I have installed the lava-deployment-tools in may pc 192.168.1.5 (IP address) From my pc I woude like to add a job. I have followed the indication: I have added $ lava-tool auth-add http://novellogp64@192.168.1.5/RPC2/ and then I have: lava-tool submit-job http://user@example.com/lava-server/RPC2/ jobfile.json (embedded)novello@qc:/srv/lava/instances/embedded$ lava-tool submit-job http://novellogp64@192.168.1.5/RPC2/ jobfile1.json EXPERIMENTAL - SUBJECT TO CHANGE (See --experimental-notice for more info) ERROR: <Fault 403: "Permission denied. User u'novellogp64' does not have the 'lava_scheduler_app.add_testjob' permission. Contact the administrators."> (embedded)novello@qc:/srv/lava/instances/embedded$

13 years

Re: [Linaro-validation] cbuild overview

by Michael Hope

On 12 June 2012 04:43, Joey STANFORD <joey(a)linaro.org> wrote: > Sweet thanks. > > One more task for you sir which should be easy and straightforward.... > > Nuke your sandbox. :-) You have a bunch of awesome stuff hidden away > that really should be under a better location in the wiki. For > example, this cbuild write-up should be under WorkingGroups/Toolchain > especially since you already have > https://wiki.linaro.org/WorkingGroups/ToolChain/Benchmarks/RunningBenchmark… I used a small yield device on the cbuild page, creating a landing crater at: https://wiki.linaro.org/WorkingGroups/ToolChain/CBuild and: https://wiki.linaro.org/WorkingGroups/ToolChain/CBuild/Overview -- Michael

13 years

using latest lava-android-test

by Andy Doan

From IRC earlier: <liuyq> asac, :( it will not work now, the branches has not been deployed. Also I haven't merged yet:( <asac> liuyq: we have to always deployt? thought we always pull latest from bzr <asac> we should always have access to all the latest tests without another deploy step <asac> doanac: ^^ new requirement it seems I wanted to discuss here and make sure I'm clear. We basically need to stop using the lava-android-test published to pip and start always pulling lava-android-test from trunk?

13 years

Is reboot necessary when andoid test timeout in lava

by YongQin Liu

Hi, Zach I am now working on a bp that adding the timeout process for android test action in lava. I am not sure if we should reboot the android image when the test run for a time longer than expected. so I'd like to know your opinion which you want to do. a. stop the test and restart the android image, then continue the next test b. stop the test and continue the next test c. others Like we submit a job to lava for running "monkey,glmark2,0xbench" test on android, while glmark2 test runs for a longer time than expected(like in which case if we don't stop it it will run for ever). In this case which one would you like? reboot the android and continue the next 0xbench test, or just stopped the glmark2 test and continue to run the next 0xbench test? Thanks, Yongqin Liu

13 years

2012.05 planning: Move existing test defintions away from LAVA test to a dedicated project

by Zygmunt Krynicki

Hi, please have a look at [1] and discuss this on the mailing list. [1] https://blueprints.launchpad.net/lava-test/+spec/lava-test-dedicated-test-r… -- Zygmunt Krynicki Linaro Validation Team

13 years

Switching LAVA Deployment to buildout

by Michael Hudson-Doyle

Those of you who have been around for a while will know that we used to package LAVA as Debian packages. This had its problems and we switched over to the world of pip and virtualenv and lava-deployment-tool. Unfortunately, pip and virtualenv have not really given us the control we need to be confident in our deployments, and so I'm proposing to change again, this time to zc.buildout. This is less of a change than the switch away from debs -- instances of LAVA will still be a concept and the lava-deployment-tool script will still be used, at least for now. The way buildout works is that there is a config file that specifies how -- reproducibly! -- to assemble various pieces into a deployment. I have a branch of lava-server at lp:~mwhudson/lava-server/use-buildout that contains such a config file (and various other related bits and pieces), and a branch of lava-deployment-tool that creates a buildout-based deployment. An instance on disk in the new world is similar to but not the same as an instance is today. In particular it is not a virtual environment -- although for compatibility, it looks like one. There is still a $LAVA_INSTANCE/bin/activate script that you can source in bash to put that instance's scripts at the front of your $PATH. Inside an instance, the etc, run, tmp and var directories server the same function as they do today. There is also a new directory, code. The code directory contains a number of subdirectories, one for each revno of lava-server that has been installed into that instance, and a symlink 'current' that points to the currently active one. There are now two merge proposals on LP: https://code.launchpad.net/~mwhudson/lava-server/use-buildout/+merge/109768 https://code.launchpad.net/~mwhudson/lava-deployment-tool/use-buildout/+mer… I've made an effort to update the documentation in l-d-t's README, and I've put an htmlified version of this file online at http://people.linaro.org/~mwh/ldt.html so that might be a good place to start. Cheers, mwh

13 years

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation June 2012