[08:29] <JamesTait> Happy Monday, all! :-D
[10:27]  * mandel reboots due to updates
[11:13] <gatox> good morning
[11:34] <mandel> gatox, morning!
[11:34] <gatox> mandel, hi, how are you?
[11:35] <mandel> gatox, fine.. although I'm getting tired of the unity trunk breaking and having to fix it every morning :-/
[11:36] <gatox> mandel, :S
[11:48] <mandel> gatox, how are you doing?
[11:48] <gatox> mandel, fine..... setting my mac up to date to start fixing stuff there
[11:49] <mandel> gatox, ouch
[12:09] <alecu> hello, all!
[12:09] <gatox> alecu, hi mister
[12:09] <mandel> alecu, morning!
[12:44] <ralsina> good morning!
[12:45] <alecu> hi there, boss!
[12:45] <gatox> ralsina, hi
[12:48] <ralsina> hello gatox, alecu
[12:50] <mandel> ralsina, morning!
[12:50] <mandel> not related, but time for lunch :)
[12:55] <nessita> gatox: would you know why when clicking on the U1 icon in the messaging menu the controlpanel is not opened?
[12:56] <gatox> nessita, checking.....
[12:56] <nessita> gatox: this is precise up to date with nightlies
[12:57] <nessita> gatox: my wild and uneducated guess is that the U1 icon still points to the inexistent u1-installer
[12:57] <gatox> nessita, let me upgrade and check
[12:59] <gatox> nessita, no.... no working here neither.... could you please file a bug for that?
[12:59] <gatox> nessita, if alecu agrees, you can assign that to me
[13:01] <nessita> ack
[13:01] <gatox> nessita, thx!
[13:02] <nessita> alecu, gatox: bug #1059571
[13:03] <dobey> eh?
[13:03] <gatox> nessita, thx
[13:03] <gatox> alecu, do you want me to take that bug?
[13:04] <alecu> gatox: sure, go ahead. But I think the darwin release takes priority.
[13:04] <dobey> ah
[13:04] <gatox> alecu, yes
[13:04] <dobey> gatox: i'll fix it
[13:05] <gatox> dobey, ok
[13:05] <gatox> nessita, dobey is going to fix that
[13:07] <nessita> gatox, dobey: thanks!
[13:38] <dobey> nessita, gatox, alecu: https://code.launchpad.net/~dobey/ubuntuone-client/fix-msg-menu/+merge/127280
[13:39] <gatox> dobey, on it
[13:47] <gatox> mmcc, ping
[13:58] <gatox> is someone currently working on mac?? i'm trying to reset the buildout, because i expect that several things change..... but i can get it to work
[14:07] <alecu> gatox: how are you doing it?
[14:08] <gatox> alecu, following the document
[14:08] <alecu> gatox: have you updated the brew too?
[14:09] <gatox> alecu, no.... i started from the buildout section
[14:09] <alecu> dobey: +1
[14:09] <gatox> but now..... pyqt is not being recognize....... so i think i will need to install everything again
[14:09] <alecu> gatox: perhaps you may want to try that too. I don't recall if it's in the document.
[14:09] <gatox> maybe with some of the updates i lost things
[14:09] <alecu> gatox: SO updates?
[14:09] <mandel> ralsina, 1-1 when ever you want
[14:09] <gatox> alecu, yes
[14:10] <alecu> i mean... OS updates :-)
[14:10] <alecu> gatox: oh, ok.
[14:10] <alecu> gatox: anywaym, try updating the qt brew first, to see if that fixes it.
[14:11] <gatox> yes
[14:11] <alecu> gatox: qt, or pyqt, or everything
[14:11] <alecu> gatox: https://github.com/mxcl/homebrew/wiki/FAQ
[14:14] <alecu> Do you guys know how newspapers always get names wrong?
[14:15] <alecu> I was surprised this morning to see that the py3.3 news got Mr. Curtain's last name wrong, too! http://docs.python.org/py3k/whatsnew/3.3.html#pep-397-python-launcher-for-windows
[14:20] <ralsina> mandel: sorry, was on a call, let's try mumble
[14:20] <mandel> ralsina, ok, let me launch os x
[14:22] <ralsina> alecu: is Brian Curtain the french cousin?
[14:26] <briancurtin> ha, i'll have to correct that
[14:26] <mmcc> hi folks. gatox, can you tell me what exact error you're getting? you shouldn't have to re-install brew stuff, only the buildout changed
[14:28] <mmcc> Brian Curtain sounds like someone used voice transcription software to write release notes… not a bad idea, really. I wonder how well it'd work for IRC
[14:28] <gatox> mmcc, i've created a new branch for the buildout..... follow all the steps in the document..... but when trying to run the tests or execute something i keep getting some dependencies issues...... let me finish with the upgrade of the things.....and i will try again and copy the output
[14:30] <mmcc> gatox, ok. don't forget to 'source env-mac' , and it's important to do it while you're in the directory scripts/devsetup/
[14:30] <mmcc> e.g., if you're just in the top level of the buildout and you do 'source scripts/devsetup/env-mac', it won't work
[14:31] <gatox> mmcc, ack
[14:31] <gatox> maybe was that
[14:51] <mandel> agh! I need to restart for the updates to take effect..
[14:55] <gatox> mmcc, i'm having a problem with the qtreactor when trying to run the tests as the document says..... let me paste the output
[14:55] <mmcc> ok, so it looks like bug 1056332 is still an issue, despite having plugged the memory leaks.  ralsina or gatox, I could use help on bug 1049973 -- I'm writing an email with what I know about that now
[14:56] <mmcc> ok gatox, I'll brb and then take a look
[14:56] <gatox> mmcc, ack, thx
[14:58] <gatox_mac> mmcc, http://paste.ubuntu.com/1254010/
[15:00] <mandel> me
[15:00] <gatox> me
[15:00] <briancurtin> me
[15:01] <dobey> me
[15:01] <ralsina> me
[15:01] <ralsina> mmcc: ?
[15:01] <ralsina> alecu: ?
[15:02] <ralsina> mandel: go!
[15:02] <mandel> DONE: Splitted preview branch to have two other branches it depends one, one for the text entry an otherone for the action link. Discovered unity trunk does not longer build in my syste :-/
[15:02] <mandel> TODO: Get unity back to compile in my system. Add some ui tests.
[15:02] <mandel> BLOCKED: trunk failing...
[15:02] <mandel> gatox, please
[15:02] <alecu> me
[15:02] <gatox> DONE:
[15:02] <gatox> Fixed and landed the u1-cp branches. Start setting up the environment to work on mac.
[15:02] <gatox> TODO:
[15:02] <gatox> Finish with the mac env setup and get it working.
[15:02] <gatox> BLOCKED:
[15:02] <gatox> With the mac env setup (working on that).
[15:02] <gatox> briancurtin, go
[15:03] <briancurtin> DONE: outside of my half-day and the team call, i just poked around debugging the U1CP issue with pkg_resources on windows
[15:03] <briancurtin> TODO: get windows IRL working
[15:03] <briancurtin> NOTE: i'm going to the john hunter memorial service in a few minutes. not sure how long it'll take but im trying to work it as a long lunch, and i'll stick around later today
[15:03] <briancurtin> NEXT: dobey
[15:03] <dobey> DONE: team meeting, reviews, bug triage, bug fixes
[15:03] <dobey> TODO: 4.0.0 releases
[15:03] <dobey> BLCK: None
[15:03] <dobey> ralsina: go
[15:03] <ralsina> DONE: calls, calls, reviews, then some calls, then some reviews. TODO: get into mac gear. Also call and reviews. BLOCKED: no NEXT: alecu
[15:03] <gatox> ralsina, i see a pattern in your tasks :P
[15:04] <ralsina> gatox: oh yes
[15:04] <ralsina> gatox: never get into management kid, your ears will fall off.
[15:04] <gatox> jejejje
[15:04] <alecu> DONE: json fixes for dash payments
[15:04] <alecu> TODO: get protobuf 3 changes merged upstream, get lens work merged
[15:04] <alecu> BLOCKED: no
[15:04] <mmcc> DONE: poking at quit bug, fsevents daemon mem usage. some reviews
[15:04] <mmcc> TODO: same
[15:04] <mmcc> BLOCK: quit bug: need expert qt help
[15:05] <alecu> mmcc: what's the problem with the quit bug?
[15:06] <mmcc> alecu. I think it's actually a couple of bugs, but one is that the system quit event doesn't seem to be sent to the places we expect.
[15:07] <mmcc> we register a qaction for cmd-q, but that doesn't fire, and our QApplication subclass doesn't seem to get the aboutToQuit signal
[15:08] <mmcc> so the overall issue is that we're not doing the right cleanup when the user quits. and I'm hoping that it's related to the bug where sometimes it hangs during quit and doens't actually go away
[15:10] <mmcc> gatox, qt4reactor should be in the eggs/ directory in your buildout. can you paste what's in scripts/devsetup/eggs ?
[15:10] <gatox> mmcc, yes...... let me do that
[15:12] <gatox_mac> mmcc, http://paste.ubuntu.com/1254045/
[15:12] <gatox> mmcc, is not there..... can i just install it in the system..... or it should be included in the buildout for the other things to work?
[15:14] <mmcc> gatox: weird. I wouldn't install it in the system. let's just get your buildout working. try this: go to scripts/devsetup and run 'bin/buildout install development'
[15:15] <mmcc> btw gatox, can you also show what's in scripts/devsetup/parts ? if it had a problem with downloading the sourcedeps (devtools, storageprotocol, and dirspec), then it might have skipped the 'development' part, which comes after sourcedeps
[15:16] <mmcc> and qt4reactor is in development but isn't a dependency for anything else, so that'd explain this
[15:18] <gatox_mac> mmcc, i just executed sudo ./bin/buildout install development…. everything was ok with that…. in the parts i have: http://paste.ubuntu.com/1254057/
[15:19] <mmcc> gatox_mac: you don't need sudo.
[15:20] <gatox_mac> mmcc, in my case yes…. or it says permission denied
[15:21] <mmcc> gatox_mac: you really shouldn't need it. where are you installing this?
[15:22] <gatox_mac> mmcc, /Users/gatox/canonical/build-env…. that's ubuntuone-windows-installer
[15:22] <mmcc> gatox_mac: did you do the initial bootstrap.py --distribute with sudo too?
[15:24] <mmcc> everything under the buildout directory should be owned by your user, but if you start out with sudo, the stuff it writes will probably have the wrong permissions
[15:24] <gatox> mmcc, nop.... the distribute was without sudo
[15:26] <mmcc> gatox, well, if you've got some permissions set wrong, the easiest thing to do is just blow it up and start over from a new branch of ubuntuone-windows-installer
[15:26] <gatox> mmcc, ok.... i'll do that
[15:26] <mmcc> no sudo this time, and let me know where you run into problems that seem to require it
[15:27] <gatox> mmcc, ack
[15:32] <dobey> gatox: were you also looking at https://code.launchpad.net/~dobey/ubuntuone-client/fix-msg-menu/+merge/127280 btw? :)
[15:32] <gatox> dobey, ah yes! and it has a failure that is not in trunk when i run the tests
[15:33] <gatox> dobey, let me run the tests again just in case
[15:37] <gatox> mmcc, now is working.... it seems that if i execute the things like: ./bin/buildout install....... it requires sudo in my case..... but if i do: bin/buildout install doesn't
[15:39] <mmcc> gatox: what does it say when you do the first one?
[15:39] <dobey> ralsina, alecu: https://code.launchpad.net/~dobey/ubuntuone-client/disable-inhibit/+merge/127311 if you please. it disables the use of the inhibit code for now
[15:39] <gatox> mmcc, permission denied something.......  i don't have the message right now...... i can retry that later if you want..... now i'm following the steps that work
[15:40] <ralsina> dobey: got it
[15:40] <ralsina> dobey: who should be made aware of the root issue?
[15:43] <mmcc> gatox: ok, sure. I don't need you to retry it.
[15:43] <mmcc> but if it's in scrollback, I'd like to see it, because I don't like not knowing :)
[15:44] <dobey> ralsina: i know what the root issue is, and discussed it with alecu earlier. but the proper fix to make it work is too large to do for the final release today i think. we can sru it though probably
[15:44] <ralsina> dobey: awesome
[15:48] <dobey> and need to take lunch break now. bbiab
[15:48] <alecu> dobey: when you get back, please check the change on ubuntuone/platform/session/__init__.py
[15:48] <ralsina> dobey: line 53 of the diff, extra space
[15:48] <alecu> ralsina: exactly
[15:48]  * alecu gets some lunch, and runs some errands too.
[15:48] <mmcc> still writing this email explaining what I know about the quit bug(s). If we're lucky, by the time I'm done writing this I'll understand how to fix it
[15:49] <gatox> mmcc, is working now!! awesome!! :D (i'm going to add 2 missing steps in the document)
[15:49] <dobey> ralsina: ah good catch, thanks. fixed that. originally from comment I added there, but it broke tests too badly :)
[15:50] <dobey> ok, really off to lunch now
[15:50] <mmcc> gatox: great.
[15:52]  * ralsina vows to someday get some style checking in u1-client
[15:53] <gatox> ralsina, hey! once i propose a branch that fix all the pep8 issues in that branch........ but because pep8 is not being executed with the tests..... it gets dirty again
[15:54] <ralsina> gatox: let's try again in november :-)
[15:54] <ralsina> gatox: and this time we add it to the test run
[15:54] <gatox> ralsina, yap..... we can also try autopep8
[15:55] <ralsina> gatox: I saw the other day a script that pep8-fies automatically is it that one?
[15:55] <gatox> ralsina, i don't know..... this is the one i know
[15:55]  * gatox plans to integrate that with a particular ide :P
[15:56] <gatox> wow........ u1-cp in mac are really slow :S
[15:56] <gatox> u1-cp tests i mean
[16:01] <ralsina> dobey: +1
[16:03] <mmcc> gatox: you need this patch or the control panel tests will never finish: http://paste.ubuntu.com/1254147/
[16:04] <gatox> mmcc, jejeje good to know....... it was ridiculous  long jeje
[16:04] <mmcc> gatox: yeah, sorry about that. just added it to the doc
[16:05] <gatox> ralsina, mmcc, but at least it work now..... i was planning to start looking why the shares tab is not working there..... or do you have in mind any other task that has more priority?
[16:06] <ralsina> gatox: that's a very good one
[16:06] <gatox> ralsina, great
[16:06] <mmcc> gatox: I'll let ralsina make that decision, but I was definitely hoping you'd look at the shares tab, since that's your stuff
[16:06] <ralsina> mmcc: unless one of the critical bugs is out of hand?
[16:06] <gatox> shares tab it is!
[16:06] <mmcc> ralsina: the quit bug! but I'm going to er, bug you about that one
[16:06] <ralsina> mmcc: happy to be bugged :-)
[16:06] <gatox> ok......... mac is upgrading..... and really slowly....... i'll have lunch now......
[16:21] <mmcc> ralsina: I just sent an email to you guys with my notes. I probably could've written more but I wanted to get it out sooner. Let me know if anything doesn't make sense.
[16:21] <mmcc> also, I have to take an early lunch now, hopefully that syncs up OK with you guys…
[16:43] <mandel> EOD, see you all tom!
[16:45] <gatox> mandel, bye
[16:45] <gatox> ok........ NOW is time to lunch
[16:51] <ralsina> mmcc: I think I know where the problem with *one* of those thigns is :-)
[16:52] <ralsina> mmcc: replied with the little bit I am guessing
[16:54] <ralsina> mmcc: at least that one is easy to try
[17:08] <ralsina> briancurtin: I scheduled a windows QA session for the 9th to see where we stand on windows
[17:08] <dobey> hrmm, maybe i should just land these branches with 1 review
[17:10] <ralsina> dobey: any  one I can review?
[17:11] <dobey> ralsina: https://code.launchpad.net/~dobey/ubuntuone-client/fix-msg-menu/+merge/127280
[17:12] <ralsina> dobey: I can do that one in about 80 minutes :-/
[17:12] <ralsina> dobey: so I trust you about merging it if that's too late
[17:14] <ralsina> and now lunch!
[17:43] <gatox> brb
[17:50] <mmcc> ralsina: your suggestion to use app-wide context doesn't change anything for me :\ I did this:   self.quit_action.setShortcutContext(3) , (3 is the value of the enum for the app-wide context )
[17:50] <mmcc> note that cmd-W DOES call the method I set with quit_action, but cmd-Q does not.
[17:50] <mmcc> so it's handling cmd-q differently
[17:55] <gatox> back
[17:59] <mmcc> gatox, what were the missing steps in the buildout that you were going to add?
[18:00] <gatox> mmcc, already there..... about the files inside u1-client/windows.... and that you need to build some projects as u1-storage-protocol by your own
[18:01] <mmcc> gatox: ah, ok
[18:18] <mmcc> so, if you create your own QApplication outside of qtreactor, qtreactor will call exec_() on a Qeventloop it creates instead of the qapplication.
[18:20] <mmcc> is quit getting sent to that event loop instead of my application? or something like that
[18:22] <dobey> gatox: what test did you see a failure on that wasn't in trunk?
[18:22] <gatox> dobey, ah sorry.... i forgot about that console...... i'll paste the error..... it fails again
[18:22] <gatox> dobey, http://paste.ubuntu.com/1254458/
[18:23] <dobey> gatox: hrmm, actually that does happen in trunk
[18:24] <gatox> dobey, i'll mark it as need fixing and copy that in the merge too
[18:24] <dobey> gatox: an armhf build failed once on that in quantal
[18:24] <dobey> gatox: rebuilding that build it succeeded
[18:25] <gatox> dobey, ok..... i'll rebuild if you want
[18:25] <gatox> but....... i already made: "make check" twice
[18:25] <gatox> or are you suggesting something else?
[18:25] <ralsina> mmcc: interesting
[18:26] <dobey> gatox: it is unrelated to my changes
[18:26] <gatox> dobey, mmmmm........ i understand that part...... but..... it's weird that happens in your branch and not in trunk..... :S
[18:27] <ralsina> mmcc: ha! I am about to guess Cmd-q is bound to QApplication::quit() by default on mac
[18:28] <mmcc> ralsina, yes http://doc-snapshot.qt-project.org/4.8/qmenubar.html#qmenubar-on-mac-os-x -- says it is
[18:29] <dobey> gatox: but it does happen in trunk
[18:29] <mmcc> so one way to attack this is to try to create a menu item that Qt will use instead of its default ,so we can control where it's getting sent
[18:30] <ralsina> mmcc: ok, then let me introduce you to http://doc.qt.digia.com/4.7-snapshot/qcoreapplication.html#aboutToQuit
[18:30] <gatox> dobey, i didn't have the last changes from trunk..... now i'm running trunk again..... i'll accept the branch and propose another branch to fix that problem
[18:30] <mmcc> ralsina: that doesn't get fired!
[18:31] <ralsina> mmcc: really????
[18:31] <ralsina> mmcc: that's supposed to always get fired before the event loop stops!
[18:31] <mmcc> ralsina: UniqueApplication already listens for that to kill its local slocket thing, but on macos it does not run
[18:31] <mmcc> I know! I hate this bug
[18:31] <mmcc> ralsina: but *which* event loop!?
[18:31] <ralsina> mmcc: the only way for that to happen is either a qt bug or a signal handler :-(
[18:31] <mmcc> I'm still not totally clear on how the qtreactor's Qeventloop interacts with the QApplication we create.
[18:32] <ralsina> mmcc: oh.... the qapp one. Which we are not running!
[18:32] <mmcc> righto
[18:32] <ralsina> mmcc: ok, so, maybe in qtreactor there is something where we can hook
[18:33] <mmcc> ralsina: well, if I print the return value from their eventloop.exec_() call, that prints 0 for me when I do cmd-q
[18:33]  * ralsina starts reading twisted code
[18:33] <mmcc> which is why I'm puzzled. why does sending quit() to the qapplication cause an unrelated QEventLoop to exit from exec()?
[18:33] <ralsina> mmcc: if we are still in our code after we exit the loop we could kill sd forcibly but that's awful
[18:34] <ralsina> mmcc: lost you there, I'm afraid
[18:35] <dobey> ralsina: https://code.launchpad.net/~dobey/dirspec/update-4-0/+merge/127345 please :)
[18:35] <ralsina> mmcc: we can reach the event loop the reactor is launching.
[18:36] <ralsina> mmcc: so we *could* patch qtreactor so that when the loop ends we do something (or even emit a signal)
[18:36] <ralsina> dobey: got it
[18:38] <ralsina> mmcc: the code is clear enough https://github.com/ghtdak/qtreactor/blob/master/qt4reactor.py#L260
[18:39] <chaselivingston> mmcc: any updates on the bug i reported about joining a shared folder but the contents don't sync down?
[18:39] <dobey> hmm, i wonder if synergyc works in quantal; latest updates seem to have broken x2x :(
[18:40] <mmcc> chaselivingston: no, I haven't been working on that. do we have a bug # for it?
[18:41] <chaselivingston> i didn't look too hard to find it… let me see
[18:41] <ralsina> dobey, global +1
[18:41] <chaselivingston> mmcc: bug #1053489
[18:41] <dobey> thanks ralsina
[18:43] <mmcc> thanks chaselivingston. well, it's on the list :)
[18:43] <chaselivingston> mmcc: haha
[18:43] <chaselivingston> mmcc: isn't the app going to QA later this week?
[18:44] <mmcc> ralsina: so what I was wondering earlier, is that since we have a default menu action that is sending quit() to the qapplication, why does that then cause the eventloop that qtreactor created to exit? Does the eventloop listen for a signal from the application or something?
[18:45] <mmcc> chaselivingston: yes, it is
[18:45] <chaselivingston> mmcc: ok, i guess you're planning on releasing at least one more updated build to us this week then?
[18:46] <ralsina> mmcc: I am guessing that killing the app kills all secondary event loops, but that would have to be tested
[18:47] <mmcc> ralsina: ok. well, I just built a sample app that doesn't use qtreactor, just pyqt, and it sends aboutToQuit just fine
[18:47] <mmcc> chaselivingston: yes, right at the deadline :)
[18:47] <chaselivingston> mmcc: haha
[18:50] <ralsina> mmcc: ok then it's a problem about not running the right event loop
[18:50] <ralsina> mmcc: qtreactor is starting a "local" event loop. We create an app. When the app gets cmd-q it ends, but since it's not running its event loop, it never gets to emit aboutToQuit
[18:51] <dobey> sigh
[18:51] <ralsina> because that's emitted "when the event loop counter reaches 0"
[18:51] <dobey> f'n cloud icons :-/
[18:51] <ralsina> mmcc: obvious solution, make qtreactor emit aboutToQuit :-)
[18:51] <ralsina> mmcc: it's a one-line patch to qtreactor
[18:52] <gatox> dobey, +1....... i'll propose a branch to fix the other issue
[18:53] <mmcc> ralsina: ok, and then somewhere we need to catch aboutToQuit and stop syncdaemon
[18:53] <ralsina> mmcc: right
[18:54] <dobey> gatox: thanks
[18:54] <ralsina> mmcc: we could make the reactor emit any signal, but semantically I like emitting the app's aboutToQuit
[18:54] <mmcc> ralsina: that covers not killing syncdaemon when we quit, but I'm not sure it'll solve the problem of sometimes hanging instead of quitting, which I was hoping we'd kill with the same stone
[18:55] <ralsina> mmcc: hmmm
[18:55] <ralsina> mmcc: I haven't gotten the hanging so I don't know
[18:55] <ralsina> mmcc: it *may* be because of the order on which things are dying
[18:55] <mmcc> ralsina: yeah, I'm not sure how to recreate it yet
[18:55] <ralsina> mmcc: as in, if the qapp takes a bit long to die,and we kill the process, we end with a hanged thread, or something
[19:04] <mmcc> ralsina: ok, so emitting the signal from qtreactor does give me the hook I need to shut down syncdaemon, that works.
[19:05] <ralsina> mmcc: good! In a very bad sense of the word.
[19:05] <mmcc> I have another question though - we're assuming that Qt is calling QApplication::quit(), but I tried overloading that in our UniqueApplication subclass of QApplication, and it wasn't getting called. Was I doing that wrong?
[19:06] <ralsina> mmcc: dunno
[19:06] <ralsina> mmcc: it may not be calling that. I have no idea what it's doing without reading Qt's source code which I am not gonna :)
[19:06] <mmcc> ralsina: I did read a bunch of Qt source code and I'm not really enlightened :\
[19:07] <dobey> mmcc: enfrightened?
[19:07] <mmcc> the fact that they have to have menu bar code that works for menu-bar-per-window and one-global-menu-bar makes it messy to see where events are coming from
[19:07] <ralsina> mmcc: more reason for me not to read it
[19:07] <ralsina> mmcc: right
[19:08] <ralsina> mmcc: since it emits aboutToQuit we could grep for that and backtrack
[19:08] <mmcc> dobey: heh
[19:08] <ralsina> I don't expect it to be emitted in more than one or two places
[19:08] <mmcc> ralsina: good idea, I'll see if that helps
[19:09] <ralsina> we could attach a gdb to the process, put a bp in the call and see
[19:10] <dobey> alecu: do you have a minute to do the review for https://code.launchpad.net/~dobey/ubuntuone-client/disable-inhibit/+merge/127311 please?
[19:15] <mmcc> ugh
[19:15] <mmcc> this is your brain on multiple nested #ifndefs
[19:16] <dobey> #ifndef BEER_IN_FRIDGE goto pub; #endif
[19:16] <mmcc> oh don't forget the double-negative #ifndef QT_NO_SESSION_MANAGER
[19:17] <dobey> mmcc: it's that japanese 'no'
[19:17] <dobey> it's the session manager that belongs to qt :P
[19:18] <mmcc> yearhgh
[19:19] <mmcc> I do like that it gives me plenty of advice thru the code though: Q_WS_WINCE
[19:50] <gatox> the good thing is that the shares tab not working on mac is consistent..... the test for that also fail
[19:50]  * gatox thinks out loud
[19:55] <dobey> ralsina: https://code.launchpad.net/~dobey/ubuntu-sso-client/update-4-0/+merge/127358 please
[19:56] <mmcc> more fun: Qt's macEventFilter, which is a top-level hook to inspect all events, doesn't appear to be included in pyqt
[19:56] <ralsina> dobey: got it
[19:57] <ralsina> gatox: awesome-ish!
[19:58] <alecu> dobey: on it
[19:59] <alecu> dobey: +1
[20:00] <dobey> thanks alecu
[20:01] <ralsina> dobey: +1
[20:01]  * alecu will be afk, and will get back later tonight to work some more
[20:01] <ralsina> mmcc: hmmm you shoul be able to use a regular eventFilter
[20:01] <dobey> gracias ralsina
[20:19] <ralsina> I am not feeling great. I will stop now and try to come back later :-(
[20:20] <gatox> eod for me! see you tomorrow people!
[20:30] <mmcc> can't figure out how to install a regular eventFilter with pyqt either.
[21:04] <dobey> can i get someone to do a quick review of https://code.launchpad.net/~dobey/ubuntuone-dev-tools/update-4-0/+merge/127371 please?
[21:14] <briancurtin> dobey: i'll take a look
[21:19] <dobey> thanks
[21:31] <dobey> i wonder why the proxy tests in sso are all failing now on quantal :(
[21:34] <dobey> oh well, need to go now. have a good evening all!
[22:15] <mmcc> hm, now that I think about this more, I don't think that emitting aboutToQuit after the eventloop has already stopped will work. on quit, we need to kill syncdaemon and stop the reactor - but syncdaemontool.quit() returns a deferred, and I'm not sure how to wait for that to finish before stopping the reactor, since we're doing it in a function called by emitting a signal at the end of the reactor's run() function…