| Summary: | MC regression in 5.15.1: account-manager/connectivity.py fails | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Simon McVittie <smcv> |
| Component: | mission-control | Assignee: | Simon McVittie <smcv> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | major | ||
| Priority: | medium | CC: | rishi.is |
| Version: | git master | Keywords: | patch |
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
1/5] run-test.sh.in: now that we run under 'set -e', catch failures
2/5] run-test.sh.in: dump logfiles to stdout on failure 3/5] Log verbose test output and give it the same treatment as MC's log 4/5] connectivity_monitor_nm_state_change_cb: if NM says DISCONNECTED, believe it 5/5] connectivity test: make sure we've caught up on GDBus messages Document the new test logging arrangement |
||
|
Description
Simon McVittie
2013-09-19 18:24:22 UTC
This is compounded by the fact that libnm-glib uses dbus-glib, whereas the FakeNetworkMonitor uses GDBus; so it's entirely possible that when the test sends this: • NM: connected (70) • FakeNetworkMonitor: connected … • NM: disconnecting (30) • NM: disconnected (20) • FakeNetworkMonitor: disconnected • NM: connected (70) • FakeNetworkMonitor: connected MC receives this: • NM: connected (70) • FakeNetworkMonitor: connected … • NM: disconnecting (30) • NM: disconnected (20) • NM: connected (70) • FakeNetworkMonitor: disconnected • FakeNetworkMonitor: connected which makes MC disconnect! Not helpful. Created attachment 86158 [details] [review] 1/5] run-test.sh.in: now that we run under 'set -e', catch failures If we just let with-session-bus.sh exit nonzero, the script aborts. We want to catch the nonzero exit status and do some more things before failing. --- Not particularly related to this, should be merged anyway Created attachment 86159 [details] [review] 2/5] run-test.sh.in: dump logfiles to stdout on failure This is a lot of very spammy output, but the failures are basically undebuggable without it, so... Created attachment 86160 [details] [review] 3/5] Log verbose test output and give it the same treatment as MC's log --- Rather than having strange runes to get verbose test output, let's just log it unconditionally, and cat it (along with MC's own logs) if it becomes necessary. Created attachment 86161 [details] [review] 4/5] connectivity_monitor_nm_state_change_cb: if NM says DISCONNECTED, believe it --- This does mean we lose the "if NM believes we are disconnected, but netlink says we're OK, then we're OK" feature, but I can't see how to avoid that. Created attachment 86162 [details] [review] 5/5] connectivity test: make sure we've caught up on GDBus messages Otherwise, the message from the FakeNetworkMonitor saying we've gone offline might not be received until after the message from the fake NM saying we've gone online - which would be a problem. There's no side-effect we can wait for here, so we just have to make sure the GDBus queue has been processed. Comment on attachment 86158 [details] [review] 1/5] run-test.sh.in: now that we run under 'set -e', catch failures Review of attachment 86158 [details] [review]: ----------------------------------------------------------------- ++ Comment on attachment 86159 [details] [review] 2/5] run-test.sh.in: dump logfiles to stdout on failure Review of attachment 86159 [details] [review]: ----------------------------------------------------------------- ++ Comment on attachment 86160 [details] [review] 3/5] Log verbose test output and give it the same treatment as MC's log Review of attachment 86160 [details] [review]: ----------------------------------------------------------------- ++ Shouldn't be update tests/README if this env variable is always set now? Comment on attachment 86161 [details] [review] 4/5] connectivity_monitor_nm_state_change_cb: if NM says DISCONNECTED, believe it Review of attachment 86161 [details] [review]: ----------------------------------------------------------------- ++ Comment on attachment 86162 [details] [review] 5/5] connectivity test: make sure we've caught up on GDBus messages Review of attachment 86162 [details] [review]: ----------------------------------------------------------------- ++ Created attachment 86176 [details] [review] Document the new test logging arrangement I merged this lot. Hopefully Attachment #86176 [details] fixes your comment on Attachment #86160 [details] - let me know if you want it changed or reverted. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.