[00:20] <thumper> Trevinho: I'm just relocating home again... back soon
[00:28] <andyrock> Trevinho, still here?
[00:39] <andyrock> btw make check doesn't work for me
[00:39] <andyrock> it never ends
[00:39] <andyrock> and make test gives me an error
[01:12] <Andy80> andyrock: hey, what are you testing?
[01:12] <andyrock> i'm testing the tests :)
[01:13] <andyrock> Andy80, i'm going to write a test for a my branch, but make check doesn't work for me
[01:22] <Trevinho> andyrock: here I am
[01:22] <andyrock> Trevinho, make check doesn't work for me :/
[01:22] <andyrock> it never ends
[01:23] <Trevinho> thumper: I've just synced this old patch to the new code: https://code.launchpad.net/~3v1n0/unity/panel-opacity-toggle/+merge/77219 It was accepted, but it doesn't include any test yet. Also because there's not a test framework for the panel yet, so I didn't know if there's something in progress
[01:23] <Trevinho> andyrock: I'm sorry for you
[01:23] <Trevinho> it works here
[01:23]  * thumper is back
[01:23] <andyrock> Trevinho, i'm getting crazy
[01:24]  * thumper looks at the merge
[01:24] <thumper> andyrock: where does it get stuck?
[01:24] <andyrock> thumper, it's not a probelm with my branch
[01:25] <andyrock> make check doesn't work for unity trunk too
[01:25] <thumper> andyrock: right, but where is it stopping?
[01:25] <andyrock> task-1: [       OK ] TestFilter.TestConnect (1 ms)
[01:25] <andyrock> task-1: [ RUN      ] TestFilter.TestChanged
[01:25] <andyrock> task-1: [       OK ] TestFilter.TestChanged (0 ms)
[01:25] <andyrock> task-1: [ RUN      ] TestFilter.TestRemoved
[01:25] <andyrock> and it never ends...
[01:38] <thumper> hmm...
[01:40] <andyrock> removing TestFilter.TestRemoved
[01:41] <andyrock> makes that the test goes on
[01:43] <thumper> hmm... works fine for me here
[01:43] <thumper> what is it doing?
[01:57] <andyrock> thumper, i'm giving a look to it...
[02:05] <andyrock> thumper, have you given a look to test_filter.cpp?
[02:07] <andyrock> so about TestRemoved
[02:07] <andyrock> it try to remove an item...
[02:08] <andyrock> to be sure that the item has been removed
[02:08] <andyrock> it uses a variable
[02:08] <andyrock> this variable is setted in the callback of the remove signal
[02:10] <andyrock> but what happens if we need variable value but remove signal callbacks has not yet been called?
[02:21] <thumper> hmm...
[02:22] <thumper> ideally it should only wait for a short time for the result
[02:22] <thumper> and if it gets a timeout, the test should fail
[02:22] <thumper> I wonder why you aren't getting a signal callback
[02:33] <andyrock> thumper, so i've added some printf functions in the test
[02:33] <andyrock> to debug
[02:33] <andyrock> and...
[02:33]  * thumper waits
[02:34] <andyrock> the removed callback is called
[02:34] <thumper> ha.
[02:34] <thumper> but?
[02:34] <andyrock> now we have
[02:34] <andyrock>   FilterRecorder recorder(model_, iter1_);
[02:34] <andyrock>   dee_model_remove(model_, iter2_);
[02:34] <andyrock>   EXPECT_EQ(recorder.removed_, false);
[02:34] <andyrock>   dee_model_remove(model_, iter0_);
[02:34] <andyrock>   EXPECT_EQ(recorder.removed_, false);
[02:34] <andyrock>   
[02:34] <andyrock>   dee_model_remove(model_, iter1_);
[02:34] <andyrock>   EXPECT_EQ(recorder.removed_, true);
[02:35] <andyrock> i've added a printf at the end
[02:35] <andyrock> and the string is printed
[02:35] <andyrock> but the test never ends...
[02:35] <andyrock> expect_eq works well
[02:35] <thumper> where does it wait?
[02:36] <thumper> actually
[02:36] <thumper> while you are there
[02:36] <andyrock> i don't know... maybe a gtest bug
[02:36] <thumper> can you change EXPECT_EQ to EXPECT_TRUE and EXPECT_FALSE?
[02:36] <andyrock> yeah
[02:36]  * thumper goes to look at the source too
[02:41] <thumper> andyrock: have you tried stepping through with gdb?
[02:42] <andyrock> i'm doing it right now...
[03:07] <andyrock> thumper, debug with gdb of a gtest test is evil
[03:07] <andyrock> there are too many macro
[03:07] <thumper> debug macros are awful agreed
[03:07] <thumper> can you step over though?
[03:08] <andyrock> but it's really really weird, the dtor of TestFilter is called
[03:09] <andyrock> step by step? right now no...
[03:09] <andyrock> because i cannot add a break
[03:09] <thumper> because?
[03:09] <andyrock> because (maybe) tests are not build with debug info...
[03:09] <andyrock> at least i guess
[03:10] <thumper> they should be if you are normally building with debug info
[03:11] <thumper> how do you run cmake?
[03:13] <andyrock> cmake .. -DCMAKE_BUILD_TYPE=Debug -DCOMPIZ_PLUGIN_INSTALL_TYPE=local -DCMAKE_INSTALL_PREFIX=/usr
[03:14] <andyrock> so to run in on gdb
[03:14] <andyrock> i do
[03:14] <andyrock> gdb dbus-test-runner
[03:14] <andyrock> than...
[03:15] <andyrock> run --task ./test-gtest-service --task ./test-gtest
[03:17]  * andyrock is going to bed (4:17 AM in Italy)
[03:18] <andyrock> thumper, mail me if something is wrong on my cmake, etc.
[03:19] <andyrock> please :)
[03:19] <thumper> ok
[03:19] <thumper> it is very weird
[03:38] <smspillaz> thumper: macros are why I am skeptical of google-test :)
[03:38] <thumper> smspillaz: all testing frameworks use macros
[03:38] <thumper> sad but true
[03:39] <smspillaz> they can't use inlines ?
[03:39] <thumper> no
[06:16] <nolaviz> anyone there?
[07:35] <smspillaz> thumper: interesting fact. vanvugt is in perth
[07:35]  * smspillaz did not know that :)
[07:41] <thumper> smspillaz: and vanvugt is?
[07:42] <smspillaz> he proposed a whole bunch of vsync fixes
[09:42] <hrw> hi
[09:42] <hrw> can someone tell me how to disable F10 going to indicators?
[09:51] <andyrock> hrw, from ccs
[09:51] <andyrock> *ccsm
[09:51] <hrw> ok
[09:52] <hrw> other question: how to disable keyboard shortcut in gnome apps? Clicking on shortcut gives me way to change key but not to disable
[10:01] <hrw> ok, found - backspace
[10:17] <hrw> is this a known problem then when I switch to Thunderbird (start+3 on 3rd desktop) I have to switch between windows to be able to type in one of them?
[10:17] <hrw> not always happens but quite often
[10:21] <hrw> same happened with terminal (start+1, 1st desktop)
[10:34] <hrw> bug 891077 anyone?
[11:00] <Andy80> hi
[12:16] <hrw> is most of ayatana team based in US?
[12:48] <hrw> bug 891116 is irritating
[12:50] <smspillaz> hrw: I'll look into that next week when I'm off exams and we're based all over the world pretty much, thumper workdays starting at UTC+11, me for workdays starting UTC+8, most of the others come on at around UTC+1 and the US people come on at about UTC-8
[12:51] <smspillaz> (starting at 9AM at each of those times)
[12:51] <hrw> thx smspillaz
[12:51] <smspillaz> so there is roughly 24 hour coverage, except for when I'm at university and part time, in which case there is a slight 3 hour gap between when thumper logs off and I log on
[12:51] <smspillaz> (since I switch to Europe then)
[12:53] <hrw> ok
[14:21] <ockham_> mhr3: nag nag...
[14:21] <ockham_> mhr3: ... about my mp ...
[14:32] <mhr3> ockham_, it looks good, the only thing i'm not sure about are the BindFlags you're using
[14:33] <mhr3> i'd suggest using just GET
[14:49] <kamstrup> mhr3: ockham_ signed the ca - so I think you can approve https://code.launchpad.net/~ockham-razor/unity-lens-applications/lp785101/+merge/82280
[14:51] <mhr3> kamstrup, yea, i got the mail, what do you think about the flags? ^^
[15:08] <ockham_> mhr3: sry, been afk
[15:09] <kamstrup> mhr3: which "flags"?
[15:11] <kamstrup> mhr3: if it's about having the conf keys in general, I am ok with it. Not that I like adding options, but there has been more than enough user requests to justify it I guess
[15:11] <mhr3> kamstrup, GSettings' BindFlags when binding the properties
[15:11] <kamstrup> ah, that
[15:11] <ockham_> this one, right: GLib.SettingsBindFlags.DEFAULT
[15:11] <mhr3> yea, i'm thinking we want just .GET
[15:11] <mhr3> kamstrup, ^^
[15:12] <mhr3> ockham_, also drop the GLib. pls
[15:13] <ockham_> mhr3: one sec...
[15:13] <kamstrup> mhr3: I don't have any particular opinion. DEFAULT definitely works. GET will too, but has a slim chance of subtly breaking in the future...
[15:14] <mhr3> kamstrup, what breaking do you have in mind?
[15:45] <ockham_> kamstrup: ^^ i'm also curious, as i'm waiting for what i should commit...
[15:46] <ockham_> mhr3: if i'd change it to GET, should i also change the properties to { get; default = true; } instead of { get; set; default = true; } ?
[15:49] <mhr3> ockham_, no
[16:05] <om26er_> kenvandine, Hello! do you have some insights on bug 854666 ? Could it be related to telepathy-indicator?
[16:06] <kenvandine> om26er_, maybe
[16:07] <om26er_> also kenvandine I suppose bug 886056 is on the TODO for LTS ?
[16:07] <om26er_> sounds also related to the telepathy-indicator
[16:09] <om26er_> ronoc, I found you :-)
[16:09] <ockham_> mhr3: i've pushed the .DEFAULT -> .GET change now
[16:10] <om26er_> ronoc, there is a problem with the sound menu controls, ref: bug 864405
[16:11] <kenvandine> om26er_, 886056  is  tp-indicator
[16:11] <kenvandine> not sure about 854666
[16:12] <kenvandine> that sounds more like focus related stuff
[16:12] <om26er_> kenvandine, I will be tested a few versions of telepathy-indicator and maybe downgrade empathy
[16:13] <om26er_> I just made a clean install and I think I dont have the issue here
[16:13] <kenvandine> om26er_, i couldn't reproduce it
[16:13] <om26er_> my two fully updated systems are affected
[16:13] <om26er_> I believe it happens the first time just after login (so could be compiz)
[16:14] <kenvandine> om26er_,  tp-indicator really just calls g_app_info_launch on empathy.desktop
[16:15] <kenvandine> so the first time the contacts list window opens?
[16:15] <om26er_> kenvandine, yep, first time
[16:15] <kenvandine> and when it goes away, is the window really gone?
[16:15] <kenvandine> or just not on top?
[16:16] <om26er_> it hides, you have to invoke from the messaging menu again
[16:16] <om26er_> just appears for few miliseconds and gone
[16:16] <om26er_> next time it starts fine though.
[16:20] <mgedmin> unity launcher keeps losing track of applications: now it doesn't see that I have xchat-gnome running any more...
[16:23] <ronoc> om26er, hey, checking now
[16:27] <om26er> ronoc, can you reproduce it as well ?
[16:28] <ronoc> om26er, yep i can
[16:28] <ronoc> i thought i fixed that
[16:30] <om26er> ronoc, I might do an SRU when its fixed :-)
[17:20] <ockham_> mhr3: ping
[18:49] <ronoc> om26er, fixed on trunk
[18:49] <ronoc> om26er, if you want a release you will need to hassle one of the packager
[19:25] <mhr3> ockham_, sorry it took a while, approved
[19:25] <ockham_> mhr3: great, thx, no problem!
[20:07] <mgedmin> hey, wait a sec -- unity now thinks my xchat-gnome window belongs to Chromium
[20:08] <mgedmin> how exactly does it assign windows to applications, again?
[20:11] <thumper> morning
[20:13] <thumper> mgedmin: it uses a library called bamf
[20:13] <thumper> as I understand it there are a number of different rules it follows
[20:15] <mgedmin> thanks for the pointer
[20:17] <mgedmin> hm, and there's a bamfdaemon
[20:18] <mgedmin> woohoo, somehow my xchat window now has _NET_WM_DESKTOP_FILE(STRING) pointing to chromium-browser.desktop
[20:34] <ockham_> mhr3: one more question, as i'm not really familiar with launchpad workflows -- what happens after your approval? who performs the actual merge?
[20:35] <mhr3> we don't have automatic merging yet, so either me or kamstrup
[20:35] <Andy80> mgedmin: who develop xchat-gnome? I'm using it since yesterday and there would be some things I'd like to be changed to improve it....
[20:36] <ockham_> mhr3: ok. but i don't need any more reviews, or do i?
[20:36] <om26er> fork it :p
[20:36] <mgedmin> dunno, https://launchpad.net/xchat-gnome ?
[20:37] <mhr3> ockham_, not unless someone else will have comments to the merge
[20:37] <Andy80> om26er: if it was not coded in C/Gtk I would be glad :P I'm not good with C/Gtk, sorry :\
[21:20] <ockham_> mhr3: hm, sry, i still don't quite understand. are you going to merge it? or are we waiting for kamstrup to approve?
[21:22] <mhr3> ockham_, we'll wait if anyone else will have comments, if not someone will merge it in a couple of hours/days
[21:23] <ockham_> mhr3: alright, thanks for clearing that up. and sorry for nagging