[06:00] fwiw, metadata issue about empty data with existing key is found on windows [07:16] 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] 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] going to test that idea quickly and head to sleep [09:02] Good morning, from a cold and rainy Derby! :-/ [09:03] hi JamesTait, I guess it's morning here too… === teknico_ is now known as teknico [09:05] mmcc: Aren't you in Ireland? Or did I mix you up with someone else? [09:05] JamesTait: nope, I'm in california [09:05] mmcc: Clearly I have you mixed up then. :-P [09:08] mmcc: oh, you're there ! What TZ are you in ? [09:08] mmcc: next: where is my bundle ? :-D [09:08] vila, I'm in US pacific, it's 2am [09:08] ouch, go to sleep ! [09:08] I will put something up for you before I head out [09:09] mmcc: remember: obscure bugs are not easier to see in the middle of the night ;-D [09:09] vila: easier to hear them when it's quiet [09:09] ... who am I to say that... when you're in hot pursuit... nothing can stop you ;) [09:09] mmcc: hehe, so true ;) [09:10] mmcc: I won't distract you anymore then ;) [09:16] morning! [09:16] mmcc: wtf? [09:16] ralsina: :D [09:16] don't worry, I was asleep from ~9-12pm [09:21] 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] 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] it looks like the controlpanel backend quota API call is not returning [09:30] Hi all, are there plans to translate the U1 webinterface? [09:31] 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] mmcc: awesome, then ugh [09:34] mmcc: go to sleep [09:43] 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] cc vila --^ [09:44] and with that, I'm going back to sleep [09:55] mmcc, what the hell are you doint up!? [09:55] ralsina, mmcc just notice you guys.. wtf [09:58] trijntje: sorry the web guys are not up yet [09:59] mandel: I just got up one hour earlier, don't worry ;-) [09:59] ralsina: are they in the us? [09:59] trijntje: argentina and the US mostly [09:59] ralsina, so I'm sending an email regarding the crash, will be looking at logging right now [10:00] mandel: ok [10:00] ralsina, we used to use pycurl, right? [10:03] ralsina: ok, thanks. Ill try again in 8 hours or so ;) [10:03] ralsina, so.. lp is down? [10:04] mandel: yes [10:05] mandel: on the pycurl stuf [10:05] mandel: have not looked at launchpad [10:05] ralsina, but we don't longer use it right? [10:05] mandel: I think we still do. We switched to pycurl from httplib because of the SSL cert checking [10:06] mandel: but not sure if trunk still has that [10:07] ralsina, oh, well because of this: http://bugs.python.org/issue816476 [10:07] ralsina, which is the only ref I could find for the crash [10:07] ralsina, but is a very very old bug [10:07] ralsina, also,m please review: https://code.launchpad.net/~mandel/ubuntuone-client/fix-logging/+merge/121816 [10:08] mandel: got t [10:16] mandel: diff doesn't update :-( [10:18] mandel: about the GC crash, we can fix for the next release since u1cp will restart sd as needed [10:20] ralsina, will it? [10:20] ralsina, we need to check that [10:21] ralsina, joder! bloody lp, I'll propose a branch without the bug linked [10:22] 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] mandel: remember that we need to wait until after all signals connect to use sd_client [10:25] mandel: so would your solution do the same? [10:26] other than that, one or the other feel the same to me [10:27] ralsina, yes, is the same [10:27] be-a-parent time [10:27] will be back in ~1 hour [10:27] ralsina, the main diff is one is not async and the other is [10:27] ralsina, I prefer to use the connected_d trick to be honest [10:27] mandel: u1cp is useless until we get the sd connection anyway [10:28] ralsina, yes, is just ui, with a backend but ui :) [10:56] 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] mandel: global +1 [11:02] mandel: and +1 on not overcomplicating things :-) [11:06] ralsina, yes, I'm nearly done with the tests so I'll propose the mp in a few mins [11:40] ralsina, I need an approve and then the global approve: https://code.launchpad.net/~mandel/ubuntuone-client/fix-logging/+merge/121825 [12:05] mandel: could swear that's what I did [12:05] mandel: fixing... [12:05] ralsina, no problem :) [12:06] mandel: done [12:06] good morning alecu! [12:06] hello, all! [12:12] morning [12:22] 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] 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] ralsina: ok, I'll give that a look. [12:24] ralsina: can you fwd it to me? [12:25] alecu: sure! [12:25] alecu: thought you were in the CC [12:26] 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] mandel: two different things [12:27] exactly, one has nothing to do with the other [12:27] mandel: the GC is not related to the corruption of metadata AFAIK [12:27] ralsina, the GC call happens with a single sd running and accepting lisettes share, after that the metadata is corrupted [12:28] alecu, ^ [12:28] mandel: the crash has nothing to do with more than one daemon running. Yes, I made that clear on the second email. [12:28] mandel: but metadata corruption *can* happen when two SDs are running. [12:28] mandel: tritcask is not multiprocess safe [12:28] alecu, ralsina, the metadata probably goes nuts because is left in a weird state due to the crash [12:29] alecu, yes, but I'm no interested in tritcask, AFAIK it works correct in all cases when there is a single daemon [12:29] mandel: I don't think that's the case. [12:29] alecu, why not? [12:29] mandel: because tritcask is self-healing. [12:29] mandel: tritcask has a journal [12:30] mandel: that is, at a given point it has a few files that read only, and one file that is append only [12:30] mandel: and each record written to the append only file, has a crc of the record contents [12:31] mandel: so, on starting SD, and replaying the journal, each record that has the crc wrong is discarded. [12:31] mandel: ergo: self-healing. [12:32] mandel: but it's not designed to be written by more than one process at a time. [12:33] mandel: tritcask does not expect the files it considers read only to be written by other process [12:34] 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] mandel: are you talking about the GC issue? [12:35] alecu, yes, which then gets the metadata busted [12:36] 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] alecu, and this has happened to chaselivingston too, we needed to remove his metadata to get u1 back to work [12:37] mandel: get the eraser, let's think of a different timeline: [12:37] 1) sd crashes with GC error [12:37] 2) u1cp is querying SD many times per second, starts two copies of SD [12:37] 3) the two copies corrupt the metadata. [12:37] 4) .... [12:37] 5) profit! [12:38] mandel: I say 4 is "we fix two SD starting at the same time" [12:38] so, if mmcc's lock fixes 2) ... [12:38] alecu, I was starting sd manually, so we have to remove the u1-control panel out of the equation [12:39] BTW, u1cp makes a bazillion calls to sd's get_homedir we should cache that [12:39] alecu, so, we only have sso and sd running, no sdtool starting a gazillion times the sd process [12:39] ralsina, I don't know why we have more than one connection in that things.. one per tab seems too much.. [12:39] but at least is showed an error [12:39] mandel: each tab has a sd_client but they are all the sameinstance [12:40] ralsina, that cannot be, how are we starting more than once sd if that is the case? [12:40] 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] alecu, and too me, more than the multiple instances.. 'cause that one we understand [12:41] ralsina, mandel: a tritcask bug we can probably fix. A bug in the C extension of macfsevents sounds scarier. [12:41] alecu, ralsina, is there a bug number for the connection issue, I have a branch from mmcc with tests [12:41] 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] mandel: that test shuld be enough since that's the behaviur we want [12:42] ou* [12:43] mandel: btw: do you get the GC errors when running with the root daemon? [12:43] alecu, I need to test that, will do after I have lunch [12:45] bug 1043287 [12:45] Launchpad bug 1043287 in Ubuntu One Client "UbuntuOneClient from ipc_client connect starts more than one sd process" [Critical,In progress] https://launchpad.net/bugs/1043287 [12:46] ralsina, alecu, feel free to review: https://code.launchpad.net/~mandel/ubuntuone-client/guard-ipc-connect/+merge/121854 [12:47] mandel: that includes mmcc's branch? [12:47] ralsina, yes [12:47] mandel: cool [12:47] 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] 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] in each iteration we assert that the connection steps where done in the correct order [12:49] as good as I could do the test, if you see a better way to do it please let me know [12:50] mandel: is this branch based on mmcc's guard-ipc-connect branch? [12:50] alecu, yes, branched form it and just added the test [12:50] mandel: great [12:51] I'm off to get the salad :) [12:51] * mandel lunch [13:37] ohhhoohhhohhh... I hate threads so much. [13:41] threads are awesome [13:43] hate is awesome [13:44] dobey: there will be no UI change branch in u1cp today, so feel free to release at will [13:46] cool [13:54] 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] 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] 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] 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] it does that for each possible case [13:58] ralsina, does the test make more sense now? [14:02] mandel: yes, I know the theory :-) [14:02] mandel: and it does seem to do that, I am just not confident in my ability to find bugs in it today [14:03] ralsina, ah, ok :) [14:05] 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] with install == copy the new app above the old one [14:07] I moved the existing one out the way, install the new one and I'm rebooting [14:07] ralsina, mmcc : Should I file a bug for that ? [14:08] vila: yes please [14:08] vila: you probably need to stop it before overwriting it [14:08] ralsina: stopping what ? [14:09] sd ? [14:14] vila: yes [14:15] ralsina: how do I do that (for reference) ? [14:15] launchctl bliblablo ? [14:15] 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] ) [14:17] oh and nothing will restart it ? [14:17] oooh, progress, no more 'getting... please wait' [14:18] click sign me in .... sorry an error has occurred... [14:18] DeadRefecenceError 'Calling Stale Broker' [14:18] known bug ? [14:19] ralsina: ^ [14:19] vila, I'm working on it :) [14:20] 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] ralsina, will restart the sso process if needed [14:21] mandel: bug # so I can subscribe ? [14:21] vila_, I need to create one, sorry, give me a sec [14:21] mandel: no worries [14:22] mandel: let me know when a new bundle is available [14:23] vila_, bug 1043367 [14:23] Launchpad bug 1043367 in Ubuntu Single Sign On Client "SSO process closes to fast resulting in Stale Brokers" [Critical,In progress] https://launchpad.net/bugs/1043367 [14:23] mandel: cool, yes, saw that [14:23] looks like logging in is reliable again! [14:24] except I have to start everything manually but that's my setup I think [14:24] ralsina, what do you mean with logging? as the log.debug? [14:24] mandel: oops, meant login [14:25] ah, ok :) [14:33] 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] alecu, is in the mail, I just get that [14:35] alecu, that is all I get: http://paste.ubuntu.com/1173495/ [14:36] alecu, is the sd logging do you need me to get anything else? [14:36] mandel: how do you know that the metadata is corrupt at that point? [14:37] alecu, I just suspect because removing the metadata fixes it and works normally [14:37] mandel: btw: U1_DEBUG=True does nothing useful for SD, so try running sd with --debug [14:37] 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] mandel: well, it does something: it enables the debug lines in the imported sso modules [14:38] ah. bummer, alecu let me run that again then [14:38] mandel: make sure your metadata is corrupt first! ;-) [14:38] alecu, it is :) [14:39] awesome! ? [14:39] mandel: btw: did you get the GC error when running with the root daemon? [14:39] mandel: I'm trying to single out macfs as the GC error culprit [14:41] alecu, Im fixing sso bugs and will do that asap (using the daemon) [14:42] alecu, here is a run with --debug: paste.ubuntu.com/1173910 [14:42] alecu, I really hope is not fsevents.. [14:43] mandel: is that the start of the run? [14:43] mandel: can I see the whole log? [14:44] alecu, that is the end of the log, I can get you all of it np, one sec [14:45] 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] mandel: (though I still would like to see the start of the log) [14:46] 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] alecu, Is work in progress to find out what is going on [14:48] mandel: what "things does not work" ? I SD activity happening there. [14:48] mandel: probably when you delete the metadata you see *a lot* more activity, because all the state has to be resyncd [14:49] * I see SD activity happening in the log [14:49] alecu, yes, but that is not the case, when I say it works I mean it does not crash [14:49] mandel: !!!! [14:49] mandel: and how did it crash in the first time? [14:50] alecu, paste.ubuntu.com/1173923 [14:50] mandel: I saw that crash (GC) a loooot, and it did not have to do with corrupt metadata! [14:50] alecu, the first time, bad luck, I accepted the u1 design share from lisette and it happened [14:50] mandel: yesterday I saw that a lot while running mmcc's bundles. [14:51] alecu, did you? I have only been able to reproduce it with that share, else it works fine in my system.. [14:51] mandel: but did you have broken metadata when you accepted that share? [14:51] mandel: let me repeat what I think, out loudly: this GC crash has nothing to do with metadata. [14:52] alecu, no, everything work ok before that [14:52] alecu, never saw the GC error at any point [14:52] alecu, mandel: I feel you are talking past each other. Mumble? [14:52] mandel: did you have any UDF syncd? [14:52] alecu, I don't use UDFs at all [14:52] mandel: that's the datapoint [14:52] mandel: there we go [14:52] alecu, but I did have shares syncing [14:53] how many shares? [14:53] alecu, as far as I remember 2 [14:53] 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] I so absolutely fraking hate debugging thread issues. [14:54] hi folks, catching up [14:54] alecu, +1000000 [14:54] mandel: right, but that's a small share compared to lisette's, isn't it? [14:54] 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] alecu, uhhh [14:56] hi mmcc [14:56] mmcc: be aware, you are taking monday off. [14:56] alecu, mmcc, please tell me that fsevents is not starting a thread per child dir.. [14:56] ralsina: yep, on the calendar [14:56] mmcc: OTOH, because of past experience, please don't take this as an endorsement of crazy hours, because it isn't ;-) [14:57] mandel: I think it's a thread per watch [14:57] ralsina: heh, understood [14:58] mandel: I'll look to be sure [14:59] 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] me [14:59] me [15:00] me [15:00] mandel: one fsm, one watchmanager, one observer, one thread. [15:00] me [15:00] me [15:01] alecu, me no comprende? what? [15:01] me [15:01] dobey: standup [15:01] ok, dobey is last, go thisfred before you doze off! [15:01] DONE: QA release, debugging controlpanel [15:01] TODO: more more controlpanel bugs [15:01] BLCK: no [15:01] NEXT: ralsina [15:02] 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] mmcc: early :-) [15:02] DONE: Bug 1043287 from mmcc branch + tests. Bug 1043353 for completness, bug 1043183. [15:02] TODO: Bug 1043367. Look if that fixes log in for mac keep looking there, help with sd crashing. [15:02] BLOCKED: no [15:02] Launchpad bug 1043287 in Ubuntu One Client "UbuntuOneClient from ipc_client connect starts more than one sd process" [Critical,Fix committed] https://launchpad.net/bugs/1043287 [15:02] Launchpad bug 1043353 in Ubuntu Single Sign On Client "IPC BaseClient connect method may lunch more than one instance of SSO" [Critical,In progress] https://launchpad.net/bugs/1043353 [15:02] Launchpad bug 1043183 in Ubuntu One Client "Logging does not deal well with paths that contain %" [High,Fix committed] https://launchpad.net/bugs/1043183 [15:02] me [15:02] briancurtin, please [15:02] Launchpad bug 1043367 in Ubuntu Single Sign On Client "SSO process closes to fast resulting in Stale Brokers" [Critical,In progress] https://launchpad.net/bugs/1043367 [15:02] 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] TODO: some unicode/bytes being passed to urllib usage, and a squid test somehow missing an attribute on 3 [15:02] NEXT: alecu [15:02] DONE: reviews, helped debugging osx craziness [15:02] TODO: more osx debugging, review dash documents [15:02] BLOCKED: no [15:02] NEXT: dobey [15:02] DONE: releases, bug # [15:02] TODO: releases, fix nautilus plug-in for Q, icon generating magic, music store work [15:02] BLCK: None. [15:03] DONE: reviews | web api thinking/ exploring TODO: add u1db server code to handle web api calls BLOCKED: no NEXT:dobey [15:03] ralsina, sorry on team call as well [15:03] thisfred_: is ok! [15:03] Comments? [15:03] EOM it is [15:03] COMMENT: I hate debugging threads. [15:04] i hate comment threads [15:05] 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] I hate smurfs [15:06] thisfred_, con razon, they are belgian :) [15:06] alecu, ok [15:06] mandel, hehe [15:07] alecu, yes that's right - I remembered wrong - one Observer, one thread [15:08] 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] alecu, mandel, I'm using the one from mandel's github [15:09] mandel, re your completeness branch, is it necessary? utils/tcpactivation already uses a lock in get_active_client_description [15:09] alecu, mmcc, we did merge changes from trunk yes, we can try with the bzr branch from mmcc [15:12] mmcc, did not notice that, let me check [15:12] mmcc, mandel: do you have an url for that macfsevents branch? [15:13] alecu, which, mmcc one? [15:13] mandel: I don't know. The one we are using! [15:13] https://github.com/mandel-macaque/macfsevents [15:13] alecu, https://code.launchpad.net/~mikemc/+junk/python-macfsevents is the old before we merged [15:13] mmcc: you are building the bundles with that one? [15:14] alecu - yes [15:14] alecu, diff with upstream of that branch: https://github.com/malthe/macfsevents/pull/11/files [15:16] mmcc, you are right is not needed, removing it [15:17] just out of paranoia I just ran the clang static analyzer on _fsevents.c and got no warnings [15:20] mandel: what's the process_asap for? [15:21] 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] alecu, it looked diff, like here: http://bazaar.launchpad.net/~diegosarmentero/+junk/python-macfsevents/view/head:/fsevents.py#L58 [15:22] mandel: that's used each time a new watch is added... [15:23] alecu, I had to add is as a keyword arg else it would not be landed in upstream [15:24] Hi all, are there plans to translate the U1 webinterface? [15:24] 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] 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] mandel: I don't recall what came out of that, nor reviewing code. [15:25] alecu, well, that is what he did I just merged with upstream and made the keyword arg changes [15:26] alecu, and we have been using since the beginning [15:26] trijntje: my guess is that it remains in the same state, but we should ping beuno to be sure. [15:27] mandel: right. [15:27] alecu: thanks === yofel_ is now known as yofel [15:28] 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] nor safer, btw. [15:29] alecu, I did not understand well the code to be honest, I just trusted him [15:29] alecu, I specially ask him about this: http://bazaar.launchpad.net/~diegosarmentero/+junk/python-macfsevents/view/head:/fsevents.py#L68 [15:29] alecu, which from my point of view is 'funny' [15:30] mandel: https://github.com/malthe/macfsevents/pull/11/files#r1486751 [15:30] mandel: I agree. weird [15:31] mandel: that's just working around thread timing issues by adding needless delays. [15:32] ok, this macfsevents is a bunch of crap. [15:32] alecu, he, but we have to work with it [15:32] alecu, anyone is willing to go to NZ and ask gatox about this ;-) [15:33] mandel: we have to fix SD, we are not forced to work with this. [15:33] mandel: I'm willing to fly, but surely our budget does not allow! [15:33] alecu, piggy back me please :) [15:34] mandel: http://www.youtube.com/watch?v=dYBjVTMUQY0 [15:36] alecu, I have longer arms than you ;) [15:36] mandel: "take turns!" [15:37] alecu, nah nah nah, I like to be the outer spoon [15:37] 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] is the eternal loading overlay fixed for other people with the changes I made last night? [15:38] and the initial stale broker from SSO is not a great first impression… [15:40] trijntje, right, no plans to translate [15:40] mmcc, I'm nearly done with the stale broker in sso [15:40] mandel: great :) [15:42] 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] trijntje, becuase we deal with money and people's files [15:50] 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] we all agree it would be nice [15:52] what functionality isn't available in the client? [15:52] ralsina, can I get a trivial review for https://code.launchpad.net/~mikemc/ubuntuone-client/change-socket-name/+merge/121643 ? [15:53] that's an old branch, just cleaning up. not related to our current bugs [15:53] sharing/publishing files, afaik [15:55] mmcc: got it [15:55] mmcc, you already have one from me, question, did you make the same change in the daemon side? [15:56] mmcc, as in, when is started by launchd [15:56] mandel, yes. The daemon changes are still sitting around here. I'll propose them after the merge [15:56] er, after the release [15:56] mmcc: global +1 [15:57] great, thanks guys [15:58] 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] I clearly don't totally understand colocated branches yet [15:59] mmcc, ein? and I though we said that the dont use that guard branch, right? [15:59] mandel, that's not the sso one [15:59] trijntje: sharing of folders and publishing of files is certainly doable from Ubuntu; although there are some small UX issues with those [16:00] mmcc, you pasted: lp:~mandel/ubuntu-sso-client/guard-ipc-connect [16:00] mmcc, that is the sso one [16:02] oh, so I did. thanks mandel [16:03] d'oh [16:03] :) [16:08] ok, so I need to figure out what to work on now [16:09] 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] mmcc, not yet, I did not have the time [16:11] ok [16:12] mmcc, if you want to tackle that go for it [16:12] I suspect that's the same thing that's killing my quota API call, so I'm going to look at it [16:13] the eagerness that sso has to close itself is amazing.. [16:14] ok, lunch time. bbiab [16:14] mandel: I've noticed the same thing. that refcount decrements as soon as it returns credentials, then boom [16:15]