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
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
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/
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
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$
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?
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
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/109768https://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