[08:11] <mandel> morning all!
[08:28] <JamesTait> Happy Monday, everyone! :-D
[11:12] <gatox> good morning!
[11:37] <mandel> gatox, morning!
[11:37] <mandel> gatox, I have a question for you!
[11:37] <mandel> :)
[11:37] <gatox> mandel, shoot
[11:38] <mandel> gatox, I'm fixing bug #1065513
[11:38] <mandel> gatox, it seems to happen because one of the overlays (don't know which) is drawn at the wrong position or something, that is, if you set the lodaing overlay to be a singleton you won't get the second one
[11:39] <mandel> gatox, why do we have server overlays? could we have used a single one and hide and show according to the tab?
[11:40] <gatox> mandel, i'm not sure i understand what you mean.... we are showing the overlay in each tab when the user press in some tab and the info need to be refreshed
[11:41] <mandel> gatox, yes, but we are creating 10 instances of the overlay
[11:41] <mandel> gatox, one for the folderspanel, other for the share links panel, devices etc...
[11:42] <mandel> gatox, the question is, why do we create one for each panel, should we use a single one and use a ref to it to tell it to be shown or not?
[11:42] <gatox> mandel, let me recheck the code
[11:43] <mandel> gatox, the code imports UbuntuOneBin (which I have no clue of what it does) in several places, which is what instantiates the overlay
[11:44] <gatox> mandel, yes... i see it
[11:45] <mandel> gatox, which means that the overlay has more than one sintance and is shown per tab, could mean that the double overlay we see in other systems (I cannot get it on ubuntu) is because of that
[11:45] <mandel> gatox, the ideal way would be to have a single overlay that is shown or not as per request of the tab
[11:46] <gatox> mandel, can you show me a screenshot of the double overlay?
[11:46] <mandel> gatox, sure, give me a sec
[11:46] <nessita> gatox, mandel: I can help with that, if you want
[11:46] <mandel> nessita, one sec, uploading pict so that we all can see the problem :)
[11:47] <nessita> gatox, mandel: if it's what I think it is, "is not a bug is a feature" :-)
[11:48] <nessita> every request that hits the "network" or syndaemon has to show feedback to the user that we're fetching data that may take a while
[11:48] <gatox> nessita, i don't think is a bug either..... but i want to see what mandel means too
[11:48] <nessita> so, when opening the control panel, we fetch 2 different pieces of info
[11:48] <gatox> yes
[11:48] <nessita> the account info, which shows a "global" overlay, covering the whole window
[11:49] <nessita> and the folder info, which shows an overlay only on top of the folder tab
[11:49] <nessita> unifying those could be a little (a lot) complicated
[11:49] <mandel> it is a bug because it looks like this: http://ubuntuone.com/73sN9YTCoGkv4wEIMpsGG3
[11:49] <nessita> cuz each piece of info can arrive a very different times
[11:50] <gatox> mandel, that is exactly what nessita explain
[11:50] <nessita> mandel: yes, is not a bug
[11:50] <nessita> does not look ideal
[11:50] <nessita> but is not a bug
[11:50] <nessita> mandel: each overlay is referrring to different info
[11:50] <mandel> nessita, gatox, is a bug, if there is loading info we should not show redundant information, we should ensure that if the loading overlay is shown we don't show it again
[11:51] <nessita> mandel: that's very very hard to do
[11:51] <mandel> you could have a singlenton in yo which you can register as a timed operation, and you removed yourself when done
[11:51] <mandel> overlay gets the signal I'm done, and if all are done gets out of the way
[11:51] <mandel> nessita, yes, I know it is a lot of work
[11:52] <nessita> mandel: ok, what I care the most if that you don't remove it without understanding why there is 2
[11:52] <nessita> FYI, this is only happening when the account info is retrieved
[11:53] <nessita> then we never show more than one overlay
[11:53] <gatox> mandel, yes........ but you will have a parentship problem if you want a single overlay....... where it can blocks the ui, so when something is loading you can't press other buttons.....  and to avoid that you need to add it in each widget, so you can set the parent and resizeEvent properly
[11:53] <nessita> mandel: also, is worth noting that you should not block the whole ui when fetching info for  single tab
[11:53] <gatox> nessita, ^
[11:53] <nessita> gatox: exactly (what I just also said)
[11:53] <gatox> nessita, yep!
[11:53] <mandel> nessita, yes, that is why if the tab is not visible should be taken into account
[11:54] <nessita> mandel: not sure what that means
[11:54] <mandel> nessita, as in, if a ui element that requires certain info to be ready is not visible do ignore it and do not show the overlay
[11:56]  * mandel hopes he makes sense
[11:57] <nessita> mandel: yes, and that's currently the case
[11:57] <nessita> mandel: if your screenthost, the 2 elements that are showing an overlay are visible:
[11:58] <nessita> the account section, and the folders tab
[11:58] <Chipaca> dobey: ralsina: ping
[11:59] <mandel> nessita, exactly, which repeats the information an adds redundancy that is not needed, a single overlay should be shown in this case for any possible combination, that is account is there and tab is not or the otherway around
[11:59] <nessita> mandel: I agree that a bug is worth reporting to design a proper solution...
[11:59] <mandel> nessita, has been reported already and ralsina pushed it my way, that is why I'm asking the reasoning from doing it like it is done :)
[12:00] <nessita> mandel: reasoning: was the not extremely complex way of doing it
[12:00] <mandel> nessita, ack
[12:00] <nessita> mandel: other ways are pretty complex. If you have any proposal for solving this, I would love to read it and help you decide if it will solve the problem
[12:01] <mandel> nessita, I'll write something about my toughs about it
[12:01] <nessita> mandel: let me know :-)
[12:13] <gatox> mandel, if you have a moment, could you review this one? (small) https://code.launchpad.net/~diegosarmentero/ubuntuone-client/deflated-size/+merge/129215
[12:17] <mandel> gatox, yes, will do asap
[12:17] <gatox> mandel, thx
[12:19] <mandel> gatox, nessita, a small idea on how to possible change the current implementation: http://paste.ubuntu.com/1280969/
[12:20] <mandel> gatox, nessita, the signal I mention does not have to have an overlay specific name, maybe currentWorkLoad or something like that is better
[12:21] <nessita> mandel: did you read the message I wrote before about not blocking the whole ui when fetching info for a single panel?
[12:21] <mandel> gatox, nessita we might want to talk with lissette to consider how to show the loading oeverlay, may be being over the entire ui is as bad as having two
[12:21] <mandel> nessita, yes, with this idea you will just do so in the first case..
[12:22] <nessita> mandel: how come? if we hav a single instance, that instance will be as big as the whole window, no?
[12:22] <mandel> nessita, we can have two overlays and one do not show the message if the other is (I'm more interested in the idea of using signals to do it)
[12:22] <nessita> or perhaps I'm missing something?
[12:22] <mandel> nessita, yes, you are right, there I did not consider that case
[12:23] <mandel> nessita, could have a single instance for all tabs and one for the account into
[12:23] <gatox> mandel, you can't one instance for all the tabs
[12:23] <mandel> nessita, the one in the account info will show the loading message only if the other overlay is hidden
[12:23] <mandel> gatox, why?>
[12:23] <nessita> mandel: well, the instance for the tabs needs to leave the tabs "out" so the can be clicked
[12:23] <gatox> mandel, because the overlay has as it parent the content of the tabs..... not the qtabwidget
[12:24] <nessita> gatox: so, when fetching shares links info, the user needs to be able to click on devices
[12:24] <gatox> which avoid having the problem nessita mention
[12:24] <nessita> sorry, mandel I meant :-)
[12:24] <nessita> mandel -> so, when fetching --for example-- shares links info, the user needs to be able to click on devices
[12:24] <nessita> so we can't have an overlay per the whole tab group
[12:25] <gatox> and that's why you can't use singleton either
[12:25] <mandel> nessita, gatox, hm... then maybe same number of instances, make the tab overlay instances be in-sync with the accounts overlay via signals
[12:25] <mandel> gatox, I hate singletons in most use cases :)
[12:25] <mandel> nessita, gatox, so that account info overlay instance know when to show or not the loading message
[12:26] <nessita> mandel: not sure how that solution would be implementable...
[12:26] <nessita> mandel: any chance you outline the specifics a little more?
[12:27] <mandel> nessita, sure, fancy to talk over mumble, I think we would agree faster :)
[12:27] <gatox> mandel, yep..... i would like to mumble..... i have some questions about that
[12:27] <nessita> mandel: I'm at the phone right now, could be in mumble in 15'...
[12:28] <nessita> mandel: but you can mumble with gatox, he understands the issue :-)
[12:28] <nessita> * I think * :-P
[12:28] <mandel> nessita, I'll mumble with gatox and then  I'll take some of you time after my lunch hehe
[12:28] <nessita> go ahead
[12:28] <mandel> gatox, to the mumble cave!!!
[12:28] <mandel> nananana
[12:35] <ralsina> good morning!
[12:35] <gatox> ralsina, hi
[12:38] <ralsina> nessita, mandel: what we need is all overlays to be in the exact same place. That way, if we have the window-overlay, we don't see two ;-)
[12:39] <ralsina> but that is mostly a cosmetic fix
[12:39] <mandel> ralsina, wet think we have a better approach
[12:39] <mandel> ralsina, join mumble :)
[12:39] <ralsina> mandel: can't, sorry
[12:39] <mandel> ralsina, fuuuu
[12:39] <ralsina> mandel: but I am all for better approaches ;-)
[12:39] <mandel> ralsina, ok, so, they can't all be in the same place because they don't know about each other
[12:40] <ralsina> mandel: nah, it's trivial
[12:40] <ralsina> mandel: so, I don't believe you ;-)
[12:40] <mandel> ralsina, gatox and I were thinking of removing the one from the account panel and add a loading gif to the name and siable the button
[12:40] <mandel> ralsina, then add the name and th enable the button when done
[12:40] <mandel> super simple
[12:40] <mandel> and no hack needed
[12:40] <ralsina> "button"?
[12:40] <gatox> the connect/disconnect
[12:40] <alecu> hello, all!
[12:41] <ralsina> mandel: is that the only bit that blocks the whole window?
[12:41] <ralsina> mandel: if yes,  +1 and remove the global overlay
[12:41] <mandel> ralsina, for the accounts, yes
[12:41] <nessita> gatox: no need to disable the connect.disconnect button
[12:41] <mandel> nessita, me, right :)
[12:41] <gatox> nessita, ah..... true
[12:41] <nessita> mandel: ^ since is not related to fetching account info
[12:41] <mandel> nessita, even better!
[12:42] <mandel> nessita, ralsina, gatox we just do it for the name and done :)
[12:42] <gatox> so, easier.... just replace the name label
[12:45] <mandel> sounds like a great way to solve it then
[12:45] <mandel> I'll speak with lisette after lunch about it
[12:46] <mandel> now, time for me to have food :)
[12:47] <gatox> dobey, let me know when you are here please..... now i can access tarmac.... but it seems it can do bzr branch there....... this thing hates me
[12:47] <gatox> it can't
[12:50] <dobey> gatox: ssh -A
[12:50] <gatox> dobey, checking.... thx
[12:50] <dobey> Chipaca: hey, what's up?
[12:51] <dobey> gatox: but i pulled your branch on that instance and ran the tests, and they passed
[12:52] <gatox> dobey, what?!....... why is failing then?!
[12:52]  * gatox cries
[12:52] <dobey> i have no idea
[12:52] <gatox> :(
[12:53] <Chipaca> dobey: hey. Nothing, in the end.
[12:53] <Chipaca> dobey: crises averted.
[12:53] <dobey> great
[12:53] <ralsina> hello dobey, welcome back!
[12:54] <gatox> dobey, ah! and welcome back! :D
[12:54] <dobey> thanks
[12:57] <gatox> ralsina, so..... i'm running the tests manually in tarmac..... and they all pass!!.... but i have u1-cp branches bouncing on launchpad.... should i try to re-accept them again or that is the definition of insane?
[13:12] <ralsina> gatox: that's very strange. Locale?
[13:13] <ralsina> gatox: also it doesn't look like a timing issue at all... perhaps something in the PYTHONPATH is different in tarmac?
[13:13] <gatox> ralsina, locale??..... but i'm running them on tarmac too.... and they pass for me and dobey when i execute the tests manually
[13:13] <dobey> gatox: no, tarmac runs with en_US.UTF-8
[13:14] <gatox> dobey, that no was for me or ralsina ?
[13:14] <dobey> gatox: for you, it's not the locale
[13:14] <gatox> ah yes.... i suppose it's not
[13:14] <dobey> and it's almost certainly not the PYTHONPATH either
[13:15] <gatox> i just tried to re approve the branch....... crazy things happend....
[13:15]  * gatox finger cross
[13:16] <dobey> gatox: i did that on your previous branch it failed again with the same errors, so i'm not sure that will help
[13:16] <gatox> dobey, nop..... it didn't work again......
[13:17] <gatox> this is driving me crazy
[13:20] <gatox> quick errand....... brb
[13:28] <dobey> gatox_brb: well, one branch just merged ok
[13:30] <dobey> gatox_brb: and why did you delete https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/shares-broken/+merge/128108 ?
[13:36] <dobey> gatox_brb: though i think i see why your branch is failing; not sure exactly the cause, but i think i know what change is triggering it
[13:37] <gatox_brb> back
[13:38] <gatox> dobey, i deleted that branch.... because it was a workaround for the mac release..... and didn't land on trunk before i proposed the proper solution for the issue... so it's not actually needed anymore having the other branch
[13:39] <ralsina> gatox: don't delete branches, reject them
[13:39] <gatox> ralsina, ack
[13:39] <dobey> gatox: what ralsina just said; deleting them is discourteous
[13:41] <ralsina> gatox: on tarmac, are you just branching your code, or branching trunk and merging it?
[13:41] <gatox> ralsina, branching my code...... i'll try merging
[13:43] <gatox> ralsina, same result
[13:43] <ralsina> gatox: so, it passes?
[13:43] <gatox> ralsina, yes
[13:43] <ralsina> gatox: ok, we can do a nasty thing :-)
[13:43]  * gatox accepts anything
[13:43] <ralsina> gatox: you could add some prints in your branch and try to merge again
[13:44] <gatox> ralsina, why?
[13:44] <gatox> why some prints i mena?
[13:44] <ralsina> gatox: because it's failing with first argument of unbound method must have type 'QThread'
[13:44] <ralsina> gatox: and I want to know exactly what thing it believes is an unbound method
[13:44] <gatox> ralsina, ahhhhh you mean to debug it
[13:44] <ralsina> gatox: exactly
[13:45] <gatox> ralsina, ack..... i'll do that!
[13:45] <ralsina> gatox: worst case, it merges with a print and dobey hunts you down ;-)
[13:45] <gatox> jejeje
[13:46] <dobey> the merge *could* be broken
[13:48] <dobey> nope
[13:48] <dobey> passes merged for me
[13:48] <dobey> so probably timing
[13:48] <gatox> dobey, yep.... for me too
[13:48] <gatox> passed i mean
[13:49] <gatox> mande|lunch, after lunch, review this one too if you can: https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/pointing-hand/+merge/129502
[13:50] <dobey> gatox: i don't quite understand what the changes in test_share_links_search.py have to do with the rest of the branch
[13:51] <dobey> gatox: and i suspect those changes are what's breaking this
[13:53] <gatox> dobey, that is actually fixing a timing issue that we used to have....... and making sure that the QThread is not executed as a thread
[13:55] <dobey> gatox: can you file a separate bug for that issue, remove those changes from that branch, and put them in a new branch for the new bug?
[13:55] <gatox> dobey, of course..... will do that
[13:55] <dobey> thanks
[13:56] <dobey> gatox: please ping me when u1-cp-publishapi branch is updated to not have those changes, and we'll try to merge without them
[13:56] <mandel> gatox, ok
[13:57] <gatox> dobey, ack
[13:57] <gatox> mandel, thx
[13:58] <dobey> anything else blow up while i was away? or just gatox's branch?
[13:59] <mmcc> hi folks, welcome back dobey! hope you had a good break
[14:01] <dobey> thanks; and eh, it was not as good as was planned; weather failed me
[14:06] <ralsina> dobey: just gatox's
[14:06] <ralsina> good morning mmcc
[14:06] <ralsina> mmcc: how hard would it be to make a separate build for 32 bit macs?
[14:06] <dobey> hrmm
[14:06] <dobey> u1cp windows tests seem to be failing
[14:07] <mandel> gatox, here: https://code.launchpad.net/~diegosarmentero/ubuntuone-client/deflated-size/+merge/129215 why changing the name from size to deflated_size ??
[14:07] <briancurtin> dobey: there are failures on a bunch of windows projects, mostly because jenkins has been down recently so they snuck in
[14:07] <briancurtin> dobey: and jenkins doesnt actually work right now (working on it)
[14:08] <dobey> briancurtin: this seems to be like it's got a messed up checkout or something
[14:08] <mmcc> ralsina: I'm not sure. Definitely requires some tweaking on the fsevents daemon to get it 32-bit compatible - it uses objc language features that are only in the 64-bit runtime…
[14:08] <gatox> mandel, check the bug description: https://bugs.launchpad.net/ubuntuone-client/+bug/1062729
[14:09] <dobey> briancurtin: but i'll leave it to you then :)
[14:09] <briancurtin> dobey: i'm probably going to rebuild the setup since it has some out-of-date stuff and should be on the same setup we're running on dev boxes
[14:09] <dobey> briancurtin: sounds good
[14:10] <ralsina> mmcc: ack, it's worth investigating
[14:10] <ralsina> mmcc: we got one request for the 32-bit version at least
[14:10] <briancurtin> all: i'm going to post my standup done/todo now because i need to head to a doctor's appointment (bad time choice, i know). i came early and will stick around late depending on how long this takes
[14:10] <briancurtin> DONE: adjusted the sso bin-finding branch to work with the u1client branch, so now u1cp on windows works fine. two small branches to review: https://code.launchpad.net/~brian.curtin/ubuntuone-client/correct-subprocess-args/+merge/129506 and https://code.launchpad.net/~brian.curtin/ubuntu-sso-client/correct-subprocess-args/+merge/129442
[14:10] <briancurtin> TODO: look at jenkins (done a bit this morning) because it still isn't running the tests, but it executes a bunch of pre-test steps. review a few branches that have backed up
[14:12] <briancurtin> (ammendment to the TODO - probably just rebuilding the jenkins setup to make it easier)
[14:12] <mmcc> ralsina: ok. I'll see if there are any other issues for 32.
[14:12] <ralsina> mmcc: at least knowing what needs to be done
[14:13] <mmcc> ralsina: ok
[14:25] <mandel> gatox, oh, ok
[14:26] <mandel> gatox, both reviews done
[14:27] <gatox> mandel, thx..... approved or need fixing?
[14:27] <mandel> gatox, both +1
[14:27] <gatox> mandel, awesome! thx
[14:41] <gatox> dobey, the branch has been modified
[14:49] <mmcc> ok, just sent an email about using PyObjC for the menu. In short, I think it's a good idea (and it's working in code). But I'm sensitive to the fact that it's adding to the number of languages & frameworks we need to know to maintain the code…
[14:51] <ralsina> mmcc: how does it affect binary size? It's a very minor concern.
[14:51] <ralsina> mmcc: also, does it add any packaging complexity?
[14:52] <chaselivingston> mmcc: you can probably kill this bug report, asked the user to submit a ticket in support. https://bugs.launchpad.net/ubuntuone-client/+bug/1066920
[14:54] <mmcc> ralsina: good questions… binary size - negligible. just a few K for PyObjC python code, no new frameworks (just loads the AppKit that's already there, and that's OK to do.)
[14:55] <mmcc> ralsina: packaging complexity, not really. need to tweak things around to have the menu be a separate process anyway, this would roll into that
[14:55] <ralsina> mmcc: ok, so no new concern there
[14:55] <ralsina> mmcc: I don't expect it to be a complex program, as long as the reactor and pyobjc get along
[14:55] <ralsina> mmcc: not much more than current systray.py at least
[14:56] <mmcc> chaselivingston: that's a dupe, I'll find the orig. It sounds like maybe we need to add a FAQ about where the logs are on osx -- the reporter was looking in ~/.cache, but they're in ~/Library/Caches/ubuntuone
[14:56] <mmcc> ralsina: it's about the same, yeah.
[14:57] <ralsina> mmcc: so +1 from me, and better now than later
[14:57] <chaselivingston> mmcc: right, my script can get those if you want to tell them about that as well
[14:57] <mmcc> ralsina - oh I forgot something in the email: I haven't tried this yet - of course :) - but I do think we can use trial to test this thing, so we don't have to adopt a new test framework
[14:57] <ralsina> mmcc: good one ;-)
[14:58] <dobey> ralsina: do we actually need a reactor in the process though?
[14:58] <ralsina> dobey: yes for the IPC
[14:58] <dobey> oh, right :-/
[14:59] <ralsina> dobey: on mac/win we pretty much always need a reactor
[15:00] <thisfred> me?
[15:00] <gatox> me
[15:00] <dobey> me
[15:01] <alecu> me
[15:01] <mmcc> me
[15:02] <thisfred> DONE: wrap u1db TODO: ?? BLOCKED: no NEXT: gatox
[15:02] <dobey> gatox: hah, and your branch merged without those changes. so that set of changes is triggering another issues it seems :)
[15:02] <gatox> DONE:
[15:02] <gatox> Proposed a couple of branches for control panel. A lot of ssh configurations and fights trying to connect to tarmac. Tested bouncing branches there. Refactor bouncing branch and updated. Working in another branch for the qthread problem.
[15:02] <gatox> TODO:
[15:02] <gatox> Proposed a fix for the race condition with qthread. Keep fixing stuff in cp.
[15:02] <gatox> BLOCKED:
[15:02] <gatox> No
[15:02] <gatox> dobey, go
[15:02] <mandel> me
[15:02] <dobey> DONE: holidays
[15:02] <dobey> TODO: catch up, bug triage, fix bugs, move off pylint
[15:02] <dobey> BLCK: None.
[15:02] <dobey> alecu: go
[15:02] <alecu> DONE: got some medical checks, more planned for this wed, fixes in dash branches
[15:02] <alecu> TODO: get dash branches reviewed and merged
[15:02] <alecu> BLOCKED: no
[15:02] <alecu> NEXT: mmcc
[15:02] <mmcc> DONE: pyobjc menu does progress bars
[15:02] <mmcc> TODO: finish menu impl, tests
[15:02] <mmcc> BLOCK: no
[15:03] <mmcc> next ralsina?
[15:03] <ralsina> sorry guys go without me :-(
[15:03] <alecu> mandel: go
[15:03] <mandel> DONE: Review, reviews, reviews. Worked on bug 1065513 with nessita and gatox, talk with lisette on the design ideas.
[15:03] <mandel> TODO: Organize possible travels, get bug 1065513 fixed. 1-1
[15:03] <mandel> BLOCKED: no
[15:05] <ralsina> gatox: wha? it merged?
[15:05] <mmcc> oh I forgot one more thing about PyObjC: method names like "NSTimer.scheduledTimerWithTimeInterval_target_selector_userInfo_repeats_" make the pep8 checker go nuts. :|
[15:06] <mmcc> (or pyflakes, I forget which. line length, anyway)
[15:06] <gatox> ralsina, yes..... i'm proposing another branch with the qhtread thing to avoid the race conditionn
[15:06] <alecu> mmcc, ralsina: while we are on the pyobjc discussion, let's keep in mind that it's a bit undermaintained, and that support for python 3 is hacky at best: http://blog.pythonaro.com/2012/08/how-to-compile-pyobjc-for-python-3-on.html
[15:07] <mandel> mmcc, you can always tell it to ignore a file (pep8 I guess is the one complaining)
[15:08] <mandel> mmcc, if this is in ubuntuone-client is pyflakes in the others is pylint
[15:08] <mandel> mmcc, in pylint you can use a # pylint: disable=#NUMBER
[15:08] <mmcc> alecu: yes, good point - ronald is the only person actively working on it. py3 support is what he's most actively working on, though. And the website is so far behind that I actually volunteered to help fix it
[15:09] <alecu> mmcc: nice
[15:09] <mmcc> mandel, in my case it's emacs highlighting lines from the result of both pyflakes and pep8.py, so still :|
[15:09] <dobey> mandel: the long line thing is probably pep8
[15:09] <mandel> dobey, I think so too
[15:10] <mandel> mmcc, well, that is a diff story, but if you ignore them tarmar will let you merge the branch, else it will be blocked
[15:10] <mmcc> alecu: and despite low # of active committers, people do use pyobjc for real shipping things. I'm not sure if that means it'd get picked up if ronald stopped, but it's something.
[15:10] <dobey> mandel: i guess this isn't in a branch yet exactly?
[15:11] <mandel> mmcc, why not using ctypes?
[15:12] <mmcc> mandel because ctypes is for C. calling ObjC with a C interface would mean reimplementing PyObjC, basically
[15:12] <mandel> oh, ok
[15:12] <mmcc> every message send in objc boils down to a C call to objc_msgsend(), so I'd need to wrap that, depythonify data structures, etc etc, boom I've rewritten pyobjc, badly :)
[15:12] <alecu> :-)
[15:14] <ralsina> alecu: keep in mind that we will stay py2 on windows for a long time, so probably makes no difference to stay py2 on mac as well
[15:15] <dobey> ralsina: it would be nice to consider dropping python 2.6 (and with it, the classic non-GIR gobject bindings) at this point though
[15:15] <ralsina> dobey: that only affects lucid, right?
[15:15] <dobey> lucid is the only active ubuntu version that uses 2.6, yeah
[15:15] <alecu> ralsina: right, I just want us to have in mind the limitations of pyobjc. And it would be nice having the possibility of switching everything to 3 when we have the chance.
[15:16] <dobey> and the only reason we still support 2.6 in the client at all really, is for some of the tests that run on the server which is still on lucid
[15:16] <mmcc> something else I forgot about - I think this might be best done as a separate project, if only because of the different test requirements (i.e., shouldn't have tarmac block on pep8 errors)
[15:17] <mmcc> but I'm not sure it needs to be separate, it just seemed simpler…
[15:17] <alecu> dobey: right, gatox had to do some fixes very recently because of the server running on lucid.
[15:17] <dobey> mmcc: it should probably be a separate project just because it doesn't have any proper direct relation to the others
[15:17] <ralsina> dobey: yes, we can't drop 2.6 until the end of this cycle because of the server tests
[15:17] <dobey> ralsina: until 12.10 or until 13.04?
[15:18] <ralsina> 13.04
[15:18] <mmcc> dobey: well, it imports from all of them, but yeah, it is a distinct thing.
[15:18] <dobey> mmcc: it imports from things other than u1-client?
[15:19] <ralsina> facundobatista: the timeline for switchng the servers to precise is 13.04 right?
[15:20] <mmcc> dobey: it imports strings from control panel and syncdaemontool from u1-client, which ends up getting credentials from sso
[15:21] <gatox> ok..... lunch here
[15:21] <mmcc> brb
[15:22] <dobey> mmcc: hrmm, the menu strings? i thought u1client had those strings as well?
[15:25] <mmcc> dobey: maybe it does. I didn't look… I'll make a note
[15:27] <dobey> mmcc: i think it does, as the strings for the menu on ubuntu are in u1-client
[15:27] <dobey> we probably need to fix control panel to import them from u1-client instead of having copies
[15:31] <mandel> ralsina, gatox_lunch I'm aiming to get this as per design: https://docs.google.com/a/canonical.com/presentation/d/13LMJQfBA3NgbRZ82j4Il1lkutg0mR03WpJA87epw1j4/edit#slide=id.g20c9f360_0_37
[15:31] <mandel> is more work, but is better to get it done the right way
[15:37] <alecu> mmcc: oh, I'm just reading your email, and it already addresses my pyobjc concerns. Doh :-)
[15:39] <dobey> ok, need to get lunch; bbiab
[15:42] <ralsina> mmcc: looking...
[15:42] <ralsina> that was for mandel. So, mandel... how? ;-)
[15:43] <mandel> ralsina, add an extra layout for the entire things that depends on the content of the name, leave the account pane with no layout
[15:43] <mandel> ralsina, the rest works the same
[15:43] <ralsina> mandel: ok, want to see it
[15:43] <ralsina> mandel: so go ahead :-)
[15:44] <mandel> ok
[15:44] <mandel> ralsina, that sounded like a challenge hehe
[15:50] <briancurtin> back after 1:45 complete waste of time
[16:10] <alecu> briancurtin: what happened?
[16:11] <briancurtin> "oh, you have an appointment? we don't do monday appointments since they doctors aren't here today" - "oh..." - "who set your appt up?" - "cathy" - "that's me"
[16:12] <briancurtin> so i guess the real appointment is now thursday if i can trust them
[16:12] <alecu> mandel: there's one catch with that design
[16:12] <mandel> alecu, tell me
[16:13] <alecu> mandel: when starting, the "getting information" bubble will move at some point, when the account info is retrieved, but the folder info is not yet.
[16:13] <alecu> mandel: so, it will appear to "jump".
[16:13] <mandel> alecu, true
[16:13] <mandel> alecu, and that is not good at all
[16:14] <mandel> lisettte, ^^
[16:14] <alecu> mandel: my opinion is that it should remain in a fixed place, and yes, the tabs and the top could be "unobscured" when the account info is available.
[16:15] <lisettte> alecu, mandel: depending on what the 'jump' looks like, it seems better for users to have all the functionality they can have in the shortest possible time
[16:15] <mmcc> yeah, let's please not make it jump around. even the font resizing when the quota percentage is finally drawn is annoying enough.
[16:16] <lisettte> alecu, mandel: what exactly is going to jump?
[16:16] <alecu> lisettte: the "getting information bubble"
[16:16] <mandel> lisettte, it will move down a little
[16:16] <alecu> lisettte: in slide 5 the bubble is many pixels below, compared to slides 3 and 4
[16:17] <lisettte> alecu, mandel: we should see how this works in reality, but it seems we need the partial cover anyway: right now it shows me the waiting animation briefly every time i move to a different tab
[16:18] <mandel> lisettte, yes, that is because it does a request for every tab change
[16:18] <lisettte> alecu, mandel: i am not sure it is a huge problem for it to move down
[16:18] <mmcc> might be a big change, but can we fix this instead by storing locally the username and quota and just not displaying the loader for the account info? Seems crazy to wait 10 seconds to see my name.
[16:18] <alecu> mmcc: your name comes free when we request the available space
[16:18] <lisettte> alecu, mandel: the alternative is to cover it until everything is available, which was my first choice, but then we would still need the partial cover for moving between tabs?
[16:19] <mandel> is just that the name is the most notizable pieze of info
[16:19] <alecu> mmcc: and the quota should be updated when we start, right?
[16:19] <lisettte> alecu, mandel: which would be 4 states
[16:19] <mandel> lisettte, alecu, yes, if you want to move between tabs that is the issue, if you add an overlay on top the tabs wont be clickable
[16:20] <mmcc> alecu: the name comes free but slow!  the quota could be out of date for a few seconds, or just display a dash instead of the actual percentage…
[16:20] <lisettte> mandel: can you show us how irritating the jump is? it seems the least of all evils
[16:20] <mandel> lisettte, sure, I'll have that done by tom and we can see how bad it is
[16:21] <mandel> I'm close to my EOD
[16:21] <lisettte> mandel: awesome!!!!! :)
[16:21] <alecu> mandel: I see what lisette proposes now: when starting, let's keep everything occluded until the folder info is retrieved
[16:21] <mandel> alecu, lisettte, I'll do both options and will record a video so we can choose
[16:22] <mandel> is better to see it
[16:22] <lisettte> mandel: saweet!
[16:22] <alecu> mandel: that means having some logic in the first tab to know this is the starting, and not the switching...
[16:22] <mmcc> alecu: and the first tab could be any tab
[16:22] <mandel> alecu, mmcc, is not the first tab, but the main widget
[16:22] <mandel> which is diff
[16:22] <mmcc> ko
[16:22] <mmcc> er ok
[16:22] <alecu> mmcc: I believe that it was chosen not to cache the name, because it was something that could be changed on the website.
[16:23] <gatox> mandel, so..... is going to be the option with the whole overlay?
[16:23] <alecu> mmcc: but yes, I agree that it's slow, and ugly
[16:23] <mmcc> hmmm.
[16:24] <alecu> mmcc: perhaps we can poke nessita to explain the reasons not to cache the name and total available quota in the control panel (at least until they are updated by the first webcall to the account api)
[16:24] <mmcc> not caching the quota makes some sense, since the cached quota could be wrong often, but the cached name would never be wrong for almost everyone...
[16:25] <alecu> gatox: not with the whole overlay. The whole overlay when starting, the per-tab overlay when switching tabs.
[16:25] <gatox> alecu, yes.... that's what i mean
[16:25] <alecu> gatox: I understand that. mandel can confirm.
[16:26] <mandel> alecu, exactly, use a global overlay for the first time, use tab overlays later..
[16:26] <mandel> is not a simple solution though ..
[16:28] <mandel> I'm nearly done with the first solution, I'll continue tom and we can decide then
[16:28] <mandel> now, I need to EOD
[16:28] <mandel> catch you all tom!
[16:29] <alecu> mmcc: bybye!
[16:30] <gatox> alecu, mmcc is not leaving :P
[16:30] <alecu> I meant mandel, sorry :P
[16:30] <mmcc> gatox: shhhh, I was making brunch plans
[16:31] <mandel> lol
[16:31] <alecu> mmcc: so, checking the code, it seems that the account webcall is used to get the subscription plan details. Then a different call is used for the quota, but the results are returned together.
[16:32] <alecu> my guess is that the quota webcall might be taking significantly longer.
[16:32] <alecu> (because of server processing)
[16:32] <alecu> but I better test irl.
[16:33] <alecu> also, we are doing the quota call only once, when starting. So while the control panel is started, the quota info won't ever be changed.
[16:34] <mmcc> so if you click on the button to get more storage and get more storage, the quota will be wrong? hmm… be nice to update that
[16:36] <mandel> alecu, mmcc, it should as updated as possible
[16:36] <alecu> mmcc: also, if you run out of u1 space, you get a popup warning you about that, but you look at the control panel and it says otherwise.
[16:39] <ralsina> alecu: we do need to make that a looping call. That it's never updated is a linux-ism since there u1cp is not a persistent process, but something that starts/stops every time the user looks
[16:40] <alecu> ralsina: yes, absolutely.
[16:40] <mandel> ralsina, but if the user does have the control panel opened for longs periods you will have the same problem
[16:41] <alecu> mandel: yes, but it's much more frequent on win/mac, since even when the user closes the window, the process persists.
[16:41] <ralsina> alecu, mandel: so, gather that info in sd and signaling out to u1cp and the indicator?
[16:41] <mandel> ralsina, alecu, it does make sense that this is more on the sd side... since it is all the time running for sure
[16:41] <ralsina> mandel: exactly
[16:42] <ralsina> same pattern as we are using for the sync menu, more or less
[16:42] <dobey> hmm
[16:42] <alecu> interesting tidbit: when starting u1cp, these webcalls are done *twice* :P
[16:42] <alecu> account call: 1.9406189918518066
[16:42] <alecu> account call: 2.4485630989074707
[16:42] <alecu> quota call: 0.28434205055236816
[16:42] <alecu> quota call: 0.3152000904083252
[16:43] <mmcc> alecu, yep I've noticed that too… I think one of them gets cached now, since I added a deferred lock around them (or was that just the credentials?)
[16:43] <ralsina> alecu: Measure twice, cut once?
[16:44] <mmcc> hm, maybe I'm thinking about getting the credentials, never mind.
[16:44] <alecu> mmcc: is that on trunk?
[16:44] <mmcc> alecu: yeah, it's from a while back, let me look
[16:45] <dobey> meh
[16:46] <mandel> mmcc, I think is the creds
[16:46] <mmcc> yeah, I was thinking of this one: https://code.launchpad.net/~mikemc/ubuntuone-control-panel/fix-credentials-race
[16:47] <mandel> that code is a little messy
[16:47] <mandel> well, I really need to go now
[16:47] <mandel> laters all!
[16:48] <mmcc> huh, so this is weird - this is merged, but doesn't have a MP: https://code.launchpad.net/~mikemc/ubuntuone-client/guard-ipc-connect
[16:49] <dobey> mmcc: you probably had the changes included in another branch
[16:49] <gatox> anyone else is having problems trying to push code to launchpad?
[16:50] <dobey> gatox: wfm
[16:50] <gatox> mm..... i'll reconnect
[16:51] <mmcc> dobey: that makes sense, but I can't guess which branch it'd be… oh well
[16:53] <dobey> mmcc: http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-client/trunk/revision/1302#ubuntuone/platform/ipc/ipc_client.py
[16:55] <mmcc> dobey: indeed. thanks
[16:57] <gatox> need to restart
[16:58] <briancurtin> ralsina: in order to fix jenkins i think i'd like to redo its setup to be based on buildout. i never got around to doing that, partly since it worked via the old "install everything globally" way it was done before. however, now it needs buildout. the question is: can i create a new project in LP to house the scripts/devsetup folder of windows-installer, especially since its now sufficiently cross-platform?
[16:58] <nessita> alecu: hi, just saw your ping
[16:59] <dobey> briancurtin: the plan was to just rename windows-installer to something more amiable to what we actually do with it
[16:59] <dobey> briancurtin: so i'd say just keep it in there, and we'll rename it when we get the chance
[16:59] <briancurtin> dobey: well it does have some code for windows installer stuff
[16:59] <nessita> alecu: no reason for caching other than not having the infrastructure in place within the project (meaning there is no current caching, so you need to persist the info somehow)
[16:59] <dobey> briancurtin: yes, and mac 'installer' stuff
[17:00] <dobey> mostly that project is 90%+ buildout though
[17:00] <dobey> the windows-specific actual installer bits are very minimal
[17:02] <ralsina> briancurtin: I don't see a reason for another project, besides the bad naming
[17:02] <ralsina> briancurtin: so, let's keep it there
[17:08] <alecu> lunch and bank time for me.
[17:12] <gatox> just a heads up....... my connection is working like crap today
[17:20]  * ralsina lunches
[17:20] <gatox> did you get my message about my connection being crap?
[17:20] <gatox> anyone?
[17:20] <dobey> no
 just a heads up....... my connection is working like crap today
[17:20] <briancurtin> gatox: i got it
[17:20] <dobey> lol
[17:20] <briancurtin> :)
[17:20] <gatox> jeje thx
[17:20] <gatox> dobey, troll
[17:20] <gatox> jeje
[17:21] <mmcc> I only see gatox's vowels
[17:21] <dobey> haha
[17:24] <alecu> beats seeing gatox's bowels
[17:25] <gatox> dobey, so now we should try to land this one :P https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/u1-cp-qthread/+merge/129722
[17:25] <gatox> alecu, ^
[17:26] <dobey> gatox: it will fail
[17:26] <gatox> dobey, ok..... i'll do here what roberto suggest..... and put a couple of prints so i can debug it when it fails
[17:28] <dobey> gatox: i've needs fixing it. can you please document in the bug report description the actual failure cases when the race occurs?
[17:29] <gatox> dobey, ok
[17:44] <dobey> muahahahah
[17:44] <gatox> dobey, what happend?
[17:44] <dobey> i think i fixed the overzealousness of "redefinition of unused var" in pyflakes
[17:45] <gatox> dobey, thank you :'D jeje
[17:54] <dobey> i have no idea how to propose the change to upstream though, or how to run their test suite
[17:55] <dobey> but presumably i also have to fix some tests
[17:59] <gatox> mmcc, ping
[18:00] <mmcc> pong gatox
[18:01] <gatox> mmcc, sorrry to bother you again with this.... i had the tab opened with the change to remember, but firefoxx decided that my tabs weren't important.... can you  remind me again the line in u1-cp that should be commented in order to run the testts please?
[18:01] <mmcc> gatox: sure, np. just a sec
[18:01] <gatox> mmcc, thx
[18:04] <mmcc> gatox http://paste.ubuntu.com/1281605/
[18:04] <gatox> thx
[18:07] <dobey> ugh
[18:13] <gatox> dobey, please let me know if this is ok for you: https://bugs.launchpad.net/ubuntuone-control-panel/+bug/1066894
[18:18] <dobey> gatox: those failures happen consistently on osx?
[18:19] <gatox> dobey, yes for me
[18:19] <gatox> dobey, running just that script.... i've seen it pass sometimes
[18:19] <gatox> but few
[18:20] <dobey> hrmm
[18:20] <gatox> dobey, i have a really slow machine for osx
[18:22] <dobey> gatox: can you run the tests with QTHREAD_MAX_IO_WORKERS=0 to see if they pass then? or maybe QTHREAD_AFFINITY="no"?
[18:23] <dobey> these failures are quite odd indeed
[18:23] <gatox> dobey, sorry.... where i should add that?
[18:23] <dobey> gatox: those are environment vars
[18:24] <gatox> ack
[18:24] <dobey> i think they work with qt4 anyway
[18:24] <dobey> of course, this may be a completely different qthread library i'm looking at documetnation for
[18:25] <dobey> indeed i am
[18:25] <dobey> so nevermind those vars :(
[18:25] <dobey> with
[18:25] <dobey> err
[18:25] <dobey> sigh
[18:25] <dobey> so i don't know
[18:25] <dobey> i guess just try the prints then :-/
[18:26]  * dobey also wonders how to get details for import aliases in python _ast
[18:28] <gatox> dobey, but the failures makes sense.... the patching is happening after the function is called..... so it executing everything in a thread instead as part of the same flow.....
[18:29] <gatox> and the branch fix that..... but for some reason is failing in launchpad..... so i'll need to debug that with lots of prints
[18:31] <dobey> ok
[18:31] <briancurtin> ugh. i think im going to try and remove all dependence on windows batch files. they are constant pain and we have python right in front of us...
[18:32] <dobey> briancurtin: do it! :)
[19:21] <gatox> dobey, should we try to land this branch? https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/u1-cp-qthread/+merge/129722
[19:21] <gatox> dobey, or should we ask for reviews?
[19:21] <gatox> s/we/i
[19:22] <dobey> i don't know
[19:22] <gatox> ralsina, ping
[19:23] <dobey> gatox: i guess i'll try to land it
[19:23] <dobey> since it will almost certainly fail
[19:23] <gatox> dobey, please....... so i can check the prints
[19:23] <gatox> dobey, because the fix is right....
[19:24] <dobey> well, not entirely i guess
[19:24] <gatox> dobey, maybe..... or maybe launchpad is crazy somehow
[19:24] <ralsina> gatox: pong
[19:24] <dobey> it has nothing to do with launchpad
[19:24] <dobey> or how crazy it might be
[19:25] <gatox> ralsina, nothing..... it was to ask you if we could try to land the branch that has the qthread tests fix and is causing problems.... but dobey already said that he will try to land it.... so we can see the prints
[19:35] <ralsina> gatox: ack
[19:39] <dobey> also ugh for last minute critical bug that we should have caught a year ago :-/
[19:40] <mmcc> looks like my connection is patchy here, probably because I'm testing upload progress bars IRL.
[19:45] <dobey> gatox: ah i see what's wrong
[19:45] <gatox> dobey, with mmy branch?
[19:45] <dobey> gatox: well i think the problem was already there, and your branch just exposes it finally
[19:45] <gatox> dobey, tell me please
[19:47] <dobey> gatox: actually, this branch seems to have two problems now
[19:47] <dobey> gatox: the old problem seems to be that _thread_explore is not yet initialzed when you try to start the thread from the patched method
[19:48] <dobey> gatox: and the new problem seems to be that self.ui is None in some cases
[19:48] <dobey> SearchBoxTestCase has the problem of self.ui being None
[19:49] <gatox> mmmmm
[19:49] <gatox> dobey, so..... probably this is not the proper solution..... and it is necessary to refactor a couple of things..... am i right?
[19:49] <dobey> gatox: possible. i don't really know anything about QThread, but looking at the traceback and the code, it seems there is still a race there
[19:50] <dobey> gatox: but your current branch seems to have isolated the race to be a consistent issue
[19:50] <gatox> dobey, ok....... i'll try to thing this carefully..... specially because i'm not being able to see it fail here....... and propose a branch fixing those stuff....... sounds ok?
[19:51] <dobey> gatox: interesting
[19:52] <dobey> gatox: so the new SearchBoxTestCase failures are failing for me as well, in your branch
[19:52] <gatox> dobey, what i say? or did you find something else?
[19:52] <dobey> the other QThread issues are still passing for me when i run the tests though
[19:52] <dobey> gatox: so fix the SearchBoxTestCase failure first, i think
[19:53] <dobey> it might be related to your addition of prints
[19:53] <dobey> though not sure how exactly :)
[19:53] <gatox> dobey, ack....... i'll do that! i'll check the race condition of ui being None sometimes
[19:53] <gatox> that is the root of some problems
[19:53] <dobey> great
[19:54] <gatox> awesome..... thx dobey
[19:55] <dobey> sure; let me know when you have an update to the branch and i'll run the tests again
[19:55] <gatox> dobey, yap
[20:10] <gatox> ok....... eod here..... i'll keep fixing the qthread tomorrow
[20:10] <gatox> bye peopleeeeeee..... see you tomorrow1
[20:19] <ralsina> dobey: I feel so guilty about that qthread code... it started as "the simplest solution" for the problem. Looks like it wasn't :-/
[20:20] <dobey> eh, at least it's not bug #1066943
[20:20] <ralsina> well, yes, that's true
[20:21] <dobey> for which i just proposed https://code.launchpad.net/~dobey/ubuntuone-client/grrrrr-gir/+merge/129754
[20:21] <ralsina> dobey: looking
[20:22] <ralsina> dobey: we are still packaging trunk for lucid, but noone is actually using it, right?
[20:22] <ralsina> dobey: also, how did that ever work and/or pass tests?
[20:22] <dobey> no, we are only packaging nightlies for 11.04+
[20:23] <dobey> it won't build on lucid
[20:23] <ralsina> dobey: yes, noticed that :-)
[20:23] <dobey> it's in the scripts, which don't have tests
[20:23] <ralsina> but really, where was that getting glib from?
[20:25] <ralsina> dobey: +1
[20:25] <dobey> python-zeitgeist maybe?
[20:26] <ralsina> so, random dependency chain...
[20:26] <dobey> in nightlies ubuntuone-control-panel was still depending on it for some reason
[20:26] <dobey> but i fixed that just now
[20:27] <alecu> dobey: +1
[20:27] <dobey> thanks guys
[20:34] <dobey> i hope there aren't any other bugs i need to fix in quantal today
[20:42] <ralsina> dobey: fingers crossed!
[20:43] <dobey> oh, crap
[20:43] <dobey> final release is thursday; so i guess this has to be an SRU and rel-noted
[20:44] <ralsina> dobey: it should not happen in the default install, right?
[20:44] <dobey> i'll have to check the manifest
[20:45] <dobey> ralsina: yeah, python-gobject is part of the default install
[20:45] <dobey> so maybe i should change it to high instead of critical
[20:45] <ralsina> dobey: so SRU is more than ok
[20:45] <ralsina> dobey: right
[20:46] <ralsina> dobey: this happened to this guy because he did a "minimal" install, if it happened in default I would have noticed
[20:46] <ralsina> by the bug report flood ;-)
[20:46] <dobey> or even mediaum
[20:47] <dobey> yeah; true
[20:48] <ralsina> high is ok to justify the SRU
[20:53] <dobey> eh, justifying the SRU is easy, for this one anyway
[20:55] <dobey> also
[20:55] <dobey> _ast is hard to use
[20:57] <ralsina> dobey: you are not supposed to use _ast directly
[20:58] <ralsina> also, IIRC gatox knows a ton about ast because of ninja
[21:02] <elopio> pedronis: dobey. is u1lint also used on the web projects ?
[21:02] <elopio> sorry pedronis.
[21:03] <elopio> wrong key :)
[21:03] <dobey> elopio: on servers? i think it is not right now
[21:03] <elopio> dobey: got it, thanks.
[21:04] <elopio> beuno: do you use some kind of style checker?
[21:04] <beuno> elopio, I'm using ninja-ide which does pep-8 checking by default, yes
[21:04] <dobey> elopio: servers has a similar wrapper around pylint
[21:05] <elopio> beuno: I meant, is it enforced by jenkins or tarmac?
[21:05] <beuno> elopio, no, not at the moment
[21:05] <beuno> will be soon
[21:06] <elopio> beuno: awesome. Can I be involved when you are doing it?
[21:10] <dobey> alright, well i think it's time for me to call it a day
[21:10] <dobey> have a good evening all!
[21:10] <ralsina> Time to take a long break now.
[21:10] <elopio> bye dobey, have a good evening.
[21:10] <ralsina> post review reqs etc here!
[21:11] <elopio> bye ralsina, have a good long break.
[21:13] <mmcc> client tests so so slow
[21:23] <mmcc> here's a brief review request for ralsina after his good long break: https://code.launchpad.net/~mikemc/ubuntuone-client/fix-dummy-sync-menu-again/+merge/129767
[21:24] <briancurtin> mmcc: review trade? mine's easy: https://code.launchpad.net/~brian.curtin/ubuntuone-windows-installer/remove-lazr-mentions/+merge/129765
[21:25] <mmcc> briancurtin: sure. you'd be a good review for mine, since it fixes something that probably broke windows syncdaemon too
[21:27] <mmcc> briancurtin: +1 on code review only, I killed those in setup-mac early on.
[21:28] <briancurtin> mmcc: i had them killed in setups where i had been building the installers from, but apparently hadn't proposed the branch
[21:29] <mmcc> briancurtin: been there!
[21:30] <mmcc> ok, lunch time
[21:48] <briancurtin> mmcc: my u1client tests aren't currently passing, but your branch has no overall effect on the fail/error count
[21:50] <mmcc> briancurtin: another test is to see if syncdaemon starts for you with/without the branch…
[21:57] <briancurtin> mmcc: ah, shows up IRL
[21:58] <briancurtin> i also realized a stupid mistake i checked in with those bin finding branches...two three-char changes if you can squeeze them in your schedule
[21:58] <briancurtin> (after your lunch, of course)
[22:33] <mmcc> briancurtin: I'm back, what's the deal? I actually haven't reviewed those branches yet, sorry…
[22:34] <briancurtin> mmcc: i approved your branch. i was looking at the changes i made and one branch got merged that needs to be adjusted (https://code.launchpad.net/~brian.curtin/ubuntuone-client/take-first-element/+merge/129779) and the other doesn't have any reviews yet (https://code.launchpad.net/~brian.curtin/ubuntu-sso-client/correct-subprocess-args/+merge/129442) - it's all related to the python at the front of the path problem, should
[22:34] <briancurtin> be quick
[22:40] <mmcc> briancurtin - aha, ok. I'll look at those later today. have to run for a few hours now, will be back later.
[22:40] <briancurtin> mmcc: cool, thanks