=== salem_ is now known as _salem === jono is now known as Guest14995 === marlinc|away is now known as marlinc === marlinc is now known as marlinc|away === alan_g is now known as alan_g|afk [07:49] MacSlow, ping [07:49] MacSlow, because we can't rely on "real" notifications implementation to be there for testing, http://pastebin.ubuntu.com/5779672/ [07:54] MacSlow, and http://pastebin.ubuntu.com/5779685/ for the depends [07:54] dandrader, dude, go to sleep! ;P [07:54] Saviq, :) [07:59] Saviq, ah ok... [07:59] Saviq, but didn't I add the "qtdeclarative5-unity-notifications-plugin | unity-notifications-impl" line already... [08:00] MacSlow, doesn't look like it [08:01] Saviq, odd... swear I had that done... probably missed a commit (before a revert) [08:01] MacSlow, yeah, happens [08:01] Saviq, are those two patches going to make it pass? [08:01] MacSlow, qmluitests - yes it should [08:02] Saviq, because looking at the test-run results there are no failing tests... of course locally it's always working [08:02] Saviq, https://jenkins.qa.ubuntu.com/job/unity-8.0-ci/116/artifact/unity-phablet-qmluitests-saucy/work/results/testNotifications.xml/*view*/ [08:02] MacSlow, because you have unity-notifications on your QML import path [08:03] MacSlow, but https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-saucy/88/testReport/junit/%28root%29/qmltestrunner/tst_Notifications__compile/ [08:04] MacSlow, for autopilot to pass we need to make lp:unity-notifications to be available in distro/PPA === alan_g|afk is now known as alan_g [08:21] MacSlow, I've uploaded unity-notifications to ppa:phablet-team - with this we should be able to pass CI [08:21] Saviq: ping [08:21] dednick, pong [08:21] Saviq, I've pushed the suggested chagnes as r24 of my branch [08:22] MacSlow, the first pass might not happen as the package needs to build in the PPA [08:22] MacSlow, but I'll keep you posted [08:22] Saviq, yeah... we need to give the jenkins-machinery some time [08:22] Saviq, I'll keep an eye on it too :) [08:22] MacSlow, btw, it passed locally for you because you had lp:unity-notifications somewhere on your QML import path [08:23] MacSlow, but qmluitests don't install the Depends (and shouldn't) [08:23] Saviq, yeah... did that manually on my desktop-machine and later on the phone too. [08:23] Saviq: having trouble with unity8 lenses on saucy. [08:24] Saviq: links dont seem to work anymore. have we changed to new libunity for unity8? [08:24] dednick, we're in the process [08:24] dednick, I hope today [08:24] MacSlow, yeah, I just built it for the phone and ran your branch and got notifications with no notify-osd in sight [08:24] dednick, https://code.launchpad.net/~unity-team/unity/8.new-libunity/+merge/167733 [08:25] dednick, but we need to land notifications first, so that we can get rid of lp:nux/phablet [08:25] dednick, 'cause that crashes the new-libunity branch [08:25] Saviq, yeah... as long as I don't reboot my Nexus I get the new ones too when someone phones/texts me :) [08:25] Saviq: ok. not sure if it's related, but autopilot tests dont seem to be working either. [08:25] Saviq: So no ci success. [08:26] MacSlow, why as long as you don't reboot? does notify-osd start even though the shell takes the dbus name? [08:26] MacSlow, or do you mean you haven't actually installed the package, but running from the local build? [08:26] Saviq, just locally build on the phone [08:27] MacSlow, cool [08:27] not any package [08:28] dednick, hmm CI was passing yesterday, no? [08:28] Saviq: dont know, but my branch is failing and trunk AP isn't working on my desktop. possibly just my branch/setup though [08:29] dednick, yeah locally won't work [08:29] dednick, 'cause libunity is conflicting [08:29] Saviq: i see [08:31] * Saviq reboots [08:41] MacSlow, ugh, *No copyright* in notifications.js [08:41] MacSlow, can you please add? [08:41] Saviq, sure [08:42] dednick, I've restarted the failed jobs, but there were only a few failed tests, so AP works fine, just that the tests failed, let's see how it goes [08:42] Saviq: my failure seems to be something to do with lock screen not showing [08:43] dednick, yeah, I saw that, let's see what happens [08:47] tsdgeos, do you see it as a "random autopilot failure" -> https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/193/testReport/unity8.tests.testhud/TestHud/test_show_hud_button_dont_open_Nexus_10_/ [08:47] ? [08:49] Saviq: hey. about that wifi bug. is anyone working on it? [08:49] mzanetti, not actively, no [08:49] nooooooo [08:49] Actual (lvwph->m_minYExtent): 323,333 [08:49] Expected (323.333): 323,333 [08:49] Saviq: hmm... thats the one that makes the phone useless for me right now [08:50] :'( [08:50] mzanetti, feel free to jump on it [08:50] tsdgeos, did javascript just bite you? [08:50] Saviq: ok. any pointers already are we all at 0 with this? [08:50] Saviq: nah, just trying to test a double number [08:50] tsdgeos: haha :P [08:51] dandrader: no video for that? we used to have autopilot videos [08:51] tsdgeos: there is something like fuzzyCompare iirc [08:51] mzanetti: this one is supposed to be using it [08:51] tsdgeos, https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/193/artifact/unity8.tests.testhud.TestHud.test_show_hud_button_dont_open%20%28Nexus%2010%29.ogv [08:51] i guess it's a too small fuzzy [08:51] tsdgeos, the fuzziness is a parameter, I think? [08:52] should be [08:52] need to find how to pass it [08:52] dandrader: the video is 40 seconds of amazing nothing :D [08:52] dandrader, yeah, I've already restarted CI on it [08:52] i'll blame the slowlyness of the machine [08:53] dandrader, it seems like it's a random unlock failure [08:53] mzanetti, I don't think we have any details beyond https://bugs.launchpad.net/touch-preview-images/+bug/1183065 [08:53] Launchpad bug 1183065 in touch-preview-images "Occassional severe battery drain" [High,New] [08:53] Saviq, tsdgeos, ok. thanks [08:53] mzanetti, but it does not feel like something we can fix in the shell [08:54] mzanetti, indicators-client at most [08:54] Saviq: no... seems network-manager related [08:55] actually can't find the fuzzy compare that let's me pass the fuzyness down :-S [08:55] ok, i'll add more 3333333333 [08:55] worked now :D [08:55] tsdgeos, verify( < ), verify ( > ) [08:55] ? [08:55] QCOMPARE(lvwph->m_minYExtent, 323.3333333333333); [08:55] lol [08:55] not sure how reliable that is [08:56] tsdgeos, http://qt-project.org/doc/qt-5.0/qtcore/qtglobal.html#qFuzzyCompare-8 didn't work? [08:57] tsdgeos: 970/3 ? [08:57] Saviq: that's the same, qcomare uses fuzzycompare for doubles [08:57] tsdgeos, yeah, just saw that [08:57] greyback: oh you the mathematic ;_) [08:57] yeah, we have a maths PhD in da house! [08:58] well it might make it more likely to equate on different arches [08:58] +1 [08:58] tis all [08:58] mzanetti, looks like there's enough people looking into the battery drain [08:58] mzanetti, unless you have some input for them [09:00] Saviq: yeah... I just read through the bug... [09:00] Saviq: still unity8 shouldn't loop at 40% cpu if network bails out [09:01] mzanetti, I suspect it's because the network indicator goes crazy [09:01] mzanetti, and so we're updating the network indicator UI constantly [09:01] hmm... that could be [09:02] damn I'm melting here... [09:02] +1 [09:02] its so hot, the fans of my PC are spinning even when the PC is off :D [09:02] lol [09:03] 27.7°C indoors at 68% humidity [09:03] and I'm adding to the humidity all the time... [09:05] dandrader, https://code.launchpad.net/~dandrader/unity/8_bottomBarDDA/+merge/170164/comments/379080 these don't look like random failures anymroe [09:05] https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/196/artifact/unity8.tests.testhud.TestHud.test_show_hud_button_dont_open%20%28Nexus%2010%29.ogv [09:05] https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/196/artifact/unity8.tests.testhud.TestHud.test_show_hud_button_dont_open%20%28Nexus%204%29.ogv [09:06] jo tak xrdp s pulseaudio fakt funguje ale byl to boj :-) [09:07] luv, I assume wrong channel? :) [09:07] dandrader, although it could be slowliness [09:07] ah, sry :-) [09:07] dandrader, as it seems for the nexus 4 it tries to drag from the bottom before the app gets into focus [09:09] Saviq, yes, I've just added some debug logs to DirectionalDragArea to pin point what's causing it [09:09] Saviq, I suspect it's the minimum speed requirements for the drag gesture [09:09] dandrader, mhm [09:09] didrocks, if phone-app depends on notify-osd, but unity8 (>= 7.81.0) will do what notify-osd did to date, how would you set up the Depends / Provides / Conflicts? [09:10] Saviq: will talk with you in a few, trying to unscrew ubuntu iso not building because of web credentials for now [09:10] didrocks, sure [09:10] didrocks, I could also bug someone else :) [09:11] seb128, your turn ^ [09:11] seb128, both should be installable in parallel (as we want notify-osd still for unity7, but unity8 handles it internally) [09:12] Saviq, hey [09:12] Saviq, you can do "Depends: notify-osd | unity (>= 7.90) [09:13] Saviq, you usually list the preferred option first [09:13] seb128, right [09:13] so likely unity8 | notify-osd [09:13] seb128, thanks, will do [09:14] Saviq, does unity8 really conflicts with notify-osd (like using same filenames on disk or same dbus namespace)? [09:14] seb128, same dbus name, yes [09:15] seb128, but only one should be running at any given time [09:15] ok, like any notification daemon [09:15] seb128, i.e. if unity8 is started, notify-osd shouldn't get dbus-activated [09:15] ok [09:15] seb128, so in theory we should be fine [09:15] so don't make those conflict or anything [09:15] yeah [09:15] some users might still want both [09:15] notify-osd to use with e.g xubuntu [09:15] yeah, we definitely want both [09:15] or unity7 [09:16] exactly [09:16] Saviq, ah, right. watching the videos it seems autopilot is doing the bottom-edge drag before the application-coming-to-foreground animation completes. [09:16] great [09:16] dandrader, yeah [09:16] it's all so incredibly slow there... [09:16] yeah, software rendering :/ [09:18] seb128, TBH it feels like it shouldn't be a dependency of the phone-app at all... [09:18] seb128, or maybe it should... [09:18] seb128, it's needed for calls, so maybe... [09:18] Saviq, we don't make every notification user depends on a notification daemon, we rely on the desktop environment to provide the feature [09:19] seb128, yeah, but here it's slightly more involved - i.e. you can't answer a call without either notify-osd or unity8... [09:19] Saviq, I guess you don't want notify-osd if you need interactions then [09:19] Saviq, notify-osd doesn't support actions [09:19] seb128, the phablet notify-osd does interactions [09:19] oh ok [09:19] which is being decommissioned anyway [09:19] so yeah, Recommends: unity8 | notify-osd [09:19] at least [09:20] (ok, waiting for feedback) I would say that we even don't need the |, it should just depends on unity8 [09:20] yeah [09:20] and having the notify-osd startup script detects the session name [09:20] to not start if dbus activated [09:20] didrocks, it only starts dbus-activated, afaict [09:21] didrocks, Saviq: well, the | is handy if you want to test the phone-app on desktop today [09:21] Saviq: yeah, we have a script on notify-osd to "only starts" in the right session name [09:21] didrocks, k [09:21] seb128: shouldn't we get unity8 soon? I think both will come at the same time [09:21] we should stop dbus activating the notification daemon at all [09:21] (as we are blocking on the converged indicator-messages anyway) [09:22] seb128, yeah, but desktop notify-osd doesn't help, since there's no interactions :) [09:22] right [09:22] no strong opinion either way, to be fair phone-app will be on the image with unity8 [09:22] yup [09:22] so that discussion is probably not worth the 15 minutes we already spammed IRC for :p [09:22] either depends/recommends including unity8 will do [09:22] ok, dropping the dependency altogether [09:23] lol [09:23] Recommends it is [09:23] ;-) [09:26] seb128: do you remember how we do handle starting notify-osd only on the ubuntu session? it seems to be an alternative now and no more a conditional startup script [09:26] which shouldn't be an issue in the unity8 session as it will own the dbus name I guess [09:26] yes [09:27] unless something tries to notify before unity8 starts... [09:27] Saviq: well, we'll figure out if that's the case, but unity8 will be, as compiz today, the first component to start :) [09:27] yup :) [09:28] if there are races, we'll figure it out [09:29] didrocks, I'm not sure, I didn't follow the recent changes ... I think Debian and others wanted to stop dbus activating notification services at all [09:29] didrocks, they wanted to just make those part of the desktop, so it should be the shell of session manager doing the activation [09:29] seb128: ok, well, the current solution should work, we'll refine if needed :) [09:29] right [09:29] thanks seb128, Saviq [09:30] didrocks, seb128 yup, thanks [09:34] didrocks, shrug, ok, the divert is still there, the content of the file is not [09:35] didrocks, robru broke it when he inlined the packaging: http://launchpadlibrarian.net/124264231/notify-osd_0.9.34-0ubuntu5_0.9.35daily12.11.28-0ubuntu1.diff.gz [09:35] didrocks, see the notify-osd-0.9.35daily12.11.28/data/org.freedesktop.Notifications.service.in in that upload [09:35] seb128: yeah, so if you install notify-osd and switch to a xfce session, you will get notify-osd [09:35] yes [09:35] seb128: not sure we care though, TBH [09:35] no, we don't [09:36] we should drop dbus activation at all [09:36] right [09:36] but on another day [09:36] atm it just works so let's not create extra work [09:36] exactly :) [09:38] mzanetti, ping [09:42] dednick, it seems the pinlock failures are consistent https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/198/? [09:42] mzanetti, any pointers ^? [09:42] dednick, maybe some trunk merge issue? [09:43] dednick, mzanetti the pinlock / passlock screens don't show up at all [09:43] tsdgeos, btw, didn't you fix the wrong placement in ListView with sections https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/198/artifact/unity8.tests.testlockscreen.TestLockscreens.test_unlock%20%28Keylock%29.ogv ? [09:43] Saviq: yah. thought they would be. i think the lightdm greeter prompt request isn't coming through [09:44] whatever that means. i was waiting on the results before going to check it out though [10:03] MacSlow, the import path is wrong [10:03] MacSlow, you have the brace after /plugins [10:03] MacSlow, should be before [10:04] MacSlow, and there's a missing "S" in qmltest_DEFAULT_ [10:04] MacSlow, why didn't you just apply my patch from [10:04] http://pastebin.ubuntu.com/5779672/ [10:05] Saviq, did copy&paste in vim... must have hit x :) [10:05] MacSlow, and notification.js, not notifications.js [10:06] MacSlow, next time, please do `patch -p0` [10:06] MacSlow, and actually check locally that it worked [10:06] MacSlow, http://pastebin.ubuntu.com/5779993/ [10:08] MacSlow, the autopilot failure is unrelated, too [10:35] Saviq: i did, question is, is the patch in saucy? and if it is, did i fix only one of the cases and there are more? [10:35] * tsdgeos checks if the patch is there on saucy [10:39] Saviq: patch still not there [10:39] tsdgeos, that's... good :) [10:39] according to Mirv is in the beta place? https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1183350 [10:39] Launchpad bug 1183350 in qtdeclarative-opensource-src (Ubuntu) "[Patch] Fix wrong initial position of delegates when using loaders and sections" [Undecided,Fix committed] [10:40] not sure what we can do to tell him to put it in proper [10:50] mzanetti, where does the logger.warning() stuff goes to when running autopilot tests in my desktop? [10:50] dandrader: stdout [10:50] dandrader: unless you specify "-f xml" when calling autopilot [10:50] dandrader: in that case it will end up in the produced xml file [10:53] mzanetti, now seeing the logged stuff anywhere. but "print 'foo'" does work [10:53] mzanetti, I'm running the tests like this: [10:53] tests/autopilot$ autopilot run unity8.tests.testhud.TestHud.test_show_hud_button_dont_open [10:53] s/now seeing/not seeing [10:54] dandrader: I think that should print to stdout/stderr [10:54] dandrader: give me a second to finish proposing that branch, then I can look at it [11:06] mzanetti, https://code.launchpad.net/~unity-team/unity-api/launcher/+merge/167586/comments/379166 [11:06] mzanetti, really just a few cosmetic changes [11:08] Saviq: ack === dandrader is now known as dandrader|afk === MacSlow is now known as MacSlow|lunch [11:15] mzanetti, btw, do we have any more hardware where we could run qmluitests on? it gets crowded there [11:23] Saviq: hmm... might be related that some VM's are detached because they are half-prepared for the switch away from unity [11:23] err... nux [11:23] mzanetti, mhm [11:25] mzanetti, should be sorted today, then [11:26] didrocks: oooh oooh! What's the threshold for unity tests? [11:26] didrocks: the number of failures I mean? [11:26] sil2100: IIRC, 17 or something like that [11:26] mzanetti, btw, I thought we should've been able to just use the newly prepared VMs already? [11:27] Saviq: but you have also a number of accepted regressions [11:27] sil2100: ^ [11:27] grrr :p [11:27] \o/ Ok, so I keep my fingers crossed, since one machine finished the tests and it had 14 failiures only! [11:27] sil2100: why? [11:27] yeah, let's hope so :) [11:27] Waiting for the other to finish [11:27] didrocks, I don't accept regressions! :P [11:27] mzanetti, i.e. we're probably not gonna drop ppa:phablet-team in the end, just unity and nux from the ppa [11:27] Saviq: lucky that you have 0 flacky tests! :) [11:28] didrocks, I wouldn't go that far [11:28] didrocks, who do you think clicks "rebuild" all the time :D [11:28] Saviq: ah, so you need to get a threshold to not block everything every time [11:28] Saviq: ok, I'll check on enabling the VM's [11:28] Saviq: I don't want to have that as part of the automated machinery [11:28] :D [11:28] especially when we have 200+ packages to deliver [11:28] so 200 clicks is not acceptable, even if it's just 10% :p [11:28] didrocks, no, it's not that bad http://s-jenkins:8080/job/unity-phablet-autolanding/ [11:29] didrocks, if jenkins doesn't barf [11:29] * didrocks doesn't know the ip of s-jenkins TBH :p [11:29] since it changed… === dandrader|afk is now known as dandrader [11:29] didrocks, https://jenkins.qa.ubuntu.com/job/unity-8.0-autolanding/? [11:29] mzanetti, ping [11:30] Saviq: 20-25% of runs [11:30] Saviq: if you scale that to all our stacks and components, it's still 50 reruns :) [11:30] didrocks, yeah, we'll get better, too :) [11:30] Saviq: hence this threshold to be quite relaxed on "some" flacky tests [11:30] we'll discuss it once we'll put unity 8 under daily release I guess :) [11:31] didrocks, yup, most often we get autopilot issues [11:31] didrocks, that fail 'cause they're so slow [11:31] similar than most of issues with unity 7 [11:31] Cimi: pong [11:31] mzanetti, I read your review, there are some things which are there for a reason [11:32] mzanetti, for example, starting from basicmenu === hikiko is now known as hikiko|lunch [11:32] mzanetti, the listitems are not themed in the sdk [11:33] mzanetti, so all the code you see, from the background to the thindivider, is for styling them [11:33] Cimi: but basicmenu inherits from ListItem [11:33] Cimi: then don't inherit from ListItem [11:33] Cimi: at least not from ListItems.Standard [11:33] mzanetti, and from what? I need the controls? [11:33] Cimi: what controls? [11:33] the icon, or the buttons [11:34] Cimi: you don't use the icons except in one case. In all the others you have a dead property in your public api, some wated resources because of the empty Image {} and worst of all, if someone uses the dead property it even breaks your component [11:35] so I should do standard and reimplement the code for the controls? [11:35] sorry, empty [11:35] Cimi: I'd say yes. If this should be used by other people, the API needs to be clean and safe [11:36] ok [11:37] Saviq: is there a way to hide inherited properties from the public API in qml? [11:37] mzanetti, I don't think there is [11:37] mzanetti, simply because everything's public... [11:40] sil2100, hey, any update on libunity9 / unity from daily-build going into distro? [11:42] Saviq: I'll have the test results in some moments and all will be known [11:43] sil2100, awesome [11:44] ooh we now get a dimmed screen before it goes off completely :D [11:44] nice one! [11:54] sil2100: seeing how long the tests are taking, I wonder if we don't have the dbus issue [11:54] mhr3: you maybe want to jump on the ati machine right now? ^ [11:54] didrocks: I think that machine might be affected indeed... [11:54] didrocks: since the other was fine [11:54] didrocks: btw. you think we could force the publication anyway? [11:55] sil2100: for unity, as we have good results on the other machine, i would say yes [11:55] sil2100: just run in 2 phases [11:55] first without "force" [11:55] to check with packaging changes and so on [11:55] Of course ;) [11:55] :) [11:55] didrocks, let me jump on it [11:55] didrocks, do i have a timer ticking before it dies? [11:56] mhr3: I don't know if jibel removed the timeout, but if we still have, you have 10 minutes :) === alan_g is now known as alan_g|lunch [11:57] Saviq: I'm confused. Should I apply your patch then which changes all the launcher api to use named imports? Didn't we just define the guideline to use explicit naming? [11:58] mzanetti, you didn't read ;) [11:58] mzanetti, when the import would look like "import Unity.Launcher", I'd rather not have "Launcher" in the registered types [11:58] mzanetti, so that with a named import you don't have to go Launcher.LauncherModel [11:59] mzanetti, explicit in class and file names, namespaced when registering - that was what I wrote down [11:59] mzanetti, but then got hit by the "Item" registration [11:59] mzanetti, and now I don't know again [12:00] ok... I did read but probably in the wrong order... confused shit out of me [12:04] mzanetti, so for this (and taking dandrader's comment into account) [12:04] mzanetti, I'll leave it to you [12:04] to decide [12:05] I still like named imports better for readability [12:05] but because there's issues like that (and especially bug https://bugreports.qt-project.org/browse/QTBUG-30730 [12:06] Trevinho, hi, is it known that bamf fires two emits of bamf_matcher.active_application_changed? with following args (OLD_APP, null) and (null, NEW_APP) instead of (OLD_APP, NEW_APP) [12:06] Saviq: holy s***... thats a bad bug [12:06] mzanetti, it's not even considered a bug [12:06] mzanetti, read Alan's comments :/ [12:06] mzanetti, we need to convince him it really is [12:07] ah... because it works without named imports [12:07] mzanetti, yeah, which is blind luck, Alan said it's not supposed to work [12:07] which is something I can't accept [12:08] ricotz: yeah... but it's also hard to fix without adding idles or something... Since it's impossible to predict wich one is going to be unactivated and which one is activated [12:08] didrocks: ok, in the meantime, I checked all stacks for the SRU that are ready for release, and the changelogs look ok, there are no packaging changes and all tests pass as expected [12:08] didrocks: can I publish so that they land in the SRU PPA? [12:08] MacSlow|lunch, SUCCESS on qmluitests [12:08] ricotz: I tried to change that, but it wasn't worth... ricotz probably we should instead just emit the new app activated and check which one was before... [12:08] MacSlow|lunch, and SUCCESS everywhere else [12:08] Trevinho, i see, there are even times where its fires 5 emmits [12:09] Saviq: ah... I see what he means === greyback is now known as greyback|lunch [12:09] Saviq: in C++, you wouldnt do something like: foo(MySingletonClass) [12:09] :/ i want d-feet, doing it all with dbus-send is not fun [12:09] Saviq: but rather foo(MySingletomClass::instance()) [12:09] mzanetti, it's not a class, it's an object of that class [12:10] sil2100: yeah \o/ [12:10] Saviq: and one way would be to make the instance() a property of that singleton [12:10] ricotz: mh, weird [12:10] Trevinho, the syntax is fine imo, and if there is a new active window, bamf should figure out what happend before emit [12:10] sil2100: tell me how it goes, just publish one stack so that we can check :) [12:10] as it's all brand new and shiny code path :p [12:10] Saviq: then you could call in QML: foo(MySingletonClass.instance) [12:10] mzanetti, but you're not exposing MySingletonClass [12:10] mzanetti, you're exposing MySingleton [12:11] mzanetti, and if MySingleton = MySingletonClass::instance() [12:11] mzanetti, you would do foo(MySingleton) [12:11] in C++ [12:11] Saviq: yeah... [12:11] Trevinho, e.g. emit-queue http://paste.debian.net/plain/11296 [12:11] Trevinho, for one window change [12:12] Saviq: just trying to figure why he doesn't think its a bug [12:12] mzanetti, it must be something weird internally [12:12] didrocks, ehm, yea, it just shutdown [12:12] mzanetti, that he didn't express [12:12] didrocks, the timeout is still 2h [12:12] ricotz: yes, the problem is that all this depends on the order that the views have on the list... but I also didn't want to introduce delays... [12:12] mhr3: indeed, did you get time to get any data? [12:12] jibel: maybe for some days, we should set it to 4? === hikiko|lunch is now known as hikiko [12:13] Trevinho, hmm, a delay seems better than doing things 5 times [12:14] didrocks, not much, i only saw that dbus was working [12:14] at least introspection was [12:14] Trevinho, may i pm you? [12:14] well, yeah... but then unity "triangles" (showiing the focused app) where not so nice... [12:14] ricotz: sure... [12:14] didrocks, jibel, also, something happened with lxc, it hangs when i lxc-list now [12:15] ricotz: however that's something I really wanted to improve, but it needs also to change something in unity probably [12:15] mhr3: right, it can't stop the container [12:15] jibel: ^ [12:15]