As part of the wiki updates we were making, I've moved our meeting logs
and templates over to:
https://wiki.linaro.org/Platform/LAVA/Meetings/
I think I've fixed the backlinks, so you'll just need to update your
bookmarks.
Hi Prakash,
Can you (a) please put in properly qualified URLs next time (you didn't have the ":" after http) and (b) send me the output from lava-master-image-info, rather than lava-device-info.
Thanks
Dave
On 18 Sep 2012, at 06:44, Prakash Ranjan wrote:
> http//paste.ubuntu.com/1212330
Hello,
I was working on lava-dispatcher today, and I found out that is has
(few) unit tests under lava_dispatchers/tests/, and I was wondering if
is there a pattern/guideline/etc on how unit tests are used acrosss the
lava components. In special:
1) How are we supposed to run the unit tests? I found a .testr.conf file
in lava-dispatcher, what gave me some hints, so I started doing
$ python -m subunit.run lava_dispatcher.tests.test_suite
The output of that was too verbose for my taste, so I ended up using
$ python -m unittest lava_dispatcher.tests.test_suite
which provides a cleaner output.
2) I had problems running these tests within the system (a VM) where I
had lava installed, after activating the virtualenv-like environment
with `. /src/lava/instances/$inst/bin/activate`. The commands above were
always running the code that was installed in the lava instance instead
of the code in the current directory. I guess that is related to the
fact that I did not inject that directory to be used by the instance,
right?
This made me end up running the tests on my main system, where there was
nothing installed - only the lava-dispatcher sources + the basic Python
stuff.
--
Antonio Terceiro
Software Engineer - Linaro
http://www.linaro.org
W dniu 14.09.2012 16:46, Andy Doan pisze:
> On 09/14/2012 09:41 AM, Zygmunt Krynicki wrote:
>> W dniu 14.09.2012 16:31, Andy Doan pisze:
>>> On 09/12/2012 08:39 PM, Michael Hudson-Doyle wrote:
>>>> Andy wrote [quoting went funny somewhere]:
>>>>
>>>>> Here's a way we could do this in lava-test:
>>>>>
>>>>> <http://bazaar.launchpad.net/~doanac/lava-test/software.sources-support/revi…>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Its minimal overhead (basically none) for the test itself. However,
>>>>> Michael may find it a bit odd how a bolted it on to our framework.
>>>>> Thoughts?
>>>>
>>>> Seems kind of OK. I don't think I have deep conceptual insight into
>>>> the
>>>> problem being solved here though :-)
>>>
>>> Yesterday during the LAVA team meeting, we came up with a better way to
>>> do this in code. It still doesn't cover the "99%" case, but it makes
>>> things more transparent to the test-definition. MP to follow soon.
>>
>> Cool, could you briefly describe this?
>
> Basically add something to the installer action that lets it clone repos
> rather than having be some command in the testdef we are unaware of.
+1 that's saner.
I'm worried about the lack of sensible API for stages such as this to
feed this information deeper into the core (to the initial bundle to be
precise)
PS: CCing the list again
ZK
--
Zygmunt Krynicki
s/Linaro Validation Team/Canonical Certification Team/
s/Validation/Android/
move the discussion to the ml.
---------- Forwarded message ----------
On 09/11/2012 10:22 AM, Fathi Boudra wrote:
>>
>> 3.2) knowing the test source. I found this pretty interesting and did some
>> >poking around. We have the concept of a "software context" in LAVA:
>> >
>> ><http://validation.linaro.org/lava-server/dashboard/streams/private/team/lin…>
>> >
>> >However, as it stands, we only populate it with dpkg information. Even if
>> >your core test code was a package, I've seen enough threads on going from
>> >package to source on linaro-dev that I'll assume that's useless. Within the
>> >software context we have a structure that currently unused called "software
>> >sources". I think this would enable drilling down to what you are after.
>> >
>> >The big question is*how* we populate that information. Based on the
>>
>> >I think we would want to add some field where you could
>> >pass this to the Test object you create. That would be pretty simple. I'm
>> >not sure if that would be ideal which is why I added Michael to the thread.
>> >
>> >So, just to make sure: does addressing 3.2 first make sense?
>
> It make sense. If we want to track the test sources, we want the software
> context/source references feature.
> Now, how can we populate it (Project/VCS/branch/tag or revision)?
>
Here's a way we could do this in lava-test:
<http://bazaar.launchpad.net/~doanac/lava-test/software.sources-support/revi…>
Its minimal overhead (basically none) for the test itself. However,
Michael may find it a bit odd how a bolted it on to our framework.
Thoughts?
Hi all,
Just to let you know that we've hit some technical issues, and so v.l.o is still down for the moment. Zen (the ISP) are working on fixing it, but I have no ETA for the moment. If the issues can not be resolved by close of play today, I will be putting the ADSL line back on.
I'll keep you posted.
Thanks
Dave
Dave Pigott
Validation Engineer
T: +44 1223 40 00 63 | M +44 7940 45 93 44
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi all,
The path is never simple. Zen scheduled a set up call for 10AM this morning and then didn't call. I sent an e-mail complaining and the work has now been re-scheduled for 10AM tomorrow.
Many apologies for the inconvenience.
Thanks
Dave
Dave Pigott
Validation Engineer
T: +44 1223 40 00 63 | M +44 7940 45 93 44
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi Mark,
It was really useful for me to meet up and present to you guys yesterday, and I hope, likewise, that they found it useful.
As per our conversation, here is the list of resources for Linaro:
Linaro wiki: wiki.linaro.org
LAVA web site: validation.linaro.org
Daily code snapshots: snapshots.linaro.org
Linaro releases: releases.linaro.org
Android build: android-build.linaro.org
You can get all the information for our Copenhagen Connect event here: http://connect.linaro.org/events/event/lce12-copenhagen/
Finally, the validation mailing list is linaro-validation(a)lists.linaro.org
Please pass this on to all those who attended the meeting.
Secondly, I'd love to come and do a lunch and learn on LAVA. Let me know when is a good time, and try to give me a couple of weeks notice!
Good to see you, and thanks again
Dave
Dave Pigott
Validation Engineer
T: +44 1223 40 00 63 | M +44 7940 45 93 44
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
As you know the LAVA team currently has alternating weekly meeting
times. The intent was to have one that worked well for our team members
in Asian timezones and one that worked well for European/American timezones.
We now have no one working in an official capacity in Asian, so that
meeting time has become just about useless. I'd like to recommend change
the current bi-weekly meeting time from:
Friday 01:00 UTC
to:
Thursday 20:00 UTC
This would work well because Michael, Antonio and myself could attend
this slot.
The other meeting time on Fridays at 13:00 UTC will continue to work
well since Antonio, Dave, and myself.
Any objections?
-andy