[00:01] <briancurtin> alright, eod here
[09:50] <czajkowski> mornign all
[09:50] <czajkowski> dobey: Good morning how are you :)
[10:16] <mandel> czajkowski, morning!
[10:16] <czajkowski> mandel: hey hey how you doing ?
[10:16] <mandel> czajkowski, welcome to the empty CET time zone in the u1 channel :)
[10:16] <czajkowski> mandel: how goes the rugby ?
[10:16] <czajkowski> tis rather quiet in here alright
[10:16] <mandel> czajkowski, injured, torn calf and screwed up ribs..
[10:17] <mandel> le me grab a coffe and I'll be back :)
[10:17] <czajkowski> mandel: oh dear :(
[10:32] <rye> yeah, kind of empty
[10:47] <ralsina> mandel: what? new injuries?
[10:47] <ralsina> and good morning
[10:51] <mandel> ralsina, yeah, not a big deal :)
[10:51] <mandel> czajkowski, well, I'm taking rugby off for a few weeks to recober
[10:52] <czajkowski> mandel: you're as broken as your dog !
[10:52] <mandel> czajkowski, yes, you know dog and owners are alike
[10:53] <mandel> ralsina, got time to run lp:~mandel/+junk/fix-sso-tests?
[10:57] <ralsina> mandel: not right away sorry
[10:57] <mandel> ralsina,  :(
[10:57] <mandel> ralsina, lets hope gatox gets back online
[10:58] <ralsina> mandel: nessita had a ton of things to say about that branch too
[10:58] <mandel> ralsina, a *ton* ?
[10:58] <ralsina> mandel: he should come back in a few minutes, it's 8AM already
[11:03] <ralsina> mandel: turns out I do have time :-)
[11:03] <mandel> ralsina, hurray1
[11:03] <mandel> s/1/!
[11:04] <mandel> 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] <ralsina> mandel: will do
[11:05] <mandel> ralsina, super thx!
[11:08] <mandel> ralsina, also, if you can run it several times, better :)
[11:27] <mandel> ralsina, did the tests pass?
[11:29] <ralsina> mandel: not finished the 1st pass yet
[11:29] <JamesTait> Happy Friday, everyone! :D
[11:29] <mandel> ralsina, puff they are slow to disconnect in your machine!
[11:30] <ralsina> I think a test just blocked
[11:30] <mandel> ralsina, if it did, it means is not disconnecting, which is good if it fails
[11:30] <ralsina> 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] <ralsina> which BTW: TYPO!
[11:30] <mandel> ralsina, not me :)
[11:35]  * mandel is starting to use bzr blame waaaay too much
[11:36] <mandel> ralsina, fixing it though :)
[11:36] <ralsina> mandel: yes, that is stuck
[11:37] <mandel> ralsina, ok, may ctrl+c and pass me the stdout please :)
[11:38] <ralsina> mandel: https://pastebin.canonical.com/62905/
[11:40] <mandel> ralsina, looks like is not connecting to the service 'cool'
[11:40] <ralsina> mandel: ok!
[11:40]  * ralsina goes walk ralsina
[11:41] <mandel> ralsina, do you have to pick up the poo when you walk him, I have to when I take Iron :P
[11:41] <ralsina> mandel: my ralsina is potty trained
[11:41] <mandel> lol
[11:47] <mandel> ralsina, whenever you are back, please check that you did not have sso running, just in case
[11:49] <mandel> also.. the number of protocols you have is too big, there should always be one, weird
[12:02] <nessita> hello everyone!
[12:12] <nessita> mandel: hola! when you can, we can chat about fix-broken-tests
[12:12] <mandel> nessita, morning! I've heard we have to chat :)
[12:12] <gatox> good morning
[12:12] <mandel> nessita, he, you read my mind :)
[12:12] <nessita> ;-)
[12:12] <nessita> hola gatox
[12:12] <mandel> gatox, can you try lp:~mandel/ubuntu-sso-client/fix-sso-tests please ?
[12:12] <gatox> mandel, ok
[12:12] <mandel> gatox, and morning!
[12:12] <gatox> :D
[12:12] <mandel> nessita, have you read this: http://mumak.net/stuff/twisted-disconnect.html
[12:13] <nessita> 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] <mandel> nessita, before we start, because my work is based on that :)
[12:13] <nessita> reading
[12:17] <urbanape> Lex to school, and then follow-up on my eyes. Should be back soon.
[12:17] <nessita> 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] <nessita> "_
[12:17] <nessita> )
[12:17] <nessita> we need to add this support of passing a deferred to  the protocol in IRL as well
[12:17] <nessita> no?
[12:18] <nessita> 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] <nessita> since, I understand, the propery closing applies also to IRL?
[12:19] <mandel> 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] <mandel> nessita, in trial, the issue is completely different, we have to disconnect to move to the next test, otherwise, dirty reactor
[12:20] <mandel> 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] <mandel> nessita, it has happened to me before, not wait, run test (hurray all green) propose and see dirty reactors in other machines
[12:21] <nessita> 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] <gatox> mandel, did you upload new changes in your branch?
[12:21] <gatox> i get nothing to pull or merge
[12:21] <mandel> gatox, is in lp:~mandel/+junl/fix-sso-tests
[12:22] <mandel> gatox, sorry junk :)
[12:22] <gatox> ah a different one.... sorry
[12:22] <mandel> 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] <mandel> 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] <nessita> mandel: we have one protocol per client, right?
[12:24] <gatox> mandel, can you give me the whole url of the branch.... is saying that is not a branch
[12:24] <mandel> gatox, sure :)
[12:24] <mandel> nessita, per client, yes, per server, we dont
[12:25] <mandel> gatox, here you have it: https://code.launchpad.net/~mandel/+junk/fix-sso-tests
[12:25] <gatox> mandel, thanks
[12:25] <mandel> 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] <mandel> nessita, lets bring alecu in the conversation, I'm a little boy with twisted compared to his knowledge :)
[12:26] <nessita> mandel: unless the protocol class you provide keeps track of that, no?
[12:26] <mandel> alecu, buenos dias!
[12:26] <alecu> hello!
[12:26] <mandel> nessita, yes, exactly
[12:26] <nessita> hola alecu
[12:27] <alecu> mandel, the above sounds right: "this means that you cannot state that the server does not have more than one client connected"
[12:28] <alecu> 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] <nessita> 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] <mandel> 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] <mandel> 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] <alecu> mandel, the "tree" deferreds? what tree?
[12:33] <mandel> alecu, sorry, brain fuck, three :)
[12:33] <alecu> oh, ok.
[12:33] <nessita> 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] <alecu> nessita, I don't think it's needed
[12:34] <nessita> alecu: since without it, I think our PB IPC services will not be able to "restart" properly?
[12:35] <nessita> alecu: we still need to make syncdaemon be able to restart on windows... you don't think this is part of that?
[12:35] <nessita> (for some cases, I understand is not always an issue)
[12:36] <mandel> nessita, I think is worth investigating if that is indeed the issue
[12:36] <mandel> 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] <alecu> nessita, I think this is nice to have for tests, but not really needed in production code.
[12:36] <nessita> alecu: why not?
[12:37] <alecu> nessita, in prod code this will be catched by twisted handlers and will be just logged as a disconnection error.
[12:38] <nessita> alecu: but we're having "ugly" traces (just traces) about the broken connections... isn't this part of the issue?
[12:38] <alecu> 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] <alecu> nessita, what are those "ugly" traces? do you have a link?
[12:39] <nessita> alecu: not right now, but is that trace from persepctive broker about... something (can't remember the trace text now)
[12:39] <nessita> about one end disconnecting and the other end not knowing
[12:40] <gatox> mandel, i get this: http://paste.ubuntu.com/896382/
[12:40] <gatox> and get stuck there
[12:41] <mandel> 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] <mandel> gatox, funny thing is, my vm is tuned so that I get just one lol
[12:42] <gatox> mandel, ah.... you already saw this? let me know if you need to test this further with my vm
[12:43] <mandel> gatox, I'm seen it, atm I have no bloody clue of the reason :(
[12:45] <alecu> 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] <mandel> alecu, in the webclient, I had to add them to ensure that we disconnected
[12:45] <alecu> nessita, but I don't think we should try to apply this solution to our ipc disconnection problems
[12:45] <mandel> alecu, and tcp activation..
[12:46] <mandel> those are the place I remember from other times..
[12:46] <nessita> alecu: ack... but why not the the production code?
[12:46] <alecu> nessita, I'd like to see what exactly are the ipc disconnection issues, and try to fix them.
[12:46] <alecu> nessita, also, the ipc in windows does not currently have the "feature" of reconnecting if one of the processes ends.
[12:46] <alecu> nessita, and that's something we should plan and add.
[12:47] <mandel> alecu, maybe letting the guy know that we started again we can do that.. does it sound hacky?
[12:49] <nessita> mandel, alecu: ack then. So mandel, will you be adding this to u1devtools?
[12:50] <mandel> nessita, yes, lets do it and clean all the tests then!
[12:50] <mandel> nessita, might not be as easy as it sounds of course, but will certainly work on it :)
[12:50] <alecu> nessita, mandel: can't we do it in a month or so? :-)
[12:51] <mandel> 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] <nessita> alecu: why?
[12:51] <nessita> mandel: what else is on your plate?
[12:51] <mandel> nessita, let me see..
[12:51] <nessita> alecu: if we're adding these pieces of code, I would prefer we add it to the right please
[12:51] <alecu> nessita, I don't like doing cleanups before releases
[12:52] <nessita> alecu: this is not a cleanup... the code is not present anywhere so far
[12:52] <mandel> 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] <mandel> 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] <mandel> nessita, god, sorry, let me make it shorter
[12:52] <nessita> alecu: mandel is adding new code, so I really prefer that he adds it to the right place
[12:52] <nessita> alecu: we may not change u1client to use this yet...
[12:53] <alecu> nessita, I thought you meant the refactoring of the tests to move the "cleaning after servers" bits to u1devtool.
[12:53] <mandel> nessita, http://tinyurl.com/c7nyqhq
[12:53] <nessita> 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] <alecu> mandel, what new code are you adding?
[12:54] <nessita> alecu: https://code.launchpad.net/~mandel/ubuntu-sso-client/fix-broken-tests/+merge/98868
[12:54] <alecu> nessita, there's code to do what the mumak article says in at least two places.
[12:54] <nessita> alecu: where?
[12:54] <nessita> alecu: and if so, why mandel is adding yet to a third place? :-)
[12:54] <mandel> nessita, webclient tests and tcpactivation, let me find the code..
[12:54] <alecu> nessita, webclient and ipc, iirc
[12:55] <alecu> ok, not ipc, tcpactivation.
[12:55] <nessita> alecu: in ussoc there is no test code using a PBClientFactory
[12:56] <nessita> nessita@dali:~/canonical/ussoc/trunk$ grep PBClientFac *
[12:56] <nessita> ubuntu_sso/utils/ipc.py:26:    PBClientFactory,
[12:56] <nessita> ubuntu_sso/utils/ipc.py:339:        self.factory = PBClientFactory()
[12:56] <nessita> nessita@dali:~/canonical/ussoc/trunk$
[12:56] <mandel> 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] <nessita> mandel: that's a different code, no?
[12:56] <mandel> 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] <mandel> nessita, yes and no.. is the same issue, is certainly due to different protocols/reasons
[12:57] <mandel> nessita, I mean, you have the same problem, need the 3 deferreds, but you are extending diff clases
[12:57] <alecu> 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] <nessita> 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] <alecu> nessita, so it needs a *delicate and thought out* piece of reusable code to go into devtools, in my opinion.
[12:58] <alecu> nessita, since we will be using this in many places.
[12:59] <nessita> alecu: I know how things goes, and I know is very unlikely this will be revisited any time soon
[12:59] <nessita> so, if we're adding *new* code, it should go in the right place
[12:59] <alecu> 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] <nessita> I disagree for this case
[12:59] <mandel> 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] <mandel> 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] <nessita> mandel: I agree we should solve this. Yet i'm not approving more hacks.
[13:01] <alecu> 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] <ralsina> mandel, checked, o sso running
[13:01] <ralsina> that's *no* sso running
[13:01] <alecu> nessita, and mostly so close to releases
[13:02] <mandel> ralsina, thx!
[13:02] <nessita> alecu: this is not affecting releases, no? we will not change production code
[13:02] <mandel> 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] <alecu> nessita, I think it affects our time to bugfix releases
[13:03] <nessita> alecu: we sacrificed doing the right before already, and we learn we lost useful time instead of gaining it
[13:04] <alecu> 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] <ralsina> 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] <nessita> alecu: but is the right thing to do
[13:05] <alecu> nessita, there's no "absolute" right. :-)
[13:05] <nessita> alecu: agreed
[13:05] <nessita> (non relevant though for this talk ;-))
[13:05] <alecu> nessita, devtools is the right place to have that bit available to other projects. But it's the wrong place to iterate.
[13:06] <nessita> alecu: then we need to fix the latter, and not adding code to other projects because of that
[13:06] <alecu> nessita, the testing classes we put in devtools never gets updated; they end up being "patched" in every test case.
[13:06] <nessita> alecu: that's not good, and the mistake is not to fix devtools
[13:07] <alecu> 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] <alecu> nessita, and I think that's counter productive to do when we are two weeks from releases on both platforms.
[13:07] <nessita> alecu: that process is not that slow, we do it very often between ussoc and controlpanel
[13:08] <nessita> alecu: the problem is the time waiting for reviews, which we need to fix
[13:08] <ralsina> I suspect most of us are not comfortable reviewing devtools
[13:08] <ralsina> since a break there breaks everything
[13:08] <ralsina> So that will always be slower
[13:08] <nessita> ralsina: perhaps, and we should change that, no?
[13:09] <ralsina> nessita: indeed
[13:09] <nessita> ralsina: my point is we can not add code elsewhere, even if it conceptually belongs to devtools, just because it may break
[13:09] <nessita> we can break ussoc, and sometimes we do, and then we fix
[13:09] <nessita> and breaking ussoc means breaking u1 *and* software center, for example, yet that does not scare us
[13:10] <ralsina> 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] <ralsina> We don't have, AFAIK, any hard data on how long a roundtrip through devtools is
[13:10] <mandel> ralsina, nessita it is not an easy piece of code what so ever
[13:10] <ralsina> mandel: she's not code! ;-)
[13:11] <nessita> mandel: I know, but you have a recipe, you have done this before, no?
[13:11] <mandel> ralsina, nessita, and is coming from me, a retard that things everything is easy
[13:11] <mandel> ralsina, lol
[13:11] <ralsina> 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] <ralsina> mandel: and then it works on linu, breaks on windows, and dejavu
[13:11] <nessita> mandel: so, I wonder why you are sure of adding this code to ussoc and not to devtools ;-)
[13:11] <mandel> nessita, I have done it before, yes, and it worked, and we could do it correctly for PB, other generalizations are hard
[13:12] <nessita> 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] <mandel> nessita, ok, it if is just Pb, I'm willing to tackle it, a bigger generalization I won't :)
[13:13] <nessita> mandel: makes sense
[13:13] <nessita> alecu: would only tackling PB be a middle ground for you?
[13:13] <alecu> nessita, yes.
[13:13] <mandel> nessita, that was my main concert 'acotar' the problem
[13:13] <nessita> alecu: thanks
[13:14] <nessita> mandel: I will review the devtools branch
[13:14] <alecu> 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] <mandel> alecu, nessita, ack!
[13:14]  * mandel adds bug
[13:15] <mandel> nessita, alecu, hehe I already added a similar bug 944125
[13:15] <ralsina> Ayone needs reviews? If not, I want some head-down time in some issues
[13:15] <mandel> but is not pb
[13:15] <alecu> 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] <ralsina> alecu: neat!
[13:16] <nessita> ralsina: before you go...
[13:16] <ralsina> nessita: I'll still be around, just not reading unless someone pings me :-)
[13:16] <nessita> 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] <briancurtin> 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] <nessita> ralsina: is starting to worry me
[13:16] <nessita> briancurtin: ack!
[13:16] <ralsina> nessita: looking...
[13:17] <ralsina> 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] <alecu> nessita, I'm taking a look too.
[13:18] <ralsina> nessita: we are getting dbus data after we lose the dbus proxy or something
[13:19] <mandel> nessita, alecu, ralsina, FYI bug 963082
[13:20] <ralsina> mandel: ack, thanks
[13:20] <alecu> mandel, no: "provide reusable code for tests that start a tcp server"
[13:20] <ralsina> nessita: have you ever had it yourself?
[13:20] <alecu> mandel, this should not be limited to PB
[13:21] <mandel> alecu, hm.. should be doable with a TCP server since all should inherit from the same, I'll update it
[13:21] <dobey> hi czajkowski
[13:21] <alecu> ralsina, how do you suspect dbus?
[13:21] <czajkowski> dobey: hello :)
[13:21] <ralsina> alecu: stacktrace
[13:22] <czajkowski> 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] <nessita> ralsina: never
[13:22] <alecu> ralsina, because of dbus/mainloop/qt.so ?
[13:22] <dobey> czajkowski: what version of rhythmbox-ubuntuone do you have?
[13:22] <ralsina> alecu: it's segfaulting on pyqtDBusHelper::readSocket
[13:23] <ralsina> alecu: that stinks of dbus ;-)
[13:23] <czajkowski> dobey: how do I find that out, am running 12.04
[13:23] <dobey> czajkowski: dpkg -l rhythmbox-ubuntuone
[13:23] <dobey> or apt-cache policy rhythmbox-ubuntuone|grep -i installed
[13:23] <czajkowski> dobey: http://pastebin.ubuntu.com/896420/
[13:24] <dobey> czajkowski: ok. quit rhythmbox; rm ~/.local/share/rhythmbox/rhythmdb.xml; start rhythmbox
[13:25] <briancurtin> ralsina: from yesterday, do we need to do something about --with-icon? or is that for after QA builds?
[13:25] <ralsina> briancurtin: if you start it from the menu, it should start with --with-icon already
[13:25] <ralsina> briancurtin: doesn't it?
[13:25] <czajkowski> dobey: start: Unknown job: rhythmbox
[13:25] <briancurtin> ralsina: i'll check (i had been starting from desktop icon)
[13:26] <ralsina> briancurtin: no, sorry, the autostart is --with-icon, the desktop icon or the menu will not
[13:26] <dobey> czajkowski: that wasn't literal. :)
[13:26] <czajkowski> :/
[13:26] <ralsina> briancurtin: if it was already running with --with-icon, starting it will just show it
[13:26] <dobey> czajkowski: just start rhythmbox again after you deleted the rhythmdb.xml :)
[13:27] <briancurtin> 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] <czajkowski> dobey: don't laugh :(
[13:27] <czajkowski> dobey: No such file or directory
[13:27] <ralsina> briancurtin: I think so yes
[13:27] <czajkowski> my day just gets better!
[13:27] <dobey> czajkowski: no such file or directory from what?
[13:28] <czajkowski>  cannot remove `/home/czajkowski/.local/share/rhythmbox/rhythmdb.xml': No such file or directory
[13:28] <briancurtin> ralsina: ack, will propose shortly (need to test in XP VM first)
[13:28] <ralsina> briancurtin: cool
[13:29] <dobey> czajkowski: ok, so it's gone then. just run rhythmbox again now
[13:30] <czajkowski> dobey: ok
[13:30] <czajkowski> dobey: now I have no music
[13:30] <dobey> czajkowski: it should be rescanning
[13:30] <dobey> so your music should appear in a minute
[13:31] <dobey> might be a little slow if you have lots of music in the u1ms folder
[13:31] <czajkowski> dobey: love your optimisim :)
[13:31] <czajkowski> shall wait and see
[13:31] <czajkowski> thanks for the help
[13:32] <ralsina> briancurtin: maybe we should just do --with-icon everywhere
[13:32] <ralsina> briancurtin: think about it and let me know ;-)
[13:32] <dobey> 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] <briancurtin> ralsina: i'll check it out
[13:32] <briancurtin> rebooting, this machine is working like crap
[13:33] <dobey> czajkowski: is there not a progress bar in the status bar going back and forth or anything?
[13:33] <czajkowski> dobey: nope nada
[13:33] <czajkowski> that would be helpful to see alright
[13:34] <dobey> czajkowski: and no music showing up? is the u1 store listed in the tree?
[13:35] <czajkowski> dobey: http://twitpic.com/905xp2/full
[13:35] <dobey> czajkowski: what if you select the "Music" entry with the icon next to it?
[13:36] <czajkowski> hmm now music is coming in
[13:36] <czajkowski> but I've been selecting it on and off for the last few mins
[13:37] <czajkowski> 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] <dobey> i think there is a bug in rhythmbox with how it handles the multiple libraries case
[13:37] <czajkowski> but at least it's still there
[13:37] <czajkowski> dobey: thanks again for the help
[13:37] <dobey> sure
[13:37] <czajkowski> popey: I now only have one copy of music :)
[13:38] <dobey> also, the fact that the u1 folder appears twice there is weird
[13:38] <czajkowski> dobey: indeed a little bit confusing :)
[13:39] <dobey> ah, that might be a bug in the plug-in
[13:49] <dobey> sigh. mocker. how dare you mock me
[13:49]  * dobey wonders how to remove mocker from these tests
[13:53] <joshuahoover> ralsina, nessita: anyone aware of bug #940669 on the team and able to work on it?
[13:54] <ralsina> joshuahoover: we were talking about it a bit earlier
[13:54] <nessita> joshuahoover: we're aware, i just mentioned this a few minutes ago
[13:54] <joshuahoover> ah, very good :)
[13:54] <ralsina> joshuahoover: so far none of us has actually seen it
[13:54] <ralsina> joshuahoover: just in case, the user is logged in anyway after the crash?
[13:54] <joshuahoover> ralsina: not sure
[13:55] <ralsina> joshuahoover: ok
[13:58] <urbanape> gonna go check out a coworking space. Will be back in plenty of time for standup.
[14:00] <dobey> 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] <ralsina> dobey: were you using a goto by chance? http://xkcd.com/292/
[14:03] <nessita> briancurtin: would you quickly fix this and I will approve?
[14:03] <nessita> ubuntuone/controlpanel/gui/qt/tests/test_folders.py:
[14:03] <nessita>     25:  [W0611] Unused import sys
[14:04] <briancurtin> nessita: yep, 1 min
[14:04] <nessita> thanks!
[14:13] <dobey> nessita: hola!
[14:13] <nessita> hola dobey!
[14:13] <nessita> dobey: want some mate? /me hands the mate
[14:14] <dobey> con medialunas?
[14:15] <dobey> nessita: might you have any ideas how to get rid of mocker usage in tests/platform/linux/test_notification.py in u1client?
[14:15] <nessita> dobey: let me look (right after I finish this review)
[14:15] <dobey> sure, thanks
[14:18] <ralsina> 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] <nessita> ralsina: ack!
[14:21] <dobey> mail languages?
[14:21] <nessita> 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] <nessita> dobey: want me to build something for you?
[14:22] <dobey> nessita: well it needs to call the real API
[14:22] <dobey> nessita: because a faked class, or mocker, seems to hide problems
[14:23] <ralsina> dobey: yes, mail languages, don't worry about it :-)
[14:23] <dobey> ralsina: was it the evolution default mail message?
[14:23] <ralsina> dobey: no, SSO's mail confirmation was sent half in spanish
[14:23] <dobey> oh
[14:24] <dobey> nessita: also, the API from the gir is a little different from the one in pynotify :(
[14:25] <dobey> maybe the fix for this bug is to fix the notify gir though
[14:25] <nessita> 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] <dobey> nessita: i guess i'm fine with having to use xvfb there. not sure if foundations guys are though
[14:27] <nessita> dobey: let me try some quick options
[14:27] <dobey> hrmm
[14:27] <nessita> dobey: what bug are you trying to fix, though?
[14:27] <dobey> bug #961342
[14:27] <ralsina> talking about notifications, do I remember right that we have a TypeError and all notifications are broken on unity?
[14:28] <dobey> ralsina: not unity
[14:28] <dobey> ralsina: but yes
[14:28] <ralsina> dobey: not *only* unity :-)
[14:28] <dobey> ralsina: broken everywhere
[14:30] <nessita> dobey: looking
[14:31] <mandel> ok, late lunch for me
[14:31]  * mandel lunch
[14:32] <ralsina> dobey: sing Xvfb and skipping them if DISPLAY is unset?
[14:32] <ralsina> s/sing/using/
[14:36] <dobey> ok
[14:36] <dobey> libnotify is itself broken
[14:36] <dobey> yays
[14:36] <mandel> ok, no, I'm stating, I'll go after the stand up
[14:37] <nessita> dobey: it is?
[14:37] <dobey> nessita: it has set_hint_foo API for various types, but not for boolean, though lots of hints are of type boolean
[14:40] <nessita> dobey: so the call self.notification.set_hint('transient', True) is not "valid" in this API?
[14:40] <dobey> nessita: apparently not with python-gi
[14:44] <dobey> hrmm
[14:44] <dobey> but looks like we can use int32
[14:44] <nessita> dobey: yes, that works
[14:45] <nessita> so, a simple integration test that we can add is a simple as:
[14:45] <nessita> dobey: http://pastebin.ubuntu.com/896508/, that does not assert anything but will fail if the notification shows crash
[14:46] <nessita> 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] <nessita> which I just checked it does not provide any getter, just setters
[14:47] <dobey> right
[14:48] <nessita> dobey: we can definitely wrap the notification instance with a very thin wrapper that records every call
[14:48] <nessita> I've done this in the past, with a recorder
[14:48] <nessita> so, make a call, the recorder saves the call, and then performs the real call
[14:50] <dobey> hrmm
[14:50] <nessita> dobey: and we can use the same suite to run it twice, one with the gi reactor, and one with the glib reactor
[14:50] <nessita> that will exercise both options using the same code
[14:50] <nessita> gatox: shall I re-review main-moved?
[14:51] <gatox> nessita, checking.....
[14:51] <dobey> nessita: i wonder if the diff will be a bit too large for doing it in precise though, at this point
[14:52] <nessita> dobey: will affect only tests
[14:52] <nessita> so I'm +1
[14:52] <gatox> nessita, ahhhhh i didn't saw your last comment..... your proposal wasn't working.... so i needed to do that.... let me check how i can do that and i'll modify the tests..... i'm finishing the test for the reset branch
[14:52]  * nessita is always +1 to have better tests that detect issues sooner
[14:52] <nessita> gatox: thanks!
[14:54] <dobey> nessita: i've fixed the existing code in lp:~dobey/ubuntuone-client/hint32 i'm not sure exactly how to do it with the real calls. i sonder if i should jusst strip out all the mocker bits and see what happens
[14:56] <nessita> dobey: I can give this a try, if I don;t  get anything good in a couple of hours, I will leave for the future
[14:57] <ralsina> people I am off to take son to pediatrician, so pasting my standup in a bit
[14:59] <ralsina> DONE: another windows QA build, debugged the sso-pops-under bug with elopio, team call, gatox 1:1, bunch of small things. TODO: get you all to review pending branches, another QA build maybe, reviews, work on unfixing geometry BLOCKED: yes, pediatricians are seldom punctual
[14:59] <urbanape> hope he's well.
[14:59] <gatox> ralsina, ack
[14:59] <ralsina> urbanape: he's great, but he needs a certificate for school's PE and swimming
[14:59] <urbanape> ah, so
[14:59] <ralsina> urbanape: and there are 16.5 million kids trying to get theirs this week ;-)
[15:00] <urbanape> so, we'll see you next month, some time?
[15:00] <nessita> me
[15:00] <gatox> me
[15:01] <briancurtin> me
[15:01] <urbanape> me
[15:01] <mandel> me
[15:01] <ralsina> urbanape: hopefully, in 2 hours :-)
[15:02] <gatox> alecu, dobey ?
[15:02] <alecu> me
[15:02] <nessita> ok, let's!
[15:02] <nessita> DONE: lots of reviews, landed code with new colours for the controlpanel (bug #956077), also fixed bug #822629 while I was at it, weekly call
[15:02] <nessita> TODO: finish reviews, see if I can help with rewritting the notification tests, start with fix for bug #959447
[15:02] <nessita> BLOCKED: nopes
[15:02] <nessita> NEXT: gatox
[15:03] <gatox> DONE:
[15:03] <gatox> Finish (finally) with the reset-password branch, fixing tests in backend getting stuck branch.
[15:03] <gatox> TODO:
[15:03] <gatox> Finish with the last tests, Bug #944256
[15:03] <gatox> BLOCKED:
[15:03] <gatox> No
[15:03] <gatox> briancurtin, go
[15:03] <briancurtin> DONE: a bunch of windows branches, cleaned a few up, did some manual testing and branch testing from the doc's office, very brief mac session
[15:03] <briancurtin> TODO: finish the last piece of autostart, get back to mac
[15:03] <briancurtin> BLOCKED: none
[15:03] <briancurtin> NEXT: urbanape
[15:03] <urbanape> DONE: Made some progress on the tests. Still two random hangs, waiting on word from mandel
[15:03] <urbanape> TODO: Code for testing network presence
[15:03] <urbanape> BLOCK: Not really
[15:03] <urbanape> mandel: go
[15:03] <mandel> DONE: Look at why are tests broken on windows. Implemented half of the solution.
[15:03] <mandel> TODO: Find out why tests on windows are getting more than one protocol. Implement solution and provide unified way to close Tcp connections correctly in trial for ubuntuone-dev-tools
[15:03] <mandel> BLOCKED: no
[15:03] <mandel> COMMENTS: I need to go a little early to take the dog to the vet
[15:03] <mandel> alecu, go
[15:03] <alecu> DONE: got a macmini, updated, installed XCode, started learning OSX, researched /dev/fsevents, got ticket to UDS
[15:03] <alecu> TODO: get back and finish proxy bugs
[15:03] <alecu> BLOCKED: no
[15:03] <alecu> NEXT: dobey
[15:03] <alecu> mandel, hope iron gets well!
[15:04] <mandel> alecu, should not be something terrible.. he is prone to problems, like the owner
[15:04] <dobey> oh
[15:04] <mandel> urbanape, let me have lunch and I'll give you a hand
[15:04] <urbanape> sure, no problem
[15:04] <alecu> mandel, is he so mindless that he plays rugby too?
[15:04] <urbanape> it's intermittent, but not something I'd want to land
[15:05] <mandel> urbanape, is that in sso?
[15:05] <nessita> dobey: standup pliz?
[15:05] <mandel> alecu, no, he is just a darwin fail.. chinese dogs.. you know :)
[15:05] <dobey> nessita: yeah, sorry. have to write the things :)
[15:05] <nessita> sure
[15:05] <dobey> λ DONE: team meeting, triage
[15:05] <dobey> λ TODO: bug fixing, triage, reviews
[15:05] <dobey> λ BLCK: none.
[15:06] <urbanape> mandel: yeah.
[15:06] <urbanape> ubuntu_sso.utils.tests.test_tcpactivation
[15:06] <urbanape>  ActivationDetectorTestCase
[15:06] <dobey> and i don't remember everything i did yesterday. meh
[15:06] <urbanape>   test_is_already_running
[15:06] <urbanape>  ActivationInstanceTestCase
[15:06] <urbanape>   test_get_port_fails_if_service_already_started
[15:06] <urbanape> mandel: ^
[15:06] <urbanape> those two tests will intermittently hang. 2 out of 5 trials will end with one or the other hanging.
[15:08] <gatox> nessita, mandel  if you have some free time for a review please: https://code.launchpad.net/~diegosarmentero/ubuntu-sso-client/reset-error/+merge/99039
[15:08] <nessita> gatox: ack
[15:09] <mandel> urbanape, sso tests are broken due to issue on how we close the tcp connections
[15:09] <urbanape> mandel: ralsina suggested that you had some fix for these in particular on the Windows port.
[15:09] <urbanape> was that fix skipIf?
[15:09] <mandel> urbanape, no, is not skipIf hehehe
[15:10] <mandel> urbanape, but yes, I'm working on a fix to be pushed to ubuntuone-dev-tools, the main reason is realted to this: http://mumak.net/stuff/twisted-disconnect.html
[15:10] <urbanape> danke
[15:10] <mandel> urbanape, feel free to 'ignore' those failures, I'll make sure things work with ipc/tcp tests
[15:10] <dobey> though we'll probably need an ffe for that
[15:12] <mandel> ok, lunch time for me
[15:12] <mandel> dobey, ouch!
[15:12]  * mandel lunch
[15:21] <dobey> oh right
[15:21] <dobey> also
[15:22] <dobey> TODO: perf review stuffs
[15:29] <gatox> nessita,  branch updated: https://code.launchpad.net/~diegosarmentero/ubuntu-sso-client/main-moved/+merge/98703
[15:29] <nessita> gatox: ack
[15:29]  * gatox go back to limit bandwitdh
[15:40] <dobey> ok, time for lunch. bbiab
[15:47]  * gatox lunch
[16:01] <nessita> alecu: would you have time for a "pure python" review?
[16:04] <alecu> nessita, looking
[16:04] <alecu> nessita, I mean, send it to me!
[16:04] <nessita> alecu: branch is https://code.launchpad.net/~nataliabidart/ubuntuone-dev-tools/add-recorder/+merge/99058
[16:04] <alecu> ack
[16:04] <nessita> alecu: just pushed a forgotten file (the test file!!!) :-)
[16:04] <nessita> forgotten as in forgot to bzr add
[16:05] <alecu> I see :-)
[16:08] <nessita> alecu: this class in currently in ussoc, my plan is once we have it in devtools, be able to reuse it from u1client (which I need now to fix some notifications tests), and also to remove it from ussoc and use the devtools' one
[16:08] <nessita> this class == Recorder
[16:09] <alecu> nessita, your branch fails pep8!
[16:09] <alecu> nessita, " it is generally better to append a single trailing underscore rather than use an abbreviation or spelling corruption" "class_ vs klass"
[16:09] <nessita> alecu: it does not here...
[16:09] <nessita> alecu: really? was not aware of that
[16:09] <nessita> will change
[16:09] <alecu> nessita, http://www.python.org/dev/peps/pep-0008/
[16:10] <nessita> alecu: changing
[16:10] <alecu> nessita, not that I really care. I don't like class_ better than klass, but I thought it would be fun correcting you on pep8ness :-)
[16:11] <nessita> alecu: was it? :-)
[16:11] <alecu> nessita, It really was!
[16:11] <nessita> glad I could help (?)
[16:11] <nessita> alecu: fixed and pushed up to revision 61.
[16:12] <alecu> great!
[16:16] <alecu> nessita, how does the logic with _next_result works?
[16:17] <alecu> nessita, say, I'm making a test, does the test_* method need to set _next_result to each result just before the tested code uses the attr?
[16:18] <alecu> nessita, this seems to be bordering a mocking framework.
[16:18] <nessita> alecu: it depends, you cat set it at setUp time if yoiu want to always return the same (use case: a backend and a ginve operations, like 'volumes_info'
[16:18] <nessita> alecu: naaaaaah :-)
[16:19] <nessita> alecu: you can also set _next_result up in a given test, if you want to force a specific result, for example, None (you may be testing None as a result is handled)
[16:20] <alecu> nessita, what I don't like about this is that if every non-existing method will return a next_result
[16:20] <alecu> -if
[16:20] <nessita> alecu: yes, you should set _next_result with pathc... like I did in the test
[16:20] <nessita> would you set _next_result to None after using it?
[16:22]  * alecu is thinking
[16:24] <alecu> nessita, what if we make _next_result a dict with the method name as the key?
[16:25] <nessita> alecu: sounds good!
[16:26] <nessita> I can also remove the _next_result altogether, but since we're using it already, I wanted this to provide it
[16:27] <alecu> nessita, anyway, if you decide to make any of those changes don't worry doing them in this branch, since the current code is fine.
[16:27] <nessita> alecu: I can ceratinly do the dict
[16:27] <alecu> I was just making sense of how it worked.
[16:27] <nessita> will be quick
[16:28] <alecu> nessita, also, please try to expand the docstring of the class so it includes the class attributes that provide this special behaviour (other than recording)
[16:28] <nessita> alecu: can you please elaborate a bit on that? not completely sure what you mean
[16:30] <alecu> nessita, this class is a Recorder, and the docstring for that aspect of this class is perfect. But since we would like this class to be used in many tests, the class docstring could also include some bits on the special attributes that other desktop+ devs using this class could set.
[16:30] <alecu> nessita, like _next_result or _handle_attr_error
[16:30] <nessita> ah, sure, will add that
[16:31] <dobey> nessita: what is this devtools branch about?
[16:32] <nessita> alecu: also, would you know how can I make the __name__ of the Recorded class be the __name__ of the class_? In code, I would like this to be:
[16:32] <nessita>     157 def add_recorder(class_):
[16:32] <nessita>     158     """Class decorator to wrap 'class_' and record every call made to it."""
[16:32] <nessita>     159      @wraps(class_)
[16:32] <nessita>     160     class Recorded(Recorder, class_):
[16:32] <nessita>     161         """Record every call."""
[16:32] <nessita>     162
[16:32] <nessita>     163     return Recorded
[16:32] <nessita> alecu: but wraps over a class does not work :-/
[16:32] <nessita> dobey: I'm moving a 'recorder' helper to devtools so I can use this to build the Notification tests, using the real notification engine and also recording every call with its paremeters, to be able to test it
[16:33] <dobey> nessita: can you file a bug please? also is it ready or are you still working on it?
[16:34] <alecu> nessita, no, no idea about that. I've not yet added @wraps to my mental toolkit, so I'm in the dark regarding using it for classes.
[16:34] <dobey> nessita: we'll probably need a ffe if this is to go in for precise
[16:35] <briancurtin> ugh, i like how this works fine in pure python but not in the frozen binary. wtf.
[16:35] <alecu> nessita, the branch so far looks good. Let me know if you make any of those changes.
[16:36]  * alecu will have lunch now.
[16:36] <briancurtin> ralsina: when you get back, i have an autostart question re: frozen binary
[16:36] <mandel> ralsina, ping!
[16:37] <nessita> dobey: oh... we will? (yeah I know the answer)
[16:37] <nessita> but but but is just a helper
[16:38] <dobey> it's new api in a library
[16:38]  * nessita cried
[16:38] <nessita> cries*
[16:38] <nessita> dobey: ok, I'll file the bug
[16:42] <mandel> nessita, yeah.. same happens for the ipc test I suppose.. :*(
[16:44] <nessita> mandel: yes, will cover both in one bug report
[16:49] <nessita> dobey: would you add anything to https://bugs.launchpad.net/ubuntu/+source/ubuntuone-dev-tools/+bug/963265?
[16:49] <nessita> mandel: what's the bug number of the thing you're working on?
[16:49] <mandel> nessita, one sec, I'll get it
[16:49] <mandel> nessita, bug 963082
[16:50] <dobey> nessita: the series targets; and i'd make it only for the recorder stuff. mandel already filed a bug about the pb test case stuff
[16:51] <dobey> but it will also need an ffe
[16:51] <nessita> dobey: yeah, but wanted to request a single FFe, like joshuahoover usually advice us
[16:51] <nessita> dobey: series target added
[16:51] <nessita> dobey: also added this comment "The first item described in this bug report is being specifically handled in bug #963082."
[16:51] <dobey> nessita: they should be separate FFes i think. they are separate things
[16:52] <nessita> dobey: they are both 'missing helpers' :-D
[16:52] <nessita> dobey: if you insist, I will make them 2 separate FFe
[16:52] <nessita> but I prefer handing one single bug # to the release tema
[16:52] <dobey> they are separate branches and separate features
[16:52] <nessita> team
[16:53] <nessita> ok then
[16:53] <nessita> mandel: just FYI, the bug reports are usually phrased describing the problem
[16:53] <nessita> not describing the task that needs to be done
[16:54] <mandel> ack
[16:54] <nessita> mandel: so, instead of "provide foo", the bug may be "foo is not provided" or "Does not provide foo" or "Need foo"
[16:54] <dobey> nessita: where is the recorder stuff being moved from?
[16:54] <nessita> dobey: ussoc, with some minor improvements
[16:54] <mandel> nessita, understood
[16:54] <nessita> mandel: thanks!
[16:55] <dobey> nessita: it might be better to leave it there for now then, and move it for after precise
[16:55] <nessita> dobey: I need it from u1client
[16:55] <nessita> for*
[16:55] <dobey> nessita: yes and u1client already depends on sso
[16:55] <nessita> dobey: you prefer u1client build-dep to list python-ubuntu-sso-client.tests?
[16:55] <dobey> nessita: isn't that why you install the tests?
[16:56] <nessita> dobey: for controlpanel, but yes, we should have move the helper to devtools
[16:56] <dobey> well it makes everything a whole lot easier for precise
[16:57] <nessita> dobey: what if: if I get the FFe, I do it in devtools, if not, I use it from ussoc?
[16:57] <dobey> moving things is a huge changset, and we've onmly got 2 weeks
[16:57] <nessita> dobey: I can have this done today (fyi)
[16:58] <dobey> nessita: well i'd really rather avoid the ffe entirely.
[16:59] <nessita> dobey: I understand your point, but I'm completely sure I see a drawback from requesting a ffe for this. Besides asking the FFe itself, what other problem do you foresee?
[16:59] <nessita> I'm not* completely sure :-)
[17:01] <dobey> it's not about potential problems i see or don't see. it's about keeping the changes as small as possible. we should not be doing any freeze exceptions at this point. it adds more work to landing the code, it adds more work to do ing the release, it means the changes are probably big (and they are in this case)
[17:03] <dobey> our goal should be to never need to request exceptions, and i think we've done way too many this cycle already
[17:04] <nessita> dobey: ok, will tweak the branch and leave it proposed. in a couple of weeks, we could still land in trunk, no?
[17:06] <nessita> alecu_away: changes pushed
[17:06] <dobey> we can land it in trunk now, if need be. but i don't really want to merge it into stable-3-0 and ship it in precise if we can avoid it
[17:07] <dobey> the same for mandel's bug
[17:07] <alecu> nessita, thanks
[17:08] <nessita> dobey: ack
[17:08] <nessita> will have lunch now
[17:08] <nessita> brb!
[17:21] <popey> czajkowski / dobey the duplicate music issue fixed?
[17:22] <dobey> popey: yes
[17:22] <popey> dobey: what do I need to do?
[17:22] <dobey> popey: remove the old duplicates (the fix doesn't remove the old ones unfortunately)
[17:22] <gatox> nessita, i've just fixed the problem in the webclient..... it's working.... i'm going to try to adapt the test for test_webclient now
[17:23] <dobey> popey: quit rhythmbox, delete ~/.local/share/rhythmbox/rhythmdb.xml, then start rhythmbox back up and let it rescan your library
[17:24] <popey> how do i know which are the "right" ones to delete dobey ?
[17:24]  * beuno senses a star wars quote coming up
[17:24] <popey> ☺
[17:25] <popey> oh, one is a symlink, bin that
[17:26] <dobey> well, make sure you only remove it from the library. don't actually delete it :)
[17:28] <gatox> alecu, ping
[17:28] <alecu> gatox, pong
[17:28] <popey> no, i removed the symlink ☺
[17:28] <gatox> alecu, quick question: where are you testing qtnetwork in sso?? (i assume your hands are related to that :P)
[17:29] <gatox> i'm looking at test_webclient..... but it's not really clear for me if that is using qtnetwork
[17:30] <alecu> gatox, test_webclient is both testing qtnetwork.py and libsoup.py
[17:30] <alecu> gatox, remember that the sso tests are two step: first the gtk test are run, then the qt ones.
[17:30] <gatox> alecu, ok, thanks..... i'll keep looking into that then
[17:31] <alecu> gatox, the switch for selecting one or the other is in ubuntu_sso/utils/webclient/__init__.py
[17:31] <alecu> gatox, what exactly are you looking for?
[17:32] <gatox> alecu, i want to test the result from _handle_finished, particularly when that fails and return a WebClientError
[17:33] <ralsina> hello again!
[17:33] <gatox> ralsina, hi there.... everything ok in the doc?
[17:33] <ralsina> briancurtin: what doesn't work on frozens?
[17:34] <ralsina> gatox: perfect!
[17:34] <gatox> ralsina, great
[17:34] <ralsina> gatox: my son is allowed to run, swim and or jump all year
[17:35] <briancurtin> ralsina: add_to_autostart() - works great running u1cp from python, but it seems like the whole function is ignored when run as a frozen exe
[17:35] <briancurtin> ralsina: that's when you already have cred
[17:35] <ralsina> briancurtin: interesting
[17:35] <briancurtin> ralsina: i know it was working when run through the wizard
[17:36] <briancurtin> ralsina: i even took the getattr(sys, "frozen", False) check out to run the winreg stuff regardless of python or frozen and it only works on frozen...
[17:36] <ralsina> briancurtin: want me to give you a hand, I can in about 15'
[17:36] <briancurtin> ralsina: yeah, whenever you have time
[17:36] <ralsina> briancurtin: ack, will ping you in a few minutes
[17:38] <nessita> gatox: awesome!!!
[17:39] <gatox> nessita, between yesterday and today..... i reach the conclusion that tests hate me jejeje
[17:39] <mandel> ralsina, 1-1 in like about 15-20 mins?
[17:39] <mandel> ralsina, we forgot to do it
[17:39] <ralsina> mandel: sure
[17:39] <ralsina> mandel: I did not forget, I skipped it
[17:39] <ralsina> mandel: *you* may have forgotten ;-)
[17:39] <nessita> gatox: as written in the back of my business card: "tests are women are always right"
[17:39] <mandel> ralsina, it was deferred :P
[17:40] <gatox> nessita, jejejejeje
[17:40] <gatox> nessita, you slogan is not very motivational right now :P
[17:40] <nessita> gatox: until you find out that tests were right, that's when you feel illuminated :) (really, not kidding)
[17:41] <gatox> nessita, i trust you..... but this backend thing confuse me a lot :P.... but i'm getting there!
[17:41] <nessita> gatox: let me know if I can help
[17:41] <gatox> nessita, no worries
[17:42] <nessita> dobey: https://code.launchpad.net/~nataliabidart/ubuntuone-dev-tools/add-recorder/+merge/99058/+edit-status set to needs review again, --fixes added and pushed, and bug invalidated for stable-3-0 and precise
[17:43] <popey> thanks dobey
[17:46] <ralsina> mandel: 1:1 quick so I am free to help brian
[17:47] <mandel> ralsina, sure, let me reboot the mac (mumble just works there)
[17:47] <ralsina> mandel: ack
[17:48] <dobey> popey: np.
[17:48] <dobey> nessita: ok, though i don't think you wanted to paste the +edit-status link :)
[17:49] <nessita> dobey: nopes :-)
[17:53] <alecu> nessita, approved.
[17:53] <nessita> alecu: thanks!
[18:02] <dobey> nessita: should i propose my fix for the TypeError issue in the notifications as-is, or do you still wnat to look at using the recorder for the tests from the one in sso?
[18:02] <nessita> dobey: I'm working on that branch as we speak
[18:09] <ralsina> briancurtin: finally, ready to help
[18:09] <mandel> nessita, got an idea, in a future branch, what about running the ipc tests of windows/mac on linux too? they have no other dependency but twisted
[18:10] <nessita> mandel: they are already ran
[18:10] <briancurtin> ralsina: i think i might have figured it out, trying something now...i think im just an idiot
[18:10] <mandel> nessita, and we do not get dirty reactors?
[18:10] <nessita> mandel: test_ipc is run on every OS
[18:10] <nessita> mandel: no
[18:10] <ralsina> briancurtin: ok, that's a valid excuse! :-)
[18:10] <mandel> nessita, uh... que feo!
[18:10] <mandel> nessita, ok, then forget what I said :)
[18:10] <nessita> :-)
[18:11] <briancurtin> ralsina: in the meantime, https://code.launchpad.net/~brian.curtin/ubuntuone-windows-installer/with-icon/+merge/99086
[18:11] <ralsina> mandel: sockets on windows and linux are not semantically the same. For example, using local sockets as a condition for app unicity worked exactly backwards
[18:11] <ralsina> briancurtin: reviewing!
[18:11] <ralsina> briancurtin: I will try to propose and merge mine first
[18:12] <mandel> ralsina, oh my lords.. is every single part of the os stack different?
[18:12] <briancurtin> ralsina: ack
[18:12] <ralsina> nessita: is it ok if we merge the branch of windows-installer I am using to build the windows test builds? It's easier for brian to fix stuff if that's in, or else we get brnaches piling up
[18:12] <nessita> ralsina: which one would be those?
[18:13] <nessita> ralsina: if we have merge proposal for that, sure, we can review and merge
[18:13] <ralsina> nessita: mine is lp:~ralsina/ubuntuone-windows-installer/doing-windows
[18:13] <ralsina> nessita: it does a few things that are "just for now" because it merges branches manually and I remove them as they get approved.
[18:14] <nessita> ralsina: reading the list of pending branches from a non-versioned file, or having them as command line arguments is too much to ask?
[18:14] <ralsina> nessita: command line arguments is a pain. A non-versioned file is possible
[18:15] <nessita> ralsina: just fyi, the version of the last release is 2.99.91 (not 2.99.1), not sure if you're using 2.99.1 on purpouse
[18:15] <ralsina> nessita: must be a mistake
[18:16] <ralsina> nessita: I think I saw that in the milestone list, may have typed wrong and then jut was wrong consistently
[18:16] <alecu> gatox, in your unicode ventures, did you happen to meet the error mentioned by elopio in bug #854328?
[18:16] <nessita> ralsina: I would prefer having the list of pending branches being loaded from some source external to the script, but will not be strict about this (meaning if you really consider is necessary to have this as is right now, I will trust you)
[18:16]  * gatox looking....
[18:17] <ralsina> nessita: yes please, because it helps brian and I build the same things
[18:17] <gatox> alecu, do you know if he is using the latest things in trunk?
[18:18] <alecu> gatox, it's a very old bug! 2011-09-26:
[18:18] <nessita> ralsina: does that means that loading the pending branches list from an external source is too much to ask? (not sure if that's what you really mean)
[18:18] <ralsina> nessita: no, it's not much but it's something else to do and I need to get this done. The list will be clean by monday
[18:18] <gatox> alecu, because that seems to be fixed in the latests changes..... but i would like some kind of confirmation
[18:19] <nessita> ralsina: ok then
[18:19] <ralsina> nessita: cool, thanks
[18:19] <alecu> gatox, should I assign that bug to you and ask elopio to try again?
[18:19] <gatox> alecu, ok
[18:19] <gatox> alecu, unicode doesn't scare me anymore! jeje
[18:19] <gatox> just make mme cries sometimes :P
[18:20] <alecu> gatox, brave man! you are a unicode superhero nowadays!
[18:20] <ralsina> nessita: rethinking, I will merge it with a clean list of branches and keep that on my own
[18:20] <elopio> alecu, gatox, I'll look at my brazilian xp to try again.
[18:20] <nessita> ralsina: sounds better :-)
[18:20] <gatox> elopio, great! thanks, please let me know if the problem persist
[18:21] <elopio> gatox: I don't think I'll have time for that today, but I'll leave it installing in the night and quickly try tomorrow.
[18:21] <elopio> I'll add a comment on the bug.
[18:21] <ralsina> briancurtin: I am proposing doing-windows now, after we merge that, let's get as many of your branches off your woodpile as we ca today :-)
[18:21] <gatox> elopio, no problme.... i'm pretty busy today too
[18:21] <gatox> elopio, ok..... alecu please assign that bug to me, so i can see it in my queue
[18:22] <gatox> alecu, assigned....... thakns
[18:22] <alecu> elopio: I've added a comment to that bug too, and assigned it to gatox.
[18:22] <elopio> great. Thanks.
[18:24] <ralsina> alecu: why is bug #633280 still "triaged" ? ;-)
[18:24] <ralsina> as well as bug #387308
[18:25] <alecu> ralsina, probably because it slipped under the radar :-)
[18:26] <ralsina> elopio: do you remember the number for the "sso pops under" bug? I have a clear explanation of why it happens now
[18:26] <elopio> ralsina: bug #962407
[18:27] <ralsina> elopio: thanks!
[18:28] <briancurtin> ralsina: here are the outstanding branches: https://pastebin.canonical.com/62951/
[18:29] <briancurtin> ralsina: the "issue" i had with autostart is that i wasn't building/bundling/installing the autostart branch, but a clean one...so yeah, that's why it didn't "work" for a few tests i was doing
[18:29] <briancurtin> i'm going to step away for a few minutes to make lunch, back in a few mins
[18:29]  * urbanape feels he could have benefitted by a week-long immersion course in syncdaemon.
[18:30] <ralsina> briancurtin: ouch
[18:30] <ralsina> briancurtin: happened to me a few times, too. Have a nice lunch!
[18:30] <urbanape> brb
[18:30] <ralsina> urbanape: it's a non-trivial piece (mass?) of code, granted.
[18:31] <dobey> https://code.launchpad.net/~dobey/rhythmbox-ubuntuone/undup-lib-entries/+merge/99085 <- fairly simple review if anyone would be so kind? :)
[18:36] <ralsina> alecu: I bet that felt good ;-)
[18:36] <ralsina> dobey: on it!
[18:36] <alecu> lol
[18:37]  * ralsina adds "ceremonial bug killing" to the possible perks for devs
[18:41] <ralsina> dobey: +1
[18:44] <ralsina> briancurtin, mandel, gatox: could I get a review of https://code.launchpad.net/~ralsina/ubuntuone-windows-installer/doing-windows/+merge/97972
[18:44] <ralsina> or two
[18:44] <gatox> ralsina, on it
[18:44] <briancurtin> ralsina: already looking
[18:44] <mandel> then I'm not needed and I EOD :)
[18:44] <mandel> all, have a bloody great weekend!
[18:44] <ralsina> mandel: have a good weekend, not too bloody!
[18:45] <ralsina> mandel: you know, spare the chihuahuas
[18:48] <ralsina> nessita: one branch that could use a review from you is https://code.launchpad.net/~ralsina/ubuntuone-control-panel/u1cp-windows-styling/+merge/98704
[18:48] <nessita> ralsina: ack
[18:48] <nessita> ralsina: did you merged trunk in there?
[18:48] <ralsina> nessita: basically, the focus hacks look like crap on windows, so I had to move them into platform-specific qsses
[18:49] <ralsina> nessita: right, will do and let you know when it's done
[18:49] <nessita> thanks
[18:51] <alecu> nessita, gatox, ralsina: this bug is no longer valid on windows, right? bug #803952
[18:51] <ralsina> alecu: I suspect it's not because all that code is gone
[18:51] <alecu> since installer was merged and it's no longer separate
[18:51] <briancurtin> ralsina: doing-windows approved
[18:51] <alecu> ralsina, great.
[18:51] <ralsina> briancurtin: thanks!
[18:51] <nessita> alecu: very likely
[18:51] <gatox> nessita, i don't think so
[18:51] <nessita> gatox: no?
[18:52] <gatox> nessita, do you think that is still valid?
[18:53] <nessita> gatox: alecu asked for the negative :-) "this bug is no longer valid on windows, right?" my answer -> "very likely" (that is no longer valid)
[18:54] <alecu> no?
[18:55] <alecu> j/k
[18:56] <gatox> nessita, ahhhhh so, i answer the same.... is no longer valid :P
[18:57] <nessita> gatox: you answered the opposite! :-D
[18:57] <gatox> jejeje you are confusing me
[18:57] <gatox> nessita, well.... i wanted to say the same as you in my brain
[18:57] <gatox> jejeje
[18:58] <nessita> gatox: I figured. But for a moment you scared me :-)
[18:58] <nessita> (like, this was still an issue)
[18:58] <gatox> jeejej
[19:10] <gatox> alecu, ping..... is there any way to force the webclient in qtnetwork to receive a custom reply in _handle_finished....... this is driving me crazy
[19:10] <gatox> ??
[19:11] <gatox> i'm trying to patch something..... but it seems that i cannot reach the things i need to patch
[19:11] <gatox> because of the way that the signals are connected and so
[19:19] <ralsina> nessita: https://code.launchpad.net/~ralsina/ubuntuone-control-panel/u1cp-windows-styling/+merge/98704 merged, conflicts resolved. It moves quite a bit of qss around, so take a good look in linux and windows
[19:20] <ralsina> nessita: basically, you should have no visual difference whatsoever on linux
[19:21] <nessita> ralsina: will do!
[19:21] <ralsina> nessita: also, will surely conflict with your colors branch :-/
[19:21] <nessita> ralsina: my colours branch landed already...
[19:22] <nessita> so I guess you solved the conflicts already?
[19:22] <ralsina> nessita: then it surely conflicted ;-)
[19:22] <nessita> ralsina: did you solve those? :-D
[19:22] <ralsina> nessita: I solved them all!
[19:22] <ralsina> nessita: did I solve them correctly? That is the question now ;-)
[19:23] <nessita> ralsina: wanna check? :-D
[19:23] <ralsina> nessita: it looks good on windows
[19:24] <ralsina> looks like we have some problem killing syncdaemon on windows
[19:24]  * ralsina debugs a bit
[19:27] <ralsina> nessita, alecu: u1sdtool -q (or other reasonable means) fail to top syncdaemon in windows
[19:27] <nessita> ralsina: when is running?
[19:27] <ralsina> it prints "2012-03-23 16:26:31,704 - twisted - INFO - Main loop terminated." but keeps the logs open
[19:27] <ralsina> nessita: yes
[19:27] <nessita> when is not running, apparently, it starts it again
[19:27] <nessita> (there is a bug for that)
[19:28] <ralsina> nessita: it is running, and if we try to stop it, it doesn't. Since it closes the IPC port, another syncademon starts, but because the logs are still open, neither works
[19:28] <ralsina> so it's sort of a real problem
[19:29] <ralsina> cannot by Ctrl-C'd either
[19:39] <nessita> ralsina: why another syncdaemon tries to start?>
[19:39] <ralsina> nessita: if, for instance, I start u1cp again
[19:39] <nessita> alecu: can that ^ be related to the tunnel? or the twisted disconnection madness?
[19:39] <nessita> ralsina: you behind a proxy?
[19:39] <ralsina> nessita: no
[19:41] <ralsina> I want to do a patch that after sd closes the main loop kills it very dead
[19:42] <ralsina> even if we are not cleaning up correctly, keeping the process alive at that point is completely useless
[19:42] <ralsina> and the OS will clean up after us
[19:42] <nessita> ralsina: I would advice talking about this with alecu, for sure
[19:42] <ralsina> nessita: yes, I will
[19:42] <ralsina> alecu: any thoughts?
[19:43] <alecu> ralsina, thinking
[19:59] <nessita> dobey: I quit having this working. The fact that the Notification.new object comes from the gi layer, is making any attempt to record the calls a complete failure
[20:00] <nessita> dobey: I'm sorry I could not help in this case. I would advice though adding a single test case that will open a real notification, like I showed in the paste
[20:02] <alecu> ralsina, I'm taking a look, and can't find anything very obvious.
[20:03] <alecu> ralsina, is this on trunk?
[20:03] <ralsina> alecu: yes
[20:03] <ralsina> alecu: I checked and main.quit is being processed, and it's doing a reactor.stop() that never returns
[20:03] <alecu> ralsina, I would add a print just after reactor.run()
[20:04] <dobey> nessita: i'm happy to just get rid of all the mocker stuff
[20:04] <dobey> nessita: then they will all be real calls
[20:04] <ralsina> alecu: to make it more fun, this can only be tested on .exes :-/
[20:04] <nessita> dobey: yes, but you can't assert that you made the proper calls, and every needed call (you can't assert you called set_hint_string if the update flag is on, etc)
[20:05] <nessita> dobey: so, until we replace Mocker tests with soemthing else, we can't remove them
[20:05] <ralsina> alecu: ok, will do some more prints
[20:05] <nessita> dobey: my advice is to add a new testcase, that will show a notification, without mocking anything
[20:05] <nessita> so, the 2 suites together, will give better coverage than what we have now
[20:05] <alecu> ralsina, only on .exes? ouch.
[20:05] <ralsina> alecu: yes, but at least I can do them quickly :-)
[20:06] <dobey> nessita: but calling the wrong thing will at least actually fail, without the mocker.
[20:06] <ralsina> alecu: feels like C++
[20:06] <dobey> anyway
[20:06] <nessita> dobey: yes, that's why I say having the 2 test suites
[20:06] <nessita> dobey: the mocker, to check that anything is left out, the real life one, to check that every call is valid
[20:06] <nessita> anything -> nothing
[20:07] <nessita> ralsina: if you do u1sdtool -q while running syncdaemon from trunk, does it stop?
[20:07] <ralsina> nessita: not on windows
[20:07] <nessita> ralsina: it does not stop? os is reproduceable from trunk?
[20:07] <dobey> ok
[20:07] <ralsina> nessita: does not stop
[20:08] <nessita> ralsina: ok, so alecu can reproduce using trunk, right?
[20:08] <ralsina> ok, this is fun. reactor.stop() is returning, but sys.exit() is not.
[20:08] <ralsina> So, it may be an atexit handler that is not finishing?
[20:08] <ralsina> nessita: yes
[20:10] <alecu> ralsina, or a thread that keeps running?
[20:10] <ralsina> alecu: all threads should be daemonic, and stop...
[20:11] <alecu> should, could, would
[20:12] <ralsina> alecu: are we creating threads somewhere in sd?
[20:12] <ralsina> I know, we are
[20:12] <ralsina> but why would this work on linux then
[20:13] <alecu> ralsina, yup: I remember the hash queue, but I know some other places may create threads too.
[20:13] <alecu> but they should be *very* few.
[20:13] <nessita> ralsina, alecu: in windows you have all the threads to read directory changes
[20:13] <alecu> ralsina, anyway, it does not make sense for them to work differently when .exed
[20:13] <ralsina> ok, so twisted is putting a lot of stuff hooked on sys.exit
[20:14] <alecu> nessita, that's right too!
[20:14] <nessita> alecu: ralsina just said this can be reproduced from trunk
[20:14] <ralsina> alecu: let me try again from .py and see what happens
[20:14] <alecu> ralsina, sure.
[20:15] <ralsina> the thing when running from .py is that u1sdtol doesn't work correctly
[20:15] <ralsina> u1sdtool -q starts an "exe" syncdaemon
[20:16] <ralsina> and everything fails differently
[20:16] <alecu> ralsina, and what if the .py sd is already running?
[20:16] <nessita> ralsina: but what if you have an already started syncdaemon?
[20:16] <ralsina> alecu, nessita: I start the .py syncdaemon, and u1sdtool starts an exe anyway
[20:16] <alecu> ralsina, how comes?
[20:17] <ralsina> alecu: if I knew I would fix it :-)
[20:17] <alecu> ralsina, they should be listening in the same port, right?
[20:17] <ralsina> alecu: yeah
[20:17] <alecu> ralsina, I mean, ipc port
[20:17] <ralsina> let me see if the .py sd is listening
[20:17] <alecu> ralsina, oh, -q
[20:17] <alecu> ralsina, perhaps we have never tested -q right on windows
[20:18] <alecu> ralsina, I know that -q does some weird things on linux
[20:18] <ralsina> alecu: used to work
[20:18] <ralsina> ok, if I use the .py, it's not opening the IPC port
[20:18] <ralsina> because it can't start the proxy tunnel
[20:18] <alecu> "<ralsina> alecu: used to work" <- what percentage of certainty? :-)
[20:18] <ralsina> alecu: previous releases, used it :-)
[20:18] <alecu> ok
[20:18] <alecu> :-)
[20:18] <ralsina> so that's why this has to be exes
[20:19] <ralsina> basically sd doesn't work from .py anymore
[20:20] <alecu> ralsina, and what was the change that made it impossible to run from .py? I can't believe it was the tunnel...
[20:21] <gatox> nessita, these branches are ready for review: https://code.launchpad.net/~diegosarmentero/ubuntu-sso-client/reset-error/+merge/99039  -  https://code.launchpad.net/~diegosarmentero/ubuntu-sso-client/main-moved/+merge/98703
[20:23] <nessita> gatox: thanks!
[20:25] <ralsina> if anyone told me something after I said "doesn't work from py anymore" I missed it
[20:28] <gatox> ralsina, alecu told you: <alecu> ralsina, and what was the change that made it impossible to run from .py? I can't believe it was the tunnel...
[20:28] <ralsina> alecu: you better believe it! ;-)
[20:29] <ralsina> alecu: the whole "start the tunnel" thing was completely broken on windows. Brian and I fixed it for the common case (exes) but not for python binaries, since those are just not executable
[20:29] <ralsina> alecu: so to fix it we would have to detect that we are not frozen and hack the argument list, and insert the python exe in it, which is gross
[20:29] <ralsina> and completely platform-specific to boot
[20:29] <alecu> ralsina, oh, I see. Since the proxy process is not being started....
[20:30] <ralsina> alecu: maybe we should make it assume there is no proxy if that process fails, though
[20:30] <alecu> ralsina, right. That's what the code does (or should be doing)
[20:31] <alecu> ralsina, I have testcases for that.
[20:31] <ralsina> alecu: it's not what it's doing, though
[20:33] <ralsina> and this may block the windows release, I'm afraid :-(
[20:34] <briancurtin> ralsina: is there anything i can do to help out? i noticed it was hard to close SD but i figured it was because of the SHOW_CMD or something making windows stick around
[20:34] <ralsina> briancurtin: No, it's gone all Bruce Willis on us :-)
[20:35] <ralsina> briancurtin: a good thing to have here that may help is a fix so that when the TunnelRunner fails it just assumes there is no proxy and sd doesn't fail. That way we can debug it much easier.
[20:35] <ralsina> briancurtin: global approve for windows-symlink
[20:35] <briancurtin> ralsina: thanks
[20:36] <ralsina> briancurtin: you have some needsfixing on autostart-clean
[20:36] <briancurtin> ralsina: that's what im working on now
[20:36] <ralsina> briancurtin: ack
[20:36] <briancurtin> is there any pending branch for the SSO login not working when started via the wizard?
[20:37] <ralsina> briancurtin: please update with-icon because you are going to have a conflict
[20:37] <ralsina> briancurtin: it *is* working, I just used it :-)
[20:37] <briancurtin> hm, i'll try again
[20:39] <gatox> people.... i'm going to enter EOD mode... i'm actually programming bugs right now :P have a nice weekend!
[20:39] <ralsina> gatox: the bug you are fixing is linux-specific right?
[20:40] <gatox> ralsina, right now?? or the 2 branches i proposed?
[20:40] <ralsina> gatox: let me put it another way ;-)
[20:40] <dobey> alecu: are we really trying to send dns queries through the proxy server?
[20:40] <ralsina> gatox: do you have any branches pending that fix windows problems?
[20:40] <gatox> ralsina, nop
[20:40] <ralsina> dobey: that's standard procedure
[20:40] <gatox> ralsina, ah yes
[20:40] <gatox> ralsina, the backend one that is for review
[20:41] <ralsina> dobey: proxys are often configured for systems that have absolutely no decent DNS resolution
[20:41] <ralsina> gatox: ack
[20:41] <gatox> ralsina, you already approved, but then i need to put the changes in another branch for some bazaar stuff....... this one: https://code.launchpad.net/~diegosarmentero/ubuntu-sso-client/main-moved/+merge/98703
[20:41] <gatox> and this after i move it, doesn't have your approve
[20:41] <alecu> dobey, no. They are tried with the locally configured dns server, and they will in most cases just fail.
[20:42] <ralsina> gatox: ok, will look
[20:42] <alecu> dobey, most proxy servers only allow HTTP proxying, so there's no way to proxy those DNS queries anyway.
[20:42] <ralsina> gatox: I am merging that one manually so far
[20:42] <dobey> w. t. f.
[20:42] <gatox> ralsina, ok..... it's working.... i tested that one a lot!
[20:42] <ralsina> gatox: so did QA :-)
[20:43] <gatox> ralsina, even with py2exe
[20:43] <ralsina> dobey: that's how proxys work IRL
[20:43] <dobey> alecu: how is the dns query failing then? the gateway is blocking the DNS queries?
[20:44] <gatox> ok, bye!! if someone needs anything or my branches needs any further improves, please e-mail me
[20:44] <dobey> proxies are a problem looking for a problem to solve
[20:48] <alecu> dobey, the dns query fails, because it's done against the local dns server or /etc/hosts, and it returns no match for a SRV type query.
[20:48] <briancurtin> nessita: removed the add_to_autostart call from the wizard - it works fine, fix pushed
[20:48] <ralsina> alecu: I am giving you bug #963404
[20:48] <nessita> briancurtin: yey!
[20:48] <ralsina> alecu: it's important
[20:48] <nessita> briancurtin: you saw mandel's comments?
[20:49] <ralsina> nessita: "don't do a setUp for only one test" is such a crappy comment :-)
[20:49] <alecu> dobey, but I've discussed this with facundo, and we have agreed to make a list out of the default server conf option, that's used when that query fails.
[20:49] <dobey> alecu: local server you mean "server configured on the local network which is broken" here?
[20:49] <briancurtin> nessita: yeah i saw them, but i need the test to work that way. if i switch the order the patching happens too late
[20:50] <dobey> alecu: yes, i'm not arguing against that. we should probably do that anyway regardless of any proxy nonsense
[20:50] <alecu> dobey, either the dnsmasq running on localhost, or the dns server running in your corporate environ that can resolve internal addresses, but blocks resolving external addresses.
[20:50] <nessita> briancurtin: looking closer then
[20:50] <dobey> alecu: i'm just trying to understand how it can break like that
[20:50] <nessita> briancurtin: your patch makes perfect sense :-)
[20:50] <dobey> or rather, why you saw it break
[20:50] <nessita> briancurtin: you need that patch before the class creation, which is inside the super'ed setUp
[20:51] <briancurtin> yep
[20:51] <nessita> briancurtin: will approve now
[20:51] <nessita> briancurtin: argh, no, will not approved
[20:51] <nessita> briancurtin: I haven't run the suite yet, but I can see pep8 issues there
[20:51] <dobey> alecu: they way you said it in the meeting, and the way it's worded in your bug report, makes it seems like the dns queries are going through the proxy server, which sounds completely wrong
[20:51] <alecu> dobey, I run tests in a VM, and I have explicitly removed the default gateway from that VM route. The only ip reachable is the ip for a squid running on the host.
[20:51] <nessita> briancurtin: can you please grab a post-it and write DOCSTRINGS in it, and paste it near your monitor? :-D
[20:52] <briancurtin> nessita: haha, i will
[20:52] <nessita> thanks ;-)
[20:52] <briancurtin> i'll fix it now, 1'
[20:52] <nessita> sure
[20:53] <alecu> dobey, what part is worded wrong in the bug report?
[20:53] <ralsina> briancurtin: while pylint is hell on windows, pep8 works just fine and can even be ran manually ;-)
[20:55] <dobey> alecu: i'm not sure, which is why i'm asking about it, because i wasn't fully understanding what you were saying :)
[20:55] <alecu> dobey, does it make sense now after I've explained it yet again?
[20:55] <dobey> alecu: but it sounds like i should not think about it and just resolve to the fact that proxies are always broken
[20:56] <alecu> dobey, proxies are usually not broken. It's just some people not getting in the same mindset as them.
[20:56] <alecu> :-)
[20:56] <dobey> alecu: no, but probably not your fault. but the fault of bad sysadmins who intentionally break the network to use a proxy
[20:57] <briancurtin> nessita: docstrings added
[20:57] <nessita> briancurtin: yey!
[20:58] <alecu> dobey, most of the sysadmins I've met at medium sized companies are overwhelmed with real work, and setting up a proxy is something they do unwillingly, because users bother them just to check mail, and the sysadmin usually has a direct connection and don't care about proxies working "right".
[21:00] <ralsina> nessita: you get "foo" ? That can't be good :-)
[21:00] <nessita> ralsina: eh? where?
[21:01] <nessita> ah, you reading the emails?
[21:01] <nessita> ralsina: there's more to come
[21:01] <ralsina> nessita: the bug mail about "need more than 3 values" yes
[21:01] <nessita> ralsina: alecu and I found it, I added a final comment
[21:02] <alecu> nessita is awesome!
[21:04] <ralsina> hahaha saw the comment. I suppose that was a bit too fake.
[21:04] <ralsina> I will take a break and put a couple of hours late tonight
[21:04] <ralsina> so, if I don't see you, have a nice weekend all!
[21:04] <briancurtin> ralsina: i just updated with-icon whenever you have time later
[21:05] <ralsina> briancurtin: will check!
[21:05] <nessita> ralsina: you too\
[21:05] <ralsina> briancurtin: please check the diff and see you are not missing any &amp; on parameters
[21:05] <briancurtin> ralsina: have a good weekend
[21:05] <ralsina> briancurtin: I added one that was missing earlier o trunk
[21:05] <briancurtin> ralsina: yeah i made sure to include those in the merge
[21:05] <ralsina> briancurtin: cool, will review tonight
[21:05] <ralsina> briancurtin: re-approve windows-symlink, it bounced for no reason
[21:06] <ralsina> and... gone!
[21:21] <dobey> ok, need to roll. have a good weekend all!
[21:33] <nessita> ok, I'm gone have a great weekend everyone!
[21:33] <briancurtin> bye nessita
[21:33] <nessita> bye!
[23:26] <mandel> ralsina, is not a crappy comment!
[23:26] <mandel> and is because I'm lazy, I'm not blocking due to that, but due to the fact that the patch is done there, which is weird :)
[23:38] <alecu> EOW! bye peoples