On Fri, 2019-04-19 at 12:58 -0700, Joe Slater wrote: > The default timeout of 300 seconds is far too low for qemu bsp's. > > Signed-off-by: Joe Slater <[email protected]> > --- > meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/run-ptest | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/run-ptest > b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/run-ptest > index 8f90723..b4f982b 100644 > --- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/run-ptest > +++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/run-ptest > @@ -1,3 +1,5 @@ > #! /bin/sh > > -gnome-desktop-testing-runner gdk-pixbuf > +# The default timeout of 300 seconds is far too low for qemu bsp's. > +# > +gnome-desktop-testing-runner -t 2400 gdk-pixbuf
This raises an interesting dilemma. Do we set the timeouts to match a real hardware system, a software emulated qemu or a KVM accelerated qemu? My instinct says we should time these for real hardware and KVM accelerated images only as ptests are simply too slow to realistically run anywhere else. The downside to long timeouts is if something does break, long hanging builds. On that basis I'm not sure we want to start patching all the timeouts for software qemu... Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
