Closed
Bug 1123085
Opened 9 years ago
Closed 8 years ago
Permaorange in test_custom_origin_uninstall_install.xul, test_hosted_uninstall.xul, test_packaged_uninstall.xul on OS X 10.10
Categories
(Firefox Graveyard :: Web Apps, defect, P1)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: philor, Assigned: myk)
Details
See, e.g., https://treeherder.mozilla.org/logviewer.html#?job_id=92519&repo=cedar - apparently 10.10 doesn't like deleting. 20:43:20 INFO - 2890 INFO TEST-UNEXPECTED-FAIL | toolkit/webapps/tests/test_custom_origin_uninstall_install.xul | Error during test: REINSTALL_FORBIDDEN - expected PASS 20:44:35 INFO - 2917 INFO TEST-UNEXPECTED-FAIL | toolkit/webapps/tests/test_hosted_uninstall.xul | App moved to Trash - expected PASS 20:46:10 INFO - 2952 INFO TEST-UNEXPECTED-FAIL | toolkit/webapps/tests/test_packaged_uninstall.xul | App moved to Trash - expected PASS
Comment 1•9 years ago
|
||
Marco, testing on 10.10.1 installing, deleting and re-installing worked with Nightly (38.0a1 (2015-01-23)). As the bug is a bit cryptic, you might have a better idea on why the tests fail exactly.
Status: NEW → UNCONFIRMED
Ever confirmed: false
Flags: needinfo?(mmucci)
Reporter | ||
Comment 2•9 years ago
|
||
It may be cryptic, but it's not unconfirmed, since it's not about whether or not there exists a 10.10 install where they pass, it's about them not passing on releng's 10.10 install. If you want the full chatty version, try this: releng is getting ready to switch from running tests on OS X 10.8 to running them on OS X 10.10 on the same pool of slaves. As part of that, they have three slaves with 10.10 installed, which for a while were running on the Cedar twig, but now are available for try runs instead since that's much simpler and more sane for us as a place to green up tests. You can run them on try with trychooser syntax like "try: -b do -p macosx64 -u mochitest-o[10.10] -t all". As always when releng rolls out a new slave platform, the reason your tests fail may be because something they do doesn't agree with the new OS, or it may be that your tests require some change in how things are installed or configured with the OS, or required something be installed or configured differently with the last version of the OS which everyone but you has now forgotten about, but because you are the only ones who know what your tests are doing and what they want and what is making them fail and how to change them to be more verbose about why they are failing, you'll have to be the ones to tell releng if they need to make changes to support your tests. For a current example of them failing as of this morning, see https://treeherder.mozilla.org/ui/logviewer.html#?job_id=4424982&repo=try for an opt job or https://treeherder.mozilla.org/ui/logviewer.html#?job_id=4424262&repo=try for a debug job, though the failures have looked exactly the same since the very first job these slaves did. To get the permaorange out of the way of blocking the transition, I'll probably be disabling them on 10.10 soon, but when I do I'll also put the link to a revert-the-disabling patch you can stick at the top of a try queue to turn them back on when you push diagnostic patches to try.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•9 years ago
|
||
(In reply to Harald Kirschner :digitarald from comment #1) > Marco, testing on 10.10.1 installing, deleting and re-installing worked with > Nightly (38.0a1 (2015-01-23)). As the bug is a bit cryptic, you might have a > better idea on why the tests fail exactly. Hi Harald, I think you might be looking for a different Marco. I have no insight into this bug.
Flags: needinfo?(mmucci)
Assignee | ||
Comment 4•9 years ago
|
||
Perhaps Harald was thinking of Marco Castelluccio?
Flags: needinfo?(mar.castelluccio)
Reporter | ||
Comment 5•9 years ago
|
||
Disabled in https://hg.mozilla.org/integration/mozilla-inbound/rev/6bcf64c6e8f3, so just stick https://hg.mozilla.org/try/rev/f6fad6f210c9 at the top of your patch queue to reenable them and run them on try.
Keywords: leave-open
Reporter | ||
Comment 6•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/6bcf64c6e8f3
Comment 7•9 years ago
|
||
Looks like we're correctly removing the installation directory, but failing to move the files to the trash: 10:34:28 INFO - 2491 INFO TEST-PASS | toolkit/webapps/tests/test_hosted_uninstall.xul | Files correctly removed 10:34:28 INFO - 2492 INFO TEST-UNEXPECTED-FAIL | toolkit/webapps/tests/test_hosted_uninstall.xul | App moved to Trash - expected PASS What's the name of the trash directory on these machines? The test that is failing is this one: ok(testAppInfo.trashDir.contains(".Trash"), "App moved to Trash"); Might be related to bug 1038376.
Flags: needinfo?(mar.castelluccio)
Reporter | ||
Comment 8•9 years ago
|
||
I'd think if Yosemite renamed the trash, googling would tell me so, but you never know.
Flags: needinfo?(kmoir)
Comment 9•9 years ago
|
||
The Trash directory is here [root@t-yosemite-r5-0001.test.releng.scl3.mozilla.com /]# ls -lad /Users/cltbld/.Trash drwx------ 3 cltbld staff 102 29 Jan 02:54 /Users/cltbld/.Trash [root@t-yosemite-r5-0001.test.releng.scl3.mozilla.com /]# ls -la /Users/cltbld/.Trash total 16 drwx------ 3 cltbld staff 102 29 Jan 02:54 . drwxr-xr-x 18 cltbld staff 612 24 Jan 01:58 .. -rw-r--r--@ 1 cltbld staff 6148 25 Jan 05:12 .DS_Store The same location as it was on 10.8 slaves, same permissions
Flags: needinfo?(kmoir)
Updated•9 years ago
|
Priority: -- → P1
Updated•9 years ago
|
Assignee: nobody → myk
Assignee | ||
Comment 10•8 years ago
|
||
Per bug 1238079, we're going to disable the desktop web runtime and remove it from the codebase, so we won't fix these bugs in the integration between Firefox and the runtime.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Updated•8 years ago
|
Product: Firefox → Firefox Graveyard
Comment 11•6 years ago
|
||
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
Comment hidden (spam) |
You need to log in
before you can comment on or make changes to this bug.
Description
•