Hello all,
We have some scheduled downtime on snapshots.linaro.org.
This has been been planned for Friday 11th October at 3PM (UTC +1).
Downtime should be around 1 hour, hopefully shorter.
Will announce a email once maintenance is complete.
Thanks
Ben Copeland
Hi Linaro Validation team, Ana, Shawn, Anton, Avi, Andreas, Henrik, Dexter,
Andrew, Andre, Francesco, Adam, John, Chad, Marco, Steve, David, Thibaut,
Jonathan and Anthony,
Your projects (LAVA dispatcher, Dexy, Checkfort, n3d, BaculaFS, Pymbolic,
Pycircuit, cuisine_sweet, notch.agent, BigJob, pyexeccontrol, BladeRunner,
kforgeinstall, bishop, hydrat, DoFler, SFLvault, Stylus2x, deployer, and
pIDLy) all use the Pexpect module in one way or another.
Pexpect development has been dormant for a long time, but Jeff Quast and I
have just taken over its maintenance, and we're planning to make a new
release, adding a unicode API and Python 3 support. Although we're giving
this a new major version number, we do intend to keep backwards
compatibility.
If you've got a few minutes to spare, please could you download the latest
beta release, and exercise it with the parts of your code that use pexpect?
You can get the beta from:
https://github.com/pexpect/pexpect/releases/
If you see any regressions, please drop me an e-mail or file an issue at:
https://github.com/pexpect/pexpect/issues
We hope to push the release out in the next couple of weeks, but we'll do
our best to fix any problems people find before the release.
We've also moved the documentation of Pexpect to Readthedocs:
http://pexpect.readthedocs.org/
Thank-you,
Thomas Kluyver
On Tue, 8 Oct 2013 17:48:18 +0100
Dean Arnold <Dean.Arnold(a)arm.com> wrote:
> Hi Neil,
*Please* keep the list in the loop. I am not the sole point of contact
for this issue.
> The reason the scheduler log wasn't present is because my scheduler
> is crashing when I try to run it. Unfortunately the upstart commands
> didn't seem to want to output the failure to me.
It's a daemon, stdout and stderr are closed for all daemons - this
isn't confined to upstart. That is why I advised running the command
manually....
> When I attempted to launch the scheduler manually I was able to
> detect from the command line output that the initial problem was due
> to the postgres database not accepting TCP/IP connections on port
> 5432.
If you had an older version of postgresql ever installed at the same
time as a new version, postgresql will change that to 5433, then 5434
and so on for each one. This is standard postgresql behaviour and
nothing to do with LAVA.
> WARNING:root:This instance will not use sentry as SENTRY_DSN is not
> configured execvp: No such file or directory
> 2013-10-08 16:26:48,742 [ERROR]
> [lava_scheduler_daemon.job.SchedulerMonitorPP] scheduler monitor for
> pdswlava-vetc2-04 crashed: [Failure instance: Traceback (failure with
> no frames): <class 'twisted.internet.error.ProcessTerminated'>: A
> process has ended with a probable error condition: process ended with
> exit code 1. ] 2013-10-08 16:26:48,864 [ERROR] [sentry.errors] No
> servers configured, and sentry not installed. Cannot send message No
> servers configured, and sentry not installed. Cannot send message
Looks like a django error - your database connection is still not
correct.
> Is this something you have seen before?
No. I just googled SENTRY_DSN.
> Did you need to install any
> extra packages outside of what the lava-deployment-tool provides when
> running the setupworker/installworker commands?
No - however, if you have a postgresql server installed on the worker,
it is not required.
> Could I have missed
> a configuration step somewhere?
The initial use of setup instead of setupworker could have messed up
the database configuration on the worker. It just looks like the worker
cannot find the database.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Hi Dave,
I am hoping that probably you might be working on this ticket https://cards.linaro.org/browse/CARD-832 (got from Kanta, although I get permission denied when accessing the card), if not please anyone in the wider validation email group please redirect me appropriately.
With 13.09 we do have the new Base model variants released and with the above ticket we expect to have LAVA support for these models also.
Since we do have a local LAVA instance, I would like to figure out how we can pick the upgrades and apply to our local instance. Could anyone please advice when we could expect this upgrade to LAVA for supporting 64-bit base models, coming our way?
I want to get Dean a heads-up in terms of his plan to get our setup upgraded.
Thanks
Basil Eljuse...
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Hi all,
Can anyone help Dean at ARM out here?
Thanks
Dave
On 2 Oct 2013, at 15:49, Dean Arnold <Dean.Arnold(a)arm.com> wrote:
> Hi Dave/Matt,
>
> I have recently installed a remote worker on a new server, but I am unable to get it to talk to the master properly. I just wanted to check if what I have done is correct and if I had missed anything.
>
> Here are the steps I followed..
>
> My master server (pdsw-lava) is running a "production" instance of LAVA. I have updated the LAVA version to the latest using the git lava-deployement-tool.
>
> On new dispatcher (pdsw-lava-dispatcher01), using the latest git lava-deployement-tool, I installed the remote worker in the following way:
> $ lava-deployment-tool setup
> $ lava-deployment-tool installworker production
>
> Giving the IP address, hostname etc of the master when prompted along with the database info.
>
> When instructed to do the following..
>
> Running installation step remote_fs
> Configuring remote fileystem access production
> Please add the following public key into your master node's
> /srv/lava/instances/production/home/.ssh/authorized_keys file
>
> -------- WORKER NODE PUBLIC KEY STARTS HERE --------
> ssh-rsa .... ssh key used by LAVA for sshfs
> -------- WORKER NODE PUBLIC KEY ENDS HERE --------
>
> I had to create the /home/.ssh/authorized_keys file and directories under /srv/lava/instances/production/ on the master as they never existed.
>
> On pdsw-lava-dispatcher01 I created these directories:
> /srv/lava/instances/production/etc/lava-dispatcher/devices
> /srv/lava/instances/production/etc/lava-dispatcher/device-types
>
> and SCP'd the contents of /srv/lava/instances/production/etc/lava-dispatcher/device-types over from my master server.
>
> I removed the device config file pdswlava-vetc2-06.conf from /srv/lava/instances/production/etc/lava-dispatcher/devices on the master and added this to the same directory on the remote worker.
>
> I then restarted lava on both servers (just in case it was needed).
>
> I submitted a job on the master using pdswlava-vetc2-06 and this stayed in the "submitted" state but never did anything.
>
> After a while I removed the pdswlava-vetc2-06.conf file from /srv/lava/instances/production/etc/lava-dispatcher/devices on the remote worker and added this back into the same directory on the master. Instantly the job ran as expected.
>
> Can you think of anything I have missed in my setup which would prevent the master and worker from talking to each other? Is there anything I should be seeing in the web UI of the master to indicate it is connected to a remote worker, or is there an easy way to test the connection between the two?
>
> Apologies if I have just done something really dumb, it wouldn't be the first time :)
>
> Cheers
> Dean
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
>
CC'ing LAVA guys
On 26 September 2013 15:46, Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote:
> As I understand this log right:
> https://validation.linaro.org/scheduler/job/74753/log_file
>
> Arndale booted with standard LE rootfs. Then there is wget rootfs and chroot
> to it.
> And of course any commands under chroot will fail.
>
> So I think for now it's impossible to run BE in lava boards unless we will
> set up any board with
> BE env or remove chroot from set up scripts.
>
> Is chroot really needed for this? :
> chroot /mnt/root ln -sf /bin/true /usr/sbin/flash-kernel
>
> Thank you,
> Maxim.
Sorry I have an error at the end.
May some one help me?
BEST REGARDS
NOVELLO G.
The file is not there I THINK THAT IT PRESENT IN THE TARGER
WE HAVE TO MOVE IT.
umount /mnt
bash-4.2 [rc=0]# <LAVA_DISPATCHER>2013-10-05 01:15:33 PM INFO: General
Exception: [Errno 2] No such file or directory:
u'/srv/lava/instances/dev/var/www/lava-server/images/tmpqF0IvL/1380971716.73/lava/results/swcontext/build.txt'
<LAVA_DISPATCHER>2013-10-05 01:15:33 PM DEBUG: finally status fail
<LAVA_DISPATCHER>2013-10-05 01:15:33 PM WARNING: [ACTION-E]
lava_test_shell is finished with error ([Errno 2] No such file or
directory:
u'/srv/lava/instances/dev/var/www/lava-server/images/tmpqF0IvL/1380971716.73/lava/results/swcontext/build.txt').
ErrorMessage: [Errno 2] No such file or directory:
u'/srv/lava/instances/dev/var/www/lava-server/images/tmpqF0IvL/1380971716.73/lava/results/swcontext/build.txt'
Lava failed at action lava_test_shell with error:[Errno 2] No such file
or directory:
u'/srv/lava/instances/dev/var/www/lava-server/images/tmpqF0IvL/1380971716.73/lava/results/swcontext/build.txt'
Traceback (most recent call last):
File
"/srv/lava/.cache/git-cache/exports/lava-dispatcher/2013-09-23-224cd02/lava_dispatcher/job.py",
line 254, in run
action.run(**params)
File
"/srv/lava/.cache/git-cache/exports/lava-dispatcher/2013-09-23-224cd02/lava_dispatcher/actions/lava_test_shell.py",
line 566, in run
self._bundle_results(target, signal_director, testdefs_by_uuid)
File
"/srv/lava/.cache/git-cache/exports/lava-dispatcher/2013-09-23-224cd02/lava_dispatcher/actions/lava_test_shell.py",
line 716, in _bundle_results
bundle = lava_test_shell.get_bundle(results_dir, testdefs_by_uuid)
File
"/srv/lava/.cache/git-cache/exports/lava-dispatcher/2013-09-23-224cd02/lava_dispatcher/lava_test_shell.py",
line 369, in get_bundle
build = _read_content(os.path.join(results_dir, 'swcontext/build.txt'))
File "/srv/lava/.cache/git-cache/exports/lava-dispatche
Hello everyone,
TL;DR: as announced previously [1], since today LAVA development happens
on git.
Some points I would like to highlight:
- Please do not send bzr merge proposals against the old bzr
repositories on Launchpad. In the next days those repositories will be
closed down (assuming that's at all possible - any tips appreciated)
to make it impossible for people to send those.
- The procedure for submitting changes to LAVA is now using the gerrit
instance at staging.review.linaro.org, which should be available as
review.linaro.org at some point in the future. As mentioned
previously, we are dogfooding the system before providing it as an
official service for the wider community, so bear with me and please
let us know of any problems or questions you might have.
Documentation for staging.review.linaro.org is available at:
https://wiki.linaro.org/Platform/LAVA/Infrastructure/StagingReview
- the source for source code is git.linaro.org, under the lava/
namespace.
As we already discussed, the LAVA team will be actually using
staging.git.linaro.org as part of the aforementioned dogfooding
exercise. However we configured sync on push in the lava repositories
so that git.linaro.org and staging.git.linaro.org will always contain
exactly the same code.
- Launchpad is still used for bug management. Please continue submitting
bugs there.
- Unrelated to the move to git, you will notice two important changes in
LAVA that I think it's useful to mention:
The first change is that now we have a new theme[2] which IMO makes
LAVA look a lot nicer. It's not a designer's job, but is an
improvement. ;-)
The second change is that now every LAVA instance hosts full
documentation _generated from the actual code it is running_, linked
from the "Documentation" link in the top menu[3]. It's still the same
old documentation we had before on .readthedocs.org, but this is just
the first visible step of the effort the LAVA team is putting in the
documentation area. Expect exciting news about this in the future.
1. http://lists.linaro.org/pipermail/linaro-validation/2013-September/002067.h…
2. see it for yourself at http://validation.linaro.org/
3. e.g. http://validation.linaro.org/static/docs/
Cheers,
--
Antonio Terceiro
Software Engineer - Linaro
http://www.linaro.org
SORRY i need some information:
a) There is a way to answer the the login and password of the target
via lava-dispatcher?
b)I 'm making a new configuration file for wandboard is better to use
master or
client_type = bootloader
client_type = master
in the wand.conf file?
Best regards
Novello G.
Hi all,
My wife is currently at the hospital with a broken toe or toes. I'm home baby sitting and have no idea when she'll be back. On that basis I have no idea if/when I'll be in the office tomorrow.
Thanks
Dave
