67777 2011-09-08 06:04:44 -0700 new-run-webkit-tests does not support qt-arm results 2013-08-26 02:23:57 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) All All RESOLVED DUPLICATE 120207 NRWT P3 Normal --- 120207 88680 89880 1 ossy webkit-unassigned abrhm dpranke eric kadam ossy rgabor zarvai oldest_to_newest 464008 0 ossy 2011-09-08 06:04:44 -0700 . 465756 1 eric 2011-09-12 13:15:21 -0700 Do we have a qt-arm port? Does it have results? 489438 2 eric 2011-10-24 10:44:20 -0700 I guess I'll assume that's a no? Please re-open if this is an issue. 490768 3 ossy 2011-10-26 05:43:02 -0700 Yes, we have. 490769 4 ossy 2011-10-26 05:43:39 -0700 And it has results and Skipped list too in LayoutTests/platform/qt-arm. 491912 5 eric 2011-10-27 13:56:48 -0700 OK. Looks like qt-arm is just supposed to fall back to qt: http://trac.webkit.org/browser/trunk/Tools/Scripts/old-run-webkit-tests#L2186 } elsif ($platform =~ /^qt-/) { push @platforms, $platform; push @platforms, "qt"; 491930 6 eric 2011-10-27 14:07:36 -0700 It would be possible to hack this by adding he following to the end of Qt.__init__ in ports/qt.py: # FIXME: This is a total hack for the qt-arm port. if 'arm' in platform.machine(): self._name = 'qt-arm' But what really should happen is we should come up with some consisten vision for how fallback should work across Qt. Right now qt-arm is a one-off (I don't believe it wishes to participate in normal version fallback, right?) and all of Qt fallback is different from Mac/Win which fall back from most-specific version to newer versions then to the base directory. Qt, my understanding is falls back just to most-specific version then the base directory. 491931 7 eric 2011-10-27 14:08:23 -0700 I plan to leave qt-arm for someone in Qt to handle. It's easy to hack-in as noted above, but I would advise understanding how we want fallback to work for Qt before adding arm support to NRWT. 491951 8 eric 2011-10-27 14:25:22 -0700 Moving this off of the "move all bots" bug, as I don't plan to do this before closing that bug and making NRWT default for all other ports. qt-arm will remain on an explicit black-list of unsupported ports for now. 659840 9 ossy 2012-06-28 14:40:05 -0700 We should add qt-arm to baseline search paths, it is quite simple. And we should find the python way for ARM architecture detection somehow. 920928 10 ossy 2013-08-26 02:23:57 -0700 bug120207 will solve this problem too. *** This bug has been marked as a duplicate of bug 120207 ***