| === marcusto_ is now known as marcustomlinson | ||
| dandrader | Saviq, fixed the background tests in tst_Shell (lp:~unity-team/unity8/externalMonitor). | 08:13 |
|---|---|---|
| Saviq | dandrader, ack, thanks | 08:13 |
| Saviq | dandrader, last issue I found is that we broke something with input, when autopilot tries to drag indicators down, it fails half of the time (the indicator panel is not pulled down to the end) | 08:14 |
| Saviq | dandrader, I thought it was touch resampling, but isn't, trying to bisect now | 08:15 |
| dandrader | Saviq, hmm... don't know what could be affecting this | 08:16 |
| dandrader | will be back in ~ 2 hours | 08:17 |
| Saviq | nothing else jumps out as could cause something like that, but it's unfortunately reliable - a test that drags indicators down passes fine on trunk, but fails ~50% in silo 22 | 08:17 |
| Saviq | dandrader, yeah I thought it's early for you ;) | 08:17 |
| Saviq | 4am? | 08:17 |
| Saviq | mzanetti, fyi ↑↑ | 08:18 |
| tsdgeos | Saviq: you're aware of the deadlock on shutdown gerry found with silo22, right? | 08:29 |
| Saviq | tsdgeos, yeah | 08:30 |
| tsdgeos | k | 08:30 |
| === zequence_ is now known as zequence | ||
| tsdgeos | greyback: so the object is not being deleted | 09:23 |
| tsdgeos | by the deleteLater | 09:23 |
| greyback | tsdgeos: which is strange. deleteLater sticks event on gui event loop, might the gui thread be blocked before it manages to process that event? | 09:31 |
| tsdgeos | greyback: i thoguht the same, but yes and no | 09:31 |
| tsdgeos | yes the gui thread is blocked since it's the thread calling the destructor | 09:32 |
| tsdgeos | no since the object doesn't live in the guy thread, it lives in the thread we're trying to quit | 09:32 |
| tsdgeos | s/guy/gui :D | 09:34 |
| tsdgeos | greyback: do you know if any changes to event porcessing in the silo? | 09:35 |
| tsdgeos | Saviq: do we have a "big diff" of what the silo introduces | 09:35 |
| tsdgeos | ? | 09:35 |
| Saviq | tsdgeos, I have a branch that reproduces what the train did (until robru fixes bug #1348531) | 09:36 |
| ubot5 | bug 1348531 in CI Train [cu2d] "Silo branches should be public" [Medium,In progress] https://launchpad.net/bugs/1348531 | 09:36 |
| Saviq | tsdgeos, interested? | 09:36 |
| greyback | tsdgeos: nope. The only thing coming to mind is the shutdown sequence might be more time consuming on the gui thread | 09:36 |
| tsdgeos | Saviq: guess so yeah | 09:37 |
| Saviq | tsdgeos, also, unity8 or qtmir? | 09:37 |
| * greyback upvoting that bug | 09:37 | |
| Saviq | greyback, robru said it should be done within days | 09:37 |
| tsdgeos | both? | 09:37 |
| Saviq | tsdgeos, ack, gimme 5 | 09:38 |
| greyback | Saviq: bit of a nudge never hurts ;) | 09:40 |
| robru | Saviq: yeah this week or next week. I unfortunately have higher priorities but I really want to get that one done. | 09:43 |
| Saviq | tsdgeos, lp:~unity-team/unity8/req-445 | 09:48 |
| Saviq | tsdgeos, ~lukas-kde/qtmir/wheelEvent | 09:51 |
| Saviq | no | 09:51 |
| Saviq | tsdgeos, lp:~unity-team/qtmir/req-445 | 09:51 |
| Saviq | tsdgeos, greyback, fwiw it is qtmir that causes the deadlock, downgrading it to overlay version helps | 09:54 |
| Saviq | also the touch issue it seems, /me bisects | 09:55 |
| Saviq | but eyeballs touch_tracing | 09:55 |
| tsdgeos | there's something very wweird with threads | 09:57 |
| tsdgeos | greyback: if you kill it while the locker is on the bt is different | 09:58 |
| tsdgeos | it's stuck at | 09:58 |
| tsdgeos | #3 0xb63366ce in QThreadPoolPrivate::waitForDone(int) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 | 09:58 |
| tsdgeos | Saviq: good find! | 09:59 |
| Saviq | tsdgeos, I should have the actual MP that caused this soon | 09:59 |
| Saviq | maybe shines a light on something | 09:59 |
| greyback | tsdgeos: yeah this is most likely qtmir's fault | 10:00 |
| greyback | am just confused how it impacts that thread | 10:00 |
| tsdgeos | ah wait | 10:01 |
| tsdgeos | maybe it's locked inside a request itself | 10:01 |
| tsdgeos | that's why the object is not deleted | 10:02 |
| tsdgeos | because the thhread doesn't go back to it's event loop | 10:02 |
| tsdgeos | that makes sense | 10:02 |
| * tsdgeos adds some debug | 10:02 | |
| tsdgeos | QThread: Destroyed while thread is still running | 10:09 |
| tsdgeos | that's bad | 10:09 |
| tsdgeos | but may be a red herring | 10:16 |
| * tsdgeos checks if we have that too without silo 22 | 10:16 | |
| Saviq | greyback_, http://pastebin.ubuntu.com/12875877/ ?? | 10:18 |
| greyback_ | Saviq: building manually? You need a cmake switch for GL/GLES | 10:19 |
| Saviq | native qtmir build on flo | 10:19 |
| Saviq | greyback_, dpkg-buildpackage should take care of it for me? | 10:19 |
| greyback_ | -DUSE_OPENGL_BUT_LINK_AGAINST_OPENGLES=1 | 10:19 |
| greyback_ | oh yes it should | 10:19 |
| Saviq | lemme clean | 10:20 |
| tsdgeos | yes it's there without silo 22 so "QThread: Destroyed while thread is still running" is probably not it | 10:22 |
| greyback_ | ok | 10:22 |
| tsdgeos | still worth fixing probably thoug | 10:22 |
| tsdgeos | so no the thread doesn't seem to be busy either :S | 10:37 |
| Saviq | greyback_, looks like dednick's debian/rules simplifications break manual armhf dpkg-builds somehow | 10:49 |
| greyback_ | Saviq: darn. Odd CI is happy though | 10:50 |
| Saviq | greyback_, indeed | 10:50 |
| greyback_ | dednick: ^^ able to have a look? | 10:50 |
| Saviq | dednick, when dpkg-buildpackage'ing qtmir with your cmake bits I get http://pastebin.ubuntu.com/12875877/ | 10:51 |
| dednick | hmmm | 10:51 |
| dednick | let me look quick | 10:52 |
| Saviq | owait | 10:52 |
| * Saviq didn't look closely maybe | 10:52 | |
| Saviq | arm-linux-gnueabihf-g++: internal compiler error: Killed (program cc1plus) | 10:52 |
| greyback_ | you were still getting linker errors | 10:53 |
| Saviq | dednick, not after I cleaned I think | 10:53 |
| dednick | ah. k | 10:53 |
| Saviq | greyback_, rather ↑ | 10:54 |
| greyback_ | Saviq: -DNO_TESTS=1 helps avoid that | 10:54 |
| Saviq | kk | 10:54 |
| greyback_ | until we land dednick's test refactoring | 10:54 |
| dednick | hm. latest CI not happy. | 10:54 |
| dednick | oh. it's multimonitoe | 10:55 |
| Saviq | dednick, yeah, I think it's fine after all | 10:55 |
| Saviq | just I got lost in the build errors | 10:55 |
| dednick | ok | 10:55 |
| Saviq | greyback_, that's OOM? | 10:57 |
| greyback_ | Saviq: yeah | 10:57 |
| greyback_ | tsdgeos: I suspect that the mir server thread isn't shutting down. I'm seeing no evidence mir is even trying to shut down on sigstop, it only appears to capture the signal | 11:14 |
| tsdgeos | greyback_: but what changed? | 11:14 |
| greyback_ | tsdgeos: I dunno yet. a lot of code changed. This is something I checked a month ago (and was ok), but not recently | 11:16 |
| tsdgeos | mhmm | 11:21 |
| tsdgeos | QCoreApplication::postEvent can't find the dispatcher | 11:22 |
| Saviq | greyback_, tsdgeos, my current suspect is touch_tracing | 11:23 |
| greyback_ | tsdgeos: might explain things. QCoreApp::quit() is being called by mir, which should go through event loop, make qt start shutting down, whih will ask mir to quit at the right time | 11:24 |
| Saviq | hmm not for the indicator drag though :/ | 11:24 |
| Saviq | but I built r394 from lp:~unity-team/qtmir/req-445 and no more hang on shutdown | 11:25 |
| Saviq | checking r395 now to confirm | 11:25 |
| tsdgeos | food! | 11:26 |
| Saviq | +1, and filing tax report | 11:26 |
| Saviq | grr no | 11:31 |
| Saviq | ok I take all that back | 11:39 |
| Saviq | qtmir old or new, there's a deadlock in new unity8, so bisecting that again | 11:44 |
| seb128 | ltinkl, I think you fix from https://code.launchpad.net/~lukas-kde/ubuntu-settings-components/extractPo is slightly incomplete, you need a "X-Ubuntu-Use-Langpack: yes" in debian/control for the template to be imported by launchpad on package build | 11:45 |
| seb128 | ltinkl, https://translations.launchpad.net/ubuntu/wily/+source/ubuntu-settings-components | 11:45 |
| ltinkl | seb128, will have a look | 11:48 |
| seb128 | ltinkl, thanks | 11:48 |
| ltinkl | seb128, should I update the MP or file a new one? | 11:49 |
| seb128 | ltinkl, that one landed so I guess a new one | 11:50 |
| ltinkl | seb128, ok | 11:50 |
| greyback_ | Saviq: have you a branch with silo22 unity8 handy? | 11:52 |
| Saviq | greyback_, lp:~unity-team/unity8/req-445 | 11:53 |
| greyback_ | thanks | 11:53 |
| ltinkl | seb128, https://code.launchpad.net/~lukas-kde/ubuntu-settings-components/langpack/+merge/275017 | 11:53 |
| * Saviq really going out now | 11:53 | |
| seb128 | ltinkl, comment approved, I'm not in a team that allows me to change the mp status though | 11:53 |
| seb128 | Saviq might be able to help there | 11:54 |
| ltinkl | :) | 11:54 |
| greyback_ | seb128: ltinkl: done | 11:56 |
| ltinkl | greyback_, great, thx | 11:56 |
| seb128 | thanks | 11:56 |
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| mterry | tsdgeos, does your use_sdk_13 branch really fix bug 1449628? (it's marked as doing so, but that would surprise me unless you did extra logic beyond 1.3 porting) | 13:14 |
| ubot5 | bug 1449628 in unity8 (Ubuntu) "[Icons] X-Ubuntu-Splash-Color=#ffffff yields #f5f5f5" [Undecided,In progress] https://launchpad.net/bugs/1449628 | 13:14 |
| tsdgeos | mterry: it does | 13:15 |
| mterry | Oh nice :) Side benefit | 13:15 |
| tsdgeos | mterry: http://bazaar.launchpad.net/~unity-team/unity8/use_sdk_13/revision/1856 | 13:15 |
| tsdgeos | Saviq: how did you try with an older qtmir? here it wants to uninstall unity8 if i do so | 13:17 |
| mterry | tsdgeos, I'm all for it, that paper overlay was dumb in my opinion, but is Design OK with dropping it? | 13:17 |
| Saviq | tsdgeos, install unity8-fake-env | 13:17 |
| mterry | Well, not dumb. Just poorly applied | 13:17 |
| tsdgeos | mterry: read the log ;) "Update with new SDK 1.3 MainViewStyle.qml looks" | 13:17 |
| tsdgeos | we're not doing anything that SDK doesn't do | 13:18 |
| Saviq | tsdgeos, in any case, it seems qtmir isn't the culrpit after all, I had a weird mix of locally built packages | 13:19 |
| mterry | tsdgeos, yeah but before we did do stuff the sdk didn't do :) | 13:20 |
| tsdgeos | mterry: not really | 13:20 |
| tsdgeos | mterry: what did we do? | 13:20 |
| tsdgeos | the paper was part of the SDK 1.2 | 13:21 |
| mterry | tsdgeos, it was? It looked like we were loading graphics/background_paper.png ourselves in that commit you linked | 13:21 |
| tsdgeos | yes because we're that smart and decided to copy the png file | 13:21 |
| tsdgeos | but if you care to check SDK 1.2 MainViewStyle.qml you'll see it does the same | 13:22 |
| mterry | tsdgeos, OK cool. :) Thanks for walking me through it. That's been a bugbear of mine for a while on my own apps that have white in their app icons | 13:22 |
| tsdgeos | Saviq: have you been able to find which rev makes it break? | 13:30 |
| Saviq | tsdgeos, not yet, wasted some time on qtmir which wasn't to blame, still a few rebase cycles away | 13:31 |
| tsdgeos | i'm a bit a lost of why the event isn't being delivered | 13:31 |
| greyback_ | as am i | 13:31 |
| tsdgeos | all i can see it now i'd blame glib going crazy | 13:31 |
| tsdgeos | since it seems really we post it to the thread event loop and it's there but it's never sent back | 13:32 |
| tsdgeos | which may mean we do something weird somewhere else that confuses glib | 13:32 |
| tsdgeos | i tried valgrind but it says nothing memory wise | 13:32 |
| tsdgeos | not sure if helgrind would make sense | 13:33 |
| === dandrader is now known as dandrader|afk | ||
| greyback_ | tsdgeos: mir uses glib for its event loop. I believe glib does fancy things consolidating event loops. Could it be mir asking glib to quit the event loop, is also quitting qt's event loop? | 14:19 |
| greyback_ | I might be on the wrong track tho | 14:19 |
| tsdgeos | greyback_: no idea, it could, but then unity8 is the only culprit, it's the unity8 packages that introduce the regressio | 14:19 |
| tsdgeos | n | 14:19 |
| Saviq | tsdgeos, greyback_, it's https://code.launchpad.net/~unity-team/unity8/externalMonitor/+merge/273829 | 14:20 |
| Saviq | must be the two windows (per-screen) make things go wrong | 14:21 |
| Saviq | IIRC thread/renderer per window? | 14:21 |
| tsdgeos | so the delete view is gone | 14:23 |
| tsdgeos | that changes destruction order of stuff | 14:23 |
| tsdgeos | may as well be that | 14:23 |
| tsdgeos | probably is that tbh | 14:23 |
| Saviq | indeed | 14:25 |
| Saviq | dandrader|afk, ↑ | 14:26 |
| === dandrader|afk is now known as dandrader | ||
| greyback_ | tsdgeos: the view is wrapped with a scoped pointer, it should be deleted | 14:29 |
| tsdgeos | greyback_: nobody says it's not being deleted | 14:30 |
| tsdgeos | greyback_: i'm saying the delete order *changed* | 14:30 |
| greyback_ | true | 14:30 |
| Saviq | greyback_, I think we had the explicit delete there for exactly that reason | 14:30 |
| dandrader | Saviq, ok, will play with explicit deletion of the quickviews | 14:36 |
| Saviq | dandrader, I'm set up quite well for testing, so whenever you're ready | 14:37 |
| tsdgeos | greyback_: the arguments thing is not caused by passing the '\0' instead of nullptr i have in some branch, right? | 14:39 |
| greyback_ | tsdgeos: no, a bit more involved, passing args to mir, mir will remove things it understands, then ensure qt gets the remainder | 14:40 |
| tsdgeos | k | 14:40 |
| greyback_ | tsdgeos: it's rough, but works https://code.launchpad.net/~gerboland/qtmir/fix-cmdline-args/+merge/274954 | 14:40 |
| tsdgeos | :D | 14:42 |
| greyback_ | Saviq: tsdgeos: replacing the main.cpp with the one from trunk, the shutdown hang goes away (replaced with a crash, yay http://pastebin.ubuntu.com/12877293/) | 15:00 |
| tsdgeos | "good"? :D | 15:01 |
| greyback_ | that might be consequence of me running unity8 by hand (i.e. upstart not doing it) | 15:01 |
| greyback_ | dandrader: ^ | 15:03 |
| dandrader | Saviq, greyback_, pushed the "hanging on shutdown" fix to lp:~unity-team/unity8/externalMonitor. | 15:05 |
| Saviq | ack | 15:06 |
| Saviq | dandrader, the mouse issue seems to be qtmir after all, bisecting now to see which MP | 15:06 |
| dandrader | Saviq, greyback_, nevermind. still hanging. it was segfaulting before :) | 15:12 |
| Saviq | kk, not holding breath | 15:12 |
| ltinkl | dandrader, http://developer.kde.org/~lukas/screenshots/unity8/screenshot20151019_164547260.png | 15:14 |
| ltinkl | dandrader, notice the window resize cursor :) | 15:14 |
| greyback_ | dandrader: it improves things a little for me, I get crash now deleting mouseTouchAdapter | 15:14 |
| dandrader | ltinkl, yes. I've seen this kind of problem before | 15:14 |
| dandrader | ltinkl, dialog (or its background) has also to consume hover events | 15:15 |
| Saviq | ltinkl, you need to not paste screenshots in Czech, I can't wipe my screen all the time ;P | 15:15 |
| ltinkl | Saviq, tsk tsk | 15:15 |
| dandrader | ltinkl, yeah, looks like your text strings are corrupted as well :) | 15:15 |
| ltinkl | dandrader, perfectly fine | 15:15 |
| ltinkl | :) | 15:16 |
| dandrader | like showing random memory or something | 15:16 |
| Saviq | worse, even | 15:16 |
| ltinkl | yeah yeah | 15:16 |
| ltinkl | I get that feeling when seeing Polish text as well | 15:16 |
| greyback_ | dandrader: yeah still hanging when I fix crash on deletion | 15:16 |
| ltinkl | Saviq, the truth is, Polish looks exactly the same Czech used to be written in 15th century, not kidding | 15:16 |
| Saviq | ltinkl, it shoulda stayed that way :D | 15:17 |
| Saviq | ltinkl, for us, most Czech words are like some funny versions of our "real" words | 15:17 |
| ltinkl | Saviq, we're a lazy bunch, that's why we invented those carons | 15:17 |
| Saviq | ltinkl, oh we have plenty of those ourselves, even ones not used anywhere else in the world | 15:18 |
| Saviq | ltinkl, but it's not even about those | 15:18 |
| ltinkl | Saviq, yea I know, we don't have many of them | 15:18 |
| dandrader | hhmmmm that shows in my stack trace: QSqlResult::setLastError(QSqlError const&) () at kernel/qsqlresult.cpp:391 | 15:18 |
| dandrader | might be the window geometry saving logic | 15:18 |
| ltinkl | The caron evolved from the dot above diacritic, which Jan Hus introduced into Czech orthography (along with the acute accent) in his De Orthographia Bohemica (1412) | 15:18 |
| ltinkl | says wikipedia | 15:18 |
| dandrader | which is async | 15:18 |
| dandrader | well, better crashing than hanging forever I guess :) | 15:19 |
| Saviq | let's just signal(SIGABRT) ;) | 15:20 |
| Saviq | errors.ubuntu.com will love us for that :) | 15:20 |
| tsdgeos | cimi: wyh do you need widgetMargins: -units.gu(1) ? | 15:22 |
| tsdgeos | shoouldn't it just be 0? | 15:22 |
| tsdgeos | it being -1 is weird since it still means it's coupled somewhere | 15:22 |
| Saviq | tsdgeos, bug #1507769 is coming our way | 15:23 |
| ubot5 | bug 1507769 in unity8 (Ubuntu) "App store does not display images" [High,Confirmed] https://launchpad.net/bugs/1507769 | 15:23 |
| tsdgeos | Saviq: yeah i saw it, not very reproducible bug being jumped around :D | 15:23 |
| Saviq | indeed | 15:23 |
| cimi | tsdgeos, it's the row | 15:23 |
| cimi | tsdgeos, Preview.qml puts widgets with spacing or a margins iirc | 15:24 |
| tsdgeos | cimi: i'd say it's | 15:25 |
| tsdgeos | leftMargin: units.gu(1) | 15:25 |
| tsdgeos | rightMargin: units.gu(1) | 15:25 |
| tsdgeos | shouldn't those be widgetmargins? | 15:25 |
| tsdgeos | cimi: lol ignore i was looking at the wrong code | 15:26 |
| dandrader | Saviq, greyback_, tsdgeos removing the logic to save window state on destruction I get this: http://pastebin.com/C4skrYQm | 15:26 |
| dandrader | (ubuntu pastebin wasn't working) | 15:26 |
| tsdgeos | dandrader: is this deleting the view before the app? | 15:27 |
| dandrader | tsdgeos, yes | 15:27 |
| greyback_ | dandrader: can you share your patch? | 15:29 |
| tsdgeos | cimi: meh, it still sucks that we need to have that -1 :/ | 15:29 |
| dandrader | greyback_, I pushed it | 15:29 |
| greyback_ | ok | 15:30 |
| dandrader | greyback_, plus this: http://pastebin.ubuntu.com/12877457/ | 15:30 |
| === dandrader is now known as dandrader|afk | ||
| cimi | tsdgeos, other ideas? | 15:41 |
| tsdgeos | cimi: the only think i can think of is passing down the parentMargins in a var and using those in the code with - | 15:43 |
| tsdgeos | if we make that var 0 by default and set it to 1 when inside the row | 15:44 |
| tsdgeos | it helps a bit with reusability | 15:44 |
| tsdgeos | but i may be overthinking this | 15:44 |
| tsdgeos | cimi: does this need a silo or i just get the top branch and try it? | 15:44 |
| cimi | tsdgeos, for the preview no, for the sharing we have no scopes using it | 15:45 |
| greyback_ | dandrader|afk: I'm seeing no impact from your patches, things still locking up with the same backtrace | 15:47 |
| greyback_ | I didn't get a fail with the google protobuf | 15:47 |
| tsdgeos | greyback_: Saviq: this deadlock thingie was not found by any test right? or was it? | 15:48 |
| greyback_ | tsdgeos: autopilot found it I believe | 15:48 |
| tsdgeos | makes sense | 15:48 |
| Saviq | tsdgeos, greyback_, well, *if* it would actually run in CI | 15:48 |
| Saviq | the only result would be longer autopilot times | 15:48 |
| Saviq | because upstart SIGKILLs after 60s or so | 15:48 |
| tsdgeos | oh | 15:49 |
| Saviq | *but* | 15:49 |
| Saviq | we have a crazy timeout set out in autopilot waiting for shutdown | 15:49 |
| Saviq | we should reduce that to a sane value now that we're actually shutting down fine | 15:49 |
| Saviq | and probably wait for the SIGKILL anyway, otherwise we'd try to start the next test before the previous one completed | 15:52 |
| greyback_ | dandrader|afk: I think you forgot to delete the QQmlEngine | 15:53 |
| greyback_ | that fixes the hang, but brings me back to the crash with dbus errors | 15:53 |
| greyback_ | and I managed to hit the google protobuf fail | 15:57 |
| === boiko_ is now known as boiko | ||
| Saviq | mterry, fyi, zsombi's beginning Ubuntu.Gestures migration to UITK right now | 16:09 |
| Saviq | if that affects OOBE at all | 16:09 |
| ltinkl | Saviq, the tutorial yes, the wizard not | 16:12 |
| Saviq | ltinkl, yeah, I was just thinking the bottom edge tutorial, we were discussing the two possible approaches (shell monitoring the gesture vs. app reporting progress) | 16:13 |
| Saviq | so just wanted to let him know what's happening there | 16:13 |
| mterry | Saviq, ok cool | 16:14 |
| mterry | That would help with consolidation if we do IPC to unity8 | 16:14 |
| === dandrader|afk is now known as dandrader | ||
| dandrader | greyback_, ah, good one. interesting I wasn't getting a hang even though I wasn't deleting the qml engine | 16:37 |
| dandrader | greyback_, but it wasn't leaking as the application was the parent | 16:38 |
| dandrader | greyback_, well, now it does as I stopped deleting the application, like in lp:unity8 | 16:38 |
| dandrader | greyback_, and unity-system-compositor hangs around for a while before finally going away | 16:45 |
| dandrader | maybe crashing as well... gonna check | 16:46 |
| Saviq | greyback_, looks like qtmir/multimonitor is what breaks input so that autopilot panel tests don't pass (the panel gets stuck a few pixels above the bottom edge, suggesting there was no TouchEnd when the autopilot finger went offscreen) | 17:02 |
| Saviq | just compiling qtmir @ multimonitor to verify, but that's my current thinking (and makes sense because there's quite a bit of input happening?) | 17:03 |
| Saviq | will also get you output from TouchRegistry / DDA debug | 17:03 |
| Saviq | dandrader, fyi, you're off the hook for the autopilot issue ↑ | 17:03 |
| Saviq | (looks like) | 17:03 |
| === alan_g is now known as alan_g|EOD | ||
| dandrader | Saviq, does unity8 handle SIGTERM? | 17:15 |
| Saviq | dandrader, Mir does | 17:15 |
| dandrader | ah, ok | 17:15 |
| Saviq | dandrader, then unity8 is told to shut down | 17:15 |
| dandrader | Saviq, so qtmir calls QGuiApplication::quit()? | 17:16 |
| * dandrader greps qtmir code | 17:17 | |
| Saviq | dandrader, our main does atm | 17:17 |
| Saviq | as in unity8's | 17:17 |
| Saviq | dandrader, main.cpp:119 | 17:17 |
| dandrader | Saviq, not sure what's the purpose of this line. qtmir does call QCoreApplication::quit | 17:19 |
| dandrader | http://pastebin.ubuntu.com/12878228/ | 17:19 |
| Saviq | dandrader, indeed | 17:20 |
| Saviq | dandrader, I think it might be the case where it's Qt that wants to quit | 17:21 |
| Saviq | dandrader, when closing the session | 17:21 |
| Saviq | we're not handling a signal then | 17:21 |
| Saviq | dandrader, yeah | 17:22 |
| Saviq | dandrader, QQmlEngine::quit() is emitted when you call Qt.quit() in qml | 17:22 |
| Saviq | dandrader, so yeah, qtmir quits when mir handles a SIGTERM, while unity8 quits when Qt.quit() is called | 17:30 |
| dandrader | Saviq, as for the google::protobuf::ShutdownProtobufLibrary() segfault. I think we will need alan_g's help | 17:33 |
| Saviq | dandrader, so we're not hanging, but crashing now? | 17:34 |
| dandrader | Saviq, yes | 17:34 |
| Saviq | dandrader, I can ~live with that... | 17:34 |
| robin-hero | Hey! I'd like to try unity8 on my laptop, but I can't find the desktop-next images. | 18:05 |
| robin-hero | Where can I find it? | 18:05 |
| davmor2 | robin-hero: I think they are removed as no-one was really working on it, since the plan changed to move to snappy for the base of unity8 aiui | 18:08 |
| robin-hero | davmor2: So I can't test the actual progress? | 18:09 |
| davmor2 | robin-hero: no idea | 18:10 |
| dandrader | robin-hero, install unity8-desktop-session-mir package and then a new session type will appear on the lightdm greeter: "Unity8-Mir" | 18:27 |
| robin-hero | dandrader: Thanks, but I don't want to install it, just want to test the live session :) | 18:28 |
| davmor2 | robin-hero: it's in an lxc container so you can dump it afterwards I guess | 18:29 |
| robin-hero | davmor2: But I have Ubuntu 14.04 on my laptop, is it not to "old"? | 18:30 |
| === dandrader is now known as dandrader|afk | ||
| === greyback__ is now known as greyback | ||
| === dandrader|afk is now known as dandrader | ||
| greyback | dandrader: about http://pastebin.ubuntu.com/12878228/, it is Mir which first gets the SIGTERM signal, and calls that lambda. But we don't shut down mir immediately, instead we tell Qt to shut down, and Qt shuts down the mir server at the right time (i.e. at QPA unload, which is after all windows & gl contexts have been released) | 19:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
