[06:00] <rye> fwiw, metadata issue about empty data with existing key is found on windows
[07:16] <mmcc> finally got a little bit of time to check back in on the bug we were talking about 7 hours ago. I've verified that we do end up calling UbuntuOneClient.is_connected several times between the time we first call connect() and the time the ipc_client_connect call completes the first time.
[08:55] <mmcc> maybe because I'm more familiar with threads than twisted-style async code, but to me it looks like the simplest solution is to use a deferredlock. it's already used for a similar problem in sso's tcpactivation
[08:55] <mmcc> going to test that idea quickly and head to sleep
[09:02] <JamesTait> Good morning, from a cold and rainy Derby! :-/
[09:03] <mmcc> hi JamesTait, I guess it's morning here too…
[09:05] <JamesTait> mmcc: Aren't you in Ireland? Or did I mix you up with someone else?
[09:05] <mmcc> JamesTait: nope, I'm in california
[09:05] <JamesTait> mmcc: Clearly I have you mixed up then. :-P
[09:08] <vila> mmcc: oh, you're there ! What TZ are you in ?
[09:08] <vila> mmcc: next: where is my bundle ? :-D
[09:08] <mmcc> vila, I'm in US pacific, it's 2am
[09:08] <vila> ouch, go to sleep !
[09:08] <mmcc> I will put something up for you before I head out
[09:09] <vila> mmcc: remember: obscure bugs are not easier to see in the middle of the night ;-D
[09:09] <mmcc> vila: easier to hear them when it's quiet
[09:09] <vila> ... who am I to say that... when you're in hot pursuit... nothing can stop you ;)
[09:09] <vila> mmcc: hehe, so true ;)
[09:10] <vila> mmcc: I won't distract you anymore then ;)
[09:16] <ralsina> morning!
[09:16] <ralsina> mmcc: wtf?
[09:16] <mmcc> ralsina: :D
[09:16] <mmcc> don't worry, I was asleep from ~9-12pm
[09:21] <mmcc> well, I'm still getting the loading overlay intermittently, but it's from the "Hi, $user" stuff at the top - I can see the folders tab loaded correctly behind it
[09:22] <mmcc> anyway, I've fixed the behavior that we saw with tcpactivation already-started test not working for SD. I'm replying to your email, ralsina, with details
[09:24] <mmcc> it looks like the controlpanel backend quota API call is not returning
[09:30] <trijntje> Hi all, are there plans to translate the U1 webinterface?
[09:31] <trijntje> I've found this on askubuntu, but the latest comment is from last year:http://askubuntu.com/questions/29839/how-to-translate-ubuntu-one-web-ui
[09:34] <ralsina> mmcc: awesome, then ugh
[09:34] <ralsina> mmcc: go to sleep
[09:43] <mmcc> ok, this build has a bit of extra debug print crap in it, but it also has the fix for the SD IPC issue we found: http://ubuntuone.com/3tuIIvLyVlqMlfb2WPsXum
[09:44] <mmcc> cc vila  --^
[09:44] <mmcc> and with that, I'm going back to sleep
[09:55] <mandel> mmcc, what the hell are you doint up!?
[09:55] <mandel> ralsina, mmcc just notice you guys.. wtf
[09:58] <ralsina> trijntje: sorry the web guys are not up yet
[09:59] <ralsina> mandel: I just got up one hour earlier, don't worry ;-)
[09:59] <trijntje> ralsina: are they in the us?
[09:59] <ralsina> trijntje: argentina and the US mostly
[09:59] <mandel> ralsina, so I'm sending an email regarding the crash, will be looking at logging right now
[10:00] <ralsina> mandel: ok
[10:00] <mandel> ralsina, we used to use pycurl, right?
[10:03] <trijntje> ralsina: ok, thanks. Ill try again in 8 hours or so ;)
[10:03] <mandel> ralsina, so.. lp is down?
[10:04] <ralsina> mandel: yes
[10:05] <ralsina> mandel: on the pycurl stuf
[10:05] <ralsina> mandel: have not looked at launchpad
[10:05] <mandel> ralsina, but we don't longer use it right?
[10:05] <ralsina> mandel: I think we still do. We switched to pycurl from httplib because of the SSL cert checking
[10:06] <ralsina> mandel: but not sure if trunk still has that
[10:07] <mandel> ralsina, oh, well because of this: http://bugs.python.org/issue816476
[10:07] <mandel> ralsina, which is the only ref I could find for the crash
[10:07] <mandel> ralsina, but is a very very old bug
[10:07] <mandel> ralsina, also,m please review: https://code.launchpad.net/~mandel/ubuntuone-client/fix-logging/+merge/121816
[10:08] <ralsina> mandel: got t
[10:16] <ralsina> mandel: diff doesn't update :-(
[10:18] <ralsina> mandel: about the GC crash, we can fix for the next release since u1cp will restart sd as needed
[10:20] <mandel> ralsina, will it?
[10:20] <mandel> ralsina, we need to check that
[10:21] <mandel> ralsina, joder! bloody lp, I'll propose a branch without the bug linked
[10:22] <mandel> ralsina, I sent the email with my thoughts about a couple of things, let me know asap what you think about the ipc_client solution
[10:25] <ralsina> mandel: remember that we need to wait until after all signals connect to use sd_client
[10:25] <ralsina> mandel: so would your solution do the same?
[10:26] <ralsina> other than that, one or the other feel the same to me
[10:27] <mandel> ralsina, yes, is the same
[10:27] <ralsina> be-a-parent time
[10:27] <ralsina> will be back in ~1 hour
[10:27] <mandel> ralsina, the main diff is one is not async and the other is
[10:27] <mandel> ralsina, I prefer to use the connected_d trick to be honest
[10:27] <ralsina> mandel: u1cp is useless until we get the sd connection anyway
[10:28] <mandel> ralsina, yes, is just ui, with a backend but ui :)
[10:56] <mandel> ralsina, FYI https://code.launchpad.net/~mandel/ubuntuone-client/fix-logging/+merge/121825 is updated, apparently some cron job where not ready just yet
[11:01] <ralsina> mandel: global +1
[11:02] <ralsina> mandel: and +1 on not overcomplicating things :-)
[11:06] <mandel> ralsina, yes, I'm nearly done with the tests so I'll propose the mp in a few mins
[11:40] <mandel> ralsina, I need an approve and then the global approve: https://code.launchpad.net/~mandel/ubuntuone-client/fix-logging/+merge/121825
[12:05] <ralsina> mandel: could swear that's what I did
[12:05] <ralsina> mandel: fixing...
[12:05] <mandel> ralsina, no problem :)
[12:06] <ralsina> mandel: done
[12:06] <ralsina> good morning alecu!
[12:06] <alecu> hello, all!
[12:12] <mandel> morning
[12:22] <ralsina> alecu: just finished talking with lisette about the file share tab UX and I have some ideas that don't involve changing UI so I'll tackle that next week, and for now it stays as it is
[12:22] <ralsina> alecu: also, neil replie, but I have not looked at the doc yet, and I suspect I will have my hands full with mac bits today
[12:24] <alecu> ralsina: ok, I'll give that a look.
[12:24] <alecu> ralsina: can you fwd it to me?
[12:25] <ralsina> alecu: sure!
[12:25] <ralsina> alecu: thought you were in the CC
[12:26] <mandel> alecu, corruption of metadata happens with a single instance of sd running, the crash has nothing to do with more than one daemon running
[12:27] <ralsina> mandel: two different things
[12:27] <mandel> exactly, one has nothing to do with the other
[12:27] <ralsina> mandel: the GC is not related to the corruption of metadata AFAIK
[12:27] <mandel> ralsina, the GC call happens with a single sd running and accepting lisettes share, after that the metadata is corrupted
[12:28] <mandel> alecu, ^
[12:28] <alecu> mandel: the crash has nothing to do with more than one daemon running. Yes, I made that clear on the second email.
[12:28] <alecu> mandel: but metadata corruption *can* happen when two SDs are running.
[12:28] <alecu> mandel: tritcask is not multiprocess safe
[12:28] <mandel> alecu, ralsina, the metadata probably goes nuts because is left in a weird state due to the crash
[12:29] <mandel> alecu, yes, but I'm no interested in tritcask, AFAIK it works correct in all cases when there is a single daemon
[12:29] <alecu> mandel: I don't think that's the case.
[12:29] <mandel> alecu, why not?
[12:29] <alecu> mandel: because tritcask is self-healing.
[12:29] <alecu> mandel: tritcask has a journal
[12:30] <alecu> mandel: that is, at a given point it has a few files that read only, and one file that is append only
[12:30] <alecu> mandel: and each record written to the append only file, has a crc of the record contents
[12:31] <alecu> mandel: so, on starting SD, and replaying the journal, each record that has the crc wrong is discarded.
[12:31] <alecu> mandel: ergo: self-healing.
[12:32] <alecu> mandel: but it's not designed to be written by more than one process at a time.
[12:33] <alecu> mandel: tritcask does not expect the files it considers read only to be written by other process
[12:34] <mandel> alecu, I can 100% ensure you that this is happening with a single process and is getting busted, so there is a bug there somewhere
[12:34] <alecu> mandel: are you talking about the GC issue?
[12:35] <mandel> alecu, yes, which then gets the metadata busted
[12:36] <mandel> alecu, that issues has two things, one, the crash of the process, second, in the next run unless metadata is remove sd will crash
[12:36] <mandel> alecu, and this has happened to chaselivingston too, we needed to remove his metadata to get u1 back to work
[12:37] <alecu> mandel: get the eraser, let's think of a different timeline:
[12:37] <alecu> 1) sd crashes with GC error
[12:37] <alecu> 2) u1cp is querying SD many times per second, starts two copies of SD
[12:37] <alecu> 3) the two copies corrupt the metadata.
[12:37] <alecu> 4) ....
[12:37] <alecu> 5) profit!
[12:38] <alecu> mandel: I say 4 is "we fix two SD starting at the same time"
[12:38] <ralsina> so, if mmcc's lock fixes 2)  ...
[12:38] <mandel> alecu, I was starting sd manually, so we have to remove the u1-control panel out of the equation
[12:39] <ralsina> BTW, u1cp makes a bazillion calls to sd's get_homedir we should cache that
[12:39] <mandel> alecu, so, we only have sso and sd running, no sdtool starting a gazillion times the sd process
[12:39] <mandel> ralsina, I don't know why we have more than one connection in that things.. one per tab seems too much..
[12:39] <mandel> but at least is showed an error
[12:39] <ralsina> mandel: each tab has a sd_client but they are all the sameinstance
[12:40] <mandel> ralsina, that cannot be, how are we starting more than once sd if that is the case?
[12:40] <alecu> ralsina: so, if mmcc's lock fixes 2), we still need to deal with the GC error, which is the scary one to me.
[12:41] <mandel> alecu, and too me, more than the multiple instances.. 'cause that one we understand
[12:41] <alecu> ralsina, mandel: a tritcask bug we can probably fix. A bug in the C extension of macfsevents sounds scarier.
[12:41] <mandel> alecu, ralsina, is there a bug number for the connection issue, I have a branch from mmcc with tests
[12:41] <mandel> could not think a very smart test rather than asserting that more than one client can connect and will be lock until all actions have been performed..
[12:42] <ralsina> mandel: that test shuld be enough since that's the behaviur we want
[12:42] <ralsina> ou*
[12:43] <alecu> mandel: btw: do you get the GC errors when running with the root daemon?
[12:43] <mandel> alecu, I need to test that, will do after I have lunch
[12:45] <mandel> bug 1043287
[12:46] <mandel> ralsina, alecu, feel free to review: https://code.launchpad.net/~mandel/ubuntuone-client/guard-ipc-connect/+merge/121854
[12:47] <ralsina> mandel: that includes mmcc's branch?
[12:47] <mandel> ralsina, yes
[12:47] <ralsina> mandel: cool
[12:47] <mandel> ralsina, alecu, the test loops through the different connect steps so that we have one client in the middle of the connection and 3 others trying to connect
[12:48] <mandel> ralsina, alecu, it does like this, perform first step, block there , 3 others try to connect, perform 2 steps, block, 3 others try to connect etc..
[12:48] <mandel> in each iteration we assert that the connection steps where done in the correct order
[12:49] <mandel> as good as I could do the test, if you see a better way to do it please let me know
[12:50] <alecu> mandel: is this branch based on mmcc's guard-ipc-connect branch?
[12:50] <mandel> alecu, yes, branched form it and just added the test
[12:50] <alecu> mandel: great
[12:51] <mandel> I'm off to get the salad :)
[12:51]  * mandel lunch
[13:37] <alecu> ohhhoohhhohhh... I hate threads so much.
[13:41] <dobey> threads are awesome
[13:43] <ralsina> hate is awesome
[13:44] <ralsina> dobey: there will be no UI change branch in u1cp today, so feel free to release at will
[13:46] <dobey> cool
[13:54] <ralsina> dobey: after you are done with the releases, you want to talk with muffinresearch about the eventual u1ms changes for rb
[13:56]  * mandel back
[13:56] <mandel> ralsina, so there are several steps in the connection, get the client, get the root object, get the remote objects and connect to the singnals
[13:57] <mandel> ralsina, being async multithread etc.. you can have clients connecting between any of the steps, so the tests uses the deferred to block between one of the steps
[13:57] <mandel> then uses other clients to connect, which should be block thanks to the lock and after those other clients try to connect the test moves up the pipeline of connection steps
[13:58] <mandel> it does that for each possible case
[13:58] <mandel> ralsina, does the test make more sense now?
[14:02] <ralsina> mandel: yes, I know the theory :-)
[14:02] <ralsina> mandel: and it does seem to do that, I am just not confident in my ability to find bugs in it today
[14:03] <mandel> ralsina, ah, ok :)
[14:05] <vila_> ralsina, mmcc : Trying to install the u1 app, the finder tells me: The operation can't be completed because the item "__boot__.py" is in use
[14:06] <vila_> with install == copy the new app above the old one
[14:07] <vila_> I moved the existing one out the way, install the new one and I'm rebooting
[14:07] <vila_> ralsina, mmcc : Should I file a bug for that ?
[14:08] <ralsina> vila: yes please
[14:08] <ralsina> vila: you probably need to stop it before overwriting it
[14:08] <vila_> ralsina: stopping what ?
[14:09] <vila_> sd ?
[14:14] <ralsina> vila: yes
[14:15] <vila_> ralsina: how do I do that (for reference) ?
[14:15] <vila_> launchctl bliblablo ?
[14:15] <ralsina> vila: I suck as a mac user, so I would do something like ps aux check the PID and kill it with kill :-
[14:15] <ralsina> )
[14:17] <vila_> oh and nothing will restart it ?
[14:17] <vila_> oooh, progress, no more 'getting... please wait'
[14:18] <vila_> click sign me in .... sorry an error has occurred...
[14:18] <vila_> DeadRefecenceError 'Calling Stale Broker'
[14:18] <vila_> known bug ?
[14:19] <vila_> ralsina: ^
[14:19] <mandel> vila, I'm working on it :)
[14:20] <mandel> ralsina, sso closes to quick in some cases and we have stale objects, I'll do the same patch that i did for the tabs problem
[14:20] <mandel> ralsina, will restart the sso process if needed
[14:21] <vila_> mandel: bug # so I can subscribe ?
[14:21] <mandel> vila_, I need to create one, sorry, give me a sec
[14:21] <vila_> mandel: no worries
[14:22] <vila_> mandel: let me know when a new bundle is available
[14:23] <mandel> vila_, bug 1043367
[14:23] <ralsina> mandel: cool, yes, saw that
[14:23] <ralsina> looks like logging in is reliable again!
[14:24] <ralsina> except I have to start everything manually but that's my setup I think
[14:24] <mandel> ralsina, what do you mean with logging? as the log.debug?
[14:24] <ralsina> mandel: oops, meant login
[14:25] <mandel> ah, ok :)
[14:33] <alecu> mandel: you said "the metadata gets corrupted with a single daemon" -> do you have a log of what happens when SD tries to open the corrupt metadata?
[14:35] <mandel> alecu, is in the mail, I just get that
[14:35] <mandel> alecu, that is all I get: http://paste.ubuntu.com/1173495/
[14:36] <mandel> alecu, is the sd logging do you need me to get anything else?
[14:36] <alecu> mandel: how do you know that the metadata is corrupt at that point?
[14:37] <mandel> alecu, I just suspect because removing the metadata fixes it and works normally
[14:37] <alecu> mandel: btw: U1_DEBUG=True does nothing useful for SD, so  try running sd with --debug
[14:37] <mandel> alecu, and why does it print: 2012-08-29 11:43:23,192:192.228078842 - ubuntu_sso.utils - DEBUG - _get_dir: trying use dir at u'/Users/mandel/Projects/Canonical/ubuntu-sso-client/trunk/bin' (exists? True)  ???
[14:38] <alecu> mandel: well, it does something: it enables the debug lines in the imported sso modules
[14:38] <mandel> ah. bummer, alecu let me run that again then
[14:38] <alecu> mandel: make sure your metadata is corrupt first! ;-)
[14:38] <mandel> alecu, it is :)
[14:39] <alecu> awesome! ?
[14:39] <alecu> mandel: btw: did you get the GC error when running with the root daemon?
[14:39] <alecu> mandel: I'm trying to single out macfs as the GC error culprit
[14:41] <mandel> alecu, Im fixing sso bugs and will do that asap (using the daemon)
[14:42] <mandel> alecu, here is a run with --debug: paste.ubuntu.com/1173910
[14:42] <mandel> alecu, I really hope is not fsevents..
[14:43] <alecu> mandel: is that the start of the run?
[14:43] <alecu> mandel: can I see the whole log?
[14:44] <mandel> alecu, that is the end of the log, I can get you all of it np, one sec
[14:45] <alecu> mandel: anyway: that seems to be working. Why do you say that the metadata is corrupted, and that you need to delete it?
[14:45] <alecu> mandel: (though I still would like to see the start of the log)
[14:46] <mandel> alecu, because if you don't delete it the things does not work, I only tried that because in a guest account everything worked ok
[14:46] <mandel> alecu, Is work in progress to find out what is going on
[14:48] <alecu> mandel: what "things does not work" ? I SD activity happening there.
[14:48] <alecu> mandel: probably when you delete the metadata you see *a lot* more activity, because all the state has to be resyncd
[14:49] <alecu> * I see SD activity happening in the log
[14:49] <mandel> alecu, yes, but that is not the case, when I say it works I mean it does not crash
[14:49] <alecu> mandel: !!!!
[14:49] <alecu> mandel: and how did it crash in the first time?
[14:50] <mandel> alecu, paste.ubuntu.com/1173923
[14:50] <alecu> mandel: I saw that crash (GC) a loooot, and it did not have to do with corrupt metadata!
[14:50] <mandel> alecu, the first time, bad luck, I accepted the u1 design share from lisette and it happened
[14:50] <alecu> mandel: yesterday I saw that a lot while running mmcc's bundles.
[14:51] <mandel> alecu, did you? I have only been able to reproduce it with that share, else it works fine in my system..
[14:51] <alecu> mandel: but did you have broken metadata when you accepted that share?
[14:51] <alecu> mandel: let me repeat what I think, out loudly: this GC crash has nothing to do with metadata.
[14:52] <mandel> alecu, no, everything work ok before that
[14:52] <mandel> alecu, never saw the GC error at any point
[14:52] <ralsina> alecu, mandel: I feel you are talking past each other. Mumble?
[14:52] <alecu> mandel: did you have any UDF syncd?
[14:52] <mandel> alecu, I don't use UDFs at all
[14:52] <alecu> mandel: that's the datapoint
[14:52] <alecu> mandel: there we go
[14:52] <mandel> alecu, but I did have shares syncing
[14:53] <alecu> how many shares?
[14:53] <mandel> alecu, as far as I remember 2
[14:53] <mandel> alecu, I synced the one from cparrion that has lots of : to test that we had no problems with those and some other one
[14:53] <alecu> I so absolutely fraking hate debugging thread issues.
[14:54] <mmcc> hi folks, catching up
[14:54] <mandel> alecu, +1000000
[14:54] <alecu> mandel: right, but that's a small share compared to lisette's, isn't it?
[14:54] <alecu> mandel: I also started getting the GC error after syncing with a huge udf
[14:55]  * alecu checks if one thread is started per volume.
[14:55] <mandel> alecu, uhhh
[14:56] <ralsina> hi mmcc
[14:56] <ralsina> mmcc: be aware, you are taking monday off.
[14:56] <mandel> alecu, mmcc, please tell me that fsevents is not starting a thread per child dir..
[14:56] <mmcc> ralsina: yep, on the calendar
[14:56] <ralsina> mmcc: OTOH, because of past experience, please don't take this as an endorsement of crazy hours, because it isn't ;-)
[14:57] <mmcc> mandel: I think it's a thread per watch
[14:57] <mmcc> ralsina: heh, understood
[14:58] <mmcc> mandel: I'll look to be sure
[14:59] <mandel> alecu, ralsina, mmcc, for mere completeness: https://code.launchpad.net/~mandel/ubuntu-sso-client/guard-ipc-connect/+merge/121879 same as the u1-client guard but for sso
[14:59] <thisfred_> me
[14:59] <mmcc> me
[15:00] <ralsina> me
[15:00] <alecu> mandel: one fsm, one watchmanager, one observer, one thread.
[15:00] <mandel> me
[15:00] <briancurtin> me
[15:01] <mandel> alecu, me no comprende? what?
[15:01] <alecu> me
[15:01] <ralsina> dobey: standup
[15:01] <ralsina> ok, dobey is last, go thisfred before you doze off!
[15:01] <mmcc> DONE: QA release, debugging controlpanel
[15:01] <mmcc> TODO: more more controlpanel bugs
[15:01] <mmcc> BLCK: no
[15:01] <mmcc> NEXT: ralsina
[15:02] <ralsina> DONE: fixed a couple of bugs, lots of reviews, mgmt call, other calls, helped around, mac twiddling TODO: more mac twiddling, reviews, etc. BLOCKED: not feeling great, but no, NEXT: mandel
[15:02] <ralsina> mmcc: early :-)
[15:02] <mandel> DONE: Bug 1043287 from mmcc branch + tests. Bug 1043353 for completness, bug 1043183.
[15:02] <mandel> TODO: Bug 1043367. Look if that fixes log in for mac keep looking there, help with sd crashing.
[15:02] <mandel> BLOCKED: no
[15:02] <dobey> me
[15:02] <mandel> briancurtin, please
[15:02] <briancurtin> DONE: two unicode/bytes branches that were killing me - one for bytes formatting, one for joining subprocess output, then storing in an envvar, then passing to dbus...need to associate a bug with this
[15:02] <briancurtin> TODO: some unicode/bytes being passed to urllib usage, and a squid test somehow missing an attribute on 3
[15:02] <briancurtin> NEXT: alecu
[15:02] <alecu> DONE: reviews, helped debugging osx craziness
[15:02] <alecu> TODO: more osx debugging, review dash documents
[15:02] <alecu> BLOCKED: no
[15:02] <alecu> NEXT: dobey
[15:02] <dobey> DONE: releases, bug #
[15:02] <dobey> TODO: releases, fix nautilus plug-in for Q, icon generating magic, music store work
[15:02] <dobey> BLCK: None.
[15:03] <thisfred_> DONE: reviews | web api thinking/ exploring TODO: add u1db server code to handle web api calls BLOCKED: no NEXT:dobey
[15:03] <thisfred_> ralsina, sorry on team call as well
[15:03] <ralsina> thisfred_: is ok!
[15:03] <ralsina> Comments?
[15:03] <ralsina> EOM it is
[15:03] <alecu> COMMENT: I hate debugging threads.
[15:04] <dobey> i hate comment threads
[15:05] <alecu> mandel: "one fsm, one watchmanager, one observer, one thread", means that SD with macfsevents only has one of each of those, not many.
[15:05] <thisfred_> I hate smurfs
[15:06] <mandel> thisfred_, con razon, they are belgian :)
[15:06] <mandel> alecu, ok
[15:06] <thisfred_> mandel, hehe
[15:07] <mmcc> alecu, yes that's right - I remembered wrong - one Observer, one thread
[15:08] <alecu> mmcc, mandel: are we still using the patched macfsevents? did we merge the changes from upstream?
[15:08]  * alecu grabs a bite, brb
[15:08] <mmcc> alecu, mandel, I'm using the one from mandel's github
[15:09] <mmcc> mandel, re your completeness branch, is it necessary? utils/tcpactivation already uses a lock in get_active_client_description
[15:09] <mandel> alecu, mmcc, we did merge changes from trunk yes, we can try with the bzr branch from mmcc
[15:12] <mandel> mmcc, did not notice that, let me check
[15:12] <alecu> mmcc, mandel: do you have an url for that macfsevents branch?
[15:13] <mandel> alecu, which, mmcc one?
[15:13] <alecu> mandel: I don't know. The one we are using!
[15:13] <mmcc> https://github.com/mandel-macaque/macfsevents
[15:13] <mandel> alecu, https://code.launchpad.net/~mikemc/+junk/python-macfsevents is the old before we merged
[15:13] <alecu> mmcc: you are building the bundles with that one?
[15:14] <mmcc> alecu - yes
[15:14] <mandel> alecu, diff with upstream of that branch: https://github.com/malthe/macfsevents/pull/11/files
[15:16] <mandel> mmcc, you are right is not needed, removing it
[15:17] <mmcc> just out of paranoia I just ran the clang static analyzer on _fsevents.c and got no warnings
[15:20] <alecu> mandel: what's the process_asap for?
[15:21] <mandel> alecu, that, according to gatox (who claims that talk with you about this) is to start processing the events before all the streams have been added, that is, as soon as we have one we start processing
[15:22] <mandel> alecu, it looked diff, like here: http://bazaar.launchpad.net/~diegosarmentero/+junk/python-macfsevents/view/head:/fsevents.py#L58
[15:22] <alecu> mandel: that's used each time a new watch is added...
[15:23] <mandel> alecu, I had to add is as a keyword arg else it would not be landed in upstream
[15:24] <trijntje> Hi all, are there plans to translate the U1 webinterface?
[15:24] <trijntje> I've found this on askubuntu, but the latest comment is from last year:http://askubuntu.com/questions/29839/how-to-translate-ubuntu-one-web-ui
[15:24] <alecu> mandel: yes, I recall talking with gatox about the absolute need SD has of having every fs event from the point when the watch is added.
[15:25] <alecu> mandel: I don't recall what came out of that, nor reviewing code.
[15:25] <mandel> alecu, well, that is what he did I just merged with upstream and made the keyword arg changes
[15:26] <mandel> alecu, and we have been using since the beginning
[15:26] <alecu> trijntje: my guess is that it remains in the same state, but we should ping beuno to be sure.
[15:27] <alecu> mandel: right.
[15:27] <trijntje> alecu: thanks
[15:28] <alecu> mandel: anyway I don't see how schedule_callback() without acquiring the lock is any ASAP than doing it without acquiring the lock.
[15:29] <alecu> nor safer, btw.
[15:29] <mandel> alecu, I did not understand well the code to be honest, I just trusted him
[15:29] <mandel> alecu, I specially ask him about this: http://bazaar.launchpad.net/~diegosarmentero/+junk/python-macfsevents/view/head:/fsevents.py#L68
[15:29] <mandel> alecu, which from my point of view is 'funny'
[15:30] <alecu> mandel: https://github.com/malthe/macfsevents/pull/11/files#r1486751
[15:30] <mmcc> mandel: I agree. weird
[15:31] <alecu> mandel: that's just working around thread timing issues by adding needless delays.
[15:32] <alecu> ok, this macfsevents is a bunch of crap.
[15:32] <mandel> alecu, he, but we have to work with it
[15:32] <mandel> alecu, anyone is willing to go to NZ and ask gatox about this ;-)
[15:33] <alecu> mandel: we have to fix SD, we are not forced to work with this.
[15:33] <alecu> mandel: I'm willing to fly, but surely our budget does not allow!
[15:33] <mandel> alecu, piggy back me please :)
[15:34] <alecu> mandel: http://www.youtube.com/watch?v=dYBjVTMUQY0
[15:36] <mandel> alecu, I have longer arms than you ;)
[15:36] <alecu> mandel: "take turns!"
[15:37] <mandel> alecu, nah nah nah, I like to be the outer spoon
[15:37] <mmcc> ok, I'm looking at fsevents.py and I think it needs some love - but where do we stand wrt the other stuff?
[15:38] <mmcc> is the eternal loading overlay fixed for other people with the changes I made last night?
[15:38] <mmcc> and the initial stale broker from SSO is not a great first impression…
[15:40] <beuno> trijntje, right, no plans to translate
[15:40] <mandel> mmcc, I'm nearly done with the stale broker in sso
[15:40] <mmcc> mandel: great :)
[15:42] <trijntje> beuno: ah, too bad. I have to say I'm a bit confused about the fraud thing mentioned on askubuntu. Volunteers translate all of ubuntu without any 'oversight', why should ubuntuone be different?
[15:42] <beuno> trijntje, becuase we deal with money and people's files
[15:50] <trijntje> I still think it would be nice to have the web ui translated, especially since not all functionality is available in the client.\
[15:51] <dobey> we all agree it would be nice
[15:52] <dobey> what functionality isn't available in the client?
[15:52] <mmcc> ralsina, can I get a trivial review for https://code.launchpad.net/~mikemc/ubuntuone-client/change-socket-name/+merge/121643 ?
[15:53] <mmcc> that's an old branch, just cleaning up. not related to our current bugs
[15:53] <trijntje> sharing/publishing files, afaik
[15:55] <ralsina> mmcc: got it
[15:55] <mandel> mmcc, you already have one from me, question, did you make the same change in the daemon side?
[15:56] <mandel> mmcc, as in, when is started by launchd
[15:56] <mmcc> mandel, yes. The daemon changes are still sitting around here. I'll propose them after the merge
[15:56] <mmcc> er, after the release
[15:56] <ralsina> mmcc: global +1
[15:57] <mmcc> great, thanks guys
[15:58] <mmcc> oh, argh. so, colo-branch gets conflicts when creating a new branch from mandel's lp:~mandel/ubuntu-sso-client/guard-ipc-connect -- what's going on there?
[15:59] <mmcc> I clearly don't totally understand colocated branches yet
[15:59] <mandel> mmcc, ein? and I though we said that the dont use that guard branch, right?
[15:59] <mmcc> mandel, that's not the sso one
[15:59] <dobey> trijntje: sharing of folders and publishing of files is certainly doable from Ubuntu; although there are some small UX issues with those
[16:00] <mandel> mmcc, you pasted:  lp:~mandel/ubuntu-sso-client/guard-ipc-connect
[16:00] <mandel> mmcc, that is the sso one
[16:02] <mmcc> oh, so I did. thanks mandel
[16:03] <mmcc> d'oh
[16:03] <mandel> :)
[16:08] <mmcc> ok, so I need to figure out what to work on now
[16:09] <mmcc> mandel, you're doing SSO stale broker now, have you also looked at that JSON error? I know you said you'd looked at it a bit
[16:09] <mandel> mmcc, not yet, I did not have the time
[16:11] <mmcc> ok
[16:12] <mandel> mmcc,  if you want to tackle that go for it
[16:12] <mmcc> I suspect that's the same thing that's killing my quota API call, so I'm going to look at it
[16:13] <mandel> the eagerness that sso has to close itself is amazing..
[16:14] <dobey> ok, lunch time. bbiab
[16:14] <mmcc> mandel: I've noticed the same thing. that refcount decrements as soon as it returns credentials, then boom
[16:15] <mandel> mmcc, yes, very annoying..
[16:21] <ralsina> mandel, mmcc: we *could* make it not-close like we do on windows, but we should go the other way around, really
[16:23] <mandel> ralsina, better do it right
[16:28] <mandel> ralsina, mmcc could it be that the spawn of the ubuntu-sso-login-qt crashes? I'm in the state where I dont get a stale broker, re-send the message but the ui crashes, I look for the pid and it does not exist..
[16:29] <mmcc> mandel: I'd be surprised if it's crashing
[16:30] <ralsina> mandel: unless you didn't python setup.py build it, it should not crash
[16:30] <mandel> mmcc, I know that if I launch it is ok.. but it never appears
[16:30] <mandel> ralsina, and then you solve my problem...
[16:30]  * mandel is stupid
[16:31] <mmcc> mandel: if you keep the activity monitor open you can see it show up and then go away in line with the log entries from U1_DEBUG
[16:31] <mmcc> ah ok
[16:31]  * mmcc has been there
[16:31] <mandel> mmcc, sooo many things to remember!
[16:59] <briancurtin> apt-get upgrade made my terminals gray...weird
[17:02] <alecu> lunch for me
[17:20] <mandel> mmcc, ralsina, I just found the reason why the ui gets grey and you have to restart it, the return code from the sso ui is never received and therefore the signal is never sent
[17:21] <mandel> found it while fixing the stale brokers stuff
[17:21] <ralsina> mandel: great
[17:21] <ralsina> mandel: as in "great that you found it" not great that it happens :-)
[17:21] <ralsina> mandel: any idea why?
[17:22] <mandel> ralsina, looking into it, is in the runner/qt.py code
[17:25] <mmcc> so control panel is making multiple requests to the accounts and quota API …
[17:28] <mmcc> mandel, is that because _show_ui in credentials.py doesn't give spawn_program a reply_handler?
[17:28] <mmcc> or is that a different spawn_program, because that looks like it shouldn't even work
[17:30] <mandel> mmcc, that spawn program you see is the one in __init__ which uses the one in qt.py
[17:30] <mandel> mmcc, but good question  you scared me :)
[17:32] <mmcc> ah ok, good
[17:35] <mmcc> you know, OT a little, but the pattern in all this code of having things with the same name only differentiated by their package name, causes lots of extra mental effort when reading… I think it might be better if (eg) runner.spawn_program called source.spawn_program_platform_specific, or something less verbose but equally obvious
[17:36] <mmcc> but I digress, don't want to derail things
[17:36] <thisfred> aha http://entre-mujeres.com/2012/08/29/el-consumo-de-marihuana-en-la-adolescencia-causa-danos-irreversibles-en-la-inteligencia-memoria-y-atencion/
[17:36] <mandel> mmcc, it is indeed a mental challenge :)
[17:37] <thisfred> that explains ... oh look, a butterfly!
[17:37] <mandel> thisfred, and that is why I started later :)
[17:37] <mandel> ralsina, why do we have a frame that contains the wizard, is that for the overlay?
[17:38] <ralsina> mandel: nothing comes to mind, I'd have to look
[17:38] <mandel> ralsina, sorry in the sso
[17:38] <ralsina> mandel: is that frame a QStackWidget?
[17:38] <mandel> in UbuntuSSOClientGUI there is a QVBoxlayout in which we add the wizard
[17:39] <ralsina> mandel: that's not a frame :-)
[17:39] <ralsina> mandel: the QVBolxLayout is not a widget
[17:39] <ralsina> mandel: there is a reason why the wizard is not the top level, but I don't quite remember what it was
[17:40] <mandel> ralsina, sorry I'm getting confused, the UbuntuSSOClientGUI is a frame that has a layout and contains the wizard, why?
[17:40] <mandel> ralsina, it seems that on mac we are not getting the close event correctly
[17:40] <ralsina> mandel: do we have something connected to the close event?
[17:41] <ralsina> mandel: connect it to the app's lastWindowClosed signal
[17:41] <ralsina> instead
[17:41] <mandel> ralsina, there is a closeEvent method there..
[17:41] <ralsina> mandel: ok, give me 1' to look
[17:41] <mandel> ralsina, ok
[17:42] <ralsina> mandel: that's strange code
[17:44] <ralsina> mandel: yes, looks like the outer widget is so we can put the overlay in it
[17:45] <ralsina> mandel: can you check if that closeEvent in ubuntu_sso_wizard.py is triggered or not?
[17:45] <ralsina> mandel: that should be called by the wizard's "done" which is above it
[17:45] <mandel> ralsina, lets mumble you know qt I know what is going on :)
[17:45] <ralsina> mandel: great idea
[17:49] <mmcc> we sure are calling the web api often, for the same things (we get the account info several times on startup)
[17:51] <ralsina> mmcc: yes, we should cache a lot of stuff there
[17:52] <mmcc> ralsina: is there a bug for that? it'd be nice to speed up startup. I note that the share links tab added another set of API calls in setup, so we're now waiting for many API calls before the UI is fully loaded
[17:53] <mmcc> also, I still see a hang while getting the quota, but only occasionally. :\ making it hard to debug
[17:53] <ralsina> mmcc: not that I know of
[17:53] <ralsina> mmcc: yes, I can see the folder list displayed and the dialog still locked :-/
[17:54] <mmcc> ralsina: aha, ok - so that's happening to you too… did you start it with U1_DEBUG?
[17:54] <ralsina> mmcc: yes
[17:54] <ralsina> mmcc: but it unlocks a little later. usually
[17:54] <mmcc> if so, you probably see your username in there at least once, but somewhere, a call to quota isn't returning
[17:56] <ralsina> mmcc: probably
[17:57] <mmcc> fyi: https://bugs.launchpad.net/ubuntuone-control-panel/+bug/1043459
[18:01] <dobey> hrmm, i wonder if anyone is even actually using libsyncdaemon from vala
[18:01] <mmcc> ralsina: are we going to disable the share links tab for release tomorrow?
[18:03] <ralsina> mmcc: maybe
[18:03] <ralsina> mmcc: or add a note saying "this doesn't work on mac yet"
[18:03] <ralsina> mmcc depending on whether this works without it :-)
[18:04] <mmcc> ralsina: I asked because I'm wondering what's the easiest way to disable it. doesn't look like I can comment out a hunk and be done with it…
[18:04] <ralsina> mmcc: let me try
[18:05] <mmcc> I wanted to see if the quota api calls hang when the share links tab isn't hammering it
[18:05] <ralsina> mmcc: will have a patch to disable it for you in 5'
[18:06] <dobey> alecu or ralsina: https://code.launchpad.net/~dobey/ubuntuone-control-panel/update-4-0/+merge/121914 please
[18:10] <ralsina> mmcc: patch to disable share link tab https://pastebin.canonical.com/73289/
[18:10] <ralsina> mmcc: I can do a better one that hides it before release if we have to
[18:11] <ralsina> dobey: got it
[18:11] <mmcc> ralsina: thanks
[18:14] <mandel> ralsina, I'm of for a little to run, the stale brokers branch is lp:~mandel/ubuntu-sso-client/fix-stale-broker
[18:14] <mandel> ralsina, it should work to get the creds but you will get stuck because the signal is not sent back
[18:14] <mandel> ralsina, look in ubuntu_sso/util/runner/qt.py
[18:14] <mandel> ok, off to run
[18:18] <ralsina> mandel: ok, I'll start from there
[18:19] <mmcc> ralsina if you have a sec first I could use an extra set of eyes / brain hemispheres on this quota hang bug…
[18:19] <ralsina> mmcc: my brain is not great today, but I can try to help :-)
[18:20] <ralsina> mmcc: are we getting the quota from the REST API or from syncdaemon?
[18:20] <mmcc> ralsina: the web api
[18:20] <ralsina> mmcc: it could be we are getting an error from the servers
[18:20] <ralsina> mmcc: perhaps because we ask too quicly
[18:21] <mmcc> so controlpanel.py on_credentials_found is intermittently not making it past the line "info = yield self.backend.account_info(), despite a log message at the end of account_info showing the correct result from the servers
[18:21] <mmcc> no, the servers seem fine with us
[18:21] <mmcc> I'm logging just before returnValue(result) in account_info in backend.py, and that always shows up
[18:21] <ralsina> mmcc: hmmm
[18:21] <ralsina> that's very strange
[18:21] <mmcc> but the log just after "yield self.backend.account_info() in the calling function does not
[18:21] <mmcc> intermittently
[18:22] <mmcc> note that the devices_info is wrapped with @process_unauthorized, I thought maybe it was getting stalled in there
[18:22] <mmcc> looking there now.
[18:22] <ralsina> mmcc: could be that
[18:22] <ralsina> mmcc: or could be a bad interaction with qtreactor (hope not)
[18:24] <mmcc> I hope not too
[18:25] <mmcc> now to loop on restarting CP until I see th bug again
[18:25] <mmcc> hate hate hate hate
[18:27] <ralsina> mmcc: I look at that code and see no place for it to fail. Since it's failing, I am obviously not helping :-(
[18:28] <mmcc> booom: http://paste.ubuntu.com/1174346/
[18:29] <mmcc> getting a 302 from the server
[18:29] <mmcc> not dealing with it well
[18:30] <ralsina> mmcc: well, that's the easiest failure it seems :-)
[18:30] <ralsina> mmcc: but what does it mean that the quota has moved temprarily?
[18:31] <mmcc> the text of the page says it moved to media.one.ubuntu.com/offline.html
[18:33] <ralsina> mmcc: so that's a server outage?
[18:33] <ralsina> beuno: ^
[18:33] <ralsina> mmcc: in any case, just a little of robustness there should fix it
[18:34] <ralsina> mmcc: at least, don't show the quota and don't stay blocked
[18:34] <mmcc> ralsina: it's a super-intermittent outage, if it is one. possibly it is reacting poorly to multiple repeated requests
[18:35] <mmcc> I wonder how hard it'd be to cache the account info, because we do always get it once or twice, it's just the third time that sometimes 302's
[18:35]  * mmcc winces
[18:35] <ralsina> mmcc: cache it, and if you get a 302 return the cached value?
[18:35] <beuno> mmcc, ralsina, edge?
[18:36] <mmcc> ralsina: right, that's the way to go… want to do it in the right place, though…
[18:36] <ralsina> beuno: no, production
[18:36] <beuno> could be a timeout
[18:37] <ralsina> mmcc: in any case, we have a plan now
[18:37] <pedronis> mmcc: the 302 sounds more like there's a missing / at the end though
[18:37] <ralsina> mmcc: I'll take a 15' and then look at mandel's branch
[18:38] <dobey> thanks alecu
[18:38] <pedronis> I mean 50x would be more like it's giving up on you
[18:38] <alecu> dobey: you're welcome!
[18:38] <ralsina> dobey: oops, I was about to +1 it :-)
[18:38] <ralsina> dobey: so go ahead ;-)
[18:38] <dobey> heh
[18:41] <mmcc> pedronis, no missing / -- the identical call is made a few times successfully, and I can confirm that the call is either account/ or quota/. see the first line of  http://paste.ubuntu.com/1174346/  for example
[18:44] <dobey> awesome; my dell duo is broken now :(
[18:53] <dobey> well, can log in again now; but it's llvm bucket of broken video blitting :-/
[18:53] <ralsina> dobey: my Q partition has been unusable for a month now :-(
[18:55] <mmcc> so, I wonder why I'm not getting the HTTP response code anywhere in that reply object from the webclient
[18:56] <ralsina> mmcc: maybe alecu knows
[18:56] <ralsina> mmcc: also, that may explain all the JSON decode errors in one stroke
[18:56] <pedronis> mmcc: beuno: that says offline.html, are we hitting the point were there's a automatic deployment
[18:57] <mmcc> ralsina: I think it does, yeah. I think it even explains why sometimes we get the JSON error shown in logs/ a dialog and sometimes it's buried… because it can hit different code paths depending on which request gets borked
[18:58] <ralsina> pedronis: we have been getting that since yesterday at least
[18:59] <beuno> pedronis, I get offline.html for timeouts on prod now
[18:59] <beuno> so something changed
[18:59] <beuno> I've been getting that for a few weeks now
[19:00] <pedronis> beuno: new oops infrastructure?
[19:00] <pedronis> that's a bit insane, timeout should give a 50x something, getting a 302, especially for apis
[19:00] <pedronis> is not that useful
[19:01] <beuno> pedronis, no, I'm pretty sure this is haproxy
[19:01] <pedronis> cute
[19:01] <pedronis> (not)
[19:01] <beuno> right  :)
[19:06] <ralsina> school run, will be back in 30'
[19:08] <alecu> mmcc: the webclient returns either a Response object (on 200) or throws some kind of WebClientError. And it's not putting the http status in the WebClientError, probably because it was not needed by the existing code.
[19:09] <alecu> mmcc: it surely might be useful to add it.
[19:10] <mmcc> alecu: it looks like 302 doesn't cause a WebClientError
[19:10] <mmcc> although I can't verify that it's actually getting a 302, I trust the web guys not to reply with a 200 and just send HTML back via the api :)
[19:11] <dobey> oops
[19:12] <alecu> mmcc: the 302 (redirect) is probably handled by some of our underlying libraries like qtnetwork or libsoup
[19:13] <alecu> mmcc: we are talking about this, right? http://en.wikipedia.org/wiki/HTTP_302
[19:13] <mmcc> alecu, yes
[19:13] <alecu> mmcc: what I mean is that the 302 is handled by those libraries, and the redirect performed there. And whatever is in the new location is returned.
[19:13] <mmcc> we're using qtnetwork in this case…
[19:14] <mmcc> I see
[19:16] <mmcc> alecu, although - look in http://paste.ubuntu.com/1174346/ -- the HTML we get back from theAPI call isn't the contents of the offline page, it's text linking to it…
[19:16] <alecu> mmcc: so, we are using QNetworkAccessManager to do the http requests, and it seems *it does not* handle the redirects automatically.
[19:16] <alecu> it has to be done manually: http://www.developer.nokia.com/Community/Wiki/Handling_an_HTTP_redirect_with_QNetworkAccessManager
[19:17] <mmcc> alecu, ok, interesting
[19:17] <alecu> mmcc: this is very likely caused by the changes server side, so it will start happening on ubuntu and windows too.
[19:18] <mmcc> for completeness: I just verified that QNetworkReply doesn't have HTTP error codes in the header pairs that it returns…
[19:18] <alecu> mmcc: the http error code is not part of the headers; it's in the first http line, just before the headers.
[19:18] <mmcc> alecu, well then that makes sense :)
[19:19]  * mmcc looking at the wiki link now
[19:20] <alecu> mmcc: and iirc, in qtnetworkmanager the standard http error codes get mangled into a custom qt enum, with different numbers.
[19:20] <mmcc> ok, so we can test the HTTP attribute and treat non-200 as an error
[19:20] <mmcc> alecu: yeah, you call reply.attribute(0)
[19:22] <alecu> mmcc: oh, right. I was thinking of reply.error(), which are not the same as http status codes, but are defined instead like: QNetworkReply.AuthenticationRequiredError
[19:23] <alecu> mmcc: so... I understand that 302 we will need to treat differently, but it should not be an error, right?
[19:23] <dobey> well 3xx shouldn't be errors
[19:23] <dobey> they should probably be handled correctly by following the redirect
[19:23] <mmcc> alecu, well, it shouldn't be an error, no - except that we are getting redirected to something that can't be parsed as json
[19:23] <alecu> mmcc: a 302 means that we need to fetch the page we are redirected to, and (barring redirect loops) we should be done.
[19:24] <alecu> mmcc: oh, that should be an error, all right.
[19:25] <mmcc> I think we don't need to change how it handles redirects to fix this issue
[19:25] <mmcc> we do need to catch unparseable JSON and return a cached value, *and* then hopefully figure out what's causing those redirects to the offline page on the server end
[19:26] <mmcc> maybe we could help them by not flooding the API from the client at startup, but that's not going to get done today
[19:28]  * briancurtin lunch
[19:28] <mark06> last time I checked music streaming was paid, is that still true?
[19:35] <dobey> mark06: yes, it requires payment for use, beyond the trial period
[19:36] <mark06> what if I just want to sync files (including music) wirelessly between phone and PC?
[19:45]  * briancurtin back
[19:47] <mmcc> mark06: there's a free plan for just syncing files, https://one.ubuntu.com/services/free/
[19:48] <mmcc> So now I'm getting all 200 responses, but still not ever returning from the account_info call in on_credentials_found
[19:48] <ralsina> mmcc, alecu: our APIs should never return a 30x in any normal situation
[19:48] <ralsina> mmcc: :-(
[19:50] <mmcc> oh, this ~explains it -- on_credentials_found isn't even getting called, those API calls in my log aren't from it
[19:57]  * mmcc smells another race!
[19:57] <mark06> mmcc: but can it sync wirelessly?
[19:58] <mark06> mmcc: ah sorry it was a dumb question
[19:59] <mark06> mmcc: I don't want to store anything on servers, is that possible? or if I wanted to keep my music library in sync between PC and phone, I would indeed need to store it on servers?}
[19:59] <mmcc> mark06: no prob :) why not sign up for the free plan and put the phone apps through their paces…
[19:59] <ralsina> mark06: no, all our clients sync to our servers
[20:00] <dobey> mark06: also, the phone app doesn't 'sync' files; you can simply use it to download files to your phone from the service, but they are not kept in sync
[20:01] <mark06> that would be enough as I use PC as primary location for music...
[20:01] <mark06> it would just need to delete from the phone if deleted form servers
[20:01] <mark06> can it do that?
[20:01] <dobey> mark06: though it will also auto-upload photos from the phone to the server if you wish as well; but they won't be kept in sync if you edit them on a PC for example
[20:02] <dobey> mark06: no, it doesn't keep them in sync. you'd have to delete them on the phone yourself
[20:03] <mark06> edit on a PC in the sync folder? (so the edit goes to server but isn't pushed to the phone?)
[20:03] <dobey> right
[20:04] <dobey> the phone app does not currently keep things in sync
[20:04] <mark06> this pages sync photos to the cloud: https://one.ubuntu.com/services/free/
[20:05] <ralsina> mark06: the phone clients are different because "real" syncing would kill your battery
[20:05] <ralsina> mark06: among other reasons
[20:05] <mark06> ok but don't say sync when you don't sync
[20:05] <dobey> mark06: like i said; it does auto-upload
[20:05] <mark06> sorry, * this page says
[20:06] <ralsina> mark06: says "sync photos taken with your phone TO the ubuntu one cloud"
[20:06] <ralsina> mark06: but I will be happy to pass your concerns to the ones that write the copy :-)
[20:06] <dobey> agree that upload or send might be a better term there
[20:06] <mark06> sorry I meant to say that the avove page says "sync photos [...] to your personal cloud"
[20:07] <mark06> *above
[20:07] <ralsina> mark06: we in this channel just write code mostly :-)
[20:07] <mark06> it would be better to say just "upload"
[20:07] <dobey> mark06: yes; it does; and it says *to* (clarifying that it's only one direction)
[20:07] <dobey> ie, it doesn't say "with"
[20:07] <mark06> ralsina: ah ok sorry, I assumed it was a general channel as doesn't have the -dev suffix, np
[20:08] <mark06> my bad English then, sorry dobey
[20:08] <ralsina> mark06: it's ok, there's also support people
[20:08] <ralsina> mark06: what we don't have is any mrketing people :-)
[20:08] <mark06> but send/upload would be better, just registering an opinion...
[20:09] <ralsina> mark06: I'll pass it along
[20:10] <mark06> ok thanks all!
[20:10] <dobey> bad ralsina
[20:11] <ralsina> dobey: ?
[20:11] <dobey> you didn't listen to roberta
[20:11] <ralsina> yes I did
[20:11] <dobey> "you are all marketing people"
[20:11] <dobey> :)
[20:11] <ralsina> just left my marketing hat in the other pants
[20:11] <ralsina> dobey: I achieved a remarkable marketing-oriented goal, made him happier with our service
[20:12] <ralsina> I call it ninja-incognito-secret-agent marketing
[20:20] <mmcc> ok, I may have solved this issue using another DeferredLock
[20:20] <mmcc> my new favorite tool
[20:21] <mmcc> need to try it from a fresh build, since I have done a bunch of hacking
[20:22] <ralsina> mmcc: yay
[20:22] <ralsina> In other news, I am feeling really crappy
[20:22] <mmcc> but the issue appears to be that controlpanel backend caches the results of login_client.find_credentials(), but again, the check if it's been set yet can be hit multiple times while the remote call is in process…
[20:23] <mmcc> this is unrelated to the JSON error, but at least fixing it will result in a couple fewer API calls, maybe that'll help that indirectly
[20:24] <mmcc> ralsina: sorry you don't feel well. you should get one of these: http://instagram.com/p/O7H6bKx2a8/
[20:25] <ralsina> mmcc: I have a similar thing, let me find a pic
[20:27] <ralsina> oh, was in picplz. Not going to open the zip for it :-)
[20:27] <ralsina> mmcc: anyway, I have a black cat sitting on my shoulder about 40% of the time
[20:28] <mmcc> ralsina: nice. "management oversight"
[20:41] <ralsina> mmcc: yeah
[20:49] <mmcc> ralsina: if you're feeling better, I just noticed this minor UI bug: https://bugs.launchpad.net/ubuntuone-control-panel/+bug/1043525
[20:50] <ralsina> mmcc: not really. I am going to lay down a bit, may come back later when I feel better
[20:51] <ralsina> mmcc: can you please mail me a status report before you stop?
[20:51] <mmcc> ralsina: sure, hope you feel better soon. and yes.
[20:51] <mmcc> ralsina: we need to release tomorrow, but exactly when tomorrow?
[20:51] <mmcc> and, uh, how?
[20:51] <ralsina> mmcc: "tomorrow"
[20:51] <ralsina> time is flexible
[20:51] <ralsina> the how is by creating the image and giving it to me
[20:51] <ralsina> :-)
[20:52] <mmcc> sounds familiar - we used to have research paper deadlines set at midnight in hawaii :)
[20:52] <ralsina> we'll put it somewhere and post something in our blog, I don't expect this to have much noise
[20:52] <mmcc> ralsina: ok, sounds good
[20:52] <ralsina> the people who post stuff are in the UK so it should be rather early, but a few hours will not hurt
[21:04] <alecu> mmcc, ralsina: I've got some more ideas on what may be causing the segfaults
[21:05] <alecu> I've been playing with twisted+fsevents on osx, in a smaller script, and I find that twisted and fsevents are not exactly... compatible, let's say.
[21:06] <alecu> but things absolutely break when the fsevents callback throws an error.
[21:06] <alecu> so, my first proposed solution is to have a big try-except on the events handler.
[21:12] <alecu> oh, and this makes no sense in our case, because the event handler is minuscule. :-(
[21:13] <alecu> waaaaait!
[21:13] <alecu> the signature of that event handler has changed in the last macfsevents!
[21:14] <alecu> mmcc, ralsina! progress!
[21:15] <mmcc> alecu: where?
[21:16] <mmcc> which handler, i mean
[21:16] <mmcc> also, :D
[21:16] <alecu> mmcc: fsevents.Stream( HANDLER )
[21:17] <mmcc> and - with my backend credentials lock, I can't make the UI freeze anymore… working on tests now, will propose after my lunch, which is starting in … about now
[21:17] <alecu> mmcc: it seems it was HANDLER(event) and now it's HANDLER(some_id, filename)
[21:18] <alecu> mmcc: I don't understand how SD even manages to receive any event at all :/
[21:20] <briancurtin> crap, i need to get out of here a bit early. will show up earlier tomorrow. girlfriend already yelling for me out the door...
[21:21] <mmcc> alecu - I'm not really seeing that -- my copy of the code has the first one, called at the end of FileEventCallback.__call__
[21:21] <mmcc> we create the stream with file_events=True, so it uses FileEventCallback()
[21:22] <mmcc> also, raw_file_events is experimental and shouldn't be used…
[21:22] <mmcc> ok, gotta go eat/cook
[21:24] <alecu> mmcc: right, I see that...
[21:24] <alecu> false alarm then.
[21:30] <alecu> mmcc, ralsina: when you get back, can you guys try this script? http://pastebin.ubuntu.com/1174680/
[21:35] <alecu> ok, I need to run. I may join up later tonight.
[21:35] <alecu> bye all!
[21:45] <ralsina> oh great, now u1cp crashes on Q: https://bugs.launchpad.net/ubuntu/+source/ubuntuone-control-panel/+bug/1043522
[21:50] <dobey> ugh; really
[21:57] <ralsina> dobey: apport seems to be catching dupes so...
[21:57] <dobey> yeah, i'm sure; looks like it's crashing deep in qt image stuff though
[21:58] <ralsina> dobey: I can probably take a look tomorrow on my Q VM
[22:04] <dobey> trunk seems to work ok for me on precise
[22:04] <ralsina> dobey: for me too, so it's probably Q-specific
[22:04] <dobey> checking
[22:05] <dobey> unity llvm is quite annoying though :(
[22:09] <dobey> it's working fine on my Q laptop too :(
[22:09] <dobey> even the share links tab works!
[22:11] <dobey> hrmm, that notification is a bit annoying though
[22:11] <ralsina> dobey: which one?
[22:12] <dobey> if you search for one of your published files in the share tab, and select it so the extra info is shown, it pops up a notification of "A file has been published..." for that file
[22:12] <ralsina> it shouldn't do that, AFAIK
[22:12] <dobey> i guess maybe searching and pressing enter on the selected result, results in that file being published
[22:13] <dobey> which is very non-obvious, and really shouldn't happen
[22:13] <ralsina> dobey: and it's on OMG already :-)
[22:13] <dobey> but i didn't try it on a file that wasn't published yet
[22:13] <ralsina> dobey: I am guessing it uses the wrong API call
[22:13] <ralsina> dobey: and it publishes it again in order to get the URL
[22:13] <ralsina> dobey: instead of getting the list of published files and searching for it
[22:14] <dobey> yeah, at first i started typing and it showed me files in a shared from ivanka
[22:16] <dobey> lol; and all the comments are about "make it prettier on ubuntu" though
[22:16] <dobey> ok, well i need to go
[22:16] <dobey> later all!
[22:53] <mmcc> alecu, the result of your script is here: http://paste.ubuntu.com/1174813/
[22:55] <mmcc> I can't tell if it's doing what you wanted - it seems to do what it's supposed to…