Bug 67777 - new-run-webkit-tests does not support qt-arm results
Summary: new-run-webkit-tests does not support qt-arm results
Status: RESOLVED DUPLICATE of bug 120207
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P3 Normal
Assignee: Nobody
Keywords: NRWT
Depends on: 120207
Blocks: 88680 89880
  Show dependency treegraph
Reported: 2011-09-08 06:04 PDT by Csaba Osztrogonác
Modified: 2013-08-26 02:23 PDT (History)
7 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Csaba Osztrogonác 2011-09-08 06:04:44 PDT
Comment 1 Eric Seidel (no email) 2011-09-12 13:15:21 PDT
Do we have a qt-arm port?  Does it have results?
Comment 2 Eric Seidel (no email) 2011-10-24 10:44:20 PDT
I guess I'll assume that's a no?  Please re-open if this is an issue.
Comment 3 Csaba Osztrogonác 2011-10-26 05:43:02 PDT
Yes, we have.
Comment 4 Csaba Osztrogonác 2011-10-26 05:43:39 PDT
And it has results and Skipped list too in LayoutTests/platform/qt-arm.
Comment 5 Eric Seidel (no email) 2011-10-27 13:56:48 PDT
OK.  Looks like qt-arm is just supposed to fall back to qt:


    } elsif ($platform =~ /^qt-/) {
        push @platforms, $platform;
        push @platforms, "qt";
Comment 6 Eric Seidel (no email) 2011-10-27 14:07:36 PDT
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.
Comment 7 Eric Seidel (no email) 2011-10-27 14:08:23 PDT
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.
Comment 8 Eric Seidel (no email) 2011-10-27 14:25:22 PDT
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.
Comment 9 Csaba Osztrogonác 2012-06-28 14:40:05 PDT
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.
Comment 10 Csaba Osztrogonác 2013-08-26 02:23:57 PDT
bug120207 will solve this problem too.

*** This bug has been marked as a duplicate of bug 120207 ***