linaro-validation

linaro-validation@lists.linaro.org

818 discussions

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

Re: [Linaro-validation] Switching LAVA Deployment to buildout

by Michael Hudson-Doyle

Abner Silva <abner(a)collabora.co.uk> writes: > Hi Michael, > > On Tue, 2012-06-12 at 17:07 +1200, Michael Hudson-Doyle wrote: >> 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. > > As I never worked with buildout before I was wondering if there was a > discussion around this topic before deciding to adopt this new > deployment approach. There was some internal discussion, but this is the first time it's been mentioned on a mailing list I guess. > I would like to read that and see what was discussed and what are the > main advantages of changing how to deploy Lava once again. Is it > available somewhere? No. Basically, as I've been the only person to do major deployments to v.l.o for several months now, I feel I'm in a pretty good position to make decisions about this! And I hate using the current scripts. I wanted to spend a little time with buildout before proposing that we use it to make sure it was worth proposing, and probably spent a little too long: I basically implemented everything except migration from existing deployments. > In case this change really happen, I believe that would be nice to have > some sort of tutorial teaching how to migrate your current setup and > deploy it with buildout, without loosing your database, etc. _Of course_ we will do this sort of thing (we need it for v.l.o!). Obviously, I don't know all the details of your deployment and so it's going to be a slightly stressful time when the change comes to be made -- I hope you can do lots of testing. I'm also happy to learn about details of your deployment and advise you on how to make the transition. > Also, I remember to have long conversations on IRC with you guys and > IIRC there was an agreement that Lava would also be released as deb > packages again, I don't know which conversations you're referring to here, I don't think I was involved. Certainly, in my position as owner of the technical plan, "package server components as debs again" is not on there. > so we would have an option to use pip or debs. How is that going? It's not. > Please, forgive me if I missed any important discussion. Well, you weren't on the phone calls Andy and I had to talk about this. I guess it's just part of the fun of open source: I am most motivated by the problems _I_ see, and fragility of deployment was one of those. I should say that nothing I am doing will prevent you from maintaining your own version of lava-deployment-tool that uses virtualenv & pip but as we won't be using this approach ourselves this might be more work for you in the long run. Cheers, mwh

13 years, 2 months

← Newer
1
...
66
67
68
69
70
71
72
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation