[00:00] <mmcc> building it now, didn't have time to make the disk image with the background
[00:01] <mmcc> (ping vila, the file will be in the shared folder, named 'build-121004.zip'
[00:01] <mmcc> now I really really have to go. will check back in late to be sure it uploaded
[04:40] <mmcc> here: http://ubuntuone.com/22JpZkHpJjGm0peelzpGVe
[05:46] <vila> mmcc: I see build-121004.zip, thanks, it unzip correctly here (on ubuntu), will test after my coffee ;)
[08:31] <mandel> morning!
[10:58] <rye> ping alecu, http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntu-sso-client/trunk/view/head:/ubuntu_sso/networkstate/linux.py#L73 - any objection against switching to online mode on any error from NM? - bug #1062051 - that impacts vila's tests
[11:30] <gatox> good morning
[11:36] <gatox> reboot....
[11:39] <gatox> back
[11:51] <gatox> mmcc so..... the branches for the share tabs weren't included in the release?
[11:55] <alecu> hello people!
[11:56] <gatox> alecu, hi
[12:14] <gatox> need to reboot again :S
[12:26] <alecu> gatox: let me know when you want to discuss the "api problem"
[12:27] <gatox> alecu, yes.......i'm debugging some part first..... to check something
[12:27] <gatox> although..... it seems that the branches for the mac release weren't included....... :S
[12:27] <nessita> gatox: I'm looking at https://code.launchpad.net/~diegosarmentero/ubuntuone-client/crazy-comma/+merge/128122, and I wanted to tell you that the comma should not be removed
[12:27] <nessita> gatox: the result of the deferred will always be a tutple
[12:27] <nessita> tuple*
[12:27] <alecu> rye: +1 to setting the mode to "online" if there are errors contacting NM
[12:28] <nessita> gatox: (perhaps we can change the code to be more explicit)
[12:29] <gatox> nessita, i'm looking at that right now....
[12:29] <nessita> gatox: what problem were you trying to solve?
[12:29] <nessita> gatox: also, never propose a branch like that without a justifying test ;-)
[12:29] <nessita> you need to "show" you're fixing something
[12:30] <rye> vila: ^
[12:32] <vila> rye: am I correct understanding that this will mean that the u1 client will stop relying on network-manager but use other means to ensure some network connectivity is available ?
[12:32] <alecu> gatox: nessita is right, the semantics are different with and without a comma: http://pastebin.ubuntu.com/1261813/
[12:32] <mandel> nessita, but will that tuple always have a single item?
[12:33] <nessita> mandel: yes
[12:33] <nessita> or should be
[12:33] <nessita> (if not, that may be the bug)
[12:33] <alecu> nessita: anyway, I would like to find some other way to do this tuple unpackings, because it looks weird, and it seems error prone.
[12:33] <vila> nessita: you've taken the TDD red pill aren't you ?
[12:33] <nessita> alecu, gatox: absolutely agreed. We may change the code to be less obscure (I will take the blame for that original code)
[12:33] <alecu> vila: nessita *is* the red pill
[12:33] <nessita> :-)
[12:34] <nessita> vila: my only goal in this world is to TDDize everyone within my reach
[12:34] <nessita> *WATCH OUT*
[12:34] <rye> vila: if reply from NM is definite (and not error) then we trust it. If NM tells us weird things, we don't trust it and think we are online
[12:34] <vila> nessita: count me in ;)
[12:35] <vila> rye: so unknown was error and will now be weird thing right ?
[12:35] <mandel> nessita, the problem I see with that result, = is that if you get more than one item you will get unpack errors, I prefer using the index, is more 'in your face'
[12:35] <mandel> ofcourse you could get an empty tuple
[12:35] <rye> vila: yes, well, when the code is fixed
[12:35] <nessita> mandel: agreed. THough the deferred will always (should always) return a tuple of a single element) for certain calls
[12:35] <alecu> mandel: the thing is that getting a tuple with more than one item when you expect just one ought to be an error
[12:36]  * vila nods, I'm subscribed to the bug so I'll know (and my test will also tell me ;)
[12:36] <rye> vila: if
[12:36] <nessita> mandel: anyways, the code is correct *and* obscure. The key word being obscure :-)
[12:36] <nessita> gatox: what motivated you to do that change?
[12:36] <vila> rye: ?
[12:36] <mandel> nessita, in this case I asked gatox why he did it and he did not know, so that is the problem :)
[12:37] <gatox> nessita, i have some problems with windows and darwin.... where it was returning a different tihng that linux
[12:37] <mandel> alecu, true..
[12:37]  * mandel gets back to fight with pointers..
[12:37] <nessita> mandel: but that code was not "made" by gatox -- I added (I'm to blame for the , =)
[12:37] <nessita> perhaps gatox fixed it a style thingy?
[12:38] <alecu> and doing "assert len(response) == 0; response[0]" sounds like overkill.
[12:38] <alecu> sorry
[12:38] <alecu> and doing "assert len(response) == 1; response[0]" sounds like overkill.
[12:38] <mandel> nessita, did not use bzr blame, we where just debugging
[12:38] <nessita> ah
[12:39] <mandel> alecu, yes, and no.. is a PITA to write but if it safes our asses in the not distant future..
[12:39] <nessita> mandel, gatox: fair enough. The best advice I can give you, is never do a change without knowing what or why you're changing, and never without a backing up test
[12:39]  * mandel agrees with nessita
[12:39] <nessita> mainly because perhaps your change is correct but someone can come in later and add the comma back, for example :-)
[12:39] <alecu> nessita, gatox: what about leaving those lines "as is", and adding some comments? like "response, = yield d  # unpacking single element tuple"
[12:40] <nessita> alecu: +1
[12:40] <alecu> mandel: we get the assertion automatically thanks to the weird comma
[12:42] <mandel> alecu, until we get a value unpack error in a inlineCallback and we have not try except, but I don't think the bug gatox is searching is related to that
[12:42] <mandel> the signal is nor fired due to some other reason
[12:42]  * gatox is wondering if the feature wasn't included in the mac release for that....
[12:44] <dobey> hmm
[12:51] <alecu> vila, rye: are you guys working on that branch, or should I?
[12:51] <vila> vila: I'm not
[12:51] <vila> meh
[12:51] <vila> alecu: I'm not
[12:51] <alecu> :-)
[12:52] <mandel> vila, is good to know that you make sure vila thinks the same ;)
[12:53] <vila> who ?
[12:53] <vila> he never listen...
[12:53] <mandel> vila, talking to yourself :)
[12:53] <mandel> like:
[12:53] <vila> that wasn't me, that was that other one
[12:53] <mandel> mandel, lets go and have lunch
[12:53] <mandel> yes
[12:53] <vila> :)
[12:54] <mandel> both mandels go to lunch
[13:00] <alecu> vila: how are you starting that "test" dbus session?
[13:00] <vila> dbus-launch
[13:01] <vila> nah, that's probably a bit incomplete as a description...
[13:02] <vila> the test runs on a vm accessed via ssh (with fabric in fact), it does a dbus-launch --sh-syntax, I get the DBUS_* env vars back, I then call (still via ssh) 'DBUS_... u1sdtool --whatever'
[13:03] <alecu> great
[13:03] <vila> and then the test kill the dbus process (pid acquired at dbus-launch time)
[13:04] <vila> rye helped understand why my tests were failing spuriously
[13:04] <vila> *helped me
[13:09] <ralsina> good morning!
[13:10] <ralsina> rye: about the network-manager policy issue... why would NM not report network status to sessions that are not in the console? I agree we should handle policy error better, but that policy is useless :)
[13:10] <ralsina> rye: so, maybe we should also affect network-manager?
[13:12] <alecu> vila: I'm trying to run sd inside an ssh, but I'm getting errors while retrieving the u1 credentials from the keyring. Have you found something similar?
[13:12] <rye> ralsina: NM is configured this way in Ubuntu, cat /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf
[13:12] <alecu> ralsina: hi!
[13:12] <rye> alecu: you need to put oauth tokens in the config file
[13:12] <rye> alecu: https://wiki.ubuntu.com/UbuntuOne/Headless
[13:12] <alecu> rye: thanks
[13:12] <vila> alecu: oh, right, I think I use the syncdaemon.cfg trick where you put the oauth token there
[13:14] <vila> alecu: see.. bah, why didn't I read the log :-/
[13:14] <vila> rye: you're too fast ;)
[13:17] <ralsina> rye: I agree it is that way, I don't see how not telling someone logged in via network that a network is up makes sense ;-)
[13:17] <ralsina> hola alecu
[13:18] <ralsina> alecu, mandel|lunch, gatox: I was at the doctor's because I have a horrible headache and it' an ear infection. I am trying to work but I don't know how much looking at brght lights I can handle.
[13:18] <alecu> ralsina: ouch :-(
[13:18] <gatox> ralsina, oops.... get better
[13:19] <ralsina> gatox, alecu: thanks. If I seem unresponsive, phone me :-)
[13:19] <gatox> :P
[13:20] <dobey> ralsina: what's the issue?
[13:20] <dobey> with nm and policy i mean
[13:22] <ralsina> dobey: let me find the bug
[13:22] <ralsina> dobey: bug #1062051
[13:28] <dobey> ah ok
[14:01] <chaselivingston> mmcc: ping
[14:03] <dobey> sigh
[14:05] <dobey> branch lp:ubuntu/unity last night to build packages with a patch, which was 6.6.0-0ubuntu4 UNRELEASED, uploaded to my PPA this morning, and it tells me a newer version is available in ubuntu as 6.8.0-0ubuntu1 :(
[14:06] <mandel> ralsina, uh, take a rest, ear infections are a dangerous thing to have
[14:07] <dobey> ugh, and bzr-builddeb won't even let me merge back up :(
[14:09] <gatox> mandel, ping
[14:10] <mandel> gatox, pong!
[14:11] <gatox> mandel, i'm looking at: def emit_signal(self, signal_name, *args, **kwargs): in ipc/perspective_broker.py..... and the "on_public_files_list" signal is being emitted successfully....  with the proper data....... do you know who should be catching that signal
[14:11] <gatox> ?
[14:12] <mandel> gatox, if the signals is emitted the callback should be called from the client code, did you create a on_public_files_list callback in the client side?
[14:12] <mandel> gatox, if it is missing nothing will happen, take a look in ipc_client.py
[14:12] <gatox> mandel, yep.......
[14:13] <gatox> mandel, i'll follow tracking things from there
[14:20] <mandel> gatox, sorry youhave to deal with this..
[14:21] <gatox> mandel, the info is coming to the ipc_client..... i'm printing the data from the cp side.... so now i'm tracking where the signal is getting lost
[14:22] <mandel> gatox, have you set the debug mode of the defers to true, that might help
[14:22] <gatox> nop.... will try that in a few
[14:25] <ralsina> mandel: thanks, it's just boring alone at home without work :-)
[14:26] <mandel> ralsina, are you getting atibiotics?
[14:28] <ralsina> mandel: will start after lunch
[14:29] <ralsina> mandel: luckily it's just a 1-a day 3-day thing
[14:30] <mandel> ralsina, he, we should change the name of the team to unhealthy+ instead of desktop+
[14:30] <mandel> at this speed the only healthy person is going to be gatox and he will probably have an accident with a paperclip or something
[14:31] <gatox> mandel, jejeje it's funny because it's true
[14:31] <gatox> or very probable
[14:31] <dobey> heh
[14:34] <gatox> mandel, i'm going to enable a mandel 's quote section in my twitter
[14:34] <gatox> jejeje
[14:34] <mandel> hehe
[14:40] <alecu> gatox: that wou
[14:40] <alecu> gatox: that would look like a stream of repeated unfunny jokes
[14:40] <gatox> :P
[14:40] <gatox> mandel, defend yourself
[14:42] <mandel> gatox, nah, is not himself talking, probably alecu decided not to use the lift to go up stairs and he is feeling funny ;-)
[14:42] <alecu> ouch :P
[14:43] <mandel> hehe
[14:46] <ralsina> mandel: look! Sashimi! <mandel faints>
[14:46] <gatox> juazzzzz
[14:46]  * ralsina kids because he cares
[14:47] <mandel> hehehe => http://25.media.tumblr.com/tumblr_m97d9iWzvi1rnrom8o2_250.gif
[15:00] <mandel> me
[15:00] <briancurtin> me
[15:00] <dobey> me
[15:01] <gatox> me
[15:02] <alecu> me
[15:02] <dobey> mandel: go
[15:03] <mandel> DONE: added some autopilot tests for the preview (mainly for links etc.. ) Fough with small mem leak
[15:03] <mandel> TODO: finally propose the work to land in trunk.
[15:03] <mandel> BLOCKED: no
[15:03] <mandel> COMMENTS: need to leave 30 min earlier, I have to go to the vet (not me)
[15:03] <mandel> briancurtin, please
[15:03] <briancurtin> DONE: updated environment and got SSO up with zero manual changes
[15:03] <briancurtin> TODO: u1cp still not working in the new env, but it looks promising given it removes all of the manual stuff that caused problems in the past. ironing out kinks to get it going
[15:03] <briancurtin> NEXT: dobey
[15:03] <dobey> DONE: releases, uploads, poke py3 twisted guys about tests crashing and packaging
[15:03] <dobey> TODO: reviews, fix bugs
[15:03] <dobey> BLCK: New Qt broke SSO authenticated proxy support. CP tests breakage.
[15:03] <dobey> gatox: go
[15:03] <gatox> DONE:
[15:03] <gatox> Propose and fix a branch for the shares tab not working on windows/darwin, file a bug for the api problem. Started working in the api problem (find some clues about this).
[15:03] <gatox> TODO:
[15:03] <gatox> Fix the api problem and find sense in the universe again.
[15:03] <gatox> BLOCKED:
[15:03] <dobey> err oops. not blocked actually
[15:03] <gatox> No
[15:03] <gatox> alecu, go
[15:03] <dobey> mmcc: standup?
[15:03] <alecu> DONE: some reviews, started looking into getting protobuf 3 upstream and a branch for bug #1062051
[15:03] <alecu> TODO: pending split in dash branches, more protobuf
[15:03] <alecu> BLOCKED: no
[15:03] <alecu> NEXT:
[15:04] <mmcc> here, writing. sorry, feeling sick again today
[15:06] <mmcc> DONE: build for qa
[15:06] <mmcc> TODO: new bugs, look at using DMG background image
[15:06] <mmcc> BLOCK: no
[15:07] <gatox> mmcc, hi..... did you include the fix in the release?
[15:07] <gatox> mmcc, also.. i've updated the branches: https://code.launchpad.net/~diegosarmentero/ubuntuone-client/crazy-comma/+merge/128122  -  https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/shares-broken/+merge/128108
[15:09] <mmcc> gatox, I included the control-panel branch with a one-off tweak to do the same thing as your updated branches there.
[15:10] <gatox> mmcc, great
[15:11] <mmcc> brb, need to start coffff…e
[15:11] <dobey> gatox: can you deal with vila_'s review of https://code.launchpad.net/~diegosarmentero/ubuntuone-client/ubuntuone-client-fix-tests/+merge/127836 please?
[15:12] <gatox> dobey, ack
[15:13] <gatox> it's actually 5 items and a separator..... i'll correct the comment
[15:13] <dobey> right
[15:15] <gatox> vila, branch updated: https://code.launchpad.net/~diegosarmentero/ubuntuone-client/ubuntuone-client-fix-tests/+merge/127836
[15:18] <vila> gatox: wow, thanks, it was worth updating the comment, I wouldn't have thought about a separator...
[15:22] <gatox> mandel, i find out the signal problem....... now i have to find out the proper way to fix it :P but i'm getting closer
[15:23] <mandel> gatox, share with me, what is the problem?
[15:24] <gatox> mandel, the def connect_signal(self, signal_name, handler): method, in SyncDaemonToolProxy..... it's being called two times with the same signal (from different places it seems).... so when it does: setattr(client, callback, handler)..... the second time with another handler, not the one i set when i said that i want to be connected to that signal, override that value..... so _success_handler is notified for that signal, but not my handler
[15:25] <gatox> _success_handler..... is the handler when it's called for the second time
[15:26] <mandel> gatox, ok, simple, do make handlers to be a list and call the in sequence
[15:26] <gatox> if i avoid that....... as i just tested..... that works
[15:26] <mmcc> gatox, that sounds familiar. i did that with the status changed handler a while back to make the sync menu status work…
[15:26] <mmcc> er, did that == "made the handlers be a list"
[15:26] <gatox> mmcc, can you point me to the place where you did that?
[15:26] <mmcc> https://code.launchpad.net/~mikemc/ubuntuone-control-panel/fix-sync-status/+merge/122974
[15:26] <mmcc> gatox, yes ^
[15:26] <gatox> mmcc, awesome
[15:27] <gatox> mandel, this was driving me crazy
[15:27] <mmcc> weird. I was wondering if that was the problem you were having so I looked for something setting a handler twice a couple of days ago, but I guess I missed this one. sorry
[15:28] <mandel> gatox, mmcc, maybe a more generic approach could be done, as ALL handlers should be lists
[15:28] <gatox> mandel, yes
[15:28] <mmcc> yeah, gatox I feel your pain - that was a LOT of tracking through spaghetti code to figure out
[15:28] <mandel> gatox, yes, I know the feeling, is partially my fault, bzr blame probably has my name somewhere there
[15:28] <gatox> mmcc, yap
[15:29] <dobey> ok, time to get some lunch i think; bbiab
[15:29] <gatox> mandel, mmcc well..... this seems that is going to be a nice way to end the week
[15:31] <cm-t> Hi, I have a short question (didnt found in FAQ), just to be sure : The owner of shared folder, he will get the quotas of files on his account, not the other people ?  (ex: A share with B a folder and B add files: the limit of 5Go will be changed only for A, not for B ?)
[15:32] <cm-t> or maybe B will "pay" for his files too ? not A?
[15:35] <chaselivingston> cm-t: hi, the quota will be affected for both users
[15:36] <cm-t> damn :/  so if i share 5Go of pics with B, he will be out of quota ?  or only file you own ?
[15:36] <cm-t> chaselivingston: ↑
[15:37] <joshuahoover> cm-t, chaselivingston: actually, only the owner's quota should be impacted, not those he or she shares with
[15:37] <chaselivingston> cm-t: if B accepts the share and only has a 5GB account, then yes
[15:40] <chaselivingston> cm-t: sorry about that, sounds like i was under a false impression as well :)
[15:41] <cm-t> joshuahoover: the owner of the shared folder you mean, not the owner of file ( i hope)
[15:41] <cm-t> no problem chaselivingston :)
[15:42] <joshuahoover> cm-t: right, the owner of the shared folder...if i share a 100 GB folder with you and you only have 5 GB, you are not over your quota
[15:43] <cm-t> ( for the story, we have the project for our next ubuntu party in paris, every one with the share will be able to share pics took on the event to be displayed on ubuntu TV image lens and a multi touch screen with photo app touch friendly if possible - it will show the ubuntu one power too)   there will be a lot of pics, if only 20 people add 3mb x 10 it will grow fast (…)  my question is: does every one will take in his quota t
[15:43] <cm-t> he pic of other ? if we take the quota of other, we might add a script that remove new photo in shared folder to put in other one (or hack like this
[15:44] <alecu> vila, rye: this should fix the NM issue: https://code.launchpad.net/~alecu/ubuntu-sso-client/other-nm-errors/+merge/128272
[15:45] <cm-t> thanks joshuahoover, that the awnser i wanted to hear,  don't want to break all people account be involved in our party
[15:47] <rye> alecu: yay simplification!
[16:03] <vila> alecu: yeah reliability !
[16:04] <vila> alecu: yeah reliability !^W^Wrobustness
[16:05] <mandel> ok, EOW for me, I need to take the dog to the vet, catch you all on monday!
[16:06] <mmcc> bye mandel, see you mon
[16:14]  * gatox lunch
[16:32] <mmcc> hey folks, am I supposed to be able to share a file that was shared with me? this is regarding https://bugs.launchpad.net/ubuntuone-control-panel/+bug/1061949
[16:34] <alecu> mmcc: you can share folders or publish files...
[16:34] <alecu> mmcc: so you must be trying to publish a file that was shared with you, right?
[16:35] <mmcc> alecu: I guess so? I'm honestly not 100% clear on what the share links tab lets me do
[16:35] <mmcc> but yeah that sounds right. I select a file in the share links tab, so that means I want to publish it…
[16:38] <alecu> mmcc: oh, right. We are now using the term "share" for links too in the UIs. It used to apply only to sharing folders with another u1 user.
[16:41] <mmcc> yep, and we're not allowed to do that. syncdaemon gets the right error, but it's not making it up to the controlpanel
[16:41] <mmcc> but the bug is really in the share links tab, I guess, since it shouldn't let me search for shared links
[16:41] <alecu> mmcc: I'm just trying to "share the link" of a file in a folder that was shared to me, and SD gets this error from the web apis: WebClientError: ('FORBIDDEN', "Can't make shared files public.")
[16:42] <alecu> mmcc: right, it should not let you search inside shared folders.
[16:42] <mmcc> alecu: yeah, I get that too now that I dig into syncdaemon.log
[16:42] <mmcc> ok, I'll change the bug I wrote for that
[16:42] <alecu> u1sdtool throws a tuple unpacking error for this :P
[16:46] <mmcc> ok, it is https://bugs.launchpad.net/ubuntuone-control-panel/+bug/1061949 -- I will let ralsina assign it
[16:47] <mmcc> there's actually kind of two bugs there - the search UI one, and then also the problem that it just hangs instead of getting the error callback
[17:18] <gatox> ralsina, are you going to take care of that bug?? or do you want me to take it?
[17:22] <mmcc> oh hey, you're back gatox. so should I approve this https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/shares-broken/+merge/128108 or are you going to fix it differently so it gets the signal?
[17:23] <gatox> mmcc, i'm going to propose another branch for the signal thing
[17:23] <gatox> mmcc, so please approve that one
[17:23] <mmcc> gatox: ok, cool
[17:24] <mmcc> gatox, +1, although did you see vila's comments in the internal channel? share links tab isn't working for him at all: https://bugs.launchpad.net/ubuntuone-client/+bug/1062151
[17:25] <gatox> mmcc, but i was working for you?
[17:26] <gatox> it
[17:26] <mmcc> gatox: yes, it works for me
[17:26] <gatox> here too.....
[17:26] <gatox> i'll need to check later
[17:26] <mmcc> I'll ask urbanape. urbanape, does the share links tab work for you?
[17:26] <ralsina> gatox: looking...
[17:27] <ralsina> mmcc, gatox: it's not going to start qorking for vila because of popular vote :-)
[17:27] <mmcc> ralsina: but what if I yell at it loud enough
[17:27] <ralsina> gatox: assigning to you
[17:28] <gatox> ralsina, ack
[17:28] <ralsina> mmcc: tried it, didn't work, sorry!
[17:28]  * vila search for qorking definition
[17:28] <ralsina> vila: I have fat fingers
[17:28] <mmcc> ralsina: qork.
[17:29] <vila> amazing, google(define qorking) guessed the tyop ;)
[17:29] <mmcc> so ralsina you tried with the version I built yesterday and it didn't work?
[17:29] <mmcc> as in, it hangs on loading info?
[17:29] <urbanape> http://ubuntuone.com/p/sTq/
[17:29] <urbanape> seems to.
[17:29] <urbanape> mmcc: works for me
[17:30] <ralsina> mmcc: no, didn't try it at all
[17:30] <ralsina> ok, so it may be something in vila's system. Perhaps OSX version?
[17:30] <ralsina> Also, vila is the only one that has no development setup in his OSX, right?
[17:31] <vila> 10.6.8
[17:31] <mmcc> a HA. well, I still have 10.6. time to go give that a try
[17:31] <vila> errr, no dev setup... not sure about that, that's the girls mac but I may have installed some xcode stuff at some point (or may be not)
[17:31] <ralsina> well, it's something to try at least.
[17:31] <mmcc> vila, is it only the share links that doesn't work? does sync work for you?
[17:32] <vila> ralsina: anything more precise to check for ?
[17:32] <ralsina> vila: nothing comes to mind
[17:32] <vila> mmcc: yes, I did some tests
[17:32] <mmcc> because that's a weird precise thing for an OS version to break…
[17:32] <ralsina> vila: so far, we have this shares tab problem only :-)
[17:36] <vila> mmcc: what do you call a precise thing ?
[17:37] <mmcc> vila: I meant that it'd be surprising if the OS version only broke just the shares tab, and nothing else. I'd be less surprised if it broke, for example, everything that used IPC, or something like that. but just the shares tab is a strange thing to be the only thing that breaks
[17:37] <vila> mmcc: can that be some internal exception caught by the main loop and as such leaving the control panel intact ? Any place I could search to validate/invalidate such a cause ?
[17:38] <vila> missing icon, missing library needed only for that tab, stuff like that ?
[17:38] <mmcc> vila: I'm looking at your logs now… there don't seem to be any exceptions. I also don't think it uses any different code
[17:38] <mmcc> I noticed that you don't actually have any shared files to display and I'm wondering how well we've tested with that
[17:39] <vila> indeed, sorry I failed to mention that
[17:39] <mmcc> i.e., control panel calls syncdaemon via IPC and sync daemon's logs show a happy return value of [] but control panel isn't logging any return value
[17:39] <vila> but that will be the case for all new users
[17:39] <mmcc> yes, if that's the problem then it's a bad bug. not sure that's it yet though
[17:40] <gatox> mmcc, vila i'll check that
[17:41] <vila> OED and family time here, I may lurk around later but no promise ;)
[17:41] <vila> Have fun all and thanks for the good work !
[17:41] <mmcc> gatox -- in share_links.py, get_public_files sets is_processing = True and _load_public_files sets it to false, *unless* len(result) == 0 :(
[17:41] <vila> mmcc: haaa ? Got it ?
[17:42] <mmcc> yep
[17:42] <vila> YES \o/
[17:42] <gatox> mmcc, that's going to be removed with my next branch anyway
[17:42] <vila> Always good to end the week on good news ;)
[17:42] <mmcc> gatox: cool, that's good news
[17:43] <mmcc> gatox: so just remember to check that we handle empty lists of shares correctly - maybe a good test to write
[17:43] <gatox> mmcc, yes
[17:43] <mmcc> vila, thanks for your help, have a good weekend
[17:48] <mmcc> gatox, can I suggest also just moving the self.is_processing = False in _load_public_files up to get_public_files? that kind of thing seems like it should always be set and unset in the same scope if we can manage it
[17:48] <mmcc> so it's easier to check
[17:55] <gatox> mmcc, i prefer not..... if we do that... we are going to hide the loading overlay before we get the response
[17:56] <mmcc> gatox, really?
[17:56] <gatox> mmcc, the fact that we are calling _load_public_files inside get_public_files is going to dissapear in the next branch
[17:56] <gatox> and that is going to be asynchronous
[17:56] <mmcc> oh, ok. it'll be a callback. got it
[17:57] <mmcc> thakns
[17:57] <mmcc> or thanks even
[18:10] <dobey> brb
[18:11] <vila> mmcc: oh, hmm, I wasn't completely out :) One last question:
[18:11] <mmcc> vila, shoot
[18:11] <vila> mmcc: does lp:~mikemc/ubuntuone-control-panel/catch-quit address quitting the app when using the quit item in the system menu ?
[18:12] <mmcc> vila: yes, it should.
[18:12] <vila> mmcc: excellent, I forgot to mention that in my test report as I remember seeing that branch... but wasn't able to check while testing
[18:13] <vila> mmcc: nor if it that was a bug or a feature ;)
[18:13] <mmcc> vila: ah, ok. cool. well, I've been alternating between using cmd-q and the quit menu item just to give it a good testing myself. feeling pretty secure about that part of it
[18:14] <mmcc> not yet 100% sure that it fixes the issue where it would sometimes hang on quit, though :\ -- that one I can't reproduce reliably
[18:14] <mmcc> (referring to bug 1042834)
[18:21] <gatox> ok.... i've everything almost fixed \o/
[18:33] <mmcc> is the systray.py menu ever used on ubuntu? we're not starting it by default…
[18:34] <gatox> mmcc, for testing..... but is not used by default in ubuntu
[18:34] <gatox> mmcc, it works....... but we use the other menu in ubuntu
[18:35] <mmcc> gatox: ok. I'm wondering about why you used a timer to update the recent transfers menu
[18:35] <gatox> mmcc, because we decided not to spam the process for each signal that is emitted
[18:39] <ralsina> mmcc: also, on ubuntu, those signals are broadcasted to all apps on the session, which means a *lot* of work for the system
[18:40] <mmcc> oh, I meant instead of just updating the menu when it is shown
[18:41] <mmcc> I see there are showEvent handlers with a comment that they don't get called on ubuntu, but if you instead connect them to aboutToShow and aboutToHide, those work
[18:41] <mmcc> by "showEvent handlers" i meant "a showEvent() and hideEvent() method"
[18:42] <gatox> mmcc, but the menu can be updated while it is being shown too
[18:42] <mmcc> so then you don't need a timer at all, you just update the menu when it's shown - but I asked about the timer because I was curious if it was supposed to update live as you hold the menu open
[18:42] <mmcc> right, only that part does not work on osx :)
[18:43] <mmcc> so that's why I asked about ubuntu, updating live works on ubuntu?
[18:43] <mmcc> I guess I'll go check :)
[18:45] <gatox> mmcc, why it doesn't work on mac? what did you see?
[18:45] <mmcc> hmmm, no, on ubuntu I see no transfers in the menu at all, even though the sync status says I'm downloading stuff
[18:46] <mmcc> on mac, when I hook up the signals, I see the transfers listed in the menu, but if I hold down the menu, it doesn't change even though I see logs showing  the handler getting called with new info every time the timer fires
[18:46] <gatox> ralsina, is that ^ related to the bug you were fixing about the events changes?
[18:47] <mmcc> I suspect that changing a QMenu while it's shown doesn't work
[18:47] <mmcc> (on osx)
[18:48] <mmcc> also, shouldn't we have these file name menu items do something when you select them? like show the file in the finder/explorer or something?
[18:50] <dobey> mmcc, gatox: https://code.launchpad.net/~dobey/ubuntuone-client-data/mac-build-icns/+merge/128304
[18:50] <gatox> dobey, on it
[18:57] <mmcc> dobey: running setup.py build_icns on my mac, it complains that I don't have icontoo
[18:57] <mmcc> icontool
[18:57] <mmcc> where can I find that?
[18:59] <dobey> hmm
[18:59] <ralsina> gatox: could be, in nightlies, but shuld also be fixed today
[19:00] <dobey> mmcc: lp:icontool
[19:00] <dobey> i guess just poking the timestamp to ensure the PNG files are new enough, isn't enough
[19:01] <dobey> mmcc: you'll also need inkscape and some perl modules to use that :-/
[19:01] <dobey> maybe i should just make build_icns not run the build_png bit?
[19:07] <mmcc> sorry, had a dog cleanup emergency there…
[19:08] <mmcc> I don't feel strongly either way - I can grab the deps and test the whole thing, or we can separate the icns from the png building
[19:09] <mmcc> if you want to just build the icns once and commit it, then maybe the right thing to do is leave it as is and check that we can build the whole thing on mac
[19:10] <mmcc> so we don't have to bounce around between linux and mac to build everything
[19:10] <mmcc> ok, I have to run for lunch… back in a bit
[19:11] <dobey> mmcc: right; i'm just concerned about all the additional deps on mac, and i don't know if the icontool/inkscape bits will work on mac
[19:55] <gatox> mmcc, ralsina i have the public files api working fine, and with the current tests passing in all the platforms.... i'll check the diff against trunk to see which new tests should be included and propose today or monday morning
[19:55] <gatox> fine and as it should
[19:56] <ralsina> cool
[19:57] <ralsina> gatox: good job, looking forward to the branch
[20:22] <gatox> ralsina, mmcc if you can review the u1-client branch please: https://code.launchpad.net/~diegosarmentero/ubuntuone-client/ubuntuone-client-publishapi/+merge/128312
[20:23] <gatox> i've another one for u1-cp that i'll proposing soon
[20:28] <dobey> gatox: why did your one branch fail with 67 versions of the same error about QThread?
[20:28] <dobey> gatox: ah, you broke the backend tests
[20:28] <gatox> dobey, which branch?
[20:28] <dobey> oh no, not the backend, sorry
[20:29] <dobey> gatox: shares-broken
[20:29] <dobey> https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/shares-broken/+merge/128108
[20:32] <gatox> dobey, mmmm..... that's working here..... i just run the tests.....
[20:37] <dobey> gatox: weird
[20:38] <gatox> dobey, did you executed there too?
[20:38] <dobey> gatox: i just ran the tests myself on the tarmac machine, and they passed for me :-/
[20:38] <gatox> :S
[20:38] <dobey> gatox: so let's try again
[20:39] <dobey> gatox: i did dist-upgrade before i did that though, so maybe something was messed up when tarmac ran
[20:45] <gatox> ralsina, mmcc and this is the other branch: https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/u1-cp-publishapi/+merge/128316  ..... so the api works in windows and darwin as it should
[20:51] <mmcc> gatox, that u1-client branch looks good, but it would be a lot easier to review with some more explanation. could you write a description that says exactly what the problem was and how this fixes it? And it seems like the test was just updated so it wouldn't break, but it'd be good to have a test that breaks with the old code and works with the new…
[20:51] <mmcc> that is, a new test that e.g. tries to connect two handlers and shows that they don't both get called with the old code
[20:57] <mmcc> also, the control panel branch doesn't make sense to me - do you still have to re-set the handlers every time you call get_public_files or share_file, if the u1-client end of things is keeping handlers as a list? It seems like you should be able to leave the control panel the way it is in trunk now if the u1-client changes work…
[21:01] <gatox> mmcc, u1-client is cleaning all the signals connected after the signal is emitted..... i assume that it is doing this to behave as in linux with dbus
[21:04] <mmcc> gatox: can you point me to where it cleans them?
[21:04] <gatox> mmcc, let me find it again
[21:05] <mmcc> I ask because I didn't think it did that with the status changed handler, when I worked on that…
[21:06] <mmcc> There, the issue was that we were setting two handlers in control-panel and only one of them was being saved, but the handler was never cleaned by u1-client
[21:06] <mmcc> (only the last one set was being saved)
[21:06] <mmcc> that's why I used a list of handlers there
[21:07] <dobey> mmcc: any luck with icontool/inkscape, or should we disable the build_png command on darwin?
[21:08] <mmcc> dobey: ah, sorry, I didn't try that yet… I'll go poke at it now
[21:09] <dobey> mmcc: no problem, would just like to get this icon stuff taken care of before i go on holiday :)
[21:11] <ralsina> dobey: is it this monday?
[21:11]  * ralsina wants to avoid touching canonicaladmin
[21:11] <mmcc> hmm, so I need gnome-autogen? oof, maybe let's disable buildpng
[21:11] <mmcc> ralsina: columbus day is monday, yes
[21:12] <mmcc> er, but I guess I don't know if dobey is taking off more. shouldn't answer for him
[21:12] <dobey> ralsina: yes; well i'm on holiday all week as i said in the call yesterday :)
[21:12] <ralsina> dobey: cool
[21:13] <ralsina> dobey: have fun!
[21:14] <mmcc> ralsina: yeah, I'm really bad about paying attention to holidays - but I will be off Monday for columbus day, even though that was never a thing anywhere else I've worked
[21:14] <gatox> mmcc, here is disconnected: ubuntuone-client/ubuntuone/platform/tools/__init__.py:288
[21:15] <mmcc> at UCSD they took César Chávez Day instead
[21:15] <mmcc> gatox thanks looking
[21:17] <dobey> ugh, apparmor
[21:19] <mmcc> gatox thanks, that makes sense now
[21:20] <mmcc> so, do we actually need to have a list of handlers in ubuntuone-client then? I guess it can't hurt, but are we really registering multiple handlers for the same signal in the short time between making that call and getting the signal?
[21:21] <ralsina> Cesar Chavez? The boxer? ;-)
[21:21] <ralsina> mmcc: I think for US employees the guideline is some federal holidays list, you should ask HHRR, I even forget my own holidays half the time ;-)
[21:22] <mmcc> ralsina: yeah, it's this: http://www.opm.gov/Operating_Status_Schedules/fedhol/2012.asp
[21:22] <mmcc> it came up on the canonical-usa mailing list this week, precisely because no one except post offices takes columbus day off
[21:22] <mmcc> so some helpful soul reminded us
[21:23] <ralsina> mmcc: it's an elaborate scam. We *are* the post office. Surprise!
[21:24] <mmcc> ralsina: so does that mean I can start working on that email client I have on the back burner?
[21:25] <ralsina> mmcc: no, you are now the maintainer for sendmail 11
[21:25] <ralsina> mmcc: *on windows*
[21:25] <mmcc> that sounds like fun
[21:26] <dobey> yay, test boot from pxe working so far
[21:26] <dobey> but is doomed to fail
[21:29] <ralsina> EOW for me. See you all on monday!
[21:29] <mmcc> bye ralsina
[21:29] <dobey> ralsina: see you in ~10 days
[21:29] <mmcc> and I'll see you tuesday
[21:31] <ralsina> slackers!
[21:31] <ralsina> ;-)
[21:31] <dobey> mmcc: so icons? :)
[21:32] <mmcc> dobey: see above, I gave up when the trail of dependencies led to gnome-autogen…
[21:32] <dobey> ah
[21:32] <mmcc> sorry, I prefixed that with 'hmm' instead of dobey. thought they were synonyms
[21:34] <gatox> mmcc, ok..... i'm having a lot of problem trying to write that test you mention because of the way this works..... i can do a test patching everything but it won't reflect the real behavior so doesn't have sense..... i'll go back to this on monday
[21:34] <dobey> mmcc: removed the build_png chaining and pushed now.
[21:34] <ralsina> gatox: monday is a holiday, you swapped?
[21:34] <gatox> ralsina, yes..... i don't have more holidays this year
[21:34] <mmcc> ok gatox, sorry to cause extra work :\ but it'll be good to have that. maybe take a look at the test I wrote for my thing, I used a deferredqueue
[21:35] <ralsina> gatox: calavera no chilla :-)
[21:35] <gatox> mmcc, is not the same as in u1-client the ones from u1-cp
[21:36] <gatox> ok...... i'm off
[21:36] <gatox> byeeeeeeee
[21:39] <dobey> mmcc: what other icons do we need to add for darwin?
[21:40] <mmcc> dobey: do you have lisette's design share? there's at least a monochrome menubar icon in there
[21:40] <dobey> yes
[21:40] <dobey> there are 2 sets of monochrome icons in there
[21:41] <dobey> "light" and "dark" ones
[21:41] <mmcc> dobey: in this path? U1_design_share from Lisette / Desktop / mac_client / top-menu_icons / mac_icons / 32
[21:41] <mmcc> (there's a 32 and 16 after mac_icons)
[21:42] <dobey> let me see what i have
[21:44] <dobey> ah, ok, so they are the same as the ubuntu-mono-light versions, though the 32px size is different
[21:44] <dobey> mmcc: what does osx require? both 16 and 32? and are we only going to have the logo icon there?
[21:46] <mmcc> dobey: I think the short answer is that we will probably want to have both
[21:47] <dobey> mmcc: and they have to be in PNG i guess, for qt?
[21:47] <mmcc> the long answer is that it's a little complicated and I haven't had time to figure out how it should work yet. You set that using an NSImage (not a path to an icns file) which can have multiple resolutions, and our code is creating a QIcon using a png
[21:48] <mmcc> so maybe for retina-friendly darwin we need to bypass the QIcon, it depends on how Qt uses the contents of the icon;
[21:48] <dobey> well, a PNG can't have both resolutions
[21:48] <mmcc> of the qicon…
[21:48] <mmcc> right
[21:48] <dobey> we should probably bypass the qicon anyway, and do the standard mac thing instead
[21:49] <dobey> though, i have no idea how to generate the correct PDF from the SVG :)
[21:50] <mmcc> Heh. I'm beginning to think this sys tray icon and menu should just be a separate pyobjc thing and not use qt at all… since the qmenu doesn't update like it does on linux, and the qactions don't appear to listen to setEnabled(false)
[21:52] <dobey> heh
[21:53] <dobey> mmcc: should you just pull in the PNG by hand for now, and we can fix it up better later on then?
[21:54] <mmcc> dobey: yeah, I think that's the best way for now. I would also like to change the icon to show the current sync state, and I want to run that by design. It kind of seems like that's what lisette was thinking anyway
[21:54] <dobey> mmcc: and hopefully with my branch now, you can build the ubuntuone.icns on darwin and it has all the sizes in it, including the 'retina' sizes
[21:54] <mmcc> dobey: checking now
[21:56] <mmcc> dobey: yes it works
[21:57] <mmcc> funny that you have to have 256x256@2x *and* 512x512 when they're exactly the same
[21:57] <mmcc> I guess they don't have to be
[21:57] <mmcc> sometimes the larger ones have more detail
[21:57] <mmcc> anyway my name is Michael McCracken and I'm going to approve of that branch
[21:58] <mmcc> +1
[21:59]  * briancurtin whispers "paid for by friends of Michael McCracken"
[21:59] <mmcc> :D
[22:00] <dobey> mmcc: yeah, the @2x aren't properly done right now, they're just the same as the others; we should get that fixed in the future, but i don't want to have to be the one trying to explain what needs to be different between them
[22:00] <mmcc> dobey: hehe. honestly it's also ok to have them be the same… it's only if designers want to add detail to the larger ones.
[22:01] <dobey> mmcc: well, the way lisette explained it to me, the @2x have some subtle but important differences
[22:01] <dobey> and those were visible in the previous set of icons we had there, from here
[22:02] <dobey> err, from her
[22:02] <mmcc> hm, ok then
[22:04] <dobey> hrmm, and gatox's branch failed again with the 67 QThread errors
[22:06] <dobey> mmcc: anyway, after my branch lands, can you propose a branch to ubuntuone-client-data to replace the ubuntuone.icns with the one generated on darwin?
[22:06] <mmcc> dobey: sure
[22:29] <mmcc> whoa, that's weird, so on linux, QMenu seems like it sends the aboutToShow event constantly, as fast as it can, as long as you are holding the menu open
[22:33] <dobey> ok, my branch is landed. i need to get away from here
[22:33] <dobey> later :)
[22:33] <dobey> mmcc: propose that branch, and i'll poke at it later
[22:33] <mmcc> dobey: ok,will do
[22:36] <mmcc> it's here: https://code.launchpad.net/~mikemc/ubuntuone-client-data/newicns/+merge/128329
[23:12] <mmcc> ok, done! see you tuesday, channel