On Tue, Jul 31, 2012 at 8:40 AM, Marcin Juszkiewicz
<marcin.juszkiewicz@linaro.org> wrote:
W dniu 30.07.2012 16:10, Alexander Sack pisze:
> Hi,
>
> big items we need to sort out:
>
> + linaro-media-create install support
> + lava-test support
> + lava support
I had some thought on it (OpenEmbedded builds and LAVA) and due to that
here are some questions.
I haven't heard much about our OE plans, but would like to... are there further details of what we're looking to do here somewhere? Is this just for v8, or for other things too?
1. Do tested image needs to have LAVA client code installed?
If it does then I would have to add LAVA client components into
OpenEmbedded because I can not use Ubuntu packages as they are not
compatible with each other.
Not really, lava-test can be installed easily on the target once it's deployed, but to the best of my knowledge, I don't think anyone's really tried running lava-test under OE. We would need pip to install it, and possibly a few other python dependencies. The bigger problem here is that lava-test was always fairly dependent on apt for a number of things. This can be worked around telling it not to gather a list of packages installed when it runs, but many of the tests rely on dependency installation via packages.
One of the things I've raised in the past that we should look at is consolidation of lava-test and lava-android-test by means of a host driven test framework, and this is one reason why. Looking to the future, I think we want to support more than ubuntu and android, and maybe even more than OE. Adding a lava-something-test every time is not going to be the best way to go about it.
2. Does lava build require rootfs + hwpack or can boot with just rootfs?
Rootfs will contain kernel in /boot/uImage and u-boot configuration in
/boot/boot.scr (or other defined location). If hwpack is required then I
will have to create one with OE and add support for them in l-m-c (as we
can not use Ubuntu packages for things other than kernel/bootloader
cause there is no warranty about binary compatibility).
Certainly the dispatcher will have to support another means of installation, just like we have to for Android images. If linaro-media-create is used, then this makes things slightly better, but I'm sure it'll need at least a bit of special handling in the dispatcher, though probably not as bad as android was. I don't foresee a big problem here.
> I think if the fast model route is blocked we should take the pain to
> work on real board.
For now using real board is less pain then using fast model. I have real
boards available at home so can test images on them.
_______________________________________________
linaro-validation mailing list
linaro-validation@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-validation