Hi.
I've just realized that we'll likely see issues when test images start showing up as armhf. Our master image compiler that builds a few of the tests is going to target armel.
I'd like to propose that we re-purpose the master image. I'd like to _stop_ using it for building software. That is: all lava-test install steps will be invoked in the _test_ image.
We can apply this without requesting our users to rewrite their test scenario definitions. I'd like to propose rewriting the scenario file to invoke any lava-test-install _after_ the boot test image step.
Thanks ZK
Hi,
On 11 March 2012 14:40, Zygmunt Krynicki wrote:
I've just realized that we'll likely see issues when test images start showing up as armhf. Our master image compiler that builds a few of the tests is going to target armel.
I'd like to propose that we re-purpose the master image. I'd like to _stop_ using it for building software. That is: all lava-test install steps will be invoked in the _test_ image.
We can apply this without requesting our users to rewrite their test scenario definitions. I'd like to propose rewriting the scenario file to invoke any lava-test-install _after_ the boot test image step.
I should hit this issue... very soon, we have preview armhf images targeting PandaBoard. I have a blueprint to hook those images to LAVA, still based on rootfs/hwpack (pre-built images coming soon).
W dniu 11.03.2012 13:51, Fathi Boudra pisze:
Hi,
On 11 March 2012 14:40, Zygmunt Krynicki wrote:
I've just realized that we'll likely see issues when test images start showing up as armhf. Our master image compiler that builds a few of the tests is going to target armel.
I'd like to propose that we re-purpose the master image. I'd like to _stop_ using it for building software. That is: all lava-test install steps will be invoked in the _test_ image.
We can apply this without requesting our users to rewrite their test scenario definitions. I'd like to propose rewriting the scenario file to invoke any lava-test-install _after_ the boot test image step.
I should hit this issue... very soon, we have preview armhf images targeting PandaBoard. I have a blueprint to hook those images to LAVA, still based on rootfs/hwpack (pre-built images coming soon).
Thanks for the update. I think we assumed too much about our master images. We should do more in the test image. I'd like to also tag tests that require building software somehow so that we can at least see how many tests are affected. If this is a large portion then perhaps we should look closer at how lava-test should abstract building so that other parts of the stack (above) know about it.
Thanks ZK
Well, try it but I'm not sure I understand where the issue is. When we compile test binaries, it'sfrom a cheroot of the test image.
- Paul Larson On Mar 11, 2012 7:51 AM, "Fathi Boudra" fathi.boudra@linaro.org wrote:
Hi,
On 11 March 2012 14:40, Zygmunt Krynicki wrote:
I've just realized that we'll likely see issues when test images start showing up as armhf. Our master image compiler that builds a few of the tests is going to target armel.
I'd like to propose that we re-purpose the master image. I'd like to
_stop_
using it for building software. That is: all lava-test install steps
will be
invoked in the _test_ image.
We can apply this without requesting our users to rewrite their test scenario definitions. I'd like to propose rewriting the scenario file to invoke any lava-test-install _after_ the boot test image step.
I should hit this issue... very soon, we have preview armhf images targeting PandaBoard. I have a blueprint to hook those images to LAVA, still based on rootfs/hwpack (pre-built images coming soon).
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
W dniu 11.03.2012 15:34, Paul Larson pisze:
Well, try it but I'm not sure I understand where the issue is. When we compile test binaries, it'sfrom a cheroot of the test image.
Hmm, I did not remember this. I still think we may hit some issues. Is there a dependency on the kernel to have hard-float userspace?
Thanks ZK
On 11 March 2012 19:03, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
W dniu 11.03.2012 15:34, Paul Larson pisze:
Well, try it but I'm not sure I understand where the issue is. When we compile test binaries, it'sfrom a cheroot of the test image.
Hmm, I did not remember this. I still think we may hit some issues. Is there a dependency on the kernel to have hard-float userspace?
No, you don't have this dependency. You can run armhf userspace with our "armel" kernel and vice-versa.
On 11 March 2012 19:23, Fathi Boudra fathi.boudra@linaro.org wrote:
On 11 March 2012 19:03, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
W dniu 11.03.2012 15:34, Paul Larson pisze:
Well, try it but I'm not sure I understand where the issue is. When we compile test binaries, it'sfrom a cheroot of the test image.
Hmm, I did not remember this. I still think we may hit some issues. Is there a dependency on the kernel to have hard-float userspace?
No, you don't have this dependency. You can run armhf userspace with our "armel" kernel and vice-versa.
1st armhf job passed successfully (nano on panda): http://validation.linaro.org/lava-server/scheduler/job/15564
linaro-validation@lists.linaro.org
-
Fathi Boudra -
Paul Larson -
Zygmunt Krynicki