[00:01] alright, eod here [09:50] mornign all [09:50] dobey: Good morning how are you :) [10:16] czajkowski, morning! [10:16] mandel: hey hey how you doing ? [10:16] czajkowski, welcome to the empty CET time zone in the u1 channel :) [10:16] mandel: how goes the rugby ? [10:16] tis rather quiet in here alright [10:16] czajkowski, injured, torn calf and screwed up ribs.. [10:17] le me grab a coffe and I'll be back :) [10:17] mandel: oh dear :( [10:32] yeah, kind of empty [10:47] mandel: what? new injuries? [10:47] and good morning [10:51] ralsina, yeah, not a big deal :) [10:51] czajkowski, well, I'm taking rugby off for a few weeks to recober [10:52] mandel: you're as broken as your dog ! [10:52] czajkowski, yes, you know dog and owners are alike [10:53] ralsina, got time to run lp:~mandel/+junk/fix-sso-tests? [10:57] mandel: not right away sorry [10:57] ralsina, :( [10:57] ralsina, lets hope gatox gets back online [10:58] mandel: nessita had a ton of things to say about that branch too [10:58] ralsina, a *ton* ? [10:58] mandel: he should come back in a few minutes, it's 8AM already [11:03] mandel: turns out I do have time :-) [11:03] ralsina, hurray1 [11:03] s/1/! [11:04] ralsina, it had a number of prints there to let me know if the protocols are correctly closing as well as the client, please get the stdout :) [11:05] mandel: will do [11:05] ralsina, super thx! [11:08] ralsina, also, if you can run it several times, better :) [11:27] ralsina, did the tests pass? [11:29] mandel: not finished the 1st pass yet [11:29] Happy Friday, everyone! :D [11:29] ralsina, puff they are slow to disconnect in your machine! [11:30] I think a test just blocked [11:30] ralsina, if it did, it means is not disconnecting, which is good if it fails [11:30] mandel: I will give it a little more time, but test_deprecated_siganl_is_also_sent has been sitting there for a while [11:30] which BTW: TYPO! [11:30] ralsina, not me :) [11:35] * mandel is starting to use bzr blame waaaay too much [11:36] ralsina, fixing it though :) [11:36] mandel: yes, that is stuck [11:37] ralsina, ok, may ctrl+c and pass me the stdout please :) [11:38] mandel: https://pastebin.canonical.com/62905/ [11:40] ralsina, looks like is not connecting to the service 'cool' [11:40] mandel: ok! [11:40] * ralsina goes walk ralsina [11:41] ralsina, do you have to pick up the poo when you walk him, I have to when I take Iron :P [11:41] mandel: my ralsina is potty trained [11:41] lol [11:47] ralsina, whenever you are back, please check that you did not have sso running, just in case [11:49] also.. the number of protocols you have is too big, there should always be one, weird [12:02] hello everyone! [12:12] mandel: hola! when you can, we can chat about fix-broken-tests [12:12] nessita, morning! I've heard we have to chat :) [12:12] good morning [12:12] nessita, he, you read my mind :) [12:12] ;-) [12:12] hola gatox [12:12] gatox, can you try lp:~mandel/ubuntu-sso-client/fix-sso-tests please ? [12:12] mandel, ok [12:12] gatox, and morning! [12:12] :D [12:12] nessita, have you read this: http://mumak.net/stuff/twisted-disconnect.html [12:13] mandel: so, I was wondering why you were adding all the PBClientFactory and PBServerFactory, since I tried really hard to remove it in the past [12:13] nessita, before we start, because my work is based on that :) [12:13] reading [12:17] Lex to school, and then follow-up on my eyes. Should be back soon. [12:17] mandel: read. If that's the case ("stopListening is easy. It returns a Deferred if it is going to take a while. The others are harder. There is only one way to know when the connection has truly been lost: override connectionLost on a Protocol instance [12:17] "_ [12:17] ) [12:17] we need to add this support of passing a deferred to the protocol in IRL as well [12:17] no? [12:18] what I don't linke is creating a PBClientFactory and PBServerFactory in the tests, whatever we need, I would love if we add the necessary code in the production code [12:18] since, I understand, the propery closing applies also to IRL? [12:19] nessita, this is not required in production, the situation is the following, in production we are async in terms of closing connection, and unless we are waiting for the connection to be closed to do something, we do not care [12:19] nessita, in trial, the issue is completely different, we have to disconnect to move to the next test, otherwise, dirty reactor [12:20] nessita, the very very annoying things, is that the bloody things is not easy to reproduce and you can get false possitives if you do not wait for it to close [12:20] nessita, it has happened to me before, not wait, run test (hurray all green) propose and see dirty reactors in other machines [12:21] mandel: but in IRL we sometimes want to disconnect and then reconnect again, I think this is perhpas the cause of ussoc not being able to re-start (and thus we keep it running all the time) [12:21] mandel, did you upload new changes in your branch? [12:21] i get nothing to pull or merge [12:21] gatox, is in lp:~mandel/+junl/fix-sso-tests [12:22] gatox, sorry junk :) [12:22] ah a different one.... sorry [12:22] nessita, that can very well be, it we want to be 100% sure we disconnected before we reconnect, yes, we need to do this [12:23] nessita, for that we have to be a little more careful, since that page assumes that you have a single protocol instance, which in IRL is not the case [12:24] mandel: we have one protocol per client, right? [12:24] mandel, can you give me the whole url of the branch.... is saying that is not a branch [12:24] gatox, sure :) [12:24] nessita, per client, yes, per server, we dont [12:25] gatox, here you have it: https://code.launchpad.net/~mandel/+junk/fix-sso-tests [12:25] mandel, thanks [12:25] nessita, in the server factory, you provide the protocol class, which is then instantiated when a client makes a connection, this means that you cannot state that the server does not have more than one client connected [12:26] nessita, lets bring alecu in the conversation, I'm a little boy with twisted compared to his knowledge :) [12:26] mandel: unless the protocol class you provide keeps track of that, no? [12:26] alecu, buenos dias! [12:26] hello! [12:26] nessita, yes, exactly [12:26] hola alecu [12:27] mandel, the above sounds right: "this means that you cannot state that the server does not have more than one client connected" [12:28] nessita, mandel: a factory does not keep references to the protocols it has created (unless you do it explicitly in your derived factory) [12:29] alecu: what I was trying to understand (which I think I almost did now), is why mandel was adding the PBClientFactory and PBServerFactory back in ussoc (see https://code.launchpad.net/~mandel/ubuntu-sso-client/fix-broken-tests/+merge/98868), since I removed those some time ago while cleaning up the ipc code [12:31] alecu, the main issue we are having is that we are not waiting for the brokers to disconnect, remember this link: https://code.launchpad.net/~mandel/+junk/fix-sso-tests [12:32] alecu, we originally did something similar with PB to wait in for the tree deferreds and I guess I failed to communicate how important that was.. [12:32] * mandel should have sent and email to ubunet-discuss or something [12:32] * alecu hates returning to Unity just while trying to get used to OS X alt-tabbing. [12:33] mandel, the "tree" deferreds? what tree? [12:33] alecu, sorry, brain fuck, three :) [12:33] oh, ok. [12:33] alecu: so, after reading the article that mandel linked to me (http://mumak.net/stuff/twisted-disconnect.html), I would like that we add that machinery to the production code, not to the tests [12:34] nessita, I don't think it's needed [12:34] alecu: since without it, I think our PB IPC services will not be able to "restart" properly? [12:35] alecu: we still need to make syncdaemon be able to restart on windows... you don't think this is part of that? [12:35] (for some cases, I understand is not always an issue) [12:36] nessita, I think is worth investigating if that is indeed the issue [12:36] nessita, and in a way, I agree that we should make it easier for people to write tests for the ipc by providing this functionality [12:36] nessita, I think this is nice to have for tests, but not really needed in production code. [12:36] alecu: why not? [12:37] nessita, in prod code this will be catched by twisted handlers and will be just logged as a disconnection error. [12:38] alecu: but we're having "ugly" traces (just traces) about the broken connections... isn't this part of the issue? [12:38] nessita, what we need to do in windows is have the IPC reconnect when some of the process is finished and looses the ipc connection [12:38] nessita, what are those "ugly" traces? do you have a link? [12:39] alecu: not right now, but is that trace from persepctive broker about... something (can't remember the trace text now) [12:39] about one end disconnecting and the other end not knowing [12:40] mandel, i get this: http://paste.ubuntu.com/896382/ [12:40] and get stuck there [12:41] gatox, what I was seeing in ralsinas trace, there is more than one protocol.. I really need to know what is doing the ipc in the background [12:41] gatox, funny thing is, my vm is tuned so that I get just one lol [12:42] mandel, ah.... you already saw this? let me know if you need to test this further with my vm [12:43] gatox, I'm seen it, atm I have no bloody clue of the reason :( [12:45] nessita, so, after re-reading the article, I agree that it's something nice to have for all our tests so we should try to generalize the bits that mandel did and have them possibly in u1devtools. (I know I used some bits similar to that too somewhere) [12:45] alecu, in the webclient, I had to add them to ensure that we disconnected [12:45] nessita, but I don't think we should try to apply this solution to our ipc disconnection problems [12:45] alecu, and tcp activation.. [12:46] those are the place I remember from other times.. [12:46] alecu: ack... but why not the the production code? [12:46] nessita, I'd like to see what exactly are the ipc disconnection issues, and try to fix them. [12:46] nessita, also, the ipc in windows does not currently have the "feature" of reconnecting if one of the processes ends. [12:46] nessita, and that's something we should plan and add. [12:47] alecu, maybe letting the guy know that we started again we can do that.. does it sound hacky? [12:49] mandel, alecu: ack then. So mandel, will you be adding this to u1devtools? [12:50] nessita, yes, lets do it and clean all the tests then! [12:50] nessita, might not be as easy as it sounds of course, but will certainly work on it :) [12:50] nessita, mandel: can't we do it in a month or so? :-) [12:51] nessita, alecu I'll create a bug for this in dev-tools, we might as well let the mac guys know that they should not trust the ipc tests atm [12:51] alecu: why? [12:51] mandel: what else is on your plate? [12:51] nessita, let me see.. [12:51] alecu: if we're adding these pieces of code, I would prefer we add it to the right please [12:51] nessita, I don't like doing cleanups before releases [12:52] alecu: this is not a cleanup... the code is not present anywhere so far [12:52] nessita, this is what I have as my bug list: https://bugs.launchpad.net/ubuntuone/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=choose&field.assignee=mandel&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&fie [12:52] ld.subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on [12:52] nessita, god, sorry, let me make it shorter [12:52] alecu: mandel is adding new code, so I really prefer that he adds it to the right place [12:52] alecu: we may not change u1client to use this yet... [12:53] nessita, I thought you meant the refactoring of the tests to move the "cleaning after servers" bits to u1devtool. [12:53] nessita, http://tinyurl.com/c7nyqhq [12:53] alecu: the thing is that there is no current code, so there is no refactoring. mandel was *adding* new code, and I think is best if he adds it to the right place [12:54] mandel, what new code are you adding? [12:54] alecu: https://code.launchpad.net/~mandel/ubuntu-sso-client/fix-broken-tests/+merge/98868 [12:54] nessita, there's code to do what the mumak article says in at least two places. [12:54] alecu: where? [12:54] alecu: and if so, why mandel is adding yet to a third place? :-) [12:54] nessita, webclient tests and tcpactivation, let me find the code.. [12:54] nessita, webclient and ipc, iirc [12:55] ok, not ipc, tcpactivation. [12:55] alecu: in ussoc there is no test code using a PBClientFactory [12:56] nessita@dali:~/canonical/ussoc/trunk$ grep PBClientFac * [12:56] ubuntu_sso/utils/ipc.py:26: PBClientFactory, [12:56] ubuntu_sso/utils/ipc.py:339: self.factory = PBClientFactory() [12:56] nessita@dali:~/canonical/ussoc/trunk$ [12:56] nessita, one: http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntu-sso-client/trunk/view/head:/ubuntu_sso/utils/webclient/tests/__init__.py#L74 [12:56] mandel: that's a different code, no? [12:56] nessita, and http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntu-sso-client/trunk/view/head:/ubuntu_sso/utils/tests/test_tcpactivation.py#L47 [12:57] nessita, yes and no.. is the same issue, is certainly due to different protocols/reasons [12:57] nessita, I mean, you have the same problem, need the 3 deferreds, but you are extending diff clases [12:57] nessita, this is not only about PBClientFactory, but about all cases where a fake server is started for testings, and we should make sure that the connection from the client being tested is completely closed before finishing the test. [12:58] alecu, mandel: so, I'm -5 to add yet another place we have this hack. I may agree we don't change existing bits, but new code should go where it belongs [12:58] nessita, so it needs a *delicate and thought out* piece of reusable code to go into devtools, in my opinion. [12:58] nessita, since we will be using this in many places. [12:59] alecu: I know how things goes, and I know is very unlikely this will be revisited any time soon [12:59] so, if we're adding *new* code, it should go in the right place [12:59] nessita, I think we should come up with some reusable bits first in one of the projects (say, sso or sd), and after a few iterations of that we move it to u1devtools and use it from other projects. [12:59] I disagree for this case [12:59] alecu, indeed, and is not that easy.. because you might be using other protocols and factories that need this and you might not know [13:00] nessita, alecu I'm out of the vote, yet I think we should be pragmatic since urbanape and briancurtin are expecting this tests to pass on mac and I don't think we should block them [13:01] mandel: I agree we should solve this. Yet i'm not approving more hacks. [13:01] nessita, I don't want to have a half-assed solution in u1devtools and to have to go iterating thru devtools, since it takes too much time. [13:01] mandel, checked, o sso running [13:01] that's *no* sso running [13:01] nessita, and mostly so close to releases [13:02] ralsina, thx! [13:02] alecu: this is not affecting releases, no? we will not change production code [13:02] nessita, alecu is not a hack, is the right way to do it for those tests.. right? is the only way to have deterministic tests on the ipc code [13:02] nessita, I think it affects our time to bugfix releases [13:03] alecu: we sacrificed doing the right before already, and we learn we lost useful time instead of gaining it [13:04] nessita, I'm not saying we do it wrong. I'm saying it's wrong because it's slow to go thru devtools for iterations. [13:04] main problem as I see it is, we are breaking tests every time on non-linux platforms. So, get me an estimate of how much it would take to fix this forever, and I am maybe happy to invest it. [13:04] alecu: but is the right thing to do [13:05] nessita, there's no "absolute" right. :-) [13:05] alecu: agreed [13:05] (non relevant though for this talk ;-)) [13:05] nessita, devtools is the right place to have that bit available to other projects. But it's the wrong place to iterate. [13:06] alecu: then we need to fix the latter, and not adding code to other projects because of that [13:06] nessita, the testing classes we put in devtools never gets updated; they end up being "patched" in every test case. [13:06] alecu: that's not good, and the mistake is not to fix devtools [13:07] nessita, and that's because going thru devtools is slow. Because you have to wait for fixes to land in devtools, then wait for devtools to be available on tarmac, etc. [13:07] nessita, and I think that's counter productive to do when we are two weeks from releases on both platforms. [13:07] alecu: that process is not that slow, we do it very often between ussoc and controlpanel [13:08] alecu: the problem is the time waiting for reviews, which we need to fix [13:08] I suspect most of us are not comfortable reviewing devtools [13:08] since a break there breaks everything [13:08] So that will always be slower [13:08] ralsina: perhaps, and we should change that, no? [13:09] nessita: indeed [13:09] ralsina: my point is we can not add code elsewhere, even if it conceptually belongs to devtools, just because it may break [13:09] we can break ussoc, and sometimes we do, and then we fix [13:09] and breaking ussoc means breaking u1 *and* software center, for example, yet that does not scare us [13:10] so, why not take this as an experiment. Let's try to do this in devtools. Let's review that every test on every platform passes, and then we check our time to deliver, and we learn from it. [13:10] We don't have, AFAIK, any hard data on how long a roundtrip through devtools is [13:10] ralsina, nessita it is not an easy piece of code what so ever [13:10] mandel: she's not code! ;-) [13:11] mandel: I know, but you have a recipe, you have done this before, no? [13:11] ralsina, nessita, and is coming from me, a retard that things everything is easy [13:11] ralsina, lol [13:11] mandel: agreed, but that just means that whenever we add another test, we may break every platform since we are not getting it right anyway [13:11] mandel: and then it works on linu, breaks on windows, and dejavu [13:11] mandel: so, I wonder why you are sure of adding this code to ussoc and not to devtools ;-) [13:11] nessita, I have done it before, yes, and it worked, and we could do it correctly for PB, other generalizations are hard [13:12] mandel: I'm +1 to solve only PB in this iteration, I agree with alecu is dangerous to try to fix pieces that are right now working [13:13] nessita, ok, it if is just Pb, I'm willing to tackle it, a bigger generalization I won't :) [13:13] mandel: makes sense [13:13] alecu: would only tackling PB be a middle ground for you? [13:13] nessita, yes. [13:13] nessita, that was my main concert 'acotar' the problem [13:13] alecu: thanks [13:14] mandel: I will review the devtools branch [13:14] mandel, but please take a deep look at all the other tests where this same technique is being used, so you can have in mind a better generalization. [13:14] alecu, nessita, ack! [13:14] * mandel adds bug [13:15] nessita, alecu, hehe I already added a similar bug 944125 [13:15] Launchpad bug 944125 in ubuntuone-dev-tools "Provide reusable code to create a twisted save server for tests" [Low,Triaged] https://launchpad.net/bugs/944125 [13:15] Ayone needs reviews? If not, I want some head-down time in some issues [13:15] but is not pb [13:15] ralsina, briancurtin, urbanape: I've been playing with /dev/fsevents, and managed to make an old C example work with Lion: http://pastebin.ubuntu.com/896369/ [13:16] alecu: neat! [13:16] ralsina: before you go... [13:16] nessita: I'll still be around, just not reading unless someone pings me :-) [13:16] ralsina: this bug affects 92 people and has a *lot* of dupes https://bugs.launchpad.net/ubuntu/+source/ubuntu-sso-client/+bug/943046 [13:16] Ubuntu bug 943046 in ubuntu-sso-client (Ubuntu Precise) "ubuntu-sso-login crashed with SIGSEGV in QSocketNotifier::setEnabled()" [High,Confirmed] [13:16] nessita: here's a cleaned up and isolated version of the symlink branch: https://code.launchpad.net/~brian.curtin/ubuntuone-control-panel/windows-symlink/+merge/99017 [13:16] ralsina: is starting to worry me [13:16] briancurtin: ack! [13:16] nessita: looking... [13:17] nessita: looks like we are losing a reference to something, but we are not using QSocketNotifier ourselves, so we must be losing something higher-level [13:17] nessita, I'm taking a look too. [13:18] nessita: we are getting dbus data after we lose the dbus proxy or something [13:19] nessita, alecu, ralsina, FYI bug 963082 [13:19] Launchpad bug 963082 in ubuntuone-dev-tools "Provide reusable code for tests that use twisted.spread.pb" [High,In progress] https://launchpad.net/bugs/963082 [13:20] mandel: ack, thanks [13:20] mandel, no: "provide reusable code for tests that start a tcp server" [13:20] nessita: have you ever had it yourself? [13:20] mandel, this should not be limited to PB [13:21] alecu, hm.. should be doable with a TCP server since all should inherit from the same, I'll update it [13:21] hi czajkowski [13:21] ralsina, how do you suspect dbus? [13:21] dobey: hello :) [13:21] alecu: stacktrace [13:22] dobey: I was told you'd be the person to talk to, having problems with banshee so trying to use Rhythmbox, but all my music is there twice :/ [13:22] ralsina: never [13:22] ralsina, because of dbus/mainloop/qt.so ? [13:22] czajkowski: what version of rhythmbox-ubuntuone do you have? [13:22] alecu: it's segfaulting on pyqtDBusHelper::readSocket [13:23] alecu: that stinks of dbus ;-) [13:23] dobey: how do I find that out, am running 12.04 [13:23] czajkowski: dpkg -l rhythmbox-ubuntuone [13:23] or apt-cache policy rhythmbox-ubuntuone|grep -i installed [13:23] dobey: http://pastebin.ubuntu.com/896420/ [13:24] czajkowski: ok. quit rhythmbox; rm ~/.local/share/rhythmbox/rhythmdb.xml; start rhythmbox [13:25] ralsina: from yesterday, do we need to do something about --with-icon? or is that for after QA builds? [13:25] briancurtin: if you start it from the menu, it should start with --with-icon already [13:25] briancurtin: doesn't it? [13:25] dobey: start: Unknown job: rhythmbox [13:25] ralsina: i'll check (i had been starting from desktop icon) [13:26] briancurtin: no, sorry, the autostart is --with-icon, the desktop icon or the menu will not [13:26] czajkowski: that wasn't literal. :) [13:26] :/ [13:26] briancurtin: if it was already running with --with-icon, starting it will just show it [13:26] czajkowski: just start rhythmbox again after you deleted the rhythmdb.xml :) [13:27] ralsina: ah, so i'll have a change for the autostart code then. i also wonder if we should start it up (coming from the installer) with --with-icon [13:27] dobey: don't laugh :( [13:27] dobey: No such file or directory [13:27] briancurtin: I think so yes [13:27] my day just gets better! [13:27] czajkowski: no such file or directory from what? [13:28] cannot remove `/home/czajkowski/.local/share/rhythmbox/rhythmdb.xml': No such file or directory [13:28] ralsina: ack, will propose shortly (need to test in XP VM first) [13:28] briancurtin: cool [13:29] czajkowski: ok, so it's gone then. just run rhythmbox again now [13:30] dobey: ok [13:30] dobey: now I have no music [13:30] czajkowski: it should be rescanning [13:30] so your music should appear in a minute [13:31] might be a little slow if you have lots of music in the u1ms folder [13:31] dobey: love your optimisim :) [13:31] shall wait and see [13:31] thanks for the help [13:32] briancurtin: maybe we should just do --with-icon everywhere [13:32] briancurtin: think about it and let me know ;-) [13:32] czajkowski: well, unless you deactivated the plug-in and the library setting got reset to the xdg music folder, and you have no music there :) [13:32] ralsina: i'll check it out [13:32] rebooting, this machine is working like crap [13:33] czajkowski: is there not a progress bar in the status bar going back and forth or anything? [13:33] dobey: nope nada [13:33] that would be helpful to see alright [13:34] czajkowski: and no music showing up? is the u1 store listed in the tree? [13:35] dobey: http://twitpic.com/905xp2/full [13:35] czajkowski: what if you select the "Music" entry with the icon next to it? [13:36] hmm now music is coming in [13:36] but I've been selecting it on and off for the last few mins [13:37] ok music now in there most of it is U1 bought music, I'd have expected to see it under the U1 purchased [13:37] i think there is a bug in rhythmbox with how it handles the multiple libraries case [13:37] but at least it's still there [13:37] dobey: thanks again for the help [13:37] sure [13:37] popey: I now only have one copy of music :) [13:38] also, the fact that the u1 folder appears twice there is weird [13:38] dobey: indeed a little bit confusing :) [13:39] ah, that might be a bug in the plug-in [13:49] sigh. mocker. how dare you mock me [13:49] * dobey wonders how to remove mocker from these tests [13:53] ralsina, nessita: anyone aware of bug #940669 on the team and able to work on it? [13:53] Launchpad bug 940669 in ubuntu-sso-client (Ubuntu) "ubuntu-sso-login crashed with SIGSEGV in QSocketNotifier::setEnabled()" [High,Confirmed] https://launchpad.net/bugs/940669 [13:54] joshuahoover: we were talking about it a bit earlier [13:54] joshuahoover: we're aware, i just mentioned this a few minutes ago [13:54] ah, very good :) [13:54] joshuahoover: so far none of us has actually seen it [13:54] joshuahoover: just in case, the user is logged in anyway after the crash? [13:54] ralsina: not sure [13:55] joshuahoover: ok [13:58] gonna go check out a coworking space. Will be back in plenty of time for standup. [14:00] fml. sitting here answering a question on askubuntu, and bam, a spider appears 6 inches in front of my face, rappelling down from the ceiling [14:02] dobey: were you using a goto by chance? http://xkcd.com/292/ [14:03] briancurtin: would you quickly fix this and I will approve? [14:03] ubuntuone/controlpanel/gui/qt/tests/test_folders.py: [14:03] 25: [W0611] Unused import sys [14:04] nessita: yep, 1 min [14:04] thanks! [14:13] nessita: hola! [14:13] hola dobey! [14:13] dobey: want some mate? /me hands the mate [14:14] con medialunas? [14:15] nessita: might you have any ideas how to get rid of mocker usage in tests/platform/linux/test_notification.py in u1client? [14:15] dobey: let me look (right after I finish this review) [14:15] sure, thanks [14:18] nessita: just saw in the backlog, that bug by elopio about the mail languages seems like just a bug somewhere, the request was more for feature work. Thanks though! [14:20] ralsina: ack! [14:21] mail languages? [14:21] dobey: I would definitely build a custom class to act as a faked notification module, following the module API, but instead of actually showing notification, storing an internal state where we can assert over it [14:21] dobey: want me to build something for you? [14:22] nessita: well it needs to call the real API [14:22] nessita: because a faked class, or mocker, seems to hide problems [14:23] dobey: yes, mail languages, don't worry about it :-) [14:23] ralsina: was it the evolution default mail message? [14:23] dobey: no, SSO's mail confirmation was sent half in spanish [14:23] oh [14:24] nessita: also, the API from the gir is a little different from the one in pynotify :( [14:25] maybe the fix for this bug is to fix the notify gir though [14:25] dobey: oh, let me dig a little deeper then. Would you be ok with showing actual notifications in the tests? I will as long as we use xvfb [14:25] * gatox fix the bug.... but the tests is killing me: CHALLENGE ACCEPTED [14:26] nessita: i guess i'm fine with having to use xvfb there. not sure if foundations guys are though [14:27] dobey: let me try some quick options [14:27] hrmm [14:27] dobey: what bug are you trying to fix, though? [14:27] bug #961342 [14:27] Launchpad bug 961342 in Ubuntu One Client "GI error while trying to show notifications" [High,Confirmed] https://launchpad.net/bugs/961342 [14:27] talking about notifications, do I remember right that we have a TypeError and all notifications are broken on unity? [14:28] ralsina: not unity [14:28] ralsina: but yes [14:28] dobey: not *only* unity :-) [14:28] ralsina: broken everywhere [14:30] dobey: looking [14:31] ok, late lunch for me [14:31] * mandel lunch [14:32] dobey: sing Xvfb and skipping them if DISPLAY is unset? [14:32] s/sing/using/ [14:36] ok [14:36] libnotify is itself broken [14:36] yays [14:36] ok, no, I'm stating, I'll go after the stand up [14:37] dobey: it is? [14:37] nessita: it has set_hint_foo API for various types, but not for boolean, though lots of hints are of type boolean [14:40] dobey: so the call self.notification.set_hint('transient', True) is not "valid" in this API? [14:40] nessita: apparently not with python-gi [14:44] hrmm [14:44] but looks like we can use int32 [14:44] dobey: yes, that works [14:45] so, a simple integration test that we can add is a simple as: [14:45] dobey: http://pastebin.ubuntu.com/896508/, that does not assert anything but will fail if the notification shows crash [14:46] dobey: if the gir API provides way to assert over its state, we can definitely migrate all tests to use the real mechanism [14:47] which I just checked it does not provide any getter, just setters [14:47] right [14:48] dobey: we can definitely wrap the notification instance with a very thin wrapper that records every call [14:48] I've done this in the past, with a recorder [14:48]