as we are getting closer to a docker container for linux32 so we can run our tests via taskcluster instead of buildbot, there is a need to green up the web-platform-tests. https://treeherder.mozilla.org/#/jobs?repo=try&revision=0fc2ae047976bf8990f41a0c6fcdaac9f1bffcef&filter-searchStr=web-platform-tests ideally we can green these up so they work on both buildbot and taskcluster. Looking at the failures, they seem to fall pretty much on a common theme: audio/video. possibly we need to do more work to get audio/video to work in linux32 as this is a linux64 vm with linux32 binaries installed in parallel.

in the latest push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d5f5bbdb7199a2c3f89e473f441aadd819d1d2ce&filter-tier=1&filter-tier=2&filter-tier=3&exclusion_profile=false&filter-searchStr=tc%20linux%20web-platform-tests&selectedJob=33236260 which has fixed for mochitest-media, we end up with just one failure in the 4th chunk: TEST-UNEXPECTED-NOTRUN | /content-security-policy/object-src/object-src-2_1.html | Async SWF load test - No Flash Player, cannot run test. TEST-UNEXPECTED-NOTRUN | /content-security-policy/object-src/object-src-2_2.html | Async SWF load test - No Flash Player, cannot run test. this seems as if we can fix this, we just need to ensure that navigator.mimetypes has "application/x-shockwave-flash" in the array. One concern is that getting a 32bit version of shockwave-flash installed alongside a 64bit version might be problematic. I see the package flashplugin-nonfree which appears to have 32 and 64 bit versions. I also see that we do not currently run this test on linux32 due to ubuntu 12.04: https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/meta/content-security-policy/object-src/object-src-2_1.html.ini

flashplugin-nonfree is the same as flashplugin-installer, which is already installed. I cannot seem to install flashplugin-installer:i386 without conflicts. I think I want to update the manifests so that object-src-2_1.html and object-src-2_2.html are not run on linux32. That seems easy enough to do with a manual update of the ini. I tried using 'mach wpt-update' but had difficulty.

I just made this change manually...is that okay? (I tried following the instructions you provided in October. fetchlogs seemed to work fine, but I couldn't get |mach wpt-update| to run successfully.)

Comment on attachment 8821610 [details] [diff] [review] don't run 2 wpt tests on linux32 Review of attachment 8821610 [details] [diff] [review]: ----------------------------------------------------------------- Please change the commit message to reflect the fact that the tests are not being disabled, but that in this configuration they get the NOTRUN status (that is, this change is descriptive, not prescriptive).

Pushed by gbrown@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/38f4f50cd295 Set wpt expected status to NOTRUN for object-src-2_1 and object-src-2_2 on linux32 only, for tc migration; r=jgraham

sorry had to back this out for linux web platform failures, https://treeherder.mozilla.org/logviewer.html#?job_id=66460982&repo=mozilla-inbound&lineNumber=2776

Backout by ihsiao@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/617b3001cf07 Backed out changeset 38f4f50cd295 for linux web platform failures

This is odd. Patches were backed out for wpt failures for object-src-2_1/2 on linux64. The failures are just the same as the linux32 failures that I worked around in this patch: Flash is not available, so the test is not run. At first I thought my image changes had affected linux64 and I had not noticed that on try, but actually, I was running wpt tests on linux64 in my try pushes and never saw this failure. Here's another for good measure, and the linux64 wpt tests passed again: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8651ac98c541caf070098bf0f01b28ea6525af81 What am I missing?

I honestly have no idea- I double checked the patches, and then double checked the inbound vs try pushes, nothing obvious is popping out. Is it possible we have issues with the image generation? Could we possibly land just the test changes, then land the image changes with only one test type using the new image (12 and 16), then finally add all the tests? Another idea is to just try landing it again, although I suspect that will result in the same failure. :jgraham, would you have other information that could help us figure out why this wpt test was backed out for a failure but cannot reproduce the failure on try?

I don't have anything useful, really. The facts that I can see are: a) the test abuses the NOTRUN status to mean "flash plugin is not available" b) prior to this bug 64bit Ubuntu 16.04 had a status of PASS on try and inbound implying that flash is available and the test passed c) With the changes in this bug, on try, Ubuntu 16.04 linux got PASS in 64bit configurations and NOTRUn on 32bit configurations, implying that the former had flash available and the latter did not d) On inbound it got NOTRUN in both configurations, implying that neither had flash available. I don't think this information is news to anyone. I suggest trying a one-click-loaner from the failing job; although wpt doesn't yet work out of the box with those configurations (something that I think we need to fix), it may nevertheless be possible to tell if flash is installed and/or run the tests by hand.

Thanks for taking a look :jgraham :) one random thought- is it possible with some 32 bit libraries on the OS we are somehow running this test as 32 bit instead of 64 bit? Otherwise, the idea of a 1 click loaner would help out.

Thanks Joel, James. I'll see what I can see on a loaner. In the meantime, I'll try landing this without the image changes. https://treeherder.mozilla.org/#/jobs?repo=try&revision=b9d3723e7c51e5e8698d7e4b7511e5c34e12d5c0

Pushed by gbrown@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/f803d8866f29 Set wpt expected status to NOTRUN for object-src-2_1 and object-src-2_2 on linux32 only, for tc migration; r=jgraham