The Shuku proposal was basically turning Sato into a test runner and validation UI instead of a bad PIM.
Do we have any kind of specs ? I assume this is a 1.4 task ?
1.4, yes. No hard specification but my proposal was on oe-core.
I think integrating “Phoronix Test Suite” in the YP layer is a good approach as the first step. I aslo get some feedback from the board manufactures that what tools are used for platform validation. most of them are tools in DOS. But I don't know whether there are some similar tools in Linux that could be used. here is the list: CPU test : chkcpu.exe (DOS6.22) com port test: BEAR UART Card (DOS6.22) LAN port test: novell link test (DOS6.22), Lanconf (DOS), iperf (Linux) USB port test: bear usb-t02 card (DOS6.22), USBHSET (Windows) SATA HDD test: copy&compare (DOS6.22) SATA test : RU473/ADU461 (DOS) DRAM test : read dram size (DOS6.22), Memtest86(Windows/Linux) PCI-E Test : bear pci-e card (DOS6.22) Fan Test : cmos check (Dos6.22) buzzer test : speaker.com (DOS6.22) Gfx test : 3DMark (Windows/Linux), OpenArena (Windows/Linux), glxgears, render_bench, VLC Burn-in for All : Passmark (Windows) for running 72 hours Burn-in for Com Port: PCCOM2000 (Windows) for running 72 hours Burn-in for Storage : Winthrax.exe (Windows)
I'm not entirely convinced phoronix is the best idea as it has a massive range of dependencies (postgres, apache, ...). My initial goal isn't to focus on raw performance but functional testing: - does the touchscreen work correctly - 2D acceleration - GL support - VAAPI support - sound input/output through each output And so on.
Promoting this to HIGH for 1.5
Ross is clearly doing this ;-)
In progress but not ready for merging.
(In reply to comment #7) > In progress but not ready for merging. Hi Ross, Any updates on this?
To make this bug clear as all the discussion happened on the mailing lists - the Shuku proposal is to take Sato, port to GTK+3 (this is mostly done, needs bug fixing), and drop the pretence that it's a reference UI for a PDA, swapping stuff like "Music Player" for "GStreamer test harness" (this in particular has happened).
*** Bug 8470 has been marked as a duplicate of this bug. ***
Reassigning to Alex as he expressed interest in actually doing this for 2.1.
Not sure if it's too late for 2.1 but I finally have something to show so I'm moving to M3 and sending some patches ...
I've sent a RFC patchset to list: IMO it's too late for 2.1 release, I propose moving to 2.2 M1.
Status update: * All of the "upstream" patchsets have been sent (mostly to yocto ML) * There's a WIP poky branch that contains these to-be-upstreamed patches and everything else I intend to send: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=jku/matchbox-wip Possible issues: * Some recipes still depend on GTK+2 (see list below). These are all development tools though: nothing that should be used on actual target images * GTK+3 still currently requires opengl (via libepoxy) * I've had to replace some software: e.g. adding l3afpad to oe-core (as a replacement for leafpad) might still require discussion List of GTK+2 reverse dependencies in oe-core world build after my patches: * gnome-themes-standard - Gtk+2 theme that matches the current Gtk+3 theme * alsa-tools - some tools depend on Gtk+2 sysprof - latest version requires gtk3 & polkit, but can compile without GUI latencytop kernelshark fstests oprofileui libglade - used by by oprofileui and (current) sysprof
It would be good to tag new versions, and make the recipes refer to those versions, instead of just updating the commit ids, e.g. here: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=jku/matchbox-wip&id=9315cad3da18127925ac0c10e2f208bd2b61c40b So that the recipe reporting system can correctly report those recipes as 'up to date' instead of 'unknown'.
Not sure how close we got to the original "Shuku proposal" (from Yocto 1.3 !) but I'm calling it done: matchbox components (and the rest of oe-core) now use Gtk+3. Tweaks and improvements to the UI should be filed as new bugs.