[01:08] <ralsina> mmcc: ouch!
[01:10] <ralsina> mmcc: the worst part is that probably there is no other way to do it
[08:13] <mandel> morning all!
[08:34] <JamesTai1> Good morning all! :)
[09:38] <rye> ralsina: https://bugs.launchpad.net/ubuntuone-client/+bug/1061490
[10:35] <ralsina> rye: probably because of facundo's branch :-(
[10:35] <ralsina> rye: we'll take a look today
[10:40] <rye> ralsina: it applies to upload and download too
[10:41] <ralsina> rye: ack
[10:43] <ralsina> rye: that branch breaks the "recent transfers" menu because it makes the commands have no path
[10:43] <ralsina> rye: so I think we'll revert it. What was that fixing?
[10:45] <ralsina> or we need to get the path from the mdid.
[10:46] <ralsina> afk school run, will beback in an hour or so
[11:20] <gatox_> good morning
[11:20] <mandel> DiegoSarmentero, wtf?
[11:21] <mandel> gatox_, che, stop changing your nickname!
[11:21] <mandel> gatox_, morning! do you have a P machine?
[11:21] <gatox_> mandel, was trying..... it doesn't let me set gatox as my nickname
[11:22] <gatox_> mandel, P? nop
[11:22] <mandel> gatox_, do you have it registered? if you do, then just use ghost
[11:22] <gatox_> mandel, yes, i have it registered
[11:22] <mandel> gatox_, I need to see if the tests work ok in P after a change I made in sso to fix the broken proxy tests
[11:22] <mandel> gatox_, hen use ghost and kick out whatever is using it
[11:22] <mandel> s/hen/then
[11:33] <rye> under win8 the firewall settings we implant are not enough - the user is still asked to permit the access to the network
[11:48] <facundobatista> ralsina, rye, don't revert it, but get the path from mdid at init
[11:48] <facundobatista> (and update the path when it's being get now)
[11:48] <facundobatista> ralsina, rye, also, clearly is a missing test that my branch didn't break
[11:49] <facundobatista> ralsina, rye, I'll be more than happy to review this branch
[11:49] <facundobatista> btw, hola a todos!
[12:03]  * mandel is very disappointed with apt-get build-dep ubuntu-sso-client
[12:03] <facundobatista> ralsina, I can do the branch, but it'd need to wait to a freaky friday, and this friday I'm in sprint, so it's next one
[12:07] <gatox> mandel, question....... do we really know that connect_signal, to connect u1-cp to some signals from u1-client is actually working on windows and mac?
[12:08] <mandel> gatox, signals do work we have tests for that which do the entire dance, what is the problem you have?
[12:09] <gatox> mandel, i have a signal that i see how the data from u1-client arrives, but for some reason never call the actual function (the last callback in that series of callbacks) that is going to process that
[12:10] <mandel> gatox, may I see the code?
[12:11] <gatox> mandel, u1-cp and u1-client in trunk..... u1-cp: share_links file, line 88 is where the signal is being connected
[12:13]  * mandel looks
[12:16] <mandel> gatox, and this works on linux yet not in the others, right?
[12:16] <gatox> mandel, yap.....
[12:17] <gatox> mandel, i'm trying to find out why.......
[12:17] <gatox> mandel, it seems that the info is coming..... but in some part of the last processes... in wait_for_signals..... the proper callback is not called
[12:18] <mandel> gatox, I did find out why :)
[12:18] <gatox> mandel, please tell me!!!!!!
[12:18] <mandel> gatox, let me double check first :)
[12:18] <gatox> mandel, ack
[12:19] <mandel> gatox, lp:ubuntuone-client/ubuntuone/platform/ipc/perspective_broker.py => signal_mapping
[12:19] <mandel> gatox, PublicFilesList is not there
[12:20] <gatox> mandel, yes, and it says: 'PublicFilesList': ('public_files', 'on_public_files_list_cb'),
[12:20] <gatox> do you have u1-client up to date?
[12:20] <ralsina> good morning gatox,mandel
[12:20] <ralsina> facundobatista: ping?
[12:20] <gatox> ralsina, hi mister!
[12:21] <mandel> gatox, hm.. true
[12:21] <facundobatista> ralsina, pong
[12:21] <ralsina> facundobatista: your branch in u1-client breaks the sync menu
[12:22] <facundobatista> ralsina, did you read what I wrote? ^
[12:22] <ralsina> facundobatista: because it uses command.path
[12:22] <ralsina> facundobatista: oops, no, wil do
[12:22] <ralsina> facundobatista: ok, so I will do it
[12:22] <ralsina> facundobatista: is it evil if I make _get_current_path not private and use that?
[12:22] <facundobatista> ralsina, use it from __init__
[12:23] <ralsina> facundobatista: and set self.path and change nothing else
[12:23] <facundobatista> ralsina, I mean, why make it not private?
[12:23] <ralsina> facundobatista: to use command.get_current_path instead of command.path
[12:23] <facundobatista> ralsina, no, no, give the responsability of knowing the path to the command
[12:23] <ralsina> facundobatista: ok then, I think I got it
[12:24] <mandel> gatox, lets look in a diff place, what about ubuntuone/syncdaemon/interaction_interfaces.py
[12:24] <ralsina> if alecu is feeling better I am throwing it at him anyway ;-)
[12:24] <facundobatista> ralsina, just add         self.path = self._get_current_path(mdid)
[12:24] <facundobatista> ralsina, at the end of Upload's __init__
[12:25] <facundobatista> ralsina, and tests in the dbus/api part so it doesn't get broken again
[12:25] <mandel> gatox, we need to find where is the signal raised
[12:25] <ralsina> facundobatista: right
[12:25] <gatox> mandel, what about that... i added def get_public_files(self): in SyncdaemonPublicFiles
[12:26] <mandel> gatox, that is calling the action q event, which does not raise a signal, right?
[12:27] <gatox> mandel, that is executing GetPublicFiles
[12:27]  * gatox hates this endless list of calls
[12:27] <mandel> gatox, which then pushes and event to the event q, right?
[12:28] <gatox> mandel, yes
[12:28] <mandel> gatox, so, lets find what does the eventq do with that event :)
[12:28] <mandel> gatox, I'm talking outloud heheh
[12:29] <gatox> mandel, we can start there...... or we can start in the part where the signal started to being sent
[12:29] <gatox> because the first part of that work
[12:29] <mandel> gatox, ok, where is that?
[12:29] <gatox> mandel, just a sec....
[12:31] <gatox> mandel, i was able to track it until wait_for_signals in ubuntuone/platform/tools/__init__.py..... i see in the args var, the info i need...... and the _success_handler inner method is being called, but after that........ i assume d.callback should call the proper function, but that never happens, and i get lost at that point
[12:33] <mandel> ralsina, gatox, tested it on P and Q and tests do pass in both (proxy tests I mean)
[12:36] <mandel> gatox, we are looking at PublicFilesList signal, is that correct?
[12:36] <gatox> mandel, yes
[12:37] <gatox> mandel, because asking the public files is a 2 steps things....... you ask..... and the answer come in the signal
[12:38] <mandel> gatox, do you know if _success_handler is called (the callback defined inside wait_for_signals)
[12:39] <ralsina> mandel: awesome
[12:40] <gatox> mandel, yes, that's the part i know is being called...... and "args" contain the proper info...... but after that, i couldn't follow it anymore, not even with pdb
[12:40] <mandel> gatox,  ok :)
[12:41] <gatox> mandel, my tracking ends at d.callback(args)  inside _success_handler
[12:41] <mandel> gatox, the result of the signal, what is it?
[12:41] <mandel> gatox, a list, at thingy
[12:42] <gatox> mandel, a really big list of file info, if you share a lot of files
[12:42] <gatox> ralsina, do you know if alecu is ok?
[12:42] <ralsina> gatox: haven't heard since yesterday, when he was going to get checked
[12:42] <mandel> gatox, I find this funny => response, = yield d
[12:42] <ralsina> gatox: didn't want to call him too early
[12:43] <mandel> gatox, that comma, is there on purpose
[12:43] <ralsina> gatox: he asked for yesterday as a sick day late last night, didn't ask for today, so I am guessing he'll show up
[12:43] <gatox> mandel, where are you looking at?
[12:43] <mandel> ralsina, I was thinking the same, I though of sending him an sms at spanish noon, then I realize what time it was in BA
[12:43] <ralsina> mandel: yeah, bad idea :-)
[12:43] <ralsina> I'll ping him at 11AM and let you guys know
[12:44] <ralsina> hi ho, hi ho, off to the call I go
[12:44] <mandel> gatox, if you have a list and do result, = [first, second, last] you will get a value error
[12:44] <gatox> mandel, omg..... that comma
[12:44] <mandel> gatox, yest, that comma, what is it doing there?
[12:44] <mandel> gatox, have you started using vim? hehehehe
[12:45] <gatox> mandel, I DON'T KNOW
[12:45]  * gatox start hurting himself
[12:45] <mandel> gatox, that might then have a errback because you have inlinecallbacks and then everything might go who knows where :)
[12:46] <gatox> mandel, i'll test that now!
[12:46] <mandel> gatox, ok, let me know if it was that little bastard :)
[12:47] <gatox> mandel, if it is that...... is going to be the craziest bug..... that was killing me since tuesday
[12:47] <mandel> lol
[12:48] <mandel> ralsina, is not only the proxy tests that fail in Q, the following failure related to qt happens: http://paste.ubuntu.com/1259896/
[12:48] <mandel> ralsina, I did not dig more than I was supposed to (just fixed the proxy issue)
[12:49] <gatox> mandel, mmmmm that maybe was part of the problem..... but is not working yet....
[12:50] <mandel> gatox, well, we are moving ahead, what happens now?
[12:50] <gatox> the same
[12:52] <mandel> gatox, that would explain why you were not getting a value error, if you have result, = l where l is a list with more than one element you should get an unpack error
[12:52] <mandel> gatox, let me have lunch and we get deeper, ok?
[12:52] <gatox> mandel, yes...... i'll keep looking in the meanwhile
[12:52] <mandel> gatox, ok, that sounds great, can you do something also
[12:53] <mandel> gatox, when you do yield d
[12:53] <mandel> please add a try except to see if there was an error
[12:53] <gatox> mandel, ack, thx!
[12:53] <gatox> will try
[12:54] <mandel> gatox, remember that inlineCallbacks does a lot of magic, and will convert errbacks in exceptions
[12:55] <mandel> ralsina, FYI there have been updates in the PreviewState machine in the dash which means that we are a smaller hack atm
[12:55] <mandel> ralsina, will explain the last bug to them to see if we can get that fix and we are just as hacky as we were supposed to be :)
[13:00] <ralsina> mandel|lunch: ok, just don't break it because I keep telling people it's finished ;-)
[13:10] <mmcc> hi folks.
[13:11] <gatox> mmcc, hi
[13:25] <dobey> hmm
[13:27] <ralsina> hi mmcc
[13:27] <ralsina> mmcc: still reviewing your branch, I fell asleep last night :-)
[13:28] <mmcc> ralsina: cool. So did I!
[13:29] <ralsina> mmcc: code looks good, tests look good, running them on mac then +1ng
[13:30] <mmcc> ralsina: nice!
[13:31] <mmcc> btw, I just really for-real fixed bug 1056332 - my previous 'fix' stopped leaks but did not actually free anything, d'oh :(
[13:32] <ralsina> mmcc: well, leaking a fixed amount is just as good as not leaking ;-)
[13:33] <mmcc> ralsina: how about allocating and never freeing every single FSEvent object?
[13:33] <ralsina> mmcc: suboptimal!
[13:33] <ralsina> ;-)
[13:34] <mmcc> no kidding!
[13:34] <ralsina> facundobatista: just FYI adding the calls to _get_current_path in init breaks a bunch of tests where _get_current_path fails because there is no key for the mdid, so the branch is going to get a bit larger
[13:35] <facundobatista> ralsina, no problem
[13:36] <ralsina> facundobatista: also, some tests still were creating Up/Downloads passing paths
[13:36] <facundobatista> ralsina, oh, I missed them :(
[13:36] <ralsina> Estoy ahí de no hacer pie ;-)
[13:36] <ralsina> facundobatista: the good news is, this makes them all fail ;-)
[13:39] <ralsina> mmcc: +1 get a good second review though
[13:39] <mmcc> ralsina: thanks!
[13:43] <alecu> und... hello!
[13:43] <alecu> ralsina, gatox: pong!
[13:44] <gatox> alecu, hey! how are you?
[13:44] <alecu> gatox: I'm feeling great today :P
[13:44] <gatox> alecu, awesome!
[13:44] <alecu> gatox: I'm starting a bit late because I had a parent's meeting at kinder
[13:45] <gatox> alecu, we were worried
[13:45] <alecu> gatox: I felt really like crap on tuesday, and it turned up to be an arrhytmia. Which means that my heart was beating jungle-style.
[13:45] <gatox> alecu, :S
[13:46] <alecu> gatox: so I spent the tue morning in a hospital in Colonia. Then I got home late, and I spent wed doing some checkups in my local hospital.
[13:46] <alecu> gatox: anyway, I seem to be ok now. They still want to do some more exams on me....
[13:47] <gatox> alecu, you should..... don't play with those things
[13:47] <alecu> gatox: it was a bit scary yes. I hope this scares me enough to start doing some exercise besides boardgames and the arduino :P
[13:47] <gatox> :P jeje
[13:47] <ralsina> hola alecu!
[13:48] <dobey> sigh bug #951992
[13:48] <ralsina> alecu: you can do boardgames in a walking machine
[13:48] <alecu> hola there boss. I'm sorry I'm starting late, I had a parent's meeting at kinder
[13:48] <ralsina> alecu: just have to find a gym that has two face to face :-)
[13:48] <ralsina> alecu: or a little table between them
[13:48] <alecu> ralsina: and sweat-proof boards and cards
[13:49] <ralsina> alecu: gloves
[13:49] <alecu> ralsina: I guess that using gloves in a walking machine is a recipe for dehydration
[13:50] <ralsina> alecu: hmmm... good? ;-)
[13:50] <dobey> mandel|lunch: this works on both precise and quantal?
[13:50] <ralsina> alecu: in any case, I am doing a u1-client branch, I may have to bother you and or dump it on you later
[13:50] <alecu> ralsina: sounds great!
[13:50] <ralsina> alecu: I *think* I have it under control, but it's not exacty my forte
[13:50] <alecu> ralsina, gatox, anything else I can help with?
[13:53] <mmcc> alecu, do you feel like a quick review of a mac branch?
[13:53] <mmcc> this one: https://code.launchpad.net/~mikemc/ubuntuone-control-panel/catch-quit/+merge/127605
[13:54] <alecu> mmcc: sure!
[13:56] <alecu> mmcc: btw: how did you solve the issue with the quit signal being sent after the reactor was stopped?
[13:57] <mmcc> alecu, I avoided it. this menu trick lets me catch the quit event without hooking into the reactor
[13:58] <alecu> mmcc: awesome then!
[13:59] <gatox> brb........... need to reboot
[14:03] <mmcc> be back in a bit, need to feed a kid (my own)
[14:03] <mandel> dobey, yes, it does
[14:04] <mandel> dobey, at least, tests pass in both
[14:07] <dobey> mandel: great
[14:08] <dobey> ralsina: can you review it please? https://code.launchpad.net/~mandel/ubuntu-sso-client/fix-proxy-q/+merge/127995
[14:10] <mandel> gatox, have you gone further in the bug hunt?
[14:10] <ralsina> dobey: sure
[14:10] <chaselivingston> mmcc: what do you think about adding that script i made to your shared folder so testers have an easier time of getting logs?
[14:10] <gatox> mandel, nop..... i'm testing some stuff on mac now
[14:11] <ralsina> If you guys ever feel our software stack is precarious, at least remember we are not doing this for a living: http://www.youtube.com/watch?v=4MiYtvbK4JY&feature=player_embedded
[14:11] <mandel> gatox, let me know when you want to get back to it
[14:11] <gatox> mandel, yes..... i don't want to bother you too much...... but will ping you when necessary :P
[14:11] <gatox> thx!
[14:13] <gatox> ralsina, jeje that looks like a lot of fun!
[14:13] <ralsina> gatox: to me *doing* it looks like a lot of work and a chance to get bonked in the head. Designing it does look like a lot of fun though ;-)
[14:14] <mandel> ralsina, our ipc feels that way
[14:15] <gatox> jeje
[14:15] <ralsina> mandel: with 75% less axes
[14:16] <mandel> and 75% more naked men
[14:16] <dobey> ralsina: i don't know, if it pays well enough, building a bunch of rube goldberg machines for a living doesn't seem so bad. :)
[14:16] <ralsina> mandel: we are supposed to be dressed while working.
[14:16] <ralsina> dobey: yes, but enough about our work! ;-)
[14:16] <mandel> ralsina, there is a reason why we use mumble
[14:17] <gatox> LOL
[14:17]  * ralsina sends patch to the employee handbook
[14:17] <ralsina> damn running tests on u1cp takes a while on ubuntu now, too
[14:18] <dobey> yes :(
[14:18] <dobey> tests == slow
[14:18] <ralsina> just the action_queue tests take about 25 minutes
[14:18] <ralsina> darned slow disk I have
[14:18] <dobey> also, lol at people who try raid5 and then are like "omg this sucks what did i do, how can i undo and keep my data?!"
[14:19] <ralsina> dobey: haha, raid5 doesn't suck *that* much,it's just about 20% slower on writes :-)
[14:20] <ralsina> I once had a custmer that asked for a setup of software raid5 with non-homogeneous disks
[14:20] <ralsina> turns out one disk was *really* slow, so performance went to the basement, but that's a corner case
[14:20] <dobey> ralsina: well, it sucks if you have no idea what you're doing, which is the only explanation for asking "how do i un-raid my raid  without buying more disks to store the data?"
[14:21] <ralsina> well, ye
[14:21] <ralsina> if they were willing to buy disks they would not go raid5
[14:21] <grammoboy> I guess its possible to use ubuntu one in ubuntu vbox, right?
[14:21] <ralsina> grammoboy: sure
[14:21] <grammoboy> there doesn't seem to exist a package for debian unfortunately
[14:22] <grammoboy> so Debian users should use dropbox I guess :/
[14:22] <grammoboy> hm
[14:22] <dobey> well, raid5 or 6 is probably the only two you'd use if you ever wanted to add more disks to the array at a later time
[14:22] <grammoboy> and osx?
[14:22] <ralsina> grammoboy: we are working on a osx version
[14:22] <grammoboy> ralsina, any idea when it will be released?
[14:22] <ralsina> grammoboy: "soon"
[14:23] <grammoboy> ralsina, why not a debian version
[14:23] <ralsina> grammoboy: sorry but am not allowed to give dates :-)
[14:23] <dobey> grammoboy: we aren't directly in debian, but you could probably add our stable PPA sources to the appropriately matched version of debian to what that version of ubuntu is based on, and install the packages
[14:23] <grammoboy> which is better, dropbox or ubuntu one?
[14:23] <grammoboy> ...
[14:23] <dobey> grammoboy: even if we supported debian, there's basically no way we could actually support any version of debian outside of unstable or experimental
[14:24] <ralsina> grammoboy: well, we develop ubuntu one, would it surprise you if we tell you ubuntu one? ;-)
[14:24]  * grammoboy /join #drobox
[14:24] <grammoboy> *dropbox
[14:24] <grammoboy> they say dropbox
[14:25] <grammoboy> ok my friends are making accounts for dropbox right now
[14:25] <grammoboy> am I a fool if I ask to open a ubuntu one account instead
[14:26] <grammoboy> in term in functionality, stability on windows, mobile etc?
[14:26] <dobey> why would you let someone else make your decisions?
[14:26] <grammoboy> is a question making someone else a decision?
[14:27] <grammoboy> that strange reasoning
[14:27] <grammoboy> don't get me wrong, I'll make that decision
[14:27] <dobey> you're asking ubuntu one developers to tell you which service to choose. we're going to tell you ubuntu one, obviously
[14:27] <grammoboy> but you probably now how well ubuntu one is working
[14:28] <dobey> but i mean, you shouldn't let your friends decide which service you should use; you should decide yourself
[14:28] <dobey> u1 works fine
[14:31] <chaselivingston> hi grammoboy: i'm w/ user support for u1, i'd be glad to chat w/ you privately if you have any questions about the service
[14:32] <grammoboy> no thanks :)
[14:35] <grammoboy> I'm more for a public debate :)
[14:35] <grammoboy> it irritates me a bit that dropbox can be used on Debian and Ubuntu One not, but alas
[14:35] <dobey> you can use ubuntu one on debian
[14:36] <grammoboy> tell me where I can find the Debian packages
[14:36] <grammoboy> please
[14:36] <ralsina> grammoboy: we are here to develop the software and to assist users, public debate is not really our thing.
[14:36] <ralsina> grammoboy: which debian version?
[14:36] <grammoboy> squeeze
[14:36] <grammoboy> testing
[14:37] <grammoboy> *err
[14:37] <dobey> grammoboy: lack of official packages does not mean you cannot use it on debian. the clients are open source. you are free to install them
[14:37] <grammoboy> you probably know that it's bad practice to install Ubuntu packages on Debian
[14:40] <grammoboy> https://www.dropbox.com/install?os=lnx
[14:40] <grammoboy> they can do it
[14:41] <ralsina> grammoboy: sorry to ask this, but what exactly do you expect to hear? "Sorry I have been hiding these Debian packages, here you have them"?
[14:42] <dobey> that's great
[14:42] <ralsina> grammoboy: currently, if you want to use ubuntu one on Debian, the recommended way is to install the ubuntu packages.
[14:42] <dobey> dropbox doesn't really support debian. they provide the same deb for both debian and ubuntu; and they install their own versions of everything in a private directory
[14:44] <grammoboy> anyway, it would be nice if you would provide debian packages in the future
[14:46] <dobey> you are more than welcome to package ubuntu one for debian.
[14:46] <dobey> as i said before, it is open source
[14:47] <grammoboy> that's it's open source is a good thing
[14:47] <grammoboy> anyway, need to go
[14:47] <grammoboy> ciao
[14:48] <chaselivingston> well that was interesting
[14:48] <dobey> i think he was trying to troll us
[14:48] <dobey> but he didn't attend Berkeley in the 60s, so doomed from the start
[14:49] <ralsina> "but all my friends are using dropbox!"
[14:51] <chaselivingston> haha
[14:52] <ralsina> I was going to use the "if all your friends jumped off a bridge" move but I am saving it for my son.
[14:53] <chaselivingston> i feel like he was probably about 13
[14:54] <mmcc> That reminds me of an idea I had when I wanted to experiment with machine learning - train a classifier to learn people's age and use it to filter out Hacker News posts by anyone under a certain age…
[14:55] <mmcc> instead I trained myself to just not read Hacker News any more, that's going really well
[14:56] <mandel> gatox, please => https://code.launchpad.net/~mandel/ubuntu-sso-client/fix-proxy-q/+merge/127995
[14:56] <gatox> on it
[14:57] <briancurtin> are we doing a mumble call?
[14:57] <chaselivingston> mmcc: see my previous comment above while you were gone ^^^
[14:57] <ralsina> yes, mumble today
[14:57] <mandel> chaselivingston, ralsina, I was going for the : 'don't let your friends choose your gf, you will get the ugly one'
[14:57] <mandel> but I was late :-*(
[14:57] <chaselivingston> haha
[14:57] <mmcc> oh chaselivingston, right - saw it, sounds like a good idea.
[14:57] <chaselivingston> mmcc: you can download it at http://people.canonical.com/~chaselivingston/scripts/mac-logs.dmg
[14:58] <mandel> so, mumble, right?
[14:58] <dobey> oh right, thursday
[15:00] <mmcc> chaselivingston: added it, thanks
[15:00] <ralsina> FUUUUUUUUUUUUUU
[15:01] <ralsina> trying to fix the mic, just a sec
[15:02] <chaselivingston> mmcc: cool, np\
[15:02] <ralsina> alecu: mumble
[15:04] <dobey> mmcc: are you deaf or mute?
[15:04] <mmcc> dobey both!
[15:04] <mandel> ralsina, you have to fix the mike!
[15:04] <mandel> hehehehehehe
[15:05] <mmcc> ok, working now
[15:21] <gatox> mandel, i have some test failing here: https://code.launchpad.net/~mandel/ubuntu-sso-client/fix-proxy-q/+merge/127995
[15:23] <mandel> gatox, running the tests in my q works..
[15:23] <mandel> wtf!
[15:23] <gatox> mandel, you know....... "the universe of gatox's machine"
[15:24] <gatox> mandel, did you do a clean install?? i did an upgrade
[15:25] <mandel> gatox, I upgraded
[15:27] <mandel> gatox, there is another bug
[15:28] <gatox> mandel, qt version here: 4.8.3.... if it helps you in something
[15:28] <mandel> gatox, can you run the tests from trunk and tell me if test_ssl_fail is ran?
[15:28] <gatox> mandel, yap..... let me run the tests
[15:30] <gatox> mandel, i get this for trunk: http://paste.ubuntu.com/1260156/
[15:32] <mandel> gatox, that is normal
[15:32] <mandel> dobey, did you ran the tests in q?
[15:32] <dobey> gatox: the proxy tests pass for me in quantal in mandel's branch
[15:33] <mandel> so is gatox machine yet again...
[15:33] <dobey> gatox: i do get that first failure in your paste though
[15:33] <gatox> my machine just say: muejejeje
[15:33] <dobey> hahaha
[15:34] <gatox> mandel, let me know if i can do "anything" from here
[15:35] <joshuahoover> ralsina, dobey: so users who upgrade from 12.04 to 12.10 get u1 uninstalled?
[15:35] <mandel> gatox, well, it does not make bloody sense for the to fail
[15:35] <dobey> joshuahoover: no; the icon disappears from the unity launcher, for the currently logged-in user
[15:35] <dobey> mandel: hahahah, bueno
[15:35] <ralsina> joshuahoover: what dobey said. It even keeps working.
[15:35] <joshuahoover> dobey: ah, and the workaround is for users is?
[15:36] <joshuahoover> that almost made sense
[15:36] <ralsina> joshuahoover: open control panel and pin it to the launcher
[15:36] <briancurtin> ralsina: speaking of holidays, im going to enter a swap day for monday (columbus day)
[15:36] <dobey> joshuahoover: run it from the dash, right-click on the icon in the launcher, and pin it
[15:36] <gatox> mandel, this is what i did: bzr branch........ cd...... ./run-tests
[15:36] <ralsina> briancurtin: go ahead
[15:36] <joshuahoover> ralsina, dobey: k, thanks...i'll make sure this gets in the release notes and we add an faq for it
[15:36] <mandel> gatox, can you add a pdb in where it fails and tell be what is self.name and the value of proxy
[15:36] <mandel> gatox, is in the _set_proxy method
[15:37] <gatox> mandel, ok..... i'll do that..... give me a sec
[15:37] <ralsina> joshuahoover: sorry we didn't catch this in time for a fix, but Q has been such a moving target we only started updating our real boxes these last two weeks :-(
[15:37] <joshuahoover> ralsina: yeah, i know...lots of moving parts this release
[15:37] <gatox> mmcc, question..... are you creating the package for mac today?? so i know how much time i have to test the part of the signal thing.... or move to the workaround
[15:38] <dobey> ralsina: even for people already running q, it would have happened for them during an apt-get update, when we dropped the installer package
[15:38] <mmcc> gatox: yes I am creating it today. you can post a branch somewhere any time today, I'll probably do the package at the end of the day
[15:38] <ralsina> gatox, mmcc: I would like it if mmcc does it today before his EOD so it's in place tomorrow eary
[15:38] <ralsina> early
[15:39] <dobey> gatox, mandel: i do keep seeing this error now though: http://pastebin.ubuntu.com/1260172/
[15:39] <gatox> ralsina, mmcc ack..... i'll have a really quick lunch...... and if i don't figure it out what's going on in a couple of minutes more..... i'll move to the other solution
[15:39] <mandel> dobey, yes, that happens here to and I mentioned to ralsina already
[15:40] <mandel> dobey, I hope gatox has a better idea than me on that code, I've never touched the overlay code
[15:41] <dobey> it's also a bit weird that i am now seeing 2 overlays when starting cp
[15:41] <ralsina> dobey: that has been happening for a while
[15:41] <mmcc> dobey: I've been seeing that for a while now
[15:41] <dobey> ah
[15:43] <mmcc> I think it's related to the fix for the race to get credentials a while back. now some code that used to fail fast is waiting.
[15:44] <mmcc> but I'm not sure, since I can't explain quickly why it used to fail fast then eventually show the username most of the time anyway :)
[15:49] <ralsina> alecu, facundobatista: reviews please https://code.launchpad.net/~ralsina/ubuntuone-client/el-sendero-de-warren-sanchez/+merge/128049
[15:49] <alecu> ralsina: looking
[15:49] <mmcc> briancurtin: I'm curious about the exe finding problems you're having. I'm suspicious of how we're adding 'python' in ubuntu_sso.utils.get_bin_cmd and potentially also adding 'python.exe' in the qt runner.
[15:49] <gatox> ralsina, jeje why warren sanchez?
[15:50] <ralsina> gatox: the problem is with paths. Path is sendero. "El sendero de warren sanchez" is awesome :-)
[15:50] <gatox> jejeje
[15:50] <mmcc> also briancurtin I'm wondering why you tweeted about WPIAL last weekend.
[15:51] <briancurtin> mmcc: im going to try the trunk installer shortly and see if theres any issues there. from source it seems that at least part of the system is working, because i can see in U1CP when it gets the CredentialsError that SSO raised it, so they are communicating
[15:51] <gatox> mandel, this is crazy..... if i do ./run-tests the tests from webclient fails....... if i do: u1trial ubuntu_sso/utils/webclient everything works....... ideas?
[15:51]  * gatox is not having a great week
[15:51] <mmcc> briancurtin: right. remember that SSO backend and the SSO gui are two different executable paths to find though…
[15:52] <mandel> gatox, this in ubuntu, right?
[15:52] <gatox> mandel, yes
[15:52] <gatox> Q
[15:52] <mandel> QQQQQQrazy!
[15:52] <briancurtin> mmcc: ha! i went to st. vincent college out in latrobe and was in town for our alumni baseball game. i was staying with a buddy up in chippewa on friday, then in latrobe on saturday. we caught the news friday night or saturday morning and it was like 20 minutes straight of football coverage
[15:52] <dobey> ralsina: i'm poking dx about fixing the unity bug
[15:52] <mandel> gatox, hm.. can you check the reactor that is used?
[15:53] <mandel> ralsina, great branches names and they even have some logic behind them!
[15:53] <mmcc> briancurtin: hey, small world. I grew up in Murrysville.
[15:53] <dobey> what was the bug # for the u1 disappears on upgrade to q issue?
[15:54] <briancurtin> mmcc: what i've been doing is start ubuntu-sso-login, ubuntuone-syncdaemon, then ubuntuone-control-panel-qt -- this is the last way i knew it to work. i have also sometimes additionally started "ubuntu-sso-login-qt --app_name 'Ubuntu One' --login_only" (before U1CP)
[15:56] <ralsina> dobey: awesome!
[15:56] <ralsina> mandel: thanks!
[15:56] <mmcc> briancurtin: so, you're starting all those manually, like in separate terminals? yikes. ideally you just start ubuntuone-control-panel-qt and as long as SSO is in your PYTHONPATH it should figure its paths out… I thought I had it working that way, but obviously it wasn't thoroughly tested :)
[15:56] <briancurtin> mmcc: let me try that again. i know that should work, but i end up liking different terminals to see the logging separately
[15:57] <mmcc> but it should still work if you start them separately too…
[15:57] <dobey> ralsina: was there a bug # for that?
[15:57] <mmcc> yeah, makes sense
[15:57] <ralsina> dobey: not AFAIK
[15:59] <briancurtin> mmcc: ah yeah, when you start u1cp and let it take care of everything else, "No module named dirspec.utils"...which reminds me of the pkg_resources issue, which just seemed to have gone away
[16:01] <mmcc> briancurtin: ah right, that reminds me that there is a ton of manual PYTHONPATH setting when I run things from source
[16:01] <mmcc> for example, running controlpanel for mac: U1_DEBUG=1 PYTHONPATH=$PYTHONPATH:.:../dirspec:../ubuntuone-client:../ubuntu-sso-client/:../ubuntuone-storage-protocol:../ubuntuone-fsevents-daemon/python:../python-macfsevents/build/lib.macosx-10.7-x86_64-2.7/ python bin/ubuntuone-control-panel-qt
[16:01] <mmcc> note that dirspec is on there. I guess I didn't put it in the pre-set path for the buildout-generated python
[16:02] <mmcc> I'm going to feel bad if you've been fighting something I just left out of the buildout and didn't document well enough :\
[16:03] <mmcc> huh, weird. the current buildout does put dirspec and dev-tools in the generated path
[16:03] <briancurtin> i'll fiddle around there and see what's up. i added dirspec and devtools manually to the sys.path in bin/python-script.py since they come from source and not eggs
[16:04] <briancurtin> really? i thought i had to add mine manually
[16:04] <mmcc> well, that's a change I made recently when I tried to improve the buildout
[16:05] <briancurtin> mmcc: is that in trunk? i just set this machine up fresh two weeks ago and had to append the paths to dirspec and devtools checkouts, since i thought we never figured out how to get buildout to add a bzr checkout to the path, only eggs
[16:05] <mmcc> it should be… checking
[16:06] <dobey> ralsina: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1061715
[16:06] <briancurtin> i noticed that the buildout.cfg had seen a good bit of changes. maybe its just windows specific that it didnt do anything fancy with dirspec/devtools
[16:06] <mmcc> yeah, it was merged on august 17
[16:07] <mmcc> the new thing is that instead of putting the paths in the python script it generates, it creates a 'development' directory next to parts/ and there's a site.py in there
[16:07] <dobey> gatox: can we get mandel's fix-proxy-q branch approved please? did you figure out why the tests failed for you? were you not actually running in his branch?
[16:07] <mandel> dobey, we are atm trying to find out why..
[16:08] <briancurtin> mmcc: ah, so you're working inside of that parts folder then?
[16:08] <mandel> any one with a q machine to run them?
[16:08] <mmcc> briancurtin so, bin/python should just put devsetup/development on the path, and devsetup/development/site.py has the code that adds the eggs and devtools and dirspec…
[16:08] <dobey> mandel: i ran them in the tarmac instance, where i duplicated the issue several times, and your branch passes there
[16:08] <dobey> mandel: are they failing for gatox on mac or something?
[16:09] <mmcc> briancurtin: yes - maybe there's a step missing. what does your directory structure look like?
[16:09] <mandel> apparently he is running an Q machine
[16:09] <mandel> dobey, ^
[16:10] <mmcc> briancurtin: when buildout does the 'sourcedeps' step, it should put dirspec, devtools and storage-protocol in parts/ , and the generated bin/python script should be able to see them without manually setting pythonpath
[16:10] <gatox> hey! not apparently.....
[16:11] <briancurtin> mmcc: i should probably start using this stuff the right way given these changes :) i do all of the buildout steps, then i created a "working" folder where i put all of my branches and whatnot. so i'm in C:\u1\working\ubuntu-sso-login-blah-branch when i should be in c:\u1\parts\development\ubuntu-sso-login-blah-branch
[16:11] <gatox> dobey, mandel approved..... something weird is happening though
[16:11] <briancurtin> that worked in the old revisions, i just didnt bring my setup up to speed. i'll set this up again and see what happens
[16:11] <gatox> tough
[16:12] <dobey> gatox: not tough
[16:12] <dobey> gatox: but thanks. i am wondering about that a=2/b=1 failure though
[16:12] <gatox> dobey, not tough
[16:13] <gatox> dobey, yes..... i'm going to take a look at that a little bit later.... i'm moving on with the mac/windows fix now, so i can propose that and let mmcc create the packages
[16:14] <mmcc> briancurtin: yeah, I only ever tested it with the code inside the buildout devsetup/parts/ directory
[16:14]  * gatox reboot and lunch...... brb!
[16:14] <mmcc> briancurtin: it just means you have to remember to set TRIAL_TEMP_DIR to something short so the tests work
[16:15] <mmcc> briancurtin: so I'm not sure exactly how but I suspect this might explain the issues you've been having
[16:15] <briancurtin> mmcc: i'll give it a shot, thanks for the help
[16:17] <briancurtin> ralsina, alecu: see #twisted-python3?
[16:17] <mmcc> briancurtin: sure. just to be clear - the devsetup/development/ directory is just for site.py (and buildout's 'develop' eggs, but we don't use them) -- the branches you're working on go in path-to-buildout/scripts/devsetup/parts/<branchname>
[16:18] <mmcc> at least, that's where buildout puts them when you use the bazaarrecipeinfrae recipe
[16:18]  * mmcc shakes head at people naming things
[16:24] <ralsina> briancurtin: saw it now, no idea
[16:25] <mandel> ok, EOD here, I'll try to land things tom (fingers crossed)
[16:25] <dobey> sigh, missing stuffs; and i need to get lunch
[16:25] <dobey> bbiab
[16:25] <ralsina> dobey: http://pastebin.ubuntu.com/1260260/
[16:26] <dobey> ralsina: no idea, they work for nightlies PPA. i'll hop over there after lunch
[16:27] <ralsina> dobey: cool
[16:41] <facundobatista> ralsina, half of these docstrings are wrong:
[16:41] <facundobatista> +        """All Downloads must have a path."""
[16:47] <ralsina> facundobatista: oh, right
[16:48] <ralsina> facundobatista: fixing now
copy paste y u no do what I mean!!!!</khan>
[16:50] <ralsina> facundobatista: pushed the fixed docstrings, thanks!
[17:51] <dobey> ralsina: https://code.launchpad.net/~dobey/ubuntu-sso-client/update-4-0/+merge/128080 please ?
[17:53] <facundobatista> ralsina, https://pastebin.canonical.com/75923/
[17:56] <alecu> hey all, I need to run some errands and then head off to kinder.
[17:56] <alecu> I'll be back later and working a bit more tonight.
[17:57] <mmcc> interesting, so we don't currently handle dropped events in linux either… AFAICT, IN_Q_OVERFLOW just gets logged, but should probably trigger a rescan or something, right?
[17:58] <mmcc> (I was looking to see what I should generate when we get dropped events in darwin, and I saw that.)
[18:06] <ralsina> dobey: got it
[18:06] <ralsina> facundobatista: looking...
[18:07] <ralsina> facundobatista: never got around to running those tests I guess :-(
[18:07] <ralsina> facundobatista: was that the only one that failed?
[18:07] <mmcc> dobey, is the plan for ubuntuone-client-data to eventually replace the contents of (eg.) ubuntuone-control-panel/data ?
[18:08] <mmcc> I ask because I have an icon.png that lisette wants to use for the mac menubar icon and I'm wondering where the right place to put it is
[18:08] <dobey> mmcc: not entirely. but it's to have a place to store common pieces of data that we use in multiple places
[18:08] <facundobatista> ralsina, didn't you do "make test"?
[18:08] <dobey> mmcc: yeah, we need to put that in ubuntuone-client-data. i guess i need to help with that though
[18:08] <ralsina> facundobatista: I did, but after 45 minutes I stopped looking :-(
[18:09] <facundobatista> ralsina, well, you just need to look when they finish
[18:09] <dobey> mmcc: when do we need to do that by?
[18:09] <ralsina> facundobatista: ha, I know, will run the whole thing now
[18:10] <ralsina> facundobatista: just wondering if you had so I didn't have to wait two hours before fixing these
[18:10] <mmcc> dobey: well, it'd be nice to include it before the beta release next week, but I can always just replace it for my build and make a note to do it right later
[18:11] <dobey> mmcc: ok, i think we can do it for that beta build next week. i was just worried we had to do it today; am a bit tied up at the moment with rushing for ubuntu release and such :)
[18:11] <facundobatista> ralsina, just those errors
[18:11] <ralsina> facundobatista: awesome
[18:12] <mmcc> dobey: no, doesn't have to be today.
[18:12] <facundobatista> ralsina, it takes 2 hours to run make test for you?
[18:12] <ralsina> facundobatista: my notebook with slow disk really sucks for u1-client development. And yes, it takes ~2 hours
[18:12] <ralsina> facundobatista: just action queue tests take over 25 minutes
[18:12] <facundobatista> Ran 2782 tests in 862.843s
[18:12] <facundobatista> ralsina, you need to get better hardware
[18:13] <dobey> even on crappy hardware, it shouldn't take 2 hours to run u1client tests
[18:13] <ralsina> facundobatista: it's just the slow disk, and it used to run in line 20 minutes a year ago
[18:13] <dobey> hell, 862 seconds is too long
[18:13] <dobey> ralsina: slow disk? what is it a 5.25" drive from 1987?
[18:13] <mmcc> ralsina: I wonder if you're running into something like what I see with the client tests: it opens too many files at once and starts erroring out on darwin. maybe on linux it just gets slow
[18:14] <ralsina> dobey: a 2.5" from 2010
[18:14] <mmcc> I'm referring to https://bugs.launchpad.net/ubuntuone-client/+bug/1037433
[18:14] <ralsina> mmcc: could be but I get no errors, just a ton of HD access
[18:14] <dobey> ralsina: it doesn't take that long to run the tests on my dell duo, and it's a freakin' atom with a slow disk
[18:14] <ralsina> dobey: don't know the
[18:14] <ralsina> n
[18:14] <ralsina> dobey: this is a i5 with 4GB of RAM
[18:15] <dobey> ralsina: i do know something is not right with the u1client tests though. they are using WAY TOO MUCH RAM in tarmac even
[18:15] <ralsina> although I have the desktop here, but still has about 2.5GB free
[18:16] <mmcc> I'd like to suggest we try fixing the tests soon - maybe after the cycle is over? The cilent tests have never been completely run on darwin AFAIK, and that makes me nervous
[18:16] <ralsina> Since I hardly ever do u1-client branches, I usually don't notice
[18:16] <dobey> mmcc: yeah, we need to do a lot of work on our tests i think
[18:16] <ralsina> mmcc: well, we can start fixing them on darwin at any time ;-)
[18:16] <dobey> ralsina: well, i run the tests a lot, since i do the releases, and i run the tests whenever i make a release. although i usually do that on workstation
[18:17] <mmcc> ralsina: it's not a particular test that fails, it's just around the ~500th that gets run, in whatever order
[18:17] <ralsina> dobey: yes, I usually check with the other reviewer for the test suite check and just do code review and/or IRL testing
[18:17] <dobey> ralsina: we can fix them everywhere at any time; we are in cherry-picking mode for stable-4-0
[18:17] <mmcc> it's a systemic problem. I think it's hitting a resource limit that we either need to just raise or avoid. probably no good reason to run 500 tests concurrently anyway
[18:17] <mmcc> (on darwin)
[18:17] <ralsina> mmcc: we don't run them concurrently, that has to be a resource leak
[18:18] <dobey> there's a reason we make the stable branches at the beginning of the cycles now :)
[18:18] <ralsina> dobey: yeah. BTW: it has worked quite nicely this cycle, too! :-)
[18:20] <mmcc> ralsina: yes, leak sounds correct. I'm running it now, and it's at 79 threads
[18:20] <ralsina> mmcc: that's insane
[18:20] <mmcc> now 95. threads are getting created about one per test case, from what I can tell
[18:20] <dobey> wtf
[18:20] <mmcc> tons of unclean reactor problems too
[18:20] <ralsina> mmcc: we had that on linux like a year ago
[18:21] <mmcc> now 280!
[18:21] <dobey> qtreactor issue?
[18:21] <ralsina> mmcc: yes, you are never shutting down the threads
[18:21] <ralsina> dobey: the u1-client tests don't use qtreactor, do they?
[18:22] <ralsina> facundobatista: pushed fix for that test, so feel free to run make check again
[18:23] <dobey> ralsina: they do on mac, no?
[18:24] <ralsina> dobey: not sure, at least for u1-client
[18:24] <mmcc> aw crap. I just saw cmd-q getting caught, killing syncdaemon, stopping the reactor and then zombie qt just hung around.
[18:24] <mmcc> I'm not happy with qtreactor
[18:24] <dobey> oh, no. plain twisted is the default
[18:24] <ralsina> dobey: twisted reactor
[18:25] <ralsina> dobey: in fact, the suites that use qtreactor work!
[18:25] <mmcc> yes, and run-mac-tests uses --reactor=twisted
[18:25] <dobey> heh
[18:25] <ralsina> (probably unrelated, should not be considered an endorsement of qtreactor)
[18:25] <dobey> u1client tests are definitely too slow though
[18:26] <ralsina> I remember some "robustness" changes mandel did that slowed them down but not this much, and not on ubuntu.
[18:26] <dobey> can someone please review https://code.launchpad.net/~dobey/ubuntu-sso-client/update-4-0/+merge/128080 asap?
[18:27] <ralsina> dobey: I am
[18:27] <dobey> thanks
[18:27] <mmcc> dobey, that appears not to have the second quoted change
[18:27] <ralsina> dobey: but, you know, running tests ;-)
[18:27] <dobey> mmcc: really?
[18:28] <mmcc> dobey: yeah, the commit msg says it includes my change to run-mac-tests, but I don't see it in the diff.
[18:28] <dobey> mmcc: ah, doh. it's already merged into stable-4-0, that one is
[18:28] <mmcc> aha
[18:28] <dobey> mmcc: i updated the commit msg
[18:28] <dobey> mmcc: thanks for catching that :)
[18:28] <mmcc> dobey: no prob
[18:29] <ralsina> dobey: other than that, +1, works and everything
[18:29] <dobey> great
[18:29] <mmcc> yeah, looks fine.
[18:29] <mmcc> ralsina, do you remember the other day we were looking at how qtreactor creates its own event loop? any idea why it does that instead of just calling QApplication.exec()?
[18:29] <dobey> man, maybe i've just been telling myself these tests aren't really that slow
[18:30] <mmcc> dobey, I get the impression you often have many things going at once. maybe you just don't notice? :)
[18:30] <dobey> they are *still* running, on my workstation
[18:30] <mmcc> or maybe it's the RAID
[18:30] <ralsina> mmcc: let me check the code, I think I know
[18:30] <dobey> mmcc: probably, i'm usually quite busy
[18:30] <ralsina> dobey: see?
[18:31] <dobey> mmcc: not the RAID. the big raid is on my server. haven't got on on workstation yet
[18:31] <mmcc> heh. was kidding anyway :) RAAAAAID
[18:31]  * ralsina may sneak a SSD into his letter to santa
[18:31] <mmcc> ralsina: do it, that stuff is great stuff
[18:32] <ralsina> mmcc: I still miss my Asus eee 701's 4GB SSD :-)
[18:32] <ralsina> mmcc: I had it cold booting in 6 seconds
[18:32] <mmcc> that's not enough gigabytes
[18:32] <dobey> Ran 2778 tests in 759.960s
[18:33] <dobey> that's on my workstation; core i7 3770S, 16GB RAM, and slow-ish disks (5400 RPM i think)
[18:33] <dobey> but they are still SATA III or II at least, so not all that slow
[18:33] <ralsina> mmcc: I had my whole PyQt dev setup + sysadmin toolkit and still had 1.2GB free. Plenty of room to type :-)
[18:33] <dobey> and over 10 minutes for that is insane
[18:33] <mmcc> ralsina, nice! I remember using RAM disks on old macs to speed rebooting. loved that stuff
[18:34] <dobey> anyway, brb. gotta run for a few
[18:34] <mmcc> whoa, I googled ram disk and people are really still advocating that for OS X (!) such a bad idea
[18:35] <ralsina> mmcc: well, if it's all contiguous, in the fast side of a slow disk... ;-)
[18:36] <mmcc> ralsina: I don't follow
[18:36] <ralsina> mmcc: qtreactor it uses its own event loop because it interleaves stuff
[18:36] <ralsina> mmcc: if it used exec_() then the twisted deferreds would never get triggered
[18:36] <ralsina> mmcc: so it does X msecs of Qt stuff, then twisted, and loops
[18:37] <mmcc> ralsina: that all makes sense, except that if you let it create the qapplication for you (by not creating it before you import reactor), it'll call exec_() on the qapplication it created… (see line 262
[18:37] <ralsina> then again, it does that via a timer, so why the heck not use a timer in QApp's event loop? Dunno.
[18:37] <ralsina> yeah
[18:38] <ralsina> mmcc: now there's a nice experiment to try, just delete half that if
[18:38] <ralsina> and use QCoreApplication.instance.exec_()
[18:39]  * mmcc testing
[18:39] <ralsina> heck, without that, it's just a class to interleave things called by a timer
[18:43] <mmcc> yeah, that change makes no noticeable difference in the app's behavior
[18:48] <ralsina> pffft
[18:49] <ralsina> so basically that code does nothing, except break cmd-q ;-)
[18:51] <gatox> mmcc, ping
[18:52] <mmcc> ralsina: It only sort of tangentially breaks cmd-q. it definitely breaks the aboutToQuit signal though
[18:52] <mmcc> hi gatox , what up?
[18:52] <gatox> mmcc, do you know if there is a bug for the shares tab not working on mac
[18:52] <gatox> ?
[18:53] <mmcc> yes
[18:53] <mmcc> gatox, it is bug https://bugs.launchpad.net/ubuntuone-control-panel/+bug/1044012
[18:53] <chaselivingston> mmcc: will that be fixed before the public beta?
[18:54] <mmcc> chaselivingston: the shares tab? it should be - gatox is working on it now
[18:54] <chaselivingston> mmcc: awesome
[18:54] <chaselivingston> mmcc: just wanted to make sure i didn't need to create an faq about it not working
[18:55] <gatox> mmcc, awesome, thx! i was going to propose a branch for that
[18:55] <gatox> was not...... i'm going to
[18:57] <chaselivingston> mmcc: when is a final build going to qa before the release?
[18:57] <mmcc> chaselivingston: EOD today, QA will look at it SOD tomorrow, in like 10 hours or something
[18:57] <chaselivingston> mmcc: ok, will that build also make it in your shared folder?
[18:58] <mmcc> there's a meeting scheduled in 17 hours from now I think
[18:58] <mmcc> yes it will
[18:58] <chaselivingston> mmcc: but we're waiting tip the 11th to release it? or are you planning on making changes between qa's feedback and the 11th?
[19:00] <mmcc> chaselivingston: I expect there will probably be some bugs to fix after they have at it. I expect there'll be some changes
[19:01] <chaselivingston> mmcc: ok cool, i suspect i'll be involved with the publicity and such once it releases, so just making sure i understand the process
[19:02] <mmcc> chaselivingston: oh, if you want to understand the process, you should not be asking me
[19:02] <chaselivingston> mmcc: haha, well that's basically what i need to know for right now
[19:02] <mmcc> ok, cool
[19:05] <dobey> back
[19:06] <dobey> hrmm
[19:08] <dobey> i'm going to need to install front panel audio connectors to my workstation it seems
[19:10] <gatox> dobey, why?
[19:12] <ralsina> chaselivingston: as long as nothing critical appears in QA, this is it
[19:12] <chaselivingston> ralsina: ok cool, good to know
[19:13] <ralsina> we may cheat and fix bugs for which we are very confident they don't break other things but we really shouldn't
[19:13] <ralsina> mmcc: you are building from stable-4 branch, not trunk, right?
[19:13] <dobey> gatox: moving the speakers off my desk, so the headphone port will be too far away; and my rack mount case doesn't have front panel audio connections already
[19:13] <mmcc> ralsina: I'm not currently, but I will for QA
[19:14] <ralsina> mmcc: ack
[19:14] <dobey> it does however, have 3 LAN LEDs, since it's meant to be used for a server of some sort. but my motherboard has no LAN LED connections
[19:15] <ralsina> dobey: hobby project opportunity! ;-)
[19:16] <dobey> ralsina: one of millions i have :)
[19:21] <dobey> hrmm, of course, it also moves the volume controls further from me, which is not great
[19:23] <ralsina> dobey: I have a set of speakers with a "remote-in-a-cable" which works well
[19:23] <ralsina> even if it feels and looks like something out of the 70
[19:23] <ralsina> s
[19:26] <dobey> i have a set of 2.1 speakers with a remove volume control with a headphone output as well, but they are fidgity and i don't use them any more. i'm using a set of lower end studio monitors now, with a built-in amp. might need to get a rack mount amp instead, and a different set of monitors that require an amp
[19:27] <dobey> like the yamahas which are pretty nice, but also $$$$
[19:30]  * mmcc still rockin' these $7 GE "computer speakers". The trick is not to ever compare them to anything that sounds good!
[19:33] <ralsina> mmcc, dobey: I have a 2.1 which has way too much bass (or way too little treble, your call) but hey, it makes "beep" very nicely
[19:33] <ralsina> also, my notebook has the worst speakers of any computer in the history of computing, and I can prove it in the sprint
[19:51] <gatox> mmcc, ping
[19:51] <gatox> mmcc, can you please show me again the line i should comment to avoid endless tests in u1-cp?
[19:54] <briancurtin> mmcc: if you have a minute, mini buildout-related review https://code.launchpad.net/~brian.curtin/ubuntu-sso-client/run-tests-update/+merge/128098
[19:54] <gatox> does anyone know which is the line inn u1-cp that need to be commented in order to run tests on mac?
[19:54] <mmcc> gatox, http://paste.ubuntu.com/1260689/
[19:54] <gatox> mmcc, awesome! thanks
[19:55] <mmcc> briancurtin: I'll take a look
[19:57] <dobey> oops. accidentally just deleted my quantal-base.tar.gz
[19:57] <dobey> whee
[19:57] <dobey> but sso package is uploaded now
[19:57] <dobey> so that's done at least
[20:00] <ralsina> dobey: cool, so officially the Q cycle is over for us. Modulo emergencies, bugs, packaging fixes, of course :-)
[20:01] <briancurtin> come on comtypes, why wont you just import. i know you want to
[20:02] <briancurtin> perfect timing - an article about Dropbox using comtypes just appeared on HN
[20:03] <dobey> right
[20:10] <mmcc> I skimmed that article - man, writing about programming and calling COM "black magic" and comtypes a "mysterious witch doctor service"…
[20:10] <ralsina> mmcc: hahaha
[20:10] <briancurtin> i need to write more blog posts
[20:10] <ralsina> "floats, a useful data type, or science playing god? Your call!"
[20:11] <mmcc> time to trot this one out again: "I'll often drop down to node.js if I really need to be close to the metal"
[20:12] <briancurtin> i want to setup a twitter bot to just post that every hour
[20:12] <mmcc> briancurtin: I want to kickstarter a series of t-shirt designs based on that theme
[20:12] <ralsina> mmcc: where "the metal" means "my braces" and "close" means "apply car battery"
[20:13] <mmcc> there, ralsina has already done the first design
[20:14] <ralsina> whoa, that dropbox blog post is the most condescending writing I have seen in a long time that was not written by me.
[20:14] <briancurtin> hm, maybe i should actually read this post then
[20:14] <dobey> ralsina: you must reclaim your throne
[20:14] <ralsina> briancurtin: it's actually useful stuff, but the tone is amazing
[20:15] <dobey> ralsina: it's almost like i wrote it?
[20:15] <ralsina> dobey: CLOSE!
[20:15] <dobey> not condascending enough?
[20:16] <ralsina> "Today, I’ll be writing about a module that few Python users have even heard of before—comtypes. "
[20:16] <dobey> haha
[20:16] <ralsina> dobey: you fake it better
[20:16] <briancurtin> that was a great way to start off
[20:17] <ralsina> " the use of strange ritual equipment like MIDL compilers"
[20:17] <briancurtin> 180k downloads on sourceforge. no one's ever heard of it
[20:17] <ralsina> "what is this compiler tool witchery you describe,white man?"
[20:17] <ralsina> (may not be an actual comment)
[20:18] <mmcc> so briancurtin, that branch runs the tests just fine, but er, I'm getting some failures with mandel's recent proxy change in trunk… do the tests pass for you?
[20:19] <briancurtin> mmcc: they don't pass, but they didn't pass before for me either...or maybe that was u1client. let me check
[20:24] <briancurtin> mmcc: eh, i dont have an easy way to go back to the old way without recreating my old broken environment now that i trashed it, but yeah, some tests were failing before
[20:24] <ralsina> mmcc: LINT
[20:25] <mmcc> found further down on the dropbox blog, a nicely detailed post about a password strength estimator based on entropy, etc -- see https://github.com/lowe/zxcvbn
[20:25] <mmcc> ralsina: ?
[20:25] <ralsina> mmcc: your branch bounced because of lint
[20:25] <ralsina> mmcc https://code.launchpad.net/~mikemc/ubuntuone-control-panel/catch-quit/+merge/127605
[20:26] <mmcc> ralsina: ok, thanks. didn't get an email yet…
[20:26] <ralsina> mmcc: I have planned to implement the guitar hero password scheme in a week or two
[20:26] <ralsina> mmcc: this one, just in case there is more than one http://www.geekosystem.com/guitar-hero-password-system/ :-)
[20:28] <mmcc> cool
[20:40] <mmcc> gatox, did you mean to link this old merge https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/tab-shares/+merge/120445 to the bug about darwin?
[20:40] <mmcc> er, the bug about the shares tab not working on darwin?
[20:41] <gatox> mmcc, ohhhhhhh i already have a branch with that name..... crap
[20:41] <gatox> i did a push without noticing that
[20:41] <mmcc> woops :) been there
[20:41] <gatox> i'll create a new branch
[20:42] <ralsina> EOD for me
[20:42] <mmcc> wait ralsina, just a sec…
[20:42] <gatox> mmcc, i'm trying to fix a problem with a patch for a thread i'm having..... and i'll be ready to propose the branch
[20:42] <ralsina> mmcc: waiting
[20:43] <gatox> woops..... if everyone is eod..... who is going to review this?
[20:43] <mmcc> ralsina when do I need to be around for this QA run tomorrow? it's a tad early for me…
[20:43] <ralsina> gatox: ok, I will
[20:43] <ralsina> mmcc: vila will start it early
[20:43] <ralsina> vila: he's probably going to be finished by the time we start
[20:43] <ralsina> oops, that was for mmcc of course
[20:43] <gatox> ralsina, i have everything working..... but just a problem with 3 tests.... because the start of Qthread is not being patched before execution
[20:44] <ralsina> so, we start the day, read the good news, and do a high five, I guess
[20:44] <ralsina> gatox: so, the branch is good IRL but tests fail?
[20:44] <mmcc> ok, cool. I'll just start as early as I can. good news - if I keep coughing up lungs like last night, I'll be up at 4AM again!
[20:44] <gatox> ralsina, only 3 tests........ need to find the proper way to patch this, and everything will be ok
[20:45] <ralsina> gatox: well, mmcc can merge it manually into the release even if the tests fail
[20:45] <ralsina> gatox: that way we also test it's actually working well for QA too
[20:45] <ralsina> mmcc: now you have two small pep8 failures
[20:46] <gatox> ralsina, let's do this..... i'll propose the branch now so you can review it...... and keep working on this 3 tests..... so you can leave.... and ask mmcc for a review when the 3 tests are ok
[20:46] <ralsina> ./ubuntuone/controlpanel/gui/qt/main/tests/test_main.py:319:1: W391 blank line at end of file
[20:46] <ralsina> ./ubuntuone/controlpanel/gui/qt/main/tests/test_main.py:319:1: W293 blank line contains whitespace
[20:46] <dobey> why does nobody sell a front panel audio cable. bah
[20:46] <gatox> ralsina, do you agree?
[20:46] <ralsina> gatox: sounds good
[20:46] <mmcc> gatox: fine by me
[20:46] <mmcc> ralsina: thanks, d'oh
[20:49] <gatox> ralsina, https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/shares-broken/+merge/128108
[20:51] <dobey> i guess i'll have to make my own cable
[20:52] <ralsina> gatox: looking
[20:52] <gatox> ralsina, i created the bug to fix that problem in the api also..... it's in the description
[20:53] <ralsina> gatox: the reason to have to do a returnResult instead of a yield could be a missing inineCallbacks
[20:53] <ralsina> or something calling the function directly instead of yielding it
[20:54] <ralsina> I would ping alecu about it, or mandel
[20:54] <gatox> ralsina, but that's not the api problem..... the thing is that we don't know why the data is there..... that function shouldn't return anything
[20:55] <gatox> but for some reason the data is coming that way, and not in the signal
[20:55] <ralsina> hmmm
[20:55] <ralsina> sounds like fu
[20:55] <ralsina> n
[20:55] <gatox> ralsina, pufffffff.... a lot
[21:03] <alecu> gatox: can I be of help?
[21:04] <gatox> alecu, about the api problem?
[21:04] <gatox> the patching thing i almost have it
[21:05] <alecu> gatox: don't know what the api problem is... do you want to tell me about it?
[21:05] <gatox> there....... tests fixed
[21:06] <gatox> alecu, could we have a mumble tomorrow about that?? now that the tests are fixed, i'm about to eod-ing..... and my brain is not in its best shape at this moment :P
[21:06] <alecu> gatox: surely yes!
[21:06] <alecu> gatox: ping me when you see me.
[21:06] <gatox> alecu, awesome...... let me know as soon as you have some time...... i'll be working on this
[21:06] <gatox> alecu, ack
[21:10] <ralsina> gatox, mmcc: that branch looks good to me but I can't run it on mac nor windows right now
[21:11] <ralsina> so, a lame +1 from me
[21:11] <gatox> mmcc, this one is ready for review, this fix the shares tab not working on windows and mac..... i've run the tests on linux, windows and mac and everything is green....... it's a little change, i'm not happy about, but we can have this to be tested for the release and keep fixing the api problem later (i've created a bug for the api problem as you can see in the description and i'll be working on that): https://code.launchpad.net/~diegosarme
[21:11] <gatox> ntero/ubuntuone-control-panel/shares-broken/+merge/128108
[21:11] <gatox> ralsina, there   ^ ........ my comments
[21:11] <mmcc> gatox, ok, looking
[21:11] <gatox> mmcc, https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/shares-broken/+merge/128108
[21:11] <gatox> mmcc, ouch..... i left the commented code for mac there...... removing that
[21:12] <dobey> hmm
[21:13] <gatox> mmcc, done
[21:17] <gatox> mmcc, let me know when the review is done, if i need to change something or don't.... and then i'll be eod-ing
[21:18] <mmcc> ok gatox, thanks. I'll try to be fast
[21:18] <gatox> mmcc, no problem..... take your time
[21:32] <ralsina> now, really EOD. See you guys tomorrow
[21:33] <gatox> ralsina, bye!
[21:34] <dobey> i'm off too. later all!
[21:34] <gatox> dobey, bye mister
[21:34] <dobey> heh
[21:43] <mmcc> gatox, testing IRL I get a traceback: http://paste.ubuntu.com/1260888/ -- the first line of that paste is the output of a log I added to just print publicfiles at the beginning of _load_public_files
[21:44] <mmcc> looks like it's getting a dict, but expecting a list of dicts
[21:44] <gatox> mmcc, mmmmmmm.....
[21:45] <gatox> mmcc, just a sec
[21:46] <mmcc> gatox, the last line of get_public_files , why is it calling _load_public_files(result[0]) ? result is the list of dicts that _load_public_files wants, it looks like
[21:46] <mmcc> yes, if I change that result[0] to result, it looks like it's workign much better
[21:46] <gatox> mmcc, just a sec
[21:47] <mmcc> yes, it works, and hey, it's really pretty nice! (this is the first time I've seen this feature)
[21:47] <mmcc> and, here's the shared picture I found with your search: http://ubuntuone.com/7carFI0DvBy3GwdYCAKO3K
[21:48] <gatox> mmcc, this is really weird..... it was working here.... let me check one thing
[21:48] <mmcc> er, while testing your search field :)
[21:48] <mmcc> ok, take your time
[21:48] <gatox> ahhhhh i know what the problem is..... the other thing that we find out with mandel today
[21:49] <gatox> i need to propose a really small branch for u1-client
[21:50] <gatox> mmcc, yes...... in a sec you will see what the problem was :P
[21:51] <gatox> mmcc, you need this branch for u1-client: https://code.launchpad.net/~diegosarmentero/ubuntuone-client/crazy-comma/+merge/128122
[21:52] <gatox> briancurtin, are you still here?
[21:52] <briancurtin> gatox: yep, whats up
[21:52] <gatox> briancurtin, can you review this ridiculous small branch? https://code.launchpad.net/~diegosarmentero/ubuntuone-client/crazy-comma/+merge/128122
[21:52] <gatox> and you too mmcc
[21:52] <mmccphone> Hey, my laptop had a kernel panic there. Be back on soon
[21:52] <gatox> that's all we need
[21:53] <briancurtin> gatox: approved. i hate single item tuple issues like that sometimes
[21:53] <gatox> briancurtin, yap
[21:53] <gatox> briancurtin, awesome! thx
[21:56] <gatox> mmcc, brian already approve it: https://code.launchpad.net/~diegosarmentero/ubuntuone-client/crazy-comma/+merge/128122
[21:57] <mmcc> still recovering from kernel panic… what does that fix?
[21:57] <gatox> mmcc, luckily you irl test it
[21:57] <gatox> mmcc, the problem you were having with the control panel.... that was changing the return value
[21:57] <mmcc> ah, ok, so we need both changes then?
[21:57] <gatox> mmcc, yes
[21:58] <gatox> mmcc, and now i really need to leave..... shower + cine
[21:58] <mmcc> alright, looks like it'll work. thanks for sticking around
[21:58] <gatox> but that's all...... re-branch it here..... and test it irl and it works
[21:59] <gatox> mmcc, no problem..... the release is important :D
[21:59] <gatox> mmcc, ok..... see you tomorrow!
[22:04] <mmcc> hrm, that function was not the only one to have that ocmma
[22:04] <mmcc> comma
[22:05] <mmcc> every other function in that file that calls wait_for_signals unpacks a tuple like that
[22:06] <mmcc> argh
[22:12] <mmcc> brb
[23:13] <mmcc> for point of reference, my 12.04 VM running on my macbook air (with SSD) took 227 seconds to run the u1-client tests just now
[23:22] <mmcc> So, that client branch with the comma seems to be unnecessary. It's not inconsistent, there are other places in that file that unpack their signal result before returning it, so I don't want to change one without understanding whether or not they should all change
[23:22] <mmcc> and if I just remove the [0] in the code that calls it, that works fine, and keeps the changes confined to one branch, which makes my life easier :)
[23:23] <mmcc> so -1 on the client crazy comma branch, and I'm going to have to split soon. Will get a new built app up right away if possible…
[23:23] <mmcc> if not, will have to do it after dinner