| === duflu_ is now known as duflu | ||
| === thumper is now known as thumper-afk | ||
| === lifeless_ is now known as lifeless | ||
| Mirv | morn | 04:58 |
|---|---|---|
| pitti | Good morning | 05:42 |
| seb128 | good morning desktopers | 06:43 |
| === ohama_ is now known as ohama | ||
| mlankhorst | morning! | 07:26 |
| === thumper-afk is now known as thumper | ||
| pitti | since today's dist-upgrade unity panel crashes every few mins, bug 1248446 | 08:32 |
| ubot2 | Launchpad bug 1248446 in unity (Ubuntu) "unity-panel-service crashed with SIGSEGV in g_object_unref()" [Undecided,New] https://launchpad.net/bugs/1248446 | 08:32 |
| pitti | this keeps rearranging windows and screen flicker, so it's quite noticeable | 08:33 |
| seb128 | pitti, hey | 08:34 |
| pitti | bonjour seb128, ça va ? | 08:34 |
| seb128 | pitti, that's an ido-trusty issue, I'm debugging it with tsdgeos on #ubuntu-unity, downgrade libido-3-0 if you need a workaround | 08:34 |
| seb128 | pitti, oui, et toi ? | 08:34 |
| pitti | seb128: ah, so known? thanks | 08:40 |
| pitti | seb128: I'm good, thanks! | 08:40 |
| seb128 | pitti, "known", you are the second one to ping me about it, tsdgeos is getting a valgrind log | 08:40 |
| pitti | apport traces arrived, too | 08:41 |
| tsdgeos | seb128: i'll add the valgrind log to the bug | 08:41 |
| seb128 | tsdgeos, thanks | 08:41 |
| seb128 | pitti, retraces matches http://paste.ubuntu.com/6369241/ from tsdgeos | 08:42 |
| tsdgeos | the valgrind log is not very interesting though | 08:42 |
| seb128 | tsdgeos, doesn't tell where the other unref is? | 08:44 |
| tsdgeos | according to the trace it'd seem it's not a double delete, just a bad delete :D | 08:44 |
| tsdgeos | but i haven't done much/any glib "bad deletion" code on valgrind so no idea if this is what one would expect from a double delete or not | 08:45 |
| pitti | you usually get a rather clear warning if you try to unref an already free'd object | 08:50 |
| pitti | (on stderr) | 08:50 |
| pitti | s/warning/critical/ | 08:50 |
| Laney | morning desktopperinos | 09:05 |
| seb128 | Laney, hey | 09:06 |
| seb128 | larsu, there? | 09:06 |
| * seb128 wonders wth about this code | 09:06 | |
| larsu | seb128: now I am | 09:20 |
| * larsu was up long last night | 09:20 | |
| seb128 | larsu, good morning! | 09:20 |
| seb128 | larsu, the issue is the g_object_unref (file); in l308 | 09:21 |
| larsu | seb128: wait, are we talking about the same thing here as in #ubuntu-unity? | 09:21 |
| seb128 | larsu, I knew I should have waited for you to be around, that you fix it easily :p | 09:21 |
| * seb128 just spent 30min looking to the changes to come to the conclusion you had directly :-( | 09:21 | |
| seb128 | larsu, yes, we moved there because pitti reported the issue as well | 09:22 |
| larsu | seb128: I wonder how this wasn't a problem during my testing | 09:23 |
| * seb128 gets the bug as well since today's update | 09:23 | |
| seb128 | larsu, yeah, me too :/ | 09:23 |
| seb128 | larsu, it segfaults every time there is a as refresh it seems | 09:23 |
| seb128 | I can trigger by calling SetIconFile in dfeet | 09:23 |
| seb128 | or just by waiting a bit | 09:23 |
| larsu | ah, doesn't happen in the loader… | 09:26 |
| larsu | oh, it does when closing it :) | 09:26 |
| seb128 | larsu, you didn't test the changes on your real session? no cookie :p | 09:26 |
| larsu | :'( | 09:27 |
| seb128 | larsu, you can still get cookies by get a fix up for review ;-) | 09:27 |
| * seb128 hugs larsu | 09:27 | |
| larsu | \o/ | 09:27 |
| seb128 | larsu, bug #1248446 if you want a bug reference | 09:28 |
| ubot2 | Launchpad bug 1248446 in ido (Ubuntu) "unity-panel-service crashed with SIGSEGV in g_object_unref()" [High,Confirmed] https://launchpad.net/bugs/1248446 | 09:28 |
| larsu | seb128: thanks. https://code.launchpad.net/~larsu/ido/remove-superfluous-unref/+merge/194088 | 09:31 |
| larsu | tsdgeos, pitti: sorry for that crash :/ (and thanks for tracking it down) | 09:32 |
| tsdgeos | larsu: no worries | 09:32 |
| tsdgeos | it took me a while to see it was crashing for how fast it restarts, but the konsole area was shirking/enlarging when switching tabs, and there's been no konsole update so i thought "WHAT?¿?" | 09:33 |
| seb128 | larsu, I wish the glib documentation was better about those things, I looked at it earlier but "transfer-none" doesn't speak to me | 09:33 |
| larsu | seb128: you should learn those, they're all over the docs. I agree its not very intuitive, but it's _very_ consistent | 09:34 |
| larsu | transfer-none: ownership is not transferred in any way (no freeing/unreffing) | 09:34 |
| seb128 | larsu, I though they were tags for gir, not human documentation :p | 09:34 |
| larsu | transfer-full: free all the things you get back | 09:34 |
| larsu | transfer-container: free the passed back array/list, but not its contents | 09:35 |
| larsu | seb128: they're used for both :) | 09:35 |
| seb128 | larsu, thanks for the explanations ;-) | 09:35 |
| seb128 | larsu, btw I set the commit message on the mr (and fixed the "trans*f*er-none" typo) | 09:35 |
| larsu | tsdgeos: I've long been a proponent of _not_ restarting things that crash so that it's more noticable. I'm very alone with that opinion though | 09:36 |
| larsu | and I can understand the other side of it | 09:36 |
| larsu | seb128: oh, thanks! | 09:36 |
| tsdgeos | yeah | 09:36 |
| tsdgeos | larsu: for devels it's better the permanent crash, for Joe User it's better the restart | 09:37 |
| tsdgeos | i guess | 09:37 |
| larsu | maybe we should only enable restarting on releases? | 09:37 |
| seb128 | larsu, what would we win of not restarting? | 09:38 |
| seb128 | that wouldn't give us more infos on the segfault | 09:38 |
| seb128 | but it would let those of us who run $unstable without a working desktop | 09:39 |
| seb128 | it seems getting the annoyance for no benefit | 09:39 |
| larsu | people would complain louder | 09:39 |
| larsu | seems like many just click away the crash reporter | 09:39 |
| larsu | but yeah, I totally see your point about a working system | 09:39 |
| seb128 | you can't really "click away the reporter", since closing it submits by default (you have to uncheck before closing to don't report) | 09:40 |
| seb128 | larsu, the current system didn't stop you to have several users reporting the issue the day the bug landed as well... | 09:40 |
| larsu | ha, fair enough | 09:41 |
| larsu | but they still had to revert to a lower version | 09:41 |
| seb128 | sil2100, can we get a new ido landing once https://code.launchpad.net/~larsu/ido/remove-superfluous-unref/+merge/194088 is in trunk? | 09:41 |
| sil2100 | seb128: I think we can do that, let me keep that on the radar | 09:42 |
| seb128 | sil2100, ok, earlier is better, unity-panel-service keeps segfaulting with yesterday's update which is going to be annoying for trusty users | 09:43 |
| larsu | lol, "trusty users" | 09:43 |
| sil2100 | ;) | 09:44 |
| seb128 | ;-) | 09:44 |
| sil2100 | seb128: if I would miss the moment when it's merged in, please poke me if you can | 09:44 |
| seb128 | larsu, best release codename ever :p | 09:44 |
| sil2100 | And I'll spin stuff | 09:44 |
| seb128 | sil2100, ok | 09:44 |
| seb128 | sil2100, it's merged | 09:53 |
| vila | mlankhorst: ping regarding bug #1244324 | 10:02 |
| ubot2 | Launchpad bug 1244324 in glamor-egl (Ubuntu) "glamor-egl crashes when running autopilot tests" [High,In progress] https://launchpad.net/bugs/1244324 | 10:02 |
| vila | mlankhorst: can you get the fix in ubuntu while it's dealt it upstream so we can restore the ci service ? | 10:03 |
| vila | *dealt with | 10:03 |
| mlankhorst | patience ;) | 10:04 |
| mlankhorst | https://launchpad.net/ubuntu/+source/glamor-egl/0.5.1-0ubuntu6 | 10:04 |
| vila | mlankhorst: wow, magic ! | 10:05 |
| mlankhorst | should autoclose the bug in an hour or so | 10:05 |
| vila | ohhhhh | 10:05 |
| sil2100 | seb128: ok, spinning! | 10:07 |
| seb128 | sil2100, thanks | 10:07 |
| vila | mlankhorst: hmm, I'm not sure I understand, none of xserver-xorg-glamoregl libglamor0 libglamor-dev in installed on qa-radeon-7750 | 10:58 |
| vila | mlankhorst: did your fix propagates somewhere else I should look for ? | 11:00 |
| mlankhorst | vila: 7750 is radeonsi right? | 11:01 |
| mlankhorst | xserver-xorg-video-ati pulls it in | 11:01 |
| vila | not installed either | 11:02 |
| vila | err wait | 11:02 |
| vila | wait wait wait | 11:02 |
| mlankhorst | ;) | 11:02 |
| vila | I'm looking at the host not at the container ;) scratch everything I said in the last minutes ;) | 11:03 |
| mlankhorst | I had a feeling | 11:04 |
| mlankhorst | considering 7750 wouldn't work otherwise | 11:05 |
| seb128 | bah, hate tests | 11:06 |
| seb128 | gdk-pixbuf fails to build due to tests, of course it works locally | 11:07 |
| mlankhorst | ;) | 11:07 |
| seb128 | https://launchpadlibrarian.net/155950592/buildlog_ubuntu-trusty-i386.gdk-pixbuf_2.30.0-0ubuntu1_FAILEDTOBUILD.txt.gz | 11:07 |
| mlankhorst | tried on a i386 chroot? | 11:07 |
| seb128 | I should | 11:07 |
| seb128 | it looks like they might be running installed-tests are build-time | 11:08 |
| seb128 | or at least relying on the package to be installed | 11:08 |
| mlankhorst | seems that way | 11:09 |
| vila | mlankhorst: yeah, xserver-xorg-glamoregl installed in the container | 11:10 |
| mlankhorst | seb128: yeah same failure here in a pbuilder | 11:10 |
| vila | mlankhorst: but I'm hitting a different bug so will need to tweak before confirming your fix ;) | 11:10 |
| mlankhorst | ERROR:animation.c:11:test_animation: assertion failed (error == NULL): Couldn't recognize the image file format for file '/tmp/buildd/gdk-pixbuf-2.30.0/tests/test-animation.gif' (gdk-pixbuf-error-quark, 3) | 11:12 |
| mlankhorst | after i created the file it asked for, but empty | 11:12 |
| seb128 | mlankhorst, it seems to be because it looks for the loader in the system location | 11:12 |
| mlankhorst | yeah | 11:13 |
| seb128 | I'm pondering just disabling the tests :p | 11:13 |
| seb128 | but Laney and pitti are going to look angry at me if I do that | 11:13 |
| mlankhorst | seb128: convert to autopkgtest or figure out how to override it? | 11:13 |
| mlankhorst | :> | 11:13 |
| * Laney stares | 11:14 | |
| mlankhorst | or define failure as another way to succeed. should be laney approved | 11:14 |
| seb128 | that's going to teach me to update to new versions when they seem fine, it was mostly new tests there | 11:15 |
| Laney | go ask mclasen, he fiddled with that stuff | 11:15 |
| seb128 | https://bugzilla.gnome.org/show_bug.cgi?id=703012 | 11:16 |
| ubot2 | Gnome bug 703012 in general "make check fails: Cannot open pixbuf loader module file '.../gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory" [Normal,Unconfirmed] | 11:16 |
| pitti | seb128: that doesn't fail on a local build? | 11:16 |
| pitti | seems strange | 11:16 |
| pitti | it doesn't sound very sensitive to a buildd environment | 11:16 |
| mlankhorst | pitti: not really, it can use the system version to test | 11:16 |
| seb128 | pitti, it doesn't fail on my system which has gdk-pixbuf installed | 11:16 |
| Laney | it fails in a clean chroot | 11:16 |
| pitti | oh, you didn't build in sbuild/chroot/pbuilder, I figure | 11:16 |
| seb128 | no I didn't | 11:16 |
| seb128 | I can't be bother to test build everything in pbuilder :p | 11:17 |
| seb128 | (that's what I get in return :/) | 11:17 |
| pitti | sbuild == ♥ :) | 11:17 |
| * seb128 needs a bigger disk than 80G | 11:17 | |
| pitti | well, sbuild + apt-cacher-ng + lots of RAM and building everything in /tmp, that is (/tmp on tmpfs) | 11:17 |
| === alan_g is now known as alan_g|afk | ||
| mlankhorst | hehehhehe | 11:18 |
| mlankhorst | pbuilder-dist + 16 gb ram to build in works for me | 11:19 |
| Laney | I think you need to set GDK_PIXBUF_MODULEDIR | 11:20 |
| mlankhorst | after I modded pbuilder to kill the archives after installing deps, before building, using 8 gb for copies of archive was a recipe for disaster | 11:20 |
| Laney | for the testsuite | 11:20 |
| mlankhorst | Laney: maybe, but the testsuite should do that upstream | 11:21 |
| Laney | ?!?!?!?! | 11:21 |
| Laney | of course, any fix is going to be an upstream fix | 11:22 |
| seb128 | Laney, do you want to have a look at it, since it seems you already have an idea what to do? ;-) | 11:25 |
| Laney | I don't :P | 11:25 |
| Laney | I just looked at the manpage for gdk-pixbuf-query-loaders | 11:25 |
| === alan_g|afk is now known as alan_g | ||
| seb128 | sil2100, what happened to the ido landing? | 11:38 |
| sil2100 | seb128: the indicator stack is running, when it is done we can release | 11:39 |
| seb128 | sil2100, ok, that's taking ages it seems | 11:40 |
| seb128 | on that note, lunch | 11:40 |
| seb128 | bbiab | 11:40 |
| sil2100 | seb128: yes, it was like that since all the stacks got ran, and this meant that indicators wasn't allowed to run by itself and was halted by waiting on other dependent stacks to finish | 11:40 |
| sil2100 | seb128: so platform had to be built first etc... | 11:41 |
| sil2100 | seb128: there was no way of dealing with this without breaking the stack builds that others prepared | 11:41 |
| seb128 | sil2100, ok, well as long as it lands soon that's ok | 11:57 |
| seb128 | sil2100, it would be nice if the fix was in by the time the US wakes up and start upgrading ... which is soon ... do you know when the stack is going to be ready? | 11:58 |
| sil2100 | seb128: sorry about that in overall, hope we'll release it in like 15 minutes or such | 11:58 |
| seb128 | ok | 11:58 |
| === MacSlow is now known as MacSlow|lunch | ||
| Laney | oh | 12:08 |
| Laney | I got the tests to pass | 12:08 |
| Laney | now to see where to insert that into the build system | 12:09 |
| seb128 | Laney, gdk-pixbuf? | 12:20 |
| Laney | ye | 12:20 |
| seb128 | oh, great ;-) | 12:20 |
| Laney | it was what I said | 12:20 |
| seb128 | I was just about to start looking at it, I though said "no" earlier | 12:20 |
| seb128 | thanks ;-) | 12:20 |
| Laney | yeah, I did | 12:20 |
| Laney | but then I thought "oh, I'll just try it quickly" | 12:20 |
| seb128 | ;-) | 12:21 |
| didrocks | sil2100: please don't land anything that is installed on touch | 12:21 |
| didrocks | seb128: what about the ido landing? | 12:21 |
| didrocks | is there a regression? | 12:22 |
| seb128 | didrocks, the landing from yesterday makes unity-panel-service segfaults every few minutes | 12:22 |
| * sil2100 checks for ido in the touch | 12:22 | |
| didrocks | sil2100: it is in touch | 12:22 |
| seb128 | didrocks, that's fixed in trunk, I really want that to land before U.S wake up/upgrade | 12:22 |
| didrocks | seb128: well, we can as well backout | 12:22 |
| didrocks | I first want to know if ido is what is getting one indicator crazy | 12:22 |
| seb128 | didrocks, "backout"? | 12:22 |
| didrocks | (the name is cut) | 12:22 |
| didrocks | revert to previous ido | 12:22 |
| seb128 | shrug | 12:22 |
| seb128 | the fix is a one liner | 12:23 |
| didrocks | it seems it wasn't network-manager | 12:23 |
| seb128 | dropping an incorrect g_free | 12:23 |
| sil2100 | hm, I was really sure that ido had nothing to do with touch | 12:23 |
| didrocks | seb128: yeah, but we have no idea if ido is what making all touch testss failing | 12:23 |
| seb128 | didrocks, I fail to see how ido could be used on the phone | 12:23 |
| didrocks | sil2100: ok, do you have any other idea? | 12:23 |
| didrocks | seb128: I just know it is in the phone by a dependency, I'm unsure if it's loaded or not | 12:23 |
| seb128 | didrocks, that doesn't make any sense to me, I checked the rdepends, no phone component uses it | 12:23 |
| seb128 | didrocks, do you have a log/error from a failing test? | 12:24 |
| seb128 | didrocks, what components have failing tests? | 12:24 |
| didrocks | seb128: it's not a failing tests, it's one indicator going crazy | 12:24 |
| didrocks | taking all CPU | 12:24 |
| seb128 | which one? | 12:24 |
| didrocks | and so a lot of tests failing | 12:24 |
| didrocks | indicator-* | 12:24 |
| didrocks | it's truncated, as said | 12:25 |
| seb128 | oh, "fun" | 12:25 |
| didrocks | indeed | 12:25 |
| didrocks | I was hoping for indicator-network | 12:25 |
| seb128 | is there any way to untruncate? | 12:25 |
| didrocks | as we got a network-manager update | 12:25 |
| didrocks | seb128: not that I know of | 12:25 |
| seb128 | didrocks, what's the diff between not-buggy and buggy? | 12:25 |
| didrocks | seb128: http://people.canonical.com/~ogra/touch-image-stats/20131105.changes | 12:25 |
| sil2100 | hmm | 12:26 |
| didrocks | psivaa downgraded all nm component | 12:26 |
| didrocks | we still have this indicator | 12:26 |
| seb128 | hum | 12:26 |
| seb128 | didrocks, can somebody reproduce the issue on an actual device? | 12:26 |
| sil2100 | psivaa: can you try downgrading ido? | 12:26 |
| didrocks | seb128: https://jenkins.qa.ubuntu.com/job/trusty-touch-maguro-smoke-ubuntu-rssreader-app-autopilot/9/artifact/clientlogs/top_before.log/*view*/ | 12:27 |
| didrocks | sil2100: already what I asked 10 minutes ago | 12:27 |
| didrocks | seb128: see different top run (for 2 minutes) | 12:27 |
| didrocks | seb128: we are trying on the test env directly now | 12:27 |
| didrocks | easier to rerun the tests | 12:27 |
| seb128 | didrocks, if an actual human could reproduce on a device where we can adb to that would be useful | 12:27 |
| psivaa | sil2100: downgraded to 13.10.0+13.10.20131031-0ubuntu1 and running a test now | 12:27 |
| sil2100 | psivaa: thanks! | 12:28 |
| seb128 | didrocks, psivaa, sil2100: do you have an uptodate device? what is apt wanting to do if you apt-get remove libido3-0.1-0 | 12:28 |
| seb128 | ? | 12:28 |
| didrocks | system settled. SUCCESS | 12:28 |
| * seb128 has saucy still there, needs to upgrade | 12:28 | |
| didrocks | seb128: no, I don't have it handy, trying to get back production working first | 12:29 |
| seb128 | didrocks, what does "system settled. SUCCESS" means? | 12:29 |
| didrocks | seb128: that the system was "quiet enough" | 12:29 |
| seb128 | didrocks, e.g that the ido downgrade fixes the issue? | 12:30 |
| didrocks | which should indicate that the indicator wasn't at that CPU % usage | 12:30 |
| didrocks | maybe, I want multiple runs before affirming it's the case | 12:30 |
| didrocks | seb128: seems to indicate ido is guilty: http://10.97.0.1:8080/job/trusty-touch-maguro-smoke-ubuntu-calculator-app-autopilot/12/artifact/clientlogs/top_before.log | 12:33 |
| didrocks | see the last top run | 12:33 |
| didrocks | no indicator* | 12:33 |
| didrocks | psivaa: running others? | 12:34 |
| seb128 | didrocks, so it's unity-services which brings ido on the image | 12:35 |
| didrocks | seb128: but unity-services isn't started, right? | 12:35 |
| didrocks | on the device | 12:35 |
| seb128 | didrocks, well, if it's not a fail to see how ido can impact on indicators :/ | 12:35 |
| didrocks | seb128: let's see with other runs, but at least, if we identify that one as being the cause… there is clearly something to look into | 12:36 |
| seb128 | didrocks, can you see if unity-panel-service is running on that test machine? | 12:36 |
| didrocks | psivaa: you are the one connected ^ | 12:36 |
| seb128 | sil2100, meanwhile please publish the new ido | 12:36 |
| seb128 | that can't hurt | 12:37 |
| seb128 | if we need to do a revert we can still do it | 12:37 |
| seb128 | but at least we don't stay on a buggy version while deciding on the revert | 12:37 |
| didrocks | sil2100: no, please don't publish it | 12:37 |
| seb128 | grrrr | 12:37 |
| didrocks | I would rather go with a backout versoin | 12:37 |
| * seb128 manual upload | 12:37 | |
| didrocks | seb128: come on, you screw us | 12:37 |
| seb128 | didrocks, and you screw us | 12:37 |
| didrocks | so please try to be cooperative | 12:37 |
| seb128 | difference is that desktop is in production | 12:37 |
| didrocks | seb128: I wasn't the one pushing a broken version to the archive | 12:37 |
| seb128 | where your image doesn't reach users | 12:38 |
| didrocks | seb128: yeah, so let's rollback | 12:38 |
| didrocks | I'm happy to handle that rollback | 12:38 |
| seb128 | didrocks, that version is not broken afaik, but it seems unity8 is doing something weird trying to load gtk components | 12:38 |
| didrocks | seb128: well, we don't know, you thought yesterday's version wasn't broken | 12:38 |
| didrocks | and it segfaults | 12:39 |
| seb128 | you better fix whatever tries to load a gtk library | 12:39 |
| didrocks | so I'm trying the safest path for now | 12:39 |
| seb128 | didrocks, still, something on the device is doing something stupid | 12:39 |
| seb128 | didrocks, and you better get at the bottom of it | 12:39 |
| didrocks | seb128: I don't say the contrary | 12:39 |
| didrocks | seb128: *but* we are doing a complex 1.4 AP transition | 12:39 |
| didrocks | I still don't have a status on the 1.3 last release because of this | 12:39 |
| didrocks | so let's get some other test runs | 12:40 |
| didrocks | (and no, no unity-panel-service is running now on my device with a recent image) | 12:40 |
| seb128 | didrocks, I guess no indicator is using 100% cpu either? | 12:40 |
| didrocks | seb128: I don't have latest | 12:41 |
| didrocks | seb128: sorry, but keep being interrupted, even no coffee from this morning | 12:41 |
| didrocks | mostly because of that issue | 12:41 |
| seb128 | didrocks, stop starting IRC before coffee! | 12:41 |
| didrocks | that's not related to it | 12:42 |
| * seb128 installs new ido on his saucy | 12:42 | |
| didrocks | psivaa: around at all? | 12:43 |
| psivaa | seb128: didrocks: so with nm downgraded (maguro) i still see some systemsettle failures. but with ido downgraded (mako) i see some improvements | 12:43 |
| psivaa | didrocks: yes, the tests take time to run :) | 12:43 |
| didrocks | psivaa: how many tries with ido downgraded? | 12:43 |
| didrocks | just one or more? | 12:43 |
| seb128 | psivaa, "some improvements" or "it's fixed"? | 12:43 |
| psivaa | didrocks: seb128: one test, still running | 12:44 |
| seb128 | psivaa, can you "grep ido /proc/*/maps" | 12:44 |
| seb128 | and see if that returns something? | 12:44 |
| didrocks | (flashed latest image and of course, can't reproduce…) | 12:45 |
| * sil2100 is confused | 12:45 | |
| seb128 | didrocks, ok, so you want to revert ido in trusty now? | 12:45 |
| didrocks | seb128: I wish we can wait for 30 minutes to get more results | 12:45 |
| sil2100 | I'll just get back to fixing AP issues maybe... ;) | 12:45 |
| * sil2100 walks away silently | 12:45 | |
| seb128 | didrocks, well, if we wait for 30 min we can land the segfault fix, so it's in, then we can revert | 12:45 |
| seb128 | if needed | 12:45 |
| * seb128 doesn't get what blocking the 1 liner segfault fix brings us | 12:46 | |
| didrocks | seb128: as you wish, but if we see that ido is really the faulty one, I don't want that we wait for testing the ido fix, agreed? | 12:46 |
| psivaa | seb128: i ran that command on both devices and both return nothing | 12:46 |
| seb128 | didrocks, sure | 12:46 |
| didrocks | sil2100: ok, please release this ido ^ know that we maybe we'll revert all ido soon though | 12:47 |
| seb128 | didrocks, I've installed the new ido on my device (saucy) and it creates no issue | 12:48 |
| didrocks | psivaa: what do we have on mako? | 12:48 |
| psivaa | didrocks: downgraded ido | 12:49 |
| didrocks | downgraded network-manager as well? | 12:49 |
| psivaa | didrocks: no | 12:49 |
| didrocks | ok, so calendar-app seems to show that ido is really guilty | 12:49 |
| didrocks | really really weird… | 12:49 |
| seb128 | didrocks, calendar-app?! wth... | 12:50 |
| didrocks | seb128: the test of calendar-app (systemsettle one) | 12:50 |
| didrocks | seb128: basically ALL tests were screwed because of this indicator | 12:50 |
| didrocks | seb128: http://reports.qa.ubuntu.com/smokeng/trusty/touch/ | 12:51 |
| seb128 | didrocks, calendar-app is not an indicator though | 12:51 |
| didrocks | http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/12:20131105:20131031.1/4903/ | 12:51 |
| didrocks | seb128: yeah, but if an indicator is using all the CPU… | 12:51 |
| didrocks | the tests will fail | 12:51 |
| seb128 | ok | 12:51 |
| didrocks | 67% of mem for an indicaotr | 12:51 |
| seb128 | how do we go about debugging the issue next? | 12:52 |
| didrocks | seb128: so, if it's not ido as it seems it can't, if it's not netowkr-manager, what can it be? | 12:52 |
| seb128 | can we figure out what loads ido | 12:52 |
| seb128 | and what indicator uses the cpu? | 12:52 |
| didrocks | seb128: I guess that's more a question for upstream to figure it out | 12:53 |
| seb128 | didrocks, we had an unity8 landing, did we rul that one to be buggy? | 12:53 |
| didrocks | right now, I'm trying to ensure we find the right guilty | 12:53 |
| seb128 | didrocks, or are we sure than downgrading ido is workaround it? | 12:53 |
| didrocks | seb128: it can be unity8, indeed | 12:53 |
| didrocks | seb128: what I'm telling, I'm not ensured it's ido right now | 12:53 |
| seb128 | didrocks, also, whoever "downgraded nm", did they include the libs or just the network-manager binary? | 12:53 |
| didrocks | seb128: psivaa told me he dowgraded all binaries from nm source | 12:54 |
| seb128 | ok | 12:54 |
| didrocks | if only we knew which indicator was at fault… | 12:54 |
| seb128 | where is the script doing the top? can we tweak it? | 12:55 |
| didrocks | seb128: we can tweak it, do you know what's the parameter for top to not truncate? | 12:55 |
| didrocks | it's in utah test suite | 12:55 |
| sil2100 | seb128, didrocks: ido publishing | 12:55 |
| psivaa | didrocks: seb128: http://pastebin.ubuntu.com/6370333/ is the nm related packages in the nm downgraded device | 12:56 |
| didrocks | sounds like the whole selection | 12:56 |
| didrocks | system settled. SUCCESS | 12:56 |
| didrocks | with friends tests | 12:56 |
| didrocks | on mako | 12:56 |
| didrocks | (with thus only ido downgraded) | 12:56 |
| psivaa | didrocks: yes | 12:57 |
| didrocks | so 3 on 3 runs? | 12:57 |
| === alan_g is now known as alan_g|lunch | ||
| sil2100 | seb128: ido should be in soon | 12:59 |
| didrocks | local run on a really fresh install -> nothing | 13:00 |
| * didrocks wonders why he's the only one caring about this | 13:02 | |
| didrocks | ok, giving up… | 13:02 |
| seb128 | didrocks, top -b -n1 -c > log | 13:02 |
| seb128 | didrocks, that gives non truncated commands | 13:02 |
| seb128 | didrocks, sorry was googling for the top truncating | 13:03 |
| === Rodge is now known as Rodge_ | ||
| seb128 | Laney, thanks for the gdk-pixbuf fix! | 13:05 |
| psivaa | didrocks: terminal app tests, systemsettle success: http://10.97.0.1:8080/job/trusty-touch-mako-smoke-ubuntu-terminal-app-autopilot/15/console | 13:05 |
| psivaa | which earlier failed with the latest ido | 13:05 |
| Laney | seb128: np! | 13:05 |
| Laney | don't really understand these new test harnesses | 13:06 |
| Laney | so I have trusty/13 on my mako | 13:06 |
| didrocks | psivaa: ok, continue running mako with this ido downgraded, let's try to reflash maguro | 13:06 |
| Laney | how do I get this bug? | 13:06 |
| psivaa | didrocks: do you want me to get maguro with the latest image and downgrade ido as well? | 13:07 |
| didrocks | Laney: I don't get it as well, locally | 13:07 |
| didrocks | psivaa: no, just get latest image on maguro, then, let me give you a branch so that we know which indicator is failing | 13:07 |
| psivaa | didrocks: ack | 13:08 |
| didrocks | psivaa: can you apply that to the systemsettle script branch? http://paste.ubuntu.com/6370377/ | 13:08 |
| didrocks | hopefully, the command name won't be truncated anymore | 13:08 |
| didrocks | so that we see what indicator is guilty | 13:09 |
| didrocks | (so just run one test) | 13:09 |
| didrocks | then, let's downgrade ido | 13:09 |
| psivaa | didrocks: ack | 13:09 |
| didrocks | and retry all tests on maguro as well | 13:09 |
| Laney | are there any crash files? | 13:11 |
| didrocks | Laney: none from the dashboard. For instance: http://reports.qa.ubuntu.com/smokeng/trusty/touch/maguro/12:20131105:20131031.1/4905/ubuntu-terminal-app-autopilot/ | 13:12 |
| Laney | mmm | 13:12 |
| didrocks | seb128: I don't htink that will work through adb though | 13:15 |
| seb128 | didrocks, the top? | 13:15 |
| didrocks | yep | 13:16 |
| didrocks | because of adb TERMCAP | 13:16 |
| didrocks | just try adb shell | 13:16 |
| didrocks | and your command | 13:16 |
| didrocks | -> see top being truncated | 13:16 |
| seb128 | didrocks, COLUMNS=900 top -b -n1 -c > log | 13:17 |
| seb128 | that works | 13:17 |
| didrocks | psivaa: mind prepending this COLUMNS=900 as well? | 13:18 |
| didrocks | seb128: nice catch | 13:18 |
| psivaa | didrocks: ack will do. the flashing ongoing btw for maguro | 13:18 |
| Laney | btw: | 13:18 |
| Laney | phablet@ubuntu-phablet:~$ aptitude why libido3-0.1-0 | 13:19 |
| Laney | i ubuntu-touch Depends unity8 | 13:19 |
| Laney | i A unity8 Depends unity8-private (= 7.83+14.04.20131105.1-0ubuntu1) | 13:19 |
| Laney | i A unity8-private Depends libunity-core-6.0-8 (>= 7.0.0) | 13:19 |
| Laney | i A libunity-core-6.0-8 Depends unity-services (= 7.1.2+13.10.20131014.1-0ubuntu1) | 13:19 |
| Laney | i A unity-services Depends libido3-0.1-0 (>= 13.10.0daily13.06.19) | 13:19 |
| didrocks | ahah, so unity8 is using it | 13:19 |
| didrocks | yeah but | 13:19 |
| didrocks | libunity-core-6.0-8 doesn't start unity-services | 13:19 |
| Laney | it's probably unused | 13:19 |
| seb128 | it's not | 13:19 |
| didrocks | (u-p-s) | 13:19 |
| Laney | but that's why it is there | 13:19 |
| seb128 | right | 13:19 |
| seb128 | libunity-core-6.0-8 depends on it (is that buggy?) | 13:19 |
| didrocks | if it's optional now, yeah, it is | 13:20 |
| didrocks | it was required before | 13:20 |
| seb128 | because of a schemas or something? | 13:20 |
| didrocks | but still, that doesn't explain if downgrading ido reliably "fix" | 13:20 |
| Laney | it has the upstart job | 13:20 |
| Laney | to start ups | 13:20 |
| didrocks | Laney: but not on touch, right? | 13:20 |
| Laney | oh and ups itself | 13:20 |
| === Rodge_ is now known as recoveryRodge | ||
| seb128 | but yeah, that ido stuff doesn't make sense to me | 13:20 |
| Laney | no | 13:20 |
| Laney | don't know if it needs to be a depends of the library or could be from unity itself or so | 13:21 |
| didrocks | I still don't know why I don't see that crazy indicators here | 13:21 |
| didrocks | the only thing I don't have is messages and sim card | 13:21 |
| didrocks | maybe popey can see the issue | 13:22 |
| popey | hm? | 13:22 |
| didrocks | popey: with latest image, if you adb shell just after you boot your phone | 13:22 |
| didrocks | and run COLUMNS=900 top -b -n1 -c | 13:22 |
| popey | immediately after boot? | 13:22 |
| didrocks | do you see some indicators being at the top, like taking most of the CPU (for the first 2 minutes | 13:23 |
| didrocks | ) | 13:23 |
| didrocks | yeah | 13:23 |
| popey | lets see | 13:23 |
| didrocks | and then 2 minutes after boot | 13:23 |
| didrocks | thanks! | 13:23 |
| popey | no | 13:24 |
| popey | i see hud-service initially | 13:24 |
| didrocks | and then everything's idled? | 13:24 |
| popey | nothing especially eating cpu | 13:24 |
| popey | aside from top | 13:24 |
| didrocks | hum… | 13:24 |
| didrocks | why? it's so reliable on the DC… | 13:25 |
| === MacSlow|lunch is now known as MacSlow | ||
| popey | current build number: 13 | 13:25 |
| popey | device name: mako | 13:25 |
| popey | that the right one? | 13:25 |
| ogra_ | we probably just need to send popey over and it will work magically | 13:25 |
| didrocks | yeah | 13:25 |
| popey | ooh | 13:25 |
| didrocks | ogra_: well, can't get it here as well :/ | 13:25 |
| didrocks | Laney neither it seems :/ | 13:25 |
| didrocks | I was hoping it was sim-card influenced | 13:26 |
| ogra_ | weird | 13:26 |
| popey | top - 13:26:23 up 3 min, 1 user, load average: 1.70, 1.34, 0.58 | 13:26 |
| didrocks | yeah, sounds reasonable | 13:26 |
| didrocks | psivaa: do you have other mako results while maguro is flashing? | 13:26 |
| didrocks | psivaa: like, we do have 0 system settle idling issue? | 13:27 |
| popey | lots of wifi networks in the DC? | 13:27 |
| * ogra_ doesnt fine a load above 1 reasonable ... | 13:27 | |
| popey | or indeed, none? | 13:27 |
| ogra_ | but thats another topic :) | 13:27 |
| popey | thats mostly "top" ogra_ | 13:27 |
| popey | 2969 root 20 0 2540 1096 708 R 2.3 0.1 0:01.26 top | 13:27 |
| psivaa | didrocks: yes terminal app is finished with success | 13:27 |
| ogra_ | popey, top cant produce a load above 1 ... thats something else | 13:27 |
| didrocks | popey: yeah, maybe… | 13:27 |
| popey | well, top is more than everything else | 13:28 |
| ogra_ | popey, try on a decent PC ... | 13:28 |
| popey | there is other stuff, but top is the largest proprtion | 13:28 |
| didrocks | ogra_: TBH, I would appreciate that we all focus the effort on fixing the regression first | 13:28 |
| ogra_ | load should always be under 1 unless there is something actally demanding going on | 13:28 |
| popey | indicator-power wakes up now and then | 13:28 |
| Laney | qengho: looks like the chromium tests fail newly now: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-chromium-browser/11/ARCH=amd64,label=adt/console | 13:28 |
| popey | http://paste.ubuntu.com/6370456/ | 13:29 |
| popey | those are all eating a little bit all the time | 13:29 |
| didrocks | psivaa: so you continue on running everything manually on mako? | 13:30 |
| didrocks | (all the one which had system settle idling issue) | 13:30 |
| ogra_ | didrocks, agreed, but what if my assumption is that top gets us wrong data ;) | 13:30 |
| psivaa | didrocks: yes, ubuntuuitoolkit is running and addressbook is the next | 13:30 |
| didrocks | psivaa: I'm so puzzled… | 13:30 |
| psivaa | didrocks: ? | 13:31 |
| didrocks | psivaa: like, we have really nothing using ido | 13:31 |
| didrocks | and you just downgraded ido on mako | 13:31 |
| didrocks | and we see no failure… | 13:31 |
| psivaa | didrocks: right, these are the nm related packages in mako: http://pastebin.ubuntu.com/6370341/ | 13:31 |
| didrocks | yeah, so latest of latest… | 13:32 |
| psivaa | didrocks: yes | 13:32 |
| psivaa | so afaik only change is downgraded ido | 13:32 |
| didrocks | Laney: seb128: any idea? ^ | 13:33 |
| seb128 | can you upgrade it again and get the non truncated top output? | 13:33 |
| didrocks | seb128: that's why we reprovision maguro | 13:33 |
| didrocks | then I guess psivaa will run one | 13:34 |
| didrocks | the first test should get the failure | 13:34 |
| seb128 | didrocks, not really, as said I can't make any sense of the situation, I fail to see why ido would be anything else than a file on disk | 13:34 |
| didrocks | with the non truncated top output | 13:34 |
| seb128 | e.g the only thing linking to it is unity-panel-service | 13:34 |
| didrocks | system settled. SUCCESS | 13:34 |
| didrocks | for ubuntuuitoolkit | 13:34 |
| seb128 | that's not used on the device | 13:34 |
| didrocks | seb128: before, most of the tests (like > 60% of them) were failing | 13:35 |
| didrocks | on image 12 and 13 | 13:35 |
| didrocks | on both devices | 13:35 |
| seb128 | didrocks, image 12 had the new ido already? | 13:35 |
| didrocks | yeah | 13:35 |
| seb128 | k | 13:35 |
| ogra_ | indicator-sound and indicator-datetime are in libdio3's rdeps | 13:35 |
| didrocks | image 12 is the diff I pasted | 13:35 |
| seb128 | ogra_, ? | 13:35 |
| ogra_ | ogra@anubis:~$ apt-cache rdepends libido3-0.1-0|grep indicator | 13:35 |
| ogra_ | indicator-sound | 13:35 |
| ogra_ | indicator-sound | 13:35 |
| ogra_ | indicator-datetime | 13:35 |
| seb128 | ogra_, is that in saucy? | 13:36 |
| seb128 | ogra_, or do you run that on a box with a raring source? | 13:36 |
| ogra_ | oh, sorry, thats precise even | 13:36 |
| jpds | larsu: 'sup. | 13:36 |
| seb128 | ogra_, that was before the convergence codebase | 13:36 |
| larsu | seb128: do you know the state of desrt's app info stuff? | 13:36 |
| seb128 | larsu, no | 13:36 |
| larsu | the branch looks pretty complete to me... | 13:36 |
| larsu | okay, I'll just wait for him to wake up then | 13:36 |
| larsu | hi jpds! | 13:36 |
| === alan_g|lunch is now known as alan_g | ||
| didrocks | psivaa: so trusty-touch-maguro-smoke-ubuntu-clock-app-autopilot failed to settle right? | 13:57 |
| psivaa | didrocks: yes | 13:57 |
| didrocks | but I don't see anything in top_before… | 13:57 |
| didrocks | psivaa: do you see anything here? ^ | 14:00 |
| psivaa | yea, i see indicator-datetime-service once no other related to indicator | 14:01 |
| didrocks | but nothing reliably on top | 14:01 |
| didrocks | on top of top | 14:01 |
| didrocks | as we had | 14:01 |
| psivaa | yea, i'll run once more | 14:02 |
| didrocks | asac: I'm completely out of ideas ^ | 14:02 |
| didrocks | 4 non stop hours I'm struggling with this… | 14:03 |
| didrocks | system is settled now | 14:05 |
| didrocks | ok psivaa: let's try to increase the timeout | 14:05 |
| didrocks | to 5 minutes | 14:05 |
| didrocks | trying to get one run | 14:05 |
| didrocks | then, we'll look later on the regression | 14:05 |
| didrocks | I'm completely out of ideas | 14:05 |
| didrocks | we have way more hectic transition to handle with | 14:06 |
| didrocks | so, let's hope that we "only" take longer to settle | 14:06 |
| didrocks | and that's not reliable | 14:06 |
| didrocks | psivaa: making sense? | 14:06 |
| psivaa | didrocks: yea, we could try that | 14:06 |
| didrocks | psivaa: so, you do continue with a longer timeout to run all mako + all maguro which system settled fail? | 14:08 |
| didrocks | so that we can have run 13 with real results | 14:08 |
| didrocks | on both | 14:09 |
| didrocks | before AP 1.4 transition | 14:09 |
| psivaa | didrocks: ack | 14:09 |
| psivaa | didrocks: im changing the timeout from 120 -> 300 | 14:09 |
| didrocks | psivaa: thanks, keep me posted in your rerun if it's not enough and we'll see | 14:09 |
| psivaa | didrocks: one more thing, do you want me to upgrade ido to the latest in mako when running with increased timeout? | 14:10 |
| didrocks | psivaa: for the remaining one? yeah, why not | 14:11 |
| didrocks | (don't rerun those for which system settle passed) | 14:11 |
| psivaa | didrocks: ok, i've run most of the tests in mako that failed systemsettle_before with older ido.. ill run them if there is anything left | 14:12 |
| didrocks | ok | 14:13 |
| didrocks | psivaa: so, friends couldn't system settle on mako, this is just after the ido upgrade + timeout? | 14:27 |
| psivaa | no, this was with downgraded ido and shorter timeout. the one that's running now is with the increased timeout, | 14:28 |
| psivaa | forgot to upgrade ido. sigh...sorry, will do that after this run | 14:28 |
| didrocks | psivaa: ok, you kept the "longer top command right"? | 14:28 |
| psivaa | didrocks: yes | 14:29 |
| didrocks | great, let's hope :) | 14:29 |
| didrocks | seb128: so, that seems to confirm it's really an annoying-unknown-issue | 14:30 |
| didrocks | and not ido related | 14:30 |
| didrocks | not sure why we had ido downgraded passing test reliably for a while, like multiple times in a row | 14:30 |
| seb128 | didrocks, yeah, that's quite weird indeed | 14:30 |
| didrocks | Saviq: did you make any change in unity8 that can make an indicator taking > 60% of CPU at load time? | 14:31 |
| didrocks | boot* | 14:31 |
| Saviq | dednick, ↑? | 14:33 |
| dednick | Saviq: :/ not that I know of | 14:36 |
| dednick | didrocks: an indicator, you mean the backend | 14:37 |
| didrocks | seb128: so, things we have better top log, I can't find a case where there is an indicator at the top | 14:38 |
| didrocks | since* | 14:38 |
| seb128 | :-( | 14:38 |
| seb128 | red herring? | 14:38 |
| didrocks | well, depressing, annoying, bothering… whatever word you want to put… | 14:39 |
| psivaa | didrocks: http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/13:20131105.1:20131031.1/4910/friends-app-autopilot/ is with increased timeout and old ido | 14:44 |
| * didrocks sigh | 14:44 | |
| didrocks | so at least: 2151 phablet 20 0 212204 177852 3848 R 69.5 9.3 2:45.98 /usr/lib/arm-linux-gnueabihf/indicator-network/indicator-network-service | 14:44 |
| didrocks | psivaa: but with downgraded nm, we got it, right? | 14:45 |
| dednick | didrocks: ubuntu-settings-components landing. Says needs upstream feedback. ? | 14:45 |
| didrocks | dednick: yeah, about why is it needed, what will use it | 14:46 |
| psivaa | didrocks: at the moment we dont have anything running with downgraded nm, but we still got systemsettle issues with downgraded nm | 14:46 |
| didrocks | psivaa: and on those systemsettle issues, it was an indicator at the top? | 14:46 |
| dednick | didrocks: sharing qml components between ubuntu-system-settings and unity8 | 14:47 |
| didrocks | dednick: can you write that on the spreadsheet please? (or someone to add that) | 14:47 |
| dednick | didrocks: ok | 14:47 |
| didrocks | thanks! | 14:47 |
| didrocks | psivaa: I wonder if we are not mixing 2 issues | 14:47 |
| didrocks | one which can be the nm one | 14:48 |
| didrocks | and another one which happens way less often | 14:48 |
| psivaa | didrocks: quite possible, let me look at some of the runs and see if we could see a pattern | 14:48 |
| didrocks | psivaa: meanwhile, can you retry downgrading nm | 14:49 |
| didrocks | and rerun the one with system settle idle failing? | 14:49 |
| didrocks | cyphermox: hey, around? | 14:52 |
| psivaa | didrocks: so now, on maguro with all the latest nm and ido but with increased systemsettle timeout, we see the systemsettle_before pass now. | 14:53 |
| psivaa | http://reports.qa.ubuntu.com/smokeng/trusty/touch/maguro/13:20131105.1:20131031.1/4909/ | 14:53 |
| psivaa | didrocks: which device you want me to downgrade nm? | 14:53 |
| didrocks | psivaa: the mako one (the one which failed friends) | 14:53 |
| cyphermox | didrocks: what's up | 14:53 |
| didrocks | psivaa: on the maguro, this is the status with no systemsettle issue? | 14:53 |
| didrocks | cyphermox: we have indicator-network going crazy sometimes in the lab just after boot | 14:54 |
| didrocks | cyphermox: see those top (taking at a some intervals): https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-friends-app-autopilot/24/artifact/clientlogs/top_before.log/*view*/ | 14:54 |
| psivaa | didrocks: yea still need to run some tests on maguro | 14:54 |
| didrocks | psivaa: ok ;) | 14:54 |
| didrocks | psivaa: if you can try to downgrade nm here as well | 14:54 |
| didrocks | the more info we have… | 14:54 |
| didrocks | cyphermox: do you think you nm upload can be linked to that? | 14:55 |
| cyphermox | no | 14:55 |
| didrocks | cyphermox: do you have any idea of what can be the cause then? | 14:55 |
| didrocks | it's really happening like 50-60% of each boot | 14:56 |
| cyphermox | no idea | 14:56 |
| didrocks | cyphermox: can you help us on that? | 14:56 |
| cyphermox | you said indicator-network? I don't see it in that listing | 14:56 |
| didrocks | cyphermox: here is the diff list: http://people.canonical.com/~ogra/touch-image-stats/20131105.changes | 14:56 |
| didrocks | cyphermox: in top you mean? | 14:56 |
| didrocks | or in the diff? | 14:56 |
| cyphermox | in top | 14:56 |
| didrocks | 2151 phablet 20 0 212204 177852 3848 R 69.5 9.3 2:45.98 /usr/lib/arm-linux-gnueabihf/indicator-network/indicator-network-service | 14:57 |
| didrocks | look at the last runs | 14:57 |
| didrocks | (5 minutes after the device booted) | 14:57 |
| cyphermox | oh, I see, it's more than one top | 14:57 |
| didrocks | yeah, it's regularly top snapshot | 14:58 |
| didrocks | the last one is 5 minutes after the first one | 14:58 |
| maxiaojun | oj, you are discussing touch in #ubuntu-desktop | 14:58 |
| maxiaojun | oh | 14:58 |
| didrocks | maxiaojun: depends on where people are :) | 14:58 |
| didrocks | nm and indicators are also desktopish | 14:58 |
| didrocks | cyphermox: indicator-network is rocking between 63 and 70% | 14:58 |
| didrocks | cyphermox: from the diff between images, apart from nm, I don't see what can cause this… | 14:59 |
| cyphermox | unity8\ | 14:59 |
| cyphermox | lxc-config-android could, depending on what changed there... | 14:59 |
| didrocks | cyphermox: Saviq is telling the same thing than you for nm: they don't think they are impacting it | 14:59 |
| cyphermox | and regardless, the bug is in indicator-network, not in NM | 15:00 |
| === tkamppeter_ is now known as tkamppeter | ||
| cyphermox | I'm not denying it's possible, I'll look at it | 15:00 |
| didrocks | cyphermox: right, but right now, I'm trying first to get us to a state where we can test things | 15:00 |
| didrocks | cyphermox: and we are totally blocked on that one | 15:00 |
| cyphermox | how is that? | 15:00 |
| didrocks | cyphermox: because a lot of tests are failing because of this CPU usage | 15:01 |
| didrocks | cyphermox: so we even don't know where we are test-wise | 15:01 |
| didrocks | which will make regression from AP 1.4 harder to read | 15:01 |
| didrocks | psivaa: I found the log with downgraded nm: http://10.97.0.1:8080/job/trusty-touch-maguro-smoke-ubuntu-system-settings-online-accounts-autopilot/11/artifact/clientlogs/top_before.log/ | 15:05 |
| didrocks | so if indicator-* is indicator-network | 15:05 |
| psivaa | that's more confusing because that was with the downgraded nm | 15:08 |
| didrocks | right | 15:09 |
| psivaa | didrocks: straight away a contradiction: on mako, with downgraded nm, systemsettle success :((((( | 15:10 |
| psivaa | http://10.97.0.1:8080/job/trusty-touch-mako-smoke-friends-app-autopilot/25/console | 15:10 |
| didrocks | psivaa: ok, can you try to push more and more mako tests | 15:11 |
| didrocks | even those which succeed | 15:11 |
| psivaa | didrocks: ack will do. | 15:11 |
| didrocks | if we see no issue, we can say it's nm | 15:13 |
| psivaa | didrocks: rssreader on mako with downgraded nm has systemsettle_before failure | 15:23 |
| psivaa | http://10.97.0.1:8080/user/psivaa/my-views/view/trusty_mako_smoke/job/trusty-touch-mako-smoke-ubuntu-rssreader-app-autopilot/14/artifact/clientlogs/top_before.log | 15:23 |
| didrocks | psivaa: ok, can you try unity8 itself? | 15:24 |
| didrocks | (there are multiple binaries) | 15:24 |
| didrocks | it's the last shot :/ | 15:24 |
| psivaa | didrocks: you want me to downgrade unity8 or run the unity8 test without downgrading unity8 | 15:26 |
| didrocks | psivaa: downgrading the whole unity8 source | 15:27 |
| didrocks | and related binaries | 15:27 |
| psivaa | didrocks: ack, will do | 15:27 |
| psivaa | didrocks: ok, i'll replace the current unity8 with the one before, 7.83+14.04.20131031-0ubuntu1 but not sure if that had any issues | 15:30 |
| didrocks | psivaa: it didn't in the previous run | 15:33 |
| psivaa | didrocks: ack, running tests with older unity8 | 15:34 |
| === alan_g is now known as alan_g|tea | ||
| seb128 | cyphermox, do you still plan to look at those wpasupplicant issues that are ranked high on the saucy e.u.c list? | 15:44 |
| seb128 | happyaron, that ibus abrt, can you at least upstream it with the stacktrace? that might be enough for them to have a clue? | 15:44 |
| seb128 | happyaron, https://errors.ubuntu.com/problem/7d83460403cc3ff966c466f15d32aecec048c0dc is ranking high on the saucy issues | 15:45 |
| happyaron | ok | 15:46 |
| seb128 | happyaron, thanks | 15:46 |
| psivaa | didrocks: clock_app and rss reader tests have failed systemsettle before even with older unity8. | 15:50 |
| didrocks | *shrugh* | 15:50 |
| === alan_g|tea is now known as alan_g | ||
| didrocks | psivaa: still indicator-network on top? | 15:52 |
| psivaa | didrocks: yes, for both app tests | 15:54 |
| psivaa | didrocks: http://pastebin.ubuntu.com/6371157/ are the relevant packages just to confirm | 15:54 |
| didrocks | psivaa: you reverted unity8-private as well, right? | 15:54 |
| psivaa | didrocks: yes, http://pastebin.ubuntu.com/6371172/ | 15:55 |
| psivaa | and unity8-fake-env:armhf as well | 15:55 |
| didrocks | ok… all libnm* as well | 15:56 |
| psivaa | didrocks: yep, http://pastebin.ubuntu.com/6371182/ | 15:57 |
| didrocks | psivaa: can you rm /etc/init/android-usb-state.conf ? | 15:57 |
| didrocks | and retry? | 15:57 |
| psivaa | didrocks: running clock with that removed | 15:58 |
| didrocks | ogra_: you told that the job is not wired, but do you think that we can have indicator-network reacting to it? ^ | 15:59 |
| didrocks | (it's started by mtp) | 15:59 |
| ogra_ | nah | 16:01 |
| ogra_ | it would only even do something on cable disconnect/reconnect | 16:01 |
| ogra_ | didrocks, i think the probalm is on a different levelö (as i told you a few hours ago) | 16:02 |
| ogra_ | *problem | 16:02 |
| didrocks | ogra_: what level? | 16:06 |
| ogra_ | kernel ... | 16:06 |
| ogra_ | or rather cpufreq in the kernel | 16:06 |
| psivaa | didrocks: so the clock app test failed on syssettle_before again with /etc/init/android-usb-state.conf removed | 16:08 |
| psivaa | indicator-network-service is at the top | 16:08 |
| psivaa | rss app test is running to confirm | 16:09 |
| dednick | didrocks: comment has been added to landing pipeline doc. | 16:11 |
| didrocks | ogra_: did we got kernel change? | 16:17 |
| ogra_ | didrocks, no, but we have a cpufreq governor (ondemand) set that makes the device always operate slightly on the edge (see the load values in the top output) ... so it can easily be that the scaling happens to slow and we just hit a threshold ... | 16:18 |
| Laney | "will be used by […] ubuntu-system-settings" - what is this? | 16:18 |
| ogra_ | moving to the interactive governor (which i'm just testing here) actually makes me see the load way below 1 (0.2 or some such on idle) and processes seemigly dropping down faster in CPU usage | 16:19 |
| seb128 | Laney, shared UI components for indicators/unity/settings | 16:20 |
| seb128 | Laney, e.g calendar widget | 16:20 |
| ogra_ | didrocks, if your timeout change improved the test, thats definitely an indicator for the slow app reaction i'm seeing here too | 16:20 |
| psivaa | didrocks: rss also fails with /etc/init/android-usb-state.conf removed. let me know if/when i could revert the changes to the tests to increase the timeout | 16:22 |
| didrocks | hum, I've no idea | 16:22 |
| didrocks | ogra_: no, it didn't improve | 16:22 |
| didrocks | ogra_: the indicator is still crazy after 5 minutes | 16:22 |
| didrocks | psivaa: are you connected on the device? | 16:22 |
| psivaa | didrocks: yes | 16:22 |
| didrocks | can you try get a backtrace to see what the indicator is doing? | 16:23 |
| ogra_ | didrocks, ok, then my issue is separate | 16:23 |
| didrocks | psivaa: like, right now, the indicator is still skyrocketing, right? | 16:23 |
| Laney | seb128: seems like they have a left checkbox and a rewritten timezone displayer thingy in there | 16:23 |
| Laney | is this coming from design? | 16:23 |
| ogra_ | (teh device feels a *lot* more responsive with interactive though) | 16:23 |
| ogra_ | didrocks, do the devices in the lab have SIMs ? | 16:24 |
| didrocks | ogra_: I guess they do have some, psivaa? | 16:24 |
| ogra_ | didrocks, i wonder if there are issues with them since you say you can reproduce it anywhere else | 16:25 |
| psivaa | didrocks: i think they have. let me confirm | 16:25 |
| seb128 | Laney, check with dednick | 16:25 |
| ogra_ | would be intresting to see what happens if someone removes the SIM and we test again | 16:25 |
| psivaa | didrocks: indicator is still coming on the top | 16:25 |
| didrocks | psivaa: ok, so installing debug symbols and gdb into the running process? | 16:25 |
| seb128 | Laney, I think they had the checkbox on the other side like us and they moved back to the standard UI, maybe outdated description/code somewhere? | 16:25 |
| Laney | looking in the example file | 16:26 |
| psivaa | didrocks: ok, this is new to me. let me try that | 16:26 |
| didrocks | psivaa: do you need help? | 16:26 |
| seb128 | Laney, I didn't follow the details, I just know what's the project is about | 16:26 |
| didrocks | seb128: would is the right person to help debugging indicator-network? | 16:27 |
| seb128 | Laney, we discussed it previous cycle when we were talking about custom widgets in indicators/settings | 16:27 |
| seb128 | didrocks, tedg | 16:27 |
| Laney | okay, weird, I'd have contributed / tried to use it earlier if I knew about it | 16:27 |
| seb128 | didrocks, or Wellmark | 16:27 |
| seb128 | didrocks, or cyphermox | 16:27 |
| seb128 | Laney, well, it was not really a thing yet, it just starts shaping I think | 16:28 |
| psivaa | didrocks: yea i need help in that | 16:28 |
| seb128 | Laney, e.g everybody start with "get stuff somewhat working for their component" | 16:28 |
| seb128 | started* | 16:28 |
| didrocks | tedg: cyphermox: one of you around to help? | 16:28 |
| cyphermox | yes | 16:28 |
| tedg | didrocks, ^ | 16:28 |
| tedg | ;-) | 16:28 |
| didrocks | psivaa: can you give cyphermox ssh access? | 16:28 |
| didrocks | he has access to the lab | 16:29 |
| cyphermox | tedg: I think you really should look at it though | 16:29 |
| didrocks | I just want someone who can install the dbgsym with psivaa | 16:29 |
| didrocks | and gdb attach | 16:29 |
| didrocks | bt full | 16:29 |
| tedg | I'm confused on what's happening. | 16:30 |
| cyphermox | rocket science. | 16:30 |
| * tedg looks for bryceh | 16:30 | |
| ogra_ | lol | 16:30 |
| ogra_ | pass the bucket ... | 16:30 |
| didrocks | tedg: so, we have indicator-network taking > 60% of CPU | 16:30 |
| tedg | Hmm, that's odd. Look at dbus and see if there's a bunch of signals coming to it? | 16:31 |
| tedg | It doesn't really do any processing. | 16:31 |
| didrocks | tedg: can you ssh to the phone with psivaa's help and debug live? | 16:31 |
| didrocks | tedg: FYI, the only diff we have is: http://people.canonical.com/~ogra/touch-image-stats/20131105.changes | 16:32 |
| didrocks | tedg: we tried to backout ido, network-manager, lxc-android-config and unity8 | 16:32 |
| * ogra_ is wondering if the SIM cards are run out of credit or some such and spam NM with error messages | 16:32 | |
| didrocks | ogra_: ohhhh | 16:32 |
| didrocks | running out of credit | 16:32 |
| didrocks | maybe… | 16:32 |
| ogra_ | didrocks, thats what i wanted to say before :) | 16:32 |
| tedg | Hmm, network-manager from 0.9.8.0-0ubuntu22 to 0.9.8.4-0ubuntu3, cyphermox might not be out of the woods yet ;-) | 16:32 |
| didrocks | ogra_: well, you told "with SIM card", that's why I asked you and popey :) | 16:32 |
| * ogra_ is just dsitracted being in a meeting | 16:32 | |
| cyphermox | meh | 16:32 |
| didrocks | tedg: we tried to downgrade | 16:33 |
| cyphermox | didrocks: did libnm* also get downgraded? | 16:33 |
| didrocks | we still have this indicator-network going crazy after boot more than 30% of the times | 16:33 |
| didrocks | cyphermox: yep | 16:33 |
| cyphermox | alright | 16:33 |
| cyphermox | then yeah, have fun tedg ;) | 16:33 |
| cyphermox | j/k :) | 16:33 |
| cyphermox | psivaa: how can I get there? | 16:33 |
| cyphermox | in the meantime my phone was just reflashed with trusty-proposed, I'm hoping to reproduce here | 16:34 |
| didrocks | cyphermox: we were 5 trying to reproduce… | 16:34 |
| didrocks | nobody was able to | 16:34 |
| didrocks | (tried to start 10 times) | 16:34 |
| cyphermox | ah | 16:34 |
| didrocks | so it's just, after boot indicator-network is using > 60% CPU | 16:34 |
| cyphermox | and what's the difference between our own phones and what's in the lab then? | 16:34 |
| didrocks | and never calm down | 16:34 |
| didrocks | (we get that I would say 30% of the time in the lab) | 16:35 |
| tedg | Is there anything in the log file? | 16:35 |
| didrocks | apart from SIM card… | 16:35 |
| cyphermox | otherwise we're testing something different, and we can't have that | 16:35 |
| cyphermox | SIM card shouldn't affect the indicator directly in any way | 16:35 |
| didrocks | psivaa: can you pastebin the indicator-network logs | 16:35 |
| tedg | cyphermox, It effects us when we read the oFono dbus interface to show status, but yes. | 16:35 |
| didrocks | psivaa: should be ~/.cache/upstart/indicator-network.log | 16:36 |
| cyphermox | tedg: well, you need to do that regardless -- that's what I mean by it shouldn't make a difference what kind of brand the SIM is for :D | 16:36 |
| didrocks | tedg: the question is "what changed?" from what we tried to downgrade, I don't see any other potential culpurit… | 16:36 |
| cyphermox | I could understand if it was breaking here for me, with my weird provider that uses UTF8 in some names | 16:36 |
| didrocks | cyphermox: let's hope you can reproduce :) | 16:36 |
| cyphermox | seems to me like it's going to be hard to reproduce... | 16:37 |
| tedg | didrocks, I think the only other possibility would be unity8 itself, it does talk to the indicator, but it'd be weird to cause that kind of traffic. | 16:37 |
| cyphermox | lxc-android-config seems to have changed | 16:37 |
| didrocks | tedg: as told, we reverted it | 16:38 |
| psivaa | didrocks: http://pastebin.ubuntu.com/6371408/ is the log | 16:38 |
| cyphermox | (ie. I don't have access to /var/lib/dpkg even though I rebooted to a writable image) | 16:38 |
| psivaa | well the last bit, let me retrieve the whole log | 16:38 |
| didrocks | tedg: seems spammy? ^ | 16:38 |
| cyphermox | it kind of is, but that shouldn't break things | 16:38 |
| didrocks | cyphermox: lxc-android-config reverted and tested as well | 16:38 |
| cyphermox | could the fact that phonesim is there extra could be breaking things? | 16:39 |
| tedg | didrocks, blame cyphermox, we get lots of messages from NM :-) | 16:39 |
| didrocks | tedg: can be, but not the cause of the regression ;) | 16:39 |
| tedg | This is an N4? | 16:39 |
| didrocks | we both have the issue on mako and maguro | 16:39 |
| didrocks | since we had that diff: http://people.canonical.com/~ogra/touch-image-stats/20131105.changes | 16:40 |
| tedg | Just to be curious, why is IDO in the phone image? | 16:40 |
| didrocks | tedg: seems to be a packaging error/change | 16:41 |
| didrocks | tedg: but it's not loaded (u-p-s isn't started) | 16:42 |
| tedg | Yeah, it just pulls GTK along with it. | 16:42 |
| didrocks | tedg: right, but not the cause of the current issue ;) | 16:42 |
| didrocks | we even tried, as not loaded, to revert it | 16:42 |
| didrocks | no effect | 16:42 |
| didrocks | tedg: you do have access to the QA lab? | 16:43 |
| tedg | VPN? Yes. | 16:43 |
| tedg | But I don't know what to do from there. | 16:43 |
| psivaa | didrocks: tedg: http://pastebin.ubuntu.com/6371436/ is the whole log | 16:43 |
| didrocks | psivaa: I think we really need to give the creds for tedg to connect and gdb | 16:43 |
| dednick | Laney, seb128: at the moment all the ubuntu-settings-components are using components from the indicators in unity8, for which we didn't really have a clearcut design for each component. I guess once we have it in archive we'll do the transision for unity8 first, update for correct design and switch then ubuntu-system-settings. | 16:43 |
| didrocks | yeah, it seems a lot of spam | 16:43 |
| didrocks | not sure why | 16:43 |
| dednick | Laney, seb128: just need to get it into archive first! | 16:43 |
| didrocks | will be better for tedg to see where the indicator is looping | 16:44 |
| Laney | I don't know why you need to do the spreadsheet stuff when it's not going to be on any image | 16:44 |
| Laney | should just be able to release it | 16:44 |
| dednick | Laney: to where? | 16:46 |
| Laney | universe | 16:46 |
| dednick | Laney: well i have no idea about packaging. But it needs to go in trusty archive surely no? | 16:48 |
| bregma | seb128, do you think the g-s-d/unity keygrab issue is worthy of a vUDS session or is it more of a "just do it" kind of thing? | 16:49 |
| Laney | dednick: yeah, that's what I mean, but you shouldn't have to go through the spreadsheet stuff if there is no way it'll impact the touch images | 16:49 |
| Laney | dednick: When stuff is moved to use it then that'll probably need to do it | 16:49 |
| didrocks | Laney: before, it was linked to the unity8 move to it | 16:49 |
| dednick | Laney: tis what I was told do to. | 16:49 |
| didrocks | I guess that's why it ended up here | 16:49 |
| didrocks | right now, it's for us to track the release to distro then | 16:50 |
| didrocks | but right now, as you noticed, we are doing a complex transition and have issues :) | 16:50 |
| didrocks | so rather than discussing process, I would appreciate all available help | 16:50 |
| Laney | hmm? | 16:50 |
| Laney | I'm trying to get it off your plate, not attacking :/ | 16:50 |
| didrocks | Laney: if you can release it from cu2d (I think it built) and get an AA review, that's fine | 16:50 |
| didrocks | IIRC, everything is wired up | 16:51 |
| cyphermox | didrocks: got something suspicious | 16:51 |
| didrocks | cyphermox: oh? | 16:51 |
| didrocks | tell me you can reproduce it :) | 16:51 |
| Laney | ok cool | 16:51 |
| tedg | didrocks, I'm logged in, but indicator-network doesn't seem to be using excess CPU? | 16:52 |
| didrocks | psivaa: didn't you tell me it was still going crazy? | 16:52 |
| psivaa | didrocks: it is at the top even now. | 16:52 |
| cyphermox | didrocks: reproducing on the lab device | 16:52 |
| didrocks | tedg: connected on the same device? ;) | 16:53 |
| tedg | AFAIK | 16:53 |
| * didrocks wonders why he needs to act as a proxy | 16:53 | |
| didrocks | cyphermox: ah? what's up then? | 16:53 |
| tedg | Ah, interesting. | 16:53 |
| didrocks | (please nobody rebooting anything) | 16:53 |
| tedg | It wasn't before, but is now. | 16:53 |
| cyphermox | it gets borked by phonesim, AFAICT | 16:54 |
| cyphermox | when phonesim starts, there's a small period of time where the device isn't quite ready | 16:54 |
| tedg | Yeah, it seems to be the system bus. | 16:54 |
| cyphermox | I'd look at that piece of code for when devices appear, first | 16:54 |
| tedg | The system dbus-daemon is at 20% CPU | 16:55 |
| tedg | ofonod is at 10% | 16:55 |
| tedg | Seems like a game of crack the whip | 16:55 |
| cyphermox | indicator-network all threads are stuck in poll() | 16:56 |
| didrocks | but phonesim wasn't changed? | 16:56 |
| cyphermox | not that I know | 16:57 |
| seb128 | bregma, it seems a technical details, not really a session topic | 16:59 |
| seb128 | bregma, we might have one on input methods/ibus/fcitx though | 17:00 |
| bregma | seb128, https://blueprints.launchpad.net/ubuntu/+spec/desktop-1311-default-imf-review | 17:00 |
| cyphermox | ahahaha | 17:00 |
| seb128 | bregma, indeed | 17:01 |
| Laney | bah | 17:01 |
| Laney | seems the sdk changed ItemSelector.expanded to read only | 17:01 |
| Laney | breaks half of the u-s-s panels | 17:01 |
| seb128 | Laney, did that change land? | 17:02 |
| Laney | I guess so | 17:02 |
| seb128 | Laney, shrug | 17:02 |
| seb128 | Laney, https://code.launchpad.net/~nicolas-doffay/ubuntu-ui-toolkit/selectors-multi-selection/+merge/190605 ? | 17:03 |
| Laney | looks like it | 17:04 |
| Laney | is that a buggy search and replace?! | 17:04 |
| tedg | cyphermox, It seems the modem state keeps changing. | 17:04 |
| cyphermox | I'm changing it | 17:05 |
| tedg | cyphermox, http://paste.ubuntu.com/6371532/ | 17:05 |
| tedg | Oh | 17:05 |
| seb128 | Laney, not sure, pinging the sdk guys | 17:05 |
| Laney | ok | 17:05 |
| Laney | it was prelimenary, so maybe that means that we lose | 17:05 |
| seb128 | Laney, that's going to teach us to not have tests :p | 17:06 |
| Laney | heh | 17:06 |
| seb128 | that would have stopped their merge | 17:06 |
| seb128 | didrocks, ^ btw, ubuntu-ui-toolkit's update has incompatible changes that makes settings really unhappy | 17:06 |
| didrocks | seb128: I guess you need to talk with the sdk guys… :/ | 17:07 |
| seb128 | didrocks, doing that right now | 17:07 |
| Laney | the change was actually noted | 17:07 |
| Laney | in some comments from timp | 17:08 |
| seb128 | Laney, SHRUG | 17:24 |
| Laney | haha | 17:24 |
| seb128 | nic-doffay is giving me the "you guys should just update your code" | 17:24 |
| Laney | so much for APIs | 17:25 |
| seb128 | yeah, that's mind boggling | 17:25 |
| seb128 | I'm not porting system settings, I told them I refuse to ack an incompatible API change in our toolkit like that | 17:26 |
| === recoveryRodge is now known as Rodge | ||
| * Laney nods | 17:28 | |
| Laney | have a nice fight then :-) | 17:28 |
| === Rodge_ is now known as Rodge | ||
| cyphermox | psivaa: I'll reboot the device now, need to check what's up | 17:39 |
| psivaa | cyphermox: ack, hope tedg is ok with it | 17:39 |
| tedg | cyphermox, That's fine. | 17:41 |
| seb128 | Laney, can you open a bug with the actual error? I'm still arguing but they want a bug report... | 17:42 |
| Laney | okay | 17:42 |
| seb128 | Laney, seems like they are going to revert the incompatibility though (thanks Kaleo for bringing some sanity) | 17:43 |
| Laney | it's just what you'd expect though: that the property is read only | 17:43 |
| Laney | oh nice | 17:43 |
| Laney | seb128: bug #1248646 | 17:46 |
| ubot2 | Launchpad bug 1248646 in ubuntu-system-settings (Ubuntu) "API break: ItemSelector.enabled changed to read-only" [Undecided,New] https://launchpad.net/bugs/1248646 | 17:46 |
| seb128 | Laney, thanks, they are going to fix the incompatibility, we should wait on their changes to land to port our code, I'm not sure what is going to be renamed and how | 17:50 |
| Laney | if they fix it then nothing ;-) | 17:50 |
| seb128 | Laney, well, the intend is still to deprecate the property so we should use the new one | 17:51 |
| attente | bschaefer, hi | 19:07 |
| kenvandine | :q | 19:18 |
| bschaefer | attente, pong | 19:21 |
| bschaefer | attente, hows the dbus stuff going? | 19:22 |
| attente | bschaefer, i think it's make the grabs now | 19:24 |
| attente | *making | 19:24 |
| attente | so it's some progress at least | 19:24 |
| attente | but i'm wondering why the action callbacks aren't getting called | 19:24 |
| attente | can you explain a bit when the initiate and terminate callbacks are supposed to be called on an action? | 19:25 |
| bschaefer | hmm from what i gather, and event comes in | 19:25 |
| bschaefer | then it sends a ::handleEvent out to all the plugins first | 19:26 |
| bschaefer | then it checks if any grabs are pressed | 19:26 |
| bschaefer | IIRC | 19:26 |
| attente | ok | 19:27 |
| bschaefer | it should eventually get: PrivateScreen::triggerKeyPressBindings | 19:27 |
| bschaefer | attente, we use to do this in umm | 19:27 |
| bschaefer | the switcher, which i removed a bit ago, one problem to keep in mind | 19:28 |
| attente | and for a KeyBinding action, do initiate and terminate represent like the key press and release? or they have some alternate meaning? | 19:28 |
| bschaefer | if you even remove the key grab, it'll remove it form compiz entirely | 19:28 |
| bschaefer | yeah | 19:28 |
| bschaefer | so like Super+A when thats pressed, the state is Init | 19:28 |
| bschaefer | then when you release it, it goes to Term | 19:28 |
| attente | ah, ok | 19:29 |
| bschaefer | attente, IIRC, once you get an init you have to remove it from the state | 19:29 |
| * bschaefer needs to check unity | 19:29 | |
| attente | bschaefer, i think the state passed into the callback is an in parameter only, no? | 19:30 |
| bschaefer | something like: | 19:30 |
| bschaefer | if (state & CompAction::StateInitKey) | 19:30 |
| bschaefer | action->setState(action->state() | CompAction::StateTermKey); | 19:30 |
| bschaefer | its in the state | 19:30 |
| bschaefer | param | 19:30 |
| bschaefer | looking at: bool UnityScreen::ShowHudInitiate | 19:31 |
| attente | oh. i see, you meant on the action itself | 19:31 |
| bschaefer | well this is once you get the press :) | 19:31 |
| bschaefer | so im jumping a bit to far ahead | 19:31 |
| attente | right, no, this is useful info :) | 19:31 |
| bschaefer | yeah, compiz is pretty ... confusing and i still don't understand most of it :) | 19:32 |
| bschaefer | from what i see you have to do: | 19:32 |
| bschaefer | screen->addAction(action.get()); | 19:32 |
| bschaefer | add an action to the screen | 19:32 |
| bschaefer | which the action will be a key binding | 19:32 |
| bschaefer | attente, take a look at: void UnityScreen::CreateSuperNewAction | 19:32 |
| bschaefer | there it sets up a keybinding, and adds that action to the screen | 19:33 |
| attente | bschaefer, but it doesn't seem to ever set those callbacks | 19:34 |
| bschaefer | hmm right | 19:35 |
| bschaefer | attente, the only way i see the callbacks getting set up is through all those xml stuff we have | 19:36 |
| bschaefer | like | 19:36 |
| bschaefer | optionSetAltTabForwardAllInitiate(boost::bind(&UnityScreen::altTabForwardAllInitiate, this, _1, _2, _3)); | 19:36 |
| bschaefer | which that is generated code in umm | 19:37 |
| bschaefer | build/generated | 19:37 |
| bschaefer | unityshell_options.h | 19:37 |
| bschaefer | attente, so, you could possibly look in there to see how those hotkeys are getting set up | 19:38 |
| bschaefer | and instead of using the xml file to generate it you can just code it in yourself somewhere else | 19:38 |
| attente | bschaefer, yeah, i've tried setting callbacks manually on the actions in the key grabber | 19:39 |
| bschaefer | attente, looking at: void UnityScreen::initAltTabNextWindow() | 19:39 |
| attente | it's just a bit of a mystery why they're not being triggered.. | 19:39 |
| bschaefer | yeah... | 19:39 |
| bschaefer | are you doing something like: | 19:40 |
| bschaefer | optionSetAltTabNextWindowTerminate(boost::bind(&UnityScreen::altTabTerminateCommon, this, _1, _2, _3)); | 19:40 |
| bschaefer | where you bind the callback? | 19:40 |
| attente | i'm doing something like: | 19:41 |
| attente | CompAction* action = new CompAction; | 19:41 |
| attente | action->keyFromString(accelerator); | 19:41 |
| attente | action->setInitiate(boost::bind(&GnomeKeyGrabber::Impl::InitiateAction, this, _1, _2, _3)); | 19:41 |
| attente | where InitiateAction is the method on the GnomeKeyGrabber::Impl class | 19:41 |
| bschaefer | hmm I dont see that setInit used in unityshell else where | 19:42 |
| bschaefer | attente, do you add that action tot he screen? | 19:42 |
| bschaefer | screen->addAction() | 19:42 |
| attente | bschaefer, yes | 19:42 |
| attente | might be better if i do a paste instead :) | 19:43 |
| attente | http://paste.ubuntu.com/6372383/ | 19:43 |
| bschaefer | hmm | 19:44 |
| attente | when i log the addAction method in compiz, it seems to be working and returning true | 19:44 |
| bschaefer | hmm possibly the hotkey is setup different from gnome -> compiz? | 19:45 |
| attente | bschaefer, you mean in the parsing of the accelerator? | 19:46 |
| bschaefer | yeah, im nost sure what format compiz takes in | 19:46 |
| attente | i was just testing it with '<Shift>F11' and '<Shift>F12' | 19:46 |
| bschaefer | hmm i think compiz needs + | 19:46 |
| bschaefer | or x11? | 19:46 |
| bschaefer | hmm I had to write a converter for ibus hotkeys | 19:46 |
| bschaefer | try | 19:46 |
| bschaefer | Shift+F11 | 19:46 |
| bschaefer | the conversion is pretty simple if that ends up working... | 19:48 |
| attente | no luck with that either | 19:48 |
| bschaefer | well shoot | 19:48 |
| bschaefer | i do wish I understood this part of compiz a bit more :) | 19:48 |
| attente | heh, don't we all :) | 19:48 |
| bschaefer | attente, oo possibly: | 19:50 |
| bschaefer | action.setState (CompAction::StateInitKey); | 19:50 |
| bschaefer | as if you don't set the state, it might just ignore that action | 19:50 |
| attente | ooo | 19:50 |
| bschaefer | (as it'll have an empty state) | 19:50 |
| attente | ok, i'll try it | 19:50 |
| bschaefer | im looking at the trigger code in compiz | 19:50 |
| attente | hmm. no luck there either | 19:55 |
| bschaefer | dammit | 19:55 |
| attente | but something is happening here | 19:55 |
| attente | when i press Shift+F8, more calls to addAction are happening | 19:55 |
| attente | they happen only after Shift+F8 are grabbed | 19:56 |
| attente | *is | 19:56 |
| bschaefer | hmm | 19:56 |
| attente | same for Shift+F11,F12 | 19:56 |
| bschaefer | more calls to addAction from your code? | 19:56 |
| attente | i hope not.. | 19:57 |
| * attente checks | 19:57 | |
| bschaefer | try: action.setState (CompAction::StateInitKey | CompAction::StateAutoGrab); | 19:57 |
| bschaefer | theres a lot of addActions | 19:57 |
| bschaefer | it seems... | 19:57 |
| bschaefer | in unityshell.cpp | 19:57 |
| attente | i wonder why pressing that keybinding would trigger more addAction calls | 19:57 |
| bschaefer | well the workhorse in compiz is: PrivateScreen::triggerKeyPressBindings | 19:58 |
| bschaefer | so something is happening there that either, could be finding your hotkeys | 19:58 |
| bschaefer | and the callback is failing, or it can't find the hotkeys | 19:58 |
| attente | ok, thanks for the guidance bschaefer | 19:59 |
| attente | i should be able to manage from here | 19:59 |
| bschaefer | attente, good luck, and sorry for the lack of hlep | 19:59 |
| bschaefer | help* | 19:59 |
| attente | no, you were very helpful, thanks! | 19:59 |
| bschaefer | you could also look in: PrivateScreen::triggerStateNotifyBindings | 20:00 |
| bschaefer | pretty much in compiz/src/event.cpp | 20:00 |
| bschaefer | theres a bunch of stuff going through and checking all the bindings | 20:00 |
| === seb128 is now known as 3JTAAAD4U | ||
| === Sweetsha1k is now known as Sweetshark | ||
| robert_ancell | mterry, still around? | 22:58 |
| mterry | robert_ancell, yeah | 23:27 |
| robert_ancell | mterry, was wondering if you saw https://code.launchpad.net/~robert-ancell/unity-greeter/end-session-dialog/+merge/193880 | 23:29 |
| mterry | robert_ancell, sure, I put it on my TODO then forgot about it. Soryr | 23:30 |
| mterry | robert_ancell, will look now | 23:30 |
| robert_ancell | ta | 23:31 |
| mterry | robert_ancell, looks good | 23:53 |
| mterry | approved | 23:53 |
| robert_ancell | :) | 23:53 |
| robert_ancell | thanks! | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!