https://lists.linaro.org/pipermail/lava-announce/2015-September/000000.html
The lava-announce mailing list has existed for some time but after
discussions at SFO15, the list has taken on a particular purpose - to
raise awareness of the upcoming refactoring, to announce when
significant improvements are made in the refactoring and later to
announce when parts of the current dispatcher support are to begin
migrating to the new codebase.
There is a new list for users to discuss problems (where users includes
test writers and admins of instances outside Linaro) called
lava-users. [0]
This list is to be renamed to lava-devel for discussions directly
relating to the refactoring, new support, use cases and discussions
about the actual migrations themselves. linaro-validation is to remain
as an alias, so your current email filtering will continue. At some
point during the migration, the alias for linaro-validation pointing at
lava-devel will be dropped. That will be announced here and on the
lava-announce mailing list.
The division between lava-users and lava-devel is a guidance, however,
as the migration gets under way, it is likely that this list will
become dominated by discussions of how to adapt existing tests to the
new methods rather than support or discussion of deployments using the
current dispatcher.
lava-announce is recommended for anyone using LAVA in any way,
especially admins. It will carry announcements from the LAVA software
team on new support in the refactoring, new use case implementations,
details of upcoming migrations and other announcements. The Reply-To of
lava-announce is set to this list, so discussion of announcements will
happen here.
These new mailing lists will be included in the documentation included
in next release of the LAVA software (2015.10). Documentation of the
new code is already in the master branch of lava-server and installed
via the lava-server-doc package and the initial code for the
refactoring is being developed in parallel with the current code. This
list will be used to announce when the refactoring codebase is ready
for admins to begin migrating tests and test writers to the new code
and methods - currently, the new dispatcher is developer only. At
SFO15, there was also an update on the state of the refactoring. [1]
lava-announce will continue to be a low volume list. Reply-To has been
set to this list (transparently migrating to lava-devel once the
linaro-validation alias is in place).
The LAVA developers would ask that everyone running LAVA would
subscribe to at least the lava-announce mailing list, to help with the
migration to the new support.
Videos will be available for most meetings at SFO15 in due course. The
slides are already available.
[0] https://sfo15.pathable.com/meetings/302656
[1] https://sfo15.pathable.com/meetings/303074
--
Neil Williams
=============
Tech Lead LAVA Software
http://www.linux.codehelp.co.uk/
How to tell LAVA to not try an update the firmware my juno-r1 board?
The default juno device type points to a tarball[1] it uses to
update/replace the juno firmware, unfortunately, that tarball seems to
only be configured for Juno, not the juno R1.
After and unpack/flash/reboot, the juno board fails to boot with:
ERROR: File not found \MB\HBI0262C\board.txt
Note the 'C' in the board name HBI0262C, whereas the tarball only
contains HBI0262B.
I have flashed working firmware onto my Juno R1 and would like LAVA to
leave it alone. Is there a way to do that?
Kevin
[1] http://images.validation.linaro.org/juno/board-recovery-image.tgz
Hello,
How does one do a partial-override of boot_cmds from the device file?
I have a panda and want to use the shipping device-type, except that I
need to 'setenv usbethaddr ...' before any of the other commands.
I can fix this by copy/paste'ing the whole boot_cmds_ramdisk section
from the device-type into my device file, but what I really want to do
to is just use the ones from the device-type with minor modifications
(and ensure I get updates to the production device-type when they
happen)
Something like this (assuming python ConfigParser style formatting) in
the device file would be useful:
boot_cmds_ramdisk =
setenv usbethaddr <MAC addr>,
%(boot_cmds_ramdisk)s
Is there a good way of doing that?
Kevin
Hello everyone,
Collabora has been working on `lqa', a tool to submit and manage LAVA
jobs, which helps to get many of the LAVA job administration and
monitoring tasks conveniently done from the command line.
`lqa' brings a new API, lqa_api python module, a complete set of classes
to easily interact with LAVA and offering at the same time a clean API
on top of which further applications can be built upon (like `lqa' itself).
It has a templating system (using jinja2 package) that allows to use
variables in json job files (in future could be expanded to support
yaml), specifying their values either from a profile file or directly
from the command line making possible the dynamic assignments of
template variables during the `lqa' command execution. The templating
mechanism allows to handle groups of jobs, therefore it makes it easier
to submit jobs in bulk.
`lqa' also features a flexible profile system (in YAML) which allows to
specify a 'main-profile' from which further sub-profiles can inherit
values, avoiding information duplication between similar profiles.
Other of the current features include:
- Test report generation with the 'analyse' subcommand.
- Polling to check for job completion.
- All the operations offer logging capabilities.
- Independent profile and configuration files.
We invite everyone to check out its official git repo at:
https://git.collabora.com/cgit/singularity/tools/lqa.git/
Suggestions and comments are welcome.
--- Luis
Hi, Dave
Our fvp build failed to boot on LAVA because of the failure of enabling adb
over tcp,
seems not able to get the ip address for the eth0 interface.
The failed job is here:
https://validation.linaro.org/scheduler/job/517934/log_file#L_1444
But the same build boot successfully on LAVA one day before:
https://validation.linaro.org/scheduler/job/515801/log_file#L_242
I am not sure if the problem is caused by configurations for device or
change of lava framework.
But could you please help to check the problem first?
--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android
