[00:08] <mmcc> UbuntuOne.app down to a slim 113 MB
[00:32] <mmcc> next up for issues: ubuntuone/storageprotocol/context.py", line 92, in get_certificates : exceptions.IOError: [Errno 2] No such file or directory: '/etc/ssl/certs/UbuntuOne-Go_Daddy_Class_2_CA.pem'
[00:51] <mmcc> saved as bug 1025950, time to go play with the baby
[05:52] <mmcc> a quick edit in storage-protocol and I have an almost-working UbuntuOne.app!  It pulls from the server great, but doesn't seem to want to upload.
[05:54] <mmcc> and I've now seen the following error from IPC twice, in different spots each time: http://paste.ubuntu.com/1097819/
[05:56] <mmcc> and the sync status isn't updated correctly...
[05:56] <mmcc> aha - I created a test file in ~/Ubuntu One/ and got a similar error: http://paste.ubuntu.com/1097821/
[05:57] <mmcc> (but the file *was* uploaded)
[06:01] <mmcc> now it's uploading its 113MB self, at apparently ~50KB/sec. So I'm going to sleep.
[06:02] <mmcc> note: as it's uploading, the sync status is correct.
[06:03] <mmcc> so what seems to be broken now: the upload/download finished notifications, and noticing that a new folder (the .app bundle in this case) was copied in.
[06:03] <mmcc> otherwise: victory!
[06:07] <mmcc> issues to discuss tomorrow - where config files and ssl certificates belong on OS X.
[06:07] <mmcc> I guess I'm going to sleep now
[06:24] <mmcc> nope, that .app uploaded fast so I'm sending an email with info on how to try it
[08:19] <JamesTait> Morning all! :)
[08:39] <mandel> morning all!
[11:17] <gatox> good morning
[11:22] <mandel> gatox, morning! how is the tests branch going?
[11:23] <gatox> mandel, it's ready since yesterday, i forgot to sent you an email about it
[11:23] <gatox> mandel, but you can re-review it now
[11:24] <mandel> gatox, oh, ok, let me finish some code and I'll take a look
[11:26] <mandel> gatox, I'm off 10- min to give water to the dog :)
[11:26] <gatox> mandel, wow..... that dog drinks a lot!
[11:26] <gatox> jeje
[11:26] <mandel> gatox, haha terrible joke, is just that I have to go home (I'm working in an office now :) )
[11:26] <mandel> and is 5 min way, :P
[11:27] <gatox> ahhhhh
[11:27] <gatox> jjje
[11:37]  * mandel back
[11:47] <mandel> gatox, while I do your review, can you do one for me here: https://code.launchpad.net/~mandel/ubuntuone-client/daemon-options/+merge/115354
[11:48] <mandel> gatox, I like mmcc comment about the imports but I prefer to fix that in a diff branch to keep things simple
[11:48]  * gatox looking....
[11:50] <mandel> gatox, thx! now I only have to go after alecu to review the mother branch of all this branches.. and start landing them like crazy :)
[11:51] <gatox> mandel, the sauron ring of all the other branches? :P
[11:51] <mandel> gatox, yes hehe
[11:55] <gatox> mandel, yes, i agree with the imports, they look messy..... it's not possible to have that defined in ubuntuone.platform.filesystem_notifications.monitor, where i assume you are doing something similar to if sys.platform blah blah.... and use it directly from there?
[11:55] <mandel> gatox, I had some issue with it due to the namespace, I want to be careful and do it in a diff branch with a bug number
[11:56] <mandel> gatox, you know, land it working so we get something ready for usage by people then clean the code
[11:56]  * gatox read that..... and want to kill someone....
[11:57] <gatox> ok..... let me run the tests
[11:58] <mandel> gatox, ein?
[11:58] <mandel> gatox, read what? kill who?
[12:00] <gatox> nothing nothing..... anger managment
[12:00] <gatox> jejee
[12:03] <mandel> gatox, tell me :)
[12:21] <gatox> mandel, need fixing: https://code.launchpad.net/~mandel/ubuntuone-client/daemon-options/+merge/115354
[12:22] <mandel> gatox, oh, goot catch, fixing
[12:43] <mandel> gatox, fix pushed
[12:43] <gatox> mandel, ack
[12:49] <dobey> hrmm
[13:12] <alecu> hola mandel!
[13:13]  * alecu hides
[13:13] <mandel> alecu, tu! ven aca, review!
[13:13] <mandel> alecu, hehehe
[13:13] <dobey> brb, gotta go to dealer real quick
[13:14] <mandel> dobey, get me some dope, please :)
[13:15] <gatox> alecu, hi
[13:19] <gatox> alecu, let me know when you have a moment please
[13:25] <mandel> ok, lunch time here :)
[13:25]  * mandel lunch
[13:26] <ralsina> ppl I am on vacation but I have an eye here, so feel free to ping me if you need me, I may be slow to respond though
[13:27] <gatox> ralsina, ack.......and enjoy! :D
[13:28] <gatox> alecu, i think i have pretty clear the big picture..... i just need to have a quick mumble with you when you have some time to finish to understand one thing, let me know! :D
[13:28] <alecu> gatox: sure
[13:29] <alecu> gatox: 5 mins
[13:29] <gatox> alecu, in 5 mins or 5 mins from now? :P
[13:36] <dobey> heh
[13:40] <dobey> brb again. need to go get some water/snack before i pass out of dehydration and starvation
[13:44] <alecu> gatox: mumble?
[13:46] <gatox> alecu, ack
[13:48] <mattgriffin_1> aquarius: congrats on the release of the java library!
[13:48] <aquarius> heya mattgriffin_1 :) All credit belongs to karni :)
[13:49] <mattgriffin_1> aquarius: not sure if it was intended in the blog post but <code></code> blocks don't show up with different formatting - http://voices.canonical.com/ubuntuone/2012/07/18/ubuntu-one-files-java-library/
[13:49] <mattgriffin_1> karni: w00t!
[13:49] <karni> mattgriffin_1: Hi Matt! Good to see you, thank you!! :)
[13:49] <mattgriffin_1> :)
[13:50] <karni> Good catch on the <code> tags
[13:52] <aquarius> heh, I hadn't seen that we'd released that yet :)
[13:53] <karni> aquarius: We went live just now :)
[13:55] <dobey> oi
[14:16] <alecu> gatox: https://wiki.ubuntu.com/SingleSignOn/UbuntuSsoClient
[14:17] <alecu> gatox: it seems to be up to date, but has lost some of the original formatting.
[14:17] <gatox> alecu, ok, thx, i'll take a look at that
[14:17] <alecu> gatox: also, it has very simple dictionaries, not nested ones. For example: DICT OF {STRING, STRING} EXTRA_PARAMS
[14:18] <gatox> alecu, ok, i'll add the spec there, and then create an example in dbus to check how it behaves with nested data types
[14:19] <alecu> gatox: also https://one.ubuntu.com/developer/files/store_files/ubuntu
[14:19] <alecu> gatox: this second doc seems to be generated from the dbus docstrings
[14:20]  * mandel back
[14:20] <alecu> gatox: but it's very ugly :-)
[14:21] <mandel> alecu, do you think you can do the reviews, if not you can pass and I'll ask dobey or mmcc
[14:21] <dobey> eh?
[14:22] <mandel> dobey, nothing just yet, begging for a review :)
[14:22] <alecu> mandel: I'll force myself into doing it right away.
[14:22] <alecu> mandel: meanwhile you shoot anybody trying to interrupt me.
[14:22] <mandel> alecu, thx! is just that is blocking other 3 branches from landing
[14:22] <mandel> alecu, ok, let me know and I'll take care :)
[14:22] <alecu> mandel: it's this one, right? https://code.launchpad.net/~mandel/ubuntuone-client/fsevents-daemon/+merge/114836
[14:23] <mandel> alecu, yes
[14:27] <mandel> mmcc, this has been updated: https://code.launchpad.net/~mandel/ubuntuone-client/daemon-options/+merge/115354
[14:38] <briancurtin> does anyone else use thunderbird, and if so, do you have any good filtering setup so canonical email isn't like drinking from a firehose?
[14:38] <briancurtin> right now my filter has become "look through, see if i recognize any names looking for merge proposals. if not, delete all"
[14:39] <ralsina> briancurtin: I don't look at merge mail, really
[14:39] <ralsina> briancurtin: I wait for people to ask for reviews
[14:39] <briancurtin> maybe i could just delete all merge mail as long as it's not my review day :)
[14:40] <briancurtin> nah i guess i do like peeking through the actual MP, but dont need to see every comment, every approve, etc...especially from people not on our team
[14:40] <mandel> briancurtin, there are a number of launchpad header you can use for that, I look for X-launchpad-bug containns product=dirspec for bugs
[14:41] <mandel> briancurtin, and for reviews: X-launchpad-notification-type = code-review
[14:41] <alecu> briancurtin: I've been using thunderbird up till a week ago
[14:41] <mandel> briancurtin, but I 'painfully' use evolution
[14:41] <alecu> briancurtin: if you still want to use thunderbird, I suggest auto... something. Let me find it.
[14:42] <mandel> alecu, hey, you, don't get distracted!
[14:42]  * mandel shoots at briancurtin 
[14:42] <mandel> sorry, following orders..
[14:43] <alecu> briancurtin: https://wiki.canonical.com/KamalMostafa/Autofolder
[14:44] <briancurtin> alecu: ahhh there we go, thats what i was thinking of
[14:45] <alecu> briancurtin: I was thinking of moving to that, but I got really tired of imap as a protocol.
[14:45] <briancurtin> im just tired of email as an anything
[14:45] <alecu> :-)
[14:47] <mmcc> howdy folks
[14:48] <mmcc> mandel, looking at your daemon-options merge now. saw it earlier but toddler and code reviews = frustration :)
[14:51] <mandel> mmcc, no problem, I'll be fixing the __init__ and imports in a later branch so that the addition of the daemon is not late due to that if you done mind :)
[14:51] <mmcc> mandel, I don't mind. that sounds like a good plan.
[14:52] <gatox> mandel, i don't see that you review my branch again....... DO IT NOW!! jeje
[14:52] <mandel> gatox, I'm looking and trying to see how bad will it merge with mine :)
[14:53] <gatox> mandel, don't worry about yours..... now is your time to fix conflicts
[14:53] <gatox> just deal with it
[14:53] <mandel> gatox, that is why I worry :)
[14:55] <mmcc> mandel, sorry, I noticed a couple more places for s/active/available/ - should be trivial to fix up, and I'll re review super fast
[14:55] <mmcc> mandel: hope it's not too annoying, just want the naming to be consistent
[14:56] <mandel> mmcc, not at all, just add a comment :)
[14:56] <mmcc> mandel, I did…
[14:57]  * mmcc goes to try setting up autofolder
[15:02] <briancurtin> me
[15:03] <gatox> me
[15:03] <dobey> meh
[15:04] <mmcc> me
[15:05] <dobey> mandel, ralsina, alecu, thisfred: ?
[15:05] <thisfred> me
[15:05] <mandel> me
[15:05] <mandel> ralsina is on holidays AFAIK
[15:05] <ralsina> DONE: vacation TODO: vacation BLOCKED: vacation
[15:05] <dobey> oh
[15:05] <ralsina> but as you can see, I'm intermittently around
[15:05]  * dobey really needs to schedule some of that
[15:06] <ralsina> so no parties
[15:06]  * dobey puts away the rum
[15:07] <mmcc> ralsina, when are you back?
[15:07] <alecu> me
[15:07] <alecu> ralsina, all: I'll be taking half day tomorrow after pm, to babysit amelia, who's on winter holidays.
[15:08] <gatox> briancurtin, go
[15:09] <briancurtin> DONE: dirspec buildout branch (ended up being really trivial...ugh)
[15:09] <briancurtin> TODO: py3 remaining branches, have some filter/comp changes to consider. want to do that before unicode so i actually feel like i'm writing code rather than just reading all the time!
[15:09] <briancurtin> NEXT: gatox
[15:09] <gatox> DONE:
[15:09] <gatox> Reviews, investigate some special widgets for the menu, read about status aggregator, writting the spec for the ipc menu request.
[15:09] <gatox> TODO:
[15:09] <gatox> Publish the spec in the wiki, start coding the ipc menu functions.
[15:09] <gatox> BLOCKED:
[15:09] <gatox> No
[15:09] <gatox> dobey, go
[15:10] <thisfred> mmcc, you
[15:10] <mmcc> DONE: reviews, built .app, synced some files
[15:10] <mmcc> TODO: figure out syncdaemon status IPC bug
[15:10] <mmcc> BLCK: none
[15:10] <mmcc> NEXT: thisfred
[15:10] <mmcc> REMINDER: I'm out tomorrow through monday, moving out of Texas.
[15:10] <thisfred> DONE: refactored query parser in python TODO: refactor query parser in C | add combine() mapping | release u1db on pypi | *party like it's 1999* BLOCKED: no NEXT: mandel
[15:10] <mandel> DONE: Reviews, update MO begged for reviews.
[15:10] <mandel> TODO: file bug about imports and fix it. Beg for reviews land daemon code.
[15:10] <mandel> BLOCKED: no
[15:11] <mandel> alecu, go
[15:11]  * alecu is writting notes
[15:11] <thisfred> mmcc, where are you moving?
[15:12] <dobey> DONE: releases, prepare some backport branches, make tarmac run tests in C.UTF-8u locale
[15:12] <thisfred> or just anywhere but Texas? :)
[15:12] <dobey> TODO: finish releases/uploads, investigate twisted-less dev-tools, work on some reorg to drop ubuntuone-installer for good, finish SRU verification poking
[15:12] <dobey> BLCK: None.
[15:12] <dobey> sorry. got distracted
[15:12] <thisfred> damn butterflies
[15:12] <mmcc> thisfred: Back to San Diego, CA. (But I'll be waking up much earlier to stay ~ in sync with you guys)
[15:12] <thisfred> mmcc, nice!
[15:13] <mandel> mmcc, not really to worry I'm the only eu guy, right?
[15:13] <thisfred> I'm moving to Portland, OR in september, so very much in the same boat time wise
[15:13] <mmcc> thisfred: yeah, we're looking forward to it. we'll be much closer to family.
[15:14] <mmcc> thisfred: cool! I love Portland - we might go there after San Diego (when the money runs out :)
[15:14] <thisfred> hehe
[15:14] <ralsina> mmcc: I will be back late next week
[15:14] <mandel> thisfred, does that mean you are going to ride a fixy and be a hipster?
[15:14] <mandel> thisfred, you already have the music, the interesting dog and the t-shirts ;)
[15:14] <mmcc> ralsina: cool! have a great vacation :)
[15:14] <ralsina> thisfred: WAT?
[15:15] <thisfred> mandel, I am totally a hipster. King of all hipsters!
[15:15] <ralsina> everyone on the team who's not changing timezones raise his hand please! ;-)
[15:15] <thisfred> ralsina, oh damn, you're still here
[15:15] <mandel> o/
[15:15] <thisfred> ralsina, I meant parse line 1999
[15:15] <alecu> DONE: fixes for the twisted bug upstream, mumbled re status aggregator with gatox
[15:15] <alecu> TODO: reviews, more reviews
[15:15] <alecu> BLOCKED: no
[15:15] <mandel> ralsina, but if country goes down the toilet I'll have to
[15:15]  * ralsina schedules mandel as a mover
[15:16] <thisfred> ralsina, I told you about the move, though that was approximately a year ago :)
[15:16] <gatox> mandel, i just looking for excuses to move to argentina....
[15:16] <thisfred> you said it was ok, as long as I was willing to get up at 6 :)
[15:17] <briancurtin> ralsina: i'm not changing timezones and it looks like i wont even have to move. apartment situation figured out! (at least for now...)
[15:18] <mandel> mmcc, branch updated :)
[15:18] <mmcc> mandel, looking now
[15:18] <mandel> thx!
[15:19] <mmcc> mandel: approved
[15:19] <mandel> toma! mmcc thx
[15:20] <mandel> I'll file a bug for the imports
[15:20] <mmcc> cool
[15:20] <ralsina> briancurtin: awesome!
[15:20] <mandel> alecu, you are the last reviewer I need :)
[15:20] <ralsina> briancurtin: you had me worried
[15:20] <mmcc> so, did anyone get my email from last night and try out the .app I posted?
[15:20] <ralsina> mmcc: got it, not tried it
[15:20] <mandel> mmcc, nop, but I can try it in a few mins or later after EOD infront of the tv :)
[15:20] <briancurtin> i was pretty worried myself. the way this whole thing was going i was pretty sure they were just going to kick everyone in the building out right away
[15:20] <mmcc> ralsina: ok, well you're on vacation, so take your time :)
[15:22] <mmcc> mandel, if you're just waiting now, can you peek at these errors I'm getting from IPC between syncdaemon and control-panel on darwin: http://paste.ubuntu.com/1097819/ http://paste.ubuntu.com/1097821/
[15:22] <gatox> mmcc, did you send it to me too?? i don't see it
[15:22] <mmcc> mandel: just to see if anything pops out. I am pretty sure I'm up to date with the packages I put in there
[15:22] <mandel> mmcc, we have that in all platforms, we never got to fix it
[15:22] <briancurtin> speaking of apartments, since im out of ink i'm heading down the street to print out some docs i need to sign for the lease. will be back shortly
[15:22] <mmcc> gatox: I meant to.. let me check
[15:23] <mmcc> mandel: really? it seems to cause real problems. ..
[15:23] <mandel> mmcc, I've seen it on windows for sure and some linux.. gatox, alecu, ralsina you have seen that, right?
[15:24] <ralsina> on windows it seemed to be harmless
[15:24] <mmcc> hmm. ok, maybe it is harmless. there is certainly room for something else to be causing the problems I saw
[15:25] <mmcc> I tried to figure out what was causing it but that RPC code is a little convoluted for 2AM
[15:27]  * gatox lunch
[15:29] <alecu> mmcc: it's more than a little convoluted, no matter how much awake you are
[15:30] <mmcc> alecu: :)
[15:30]  * mmcc was being polite :)
[15:33] <mandel> mmcc, alecu, is great, because it works and it can be used to share secrets within the code and no one will ever know
[15:34] <mandel> is that a real method, is the decorator needed?
[15:39] <mmcc> mandel, were you asking me?
[15:39] <mandel> mmcc, bad joke :)
[15:40] <mandel> mmcc, once you get in that ipc stuff.. you will understand the decorator comment
[15:40] <mmcc> mandel: heh, ok.
[15:43] <alecu> mandel: ping
[15:43] <mandel> alecu, mmcc, which reminds me to http://www.youtube.com/watch?v=2EnkSshoEkk&feature=youtu.be&t=19m30s
[15:43] <mandel> alecu, pong
[15:43] <alecu> mandel: why is this static? DAEMON_SOCKET = '/var/run/ubuntuone_fsevents_daemon'
[15:44] <mandel> alecu, because at the moment is always the same one, will fix that in a later branch to be passed
[15:47]  * briancurtin back
[15:49] <mmcc> briancurtin: did you get a chance to try that autofolder thing? I too was drowning in bug mail… tried it but the instructions don't work for me :\
[15:49] <alecu> mandel: does this mean that right now every logged in user can spy on the events of every other user?
[15:50] <briancurtin> mmcc: i didn't try it yet. i guess you need to do an RT and get access to run it all. i may start down that path later this afternoon
[15:50] <alecu> mandel: so, you don't regret spaghetti ipc either??? :-)
[15:50] <briancurtin> but i might also just forget about it and just delete all of my email
[15:51] <mandel> alecu, no, the sever will request the user id from the connected client and will only send events for those paths owned by the same user id
[15:51] <mandel> alecu, I regret it, and I inherited the design, the 3/4 layers in sso are not mine :)
[15:51] <mandel> alecu, but is in my list of 'pecados' that I want to fix in u1client
[15:52] <mmcc> briancurtin: ah, ok. yeah I can log into mail.canonical.com but it kicks me right away. I'll let you know if I learn anything valuable
[15:52] <mandel> alecu, the idea is that when the user connects we get the uid from the connecting process so you cannot request events of a path you don't own
[15:52] <alecu> mandel: right. But what if two users are logged in at once? Can you do that in mac at all?
[15:53] <mmcc> alecu: two users can log in, sure. but the server won't send the events for a path owned by user 501 to user 502
[15:53] <mmcc> and once it's integrated, the hardcoded path to a socket goes away in favor of a launchd 'checkin'
[15:54] <mandel> which is the next step
[15:54] <mandel> but right now is hardcoded to get a bundle working
[15:54] <alecu> mmcc, mandel: great then!
[15:55] <mandel> alecu, ideally we are in the state where we have an alpha doing syncing etc.. and yet not perfectly integrated with launchd, step by step :)
[15:56] <mmcc> mandel: yes - today I'll try getting a bundled app to connect with the root daemon
[15:57] <mandel> mmcc, awesome, I think it will nice for us to talk about the next steps, but maybe after your holiday/move
[15:57] <alecu> mandel: "from ubuntuone.darwin import fsevents" <- where does this come from?
[15:57] <mandel> alecu, is the python code in the lp:ubuntuone-fsevents-daemon so that all protocol info/code resides in the same place
[15:58] <mmcc> mandel: sure, I have a few smaller things to clean up today. we can talk next week
[15:58] <mandel> alecu, ideally if there are changes in the protocol u1-client should not care
[15:58] <mandel> mmcc, same here :)
[15:58] <mmcc> assuming I make it out of Texas alive
[16:00] <dobey> ugh. "ubuntuone.darwin" ?
[16:00] <alecu> dobey: ditto
[16:00] <mandel> meh, I had to add a bloody namespace and I did not want to do ubuntuone/platform/darwin
[16:00] <alecu> mandel: would you mind making a bug to move that to a different namespace?
[16:01] <dobey> ubuntuone.fsevents should be the namespace of ubuntuone-fsevents-daemon
[16:01] <mandel> alecu, not at all
[16:01] <alecu> mandel: great.
[16:01] <mandel> dobey, sure, I'm bad with names and is not too much work
[16:02] <mmcc> hrm. ubuntuone.fsevents doesn't tell me that it's darwin-only, or that it's the root daemon (as opposed to the other module we have that accesses fsevents)
[16:02] <mmcc> not that I have a much better suggestion right now…
[16:03] <alecu> ubuntuone.fseventsd ?
[16:03] <mandel> dobey, alecu, mmcc bug 1026209
[16:03] <mandel> comments for names are welcome :)
[16:04] <alecu> mandel: your name looks fine. Let me know if you have kids or a new dog.
[16:04] <alecu> mandel: I can do a review in that case :-)
[16:04] <mandel> alecu, hehe ok :)
[16:04] <alecu> mandel: also, do you have a bug for filling in the empty function events_dropper() ?
[16:05] <mandel> alecu, adding, I have to talk with _facundobatista about what to do then
[16:06] <mandel> mmcc, FYI bug 1026212
[16:06] <dobey> file bugs as bugs, not TODOs :)
[16:07] <mandel> dobey, agg I rephrase things..
[16:08] <alecu> mandel: here's a different concern: "any(path.startswith(watched_path) for watched_path in self.watched_paths)"
[16:09] <mandel> alecu, shoot, what is the issue
[16:09] <alecu> mandel: those lookups have a tendency to degrade awfully. But it's probably just me thinking of premature optimization.
[16:10] <alecu> mandel: the thing is that for every watched path (or ignored, in the following line), we end up doing a whole byte-per-byte comparison.
[16:11] <mandel> alecu, the max num of watched paths is the number of udfs, it will take a long time to be a problem, on the other hand the ignored paths could be a problem if there are lots of add remove dir operations and we might look at a way to clean that
[16:11] <mandel> alecu, having said that, we should fix that on windows and the user fsevents implementation because a similar approach is taken
[16:12] <alecu> mandel: oh, right, with the root daemon we have a watch per udf, I was thinking of a watch per folder.
[16:12] <mandel> alecu, exactly
[16:12] <mandel> alecu,  we can look at optimizations about this for the ignored paths
[16:15] <alecu> mandel: there are a few typos all around, but this one is really hard to understand: "lets generate to" -> "let's generate two"
[16:16] <mandel> alecu, uh.. sorry can you add them in comments and I'll fix all of the in one go?
[16:16] <alecu> sure
[16:16] <mandel> thx
[16:17] <alecu> mandel: in fact, I'll only correct that one, I find it an excercise in futility, since you have not yet installed a spellchecker in your editor :-P
[16:18] <mandel> alecu, I'll take the thing for a spell check :)
[16:18] <alecu> can you explain why this happens?
[16:18] <alecu> 1031 + # FIXME: event deduces the pathname wrong and we need to manually
[16:18] <alecu> 1032 + # set it
[16:18] <mandel> alecu, is an issue for the pyinotify code we have, I need to look at it to understand the bug
[16:19] <mandel> alecu, under the pyinotify agnostic code
[16:20] <mandel> alecu, I can add a bug and fix it in all the impl that use it, windows, user fsevents and daemon fsevents have the same problem
[16:23] <alecu> mandel: that would be great.
[16:23] <dobey> ok, need to get lunch. bbiab
[16:23] <alecu> mandel: process_IN_MOVED_TO has too many levels of nested ifs
[16:25] <alecu> mandel: perhaps you can move the outermost if else, so the else is on top, and returns from the function after logging the error...
[16:25] <alecu> mandel: and why is the second level else not logging something?
[16:26] <alecu> mandel: the second level else has the same comment as the first: # we should never get to this point on darwin, never ever!
[16:26] <alecu> mandel: but the second level else logs no warning...
[16:26]  * alecu wears a puzzled look
[16:26] <mandel> alecu, yes, in a following branch the notify processor is shared between windows,darwin-user and darwin-daemon and that should be fixed there
[16:27] <mandel> alecu, look here: https://code.launchpad.net/~mandel/ubuntuone-client/unify-processors/+merge/114906
[16:27] <mandel> alecu, this is just the tip of a huge 6000 lines branch split in diff smaller working branches
[16:28] <mandel> alecu, I think we have to fix that in the later branches, also, linux has the same amount of nested ifs which we might as well fix: http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-client/trunk/view/head:/ubuntuone/platform/filesystem_notifications/linux.py#L254
[16:28] <mandel> is not a nice method, you are right
[16:29] <mandel> is also interesting to note that I dont think that is really needed because is dealing with lost events which AFAIK does not happen in any platform but linux
[16:29] <mandel> so we can clean up that method a lot more
[16:30] <mmcc> mandel - lost events? is that the same as dropped events? those do happen on osx
[16:30] <mandel> mmcc, lost not dropped, moved_to with no moved_from
[16:30] <mandel> mmcc, when in linux you moved from a watched folder to a not watched one
[16:31] <alecu> mandel: you've mixed the examples!
[16:32] <alecu> mandel: "moved from a watched folder to a not watched one" is "moved_from without moved_to"
[16:32] <mandel> alecu, sorry yes
[16:32] <mmcc> ah, ok - and IIRC, the other platforms fake those events and generate them together or something right? so there is always both events on win/darwin?
[16:33] <mandel> while on windows that does not happen and on fsevents user AFAIK it does not (is translated to a delete, right gatox)
[16:33] <mandel> mmcc, yes, in windows you always get them one after the other, on fsevents user is translated to a delete on fsevents daemon you do get both events
[16:33] <mmcc> aha, ok
[16:33] <gatox> mandel, right
[16:35] <mmcc> so I need to write some code to do part of the 'install' step on first run, since we won't have an installer for macos
[16:35] <mmcc> need to copy .conf files and ssl certs to the right place.
[16:36] <mandel> mmcc, and add the daemon if possible
[16:36] <mandel> mmcc,  which means adding it to the bundle too, right?
[16:36] <mmcc> need to figure out where to put stuff: ssl certs on OSX are traditionally stored in the keychain, but since we're not using OSX api, I think we can just put them in the "~/Library/Application Support/UbuntuOne/" directory (which will be xdg_data_home)
[16:37] <mmcc> mandel: yes, that'll be the same code that adds the daemon.
[16:37] <mmcc> mandel: and yes, it needs to go in the bundle
[16:39] <mmcc> mandel, that'll be bug 1026235
[16:40] <mandel> mmcc, awesome
[17:10] <mandel> all, I'm EOD laters!
[17:19] <mmcc> UbuntuOne.app now ~10 MB smaller, because all dependencies are in the .zip
[17:20] <mandel> mmcc, current total size?
[17:20] <mmcc> mandel, 98 MB.
[17:21] <mandel> mmcc, getting to a reasonable size
[17:21] <mandel> by the way I have been thinking about this: https://github.com/kfdm/gntp/
[17:21] <mandel> mmcc, anything against growl integration for the notifications?
[17:22] <mmcc> mandel: yep. there are probably some things we can prune too. All the Qt libs are included and we may not use them all…
[17:23] <mandel> anyway, I'm off to have a milkshake, laters :)
[17:23] <mmcc> mandel: no, I like growl. need to read up on how they're changing WRT 10.8 though
[17:23] <mmcc> because 10.8 has its own notification center that behaves differently
[17:23] <mmcc> and IIRC sandboxed apps can't use growl
[17:23] <mandel> mmcc, we can do growl integration and 10.8 thingy integration, also, there is a growl for windows
[17:24] <mmcc> enjoy your milkshake, I'll talk to you Tuesday
[17:24] <mandel> mmcc, so, we can have 2 for 1 :P
[17:24] <mmcc> sounds good. just as long as we avoid ever showing two notifications for the same event… that'll get some angry twitters I bet
[17:27] <mmcc> fwiw - I was wrong, a recent update to growl has a 'lite' version that works from within sandboxed apps: http://growl.info/notetodevelopers
[17:49] <gatox> alecu, it's working with dbus :D
[17:57] <mmcc> alecu, may I request a review for setup-mac changes: https://code.launchpad.net/~mikemc/ubuntuone-windows-installer/package-everything/+merge/115596
[18:01] <dobey> is anyone helping alecu do reviews today?
[18:02] <mmcc> alecu: and (this one is much shorter) https://code.launchpad.net/~mikemc/ubuntuone-storage-protocol/darwin-certs/+merge/115599
[18:03] <briancurtin> i wouldnt mind doing a review. mmcc - is that package one anything super mac specific?
[18:03] <mmcc> briancurtin: yes! it's as mac-specific as it gets. you won't be able to test it, I guess, but a code review couldn't hurt
[18:04] <briancurtin> mmcc: i'll take a look and see what i can contribute
[18:04] <mmcc> briancurtin thanks! also the other one is a lot less mac specific.
[18:05] <dobey> i need easy reviews of backport branches that are just merging stuff from trunk to stable-4-0
[18:06] <mmcc> dobey, maybe you could take a look at this one too? I'm not 100% sure it's doing the right thing, it's telling storageprotocol to look for the SSL certs in XDG_DATA_HOME, which is similar to how we do it in windows... https://code.launchpad.net/~mikemc/ubuntuone-storage-protocol/darwin-certs/+merge/115599
[18:06] <dobey> https://code.launchpad.net/~dobey/dirspec/update-4-0/+merge/115597
[18:06] <mmcc> dobey: I'll help with some of those
[18:06] <dobey> mmcc: i don't think that's write; the _HOME variables would be paths into the user's directory
[18:07] <dobey> mmcc: also, you can just import "xdg_data_home" and use it as the variable
[18:08] <mmcc> dobey: yeah I wanted to hash out where the certs should go. there isn't a standard path to put them in OSX - the usual thing is to store them in the keychain, using some C API we could use if we wanted to
[18:10] <dobey> well, we should probably switch to using the system certs DB on all the platforms, rather than shipping our own copies of a few certs
[18:10] <dobey> but either way, we wouldn't be installing anything to the user's home
[18:12] <mmcc> briancurtin: what is the Common AppData reg key on your system? I don't seem to have it in my VM's registry. That's where storageprotocol looks for the certs…
[18:12] <mmcc> the other AppData keys are in my home dir.
[18:13] <mmcc> I wonder if we add the cert to the system keychain, will Qt use it?
[18:13] <briancurtin> mmcc: do you have a full path? i'm familiar with AppData by itself, "Common AppData" looks weird as a key
[18:13] <dobey> mmcc: the certs are probably already in the system keychain
[18:14] <mmcc> briancurtin: here's the code: http://paste.ubuntu.com/1098734/
[18:15] <briancurtin> ohhh C:\ProgramData
[18:15] <briancurtin> and there's a ubuntuone-storageprotocol folder in there with the certs
[18:16] <briancurtin> mmcc: what version of win are you running in this vm?
[18:17] <mmcc> briancurtin: it's win 7
[18:21] <mmcc> dobey, the valicert one and the godaddy class 2 one are indeed in my keychain already. The godaddy intermediate one is not.
[18:22] <briancurtin> mmcc: even though you dont have that Common AppData, do you have C:\ProgramData with any ubuntuone sub-folders?
[18:23] <dobey> mmcc: i guess on osx we'd have to pull them out of the bundle somehow to load them
[18:24] <dobey> mmcc: so maybe use the get_program_path() from dirspec utils to get them?
[18:24] <dobey> although it will fail when not in the bundle
[18:24] <mmcc> briancurtin: yes, I have C:\ProgramData\ubuntuone-storageprotocol with the certs in there... weird that I didn't see that path in regedit
[18:25] <dobey> maybe we need some more API there
[18:25] <briancurtin> i got there from the full "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common AppData"
[18:27] <mmcc> briancurtin: aha, in retrospect I was looking at HKEY_CURRENT_USER\blah de blah - even though I thought I checked that :\
[18:27] <mmcc> thx
[18:30] <mmcc> dobey: yes, dirspec needs some more tweaking for osx. these config paths should really be under ~/Library/
[18:31] <mmcc> as far as finding the certs to install them, they'll be at a fixed location in the app package, so the same code that installs the conf files can do the cert install, and I don't think we need to use dirspec for that. It'll only be used in one place
[18:33] <dobey> mmcc: well, dirspec already has the code to look in the sub-app and whatnot. i don't think we'll need to only look in (from) one place to find extra data files
[18:37] <mmcc> dobey, the data files from the sub-apps (eg, syncdaemon's conf file and storageprotocol's certs) are all installed into the top-level app's Resources directory. All the sub apps just link to it.*
[18:37] <mmcc> * - that's a lie: for now, they all have a copy of every conf file and .pem, but that's a TODO
[18:39] <mmcc> ok, time for lunch here. back in a bit
[18:44] <dobey> alecu, briancurtin: either of you care to review https://code.launchpad.net/~dobey/dirspec/update-4-0/+merge/115597 ?
[18:44] <alecu> dobey: sure. I'm doing mmcc's reviews, and then I'll get to yours.
[18:45] <briancurtin> dobey: will do
[18:54] <dobey> also have https://code.launchpad.net/~dobey/ubuntu-sso-client/update-4-0/+merge/115606 which needs review
[19:10] <dobey> and https://code.launchpad.net/~dobey/ubuntuone-control-panel/update-4-0/+merge/115607
[19:49] <gatox> alecu, ping
[19:49] <alecu> gatox: pong
[19:50] <gatox> alecu, i already have a new item in the api, where it's returning a lot of stuff via dbus that i can use in the menu, such as the files being uploaded and the progress of each one, etc.....
[19:50] <gatox> alecu, buttttt
[19:50] <gatox> i have some doubts regardings some of the actions
[19:51] <alecu> gatox: do you have the spec for the dict?
[19:51] <alecu> gatox: do you want to mumble regarding the actions?
[19:51] <gatox> alecu, ok, better
[19:51] <gatox> alecu, in mumble
[20:01] <alecu> gatox: http://pastebin.ubuntu.com/1098954/
[20:02] <gatox> alecu, http://developer.ubuntu.com/api/ubuntu-11.10/python/Dbusmenu-0.4.html
[20:04] <alecu> gatox: https://wiki.edubuntu.org/Unity/LauncherAPI
[20:04] <dobey> are you adding quicklists to the launcher, or are you working on the sync menu?
[20:19] <gatox> alecu, bssssasaa{si}as
[20:23] <dobey> gatox: what the heck? you're adding new dbus api with a signature like that?
[20:24] <alecu> dobey: I'm talking him out of that idea, right now.
[20:25] <dobey> good
[20:25] <dobey> we probably already have all the api he needs (aside from the fact that one set of signals is currently broken)
[20:25] <alecu> {"file1_percentage": 30, "file1_name": "pr0n.png"}
[20:25] <alecu> gatox: ^
[20:25] <dobey> uh
[20:26] <dobey> just fix the UploadProgress and DownloadProgress signals to work :)
[20:32] <alecu> dobey: I remember that verterok disabled some of those dbus signals because they were clogging the cpu
[20:34] <mmcc> about halfway through that u1client update-4-0 merge.... just so we don't get too many people reading all 4000 lines of it
[20:35] <dobey> alecu: right, i know the Event one would have done that. but if we're going to be sending progress over dbus every X ms or anything, we should use the signals we already have
[20:37] <alecu> dobey: we are only going to query progress when the sync menu is opened. And perhaps query it every 1000ms while it's opened.
[20:38] <alecu> dobey: I think it makes no sense to send those signals all the time if nobody is using them for nothing.
[20:38] <mmcc> no way to only send signals if someone's listening?
[20:38]  * mmcc is not familiar with dbus
[20:39] <dobey> alecu: we had one person wanting to use them last week, in their ubuntu app showdown entry; but the signals don't work so they couldn't use them
[20:39] <dobey> mmcc: the bus daemon (the server) is always listening. it's basically a proxy for the messages
[20:40] <dobey> mmcc: so we'd always send them regardless of any apps listening or not
[20:41] <dobey> but we could add API to "register" that something is watching, and only send those signals out when that dict isn't empty or something
[20:41] <mmcc> dobey: ok. I guess I could imagine a more complicated protocol that'd have the server let you know when to start & stop sending messages based on who'd registered for them... but it sounds like you'd have to build that yourself
[20:41] <mmcc> ayup
[20:56] <mmcc> dobey, ping about osx-specific basedirs in dirspec
[20:57] <mmcc> for the paths vars, since the linux paths (/etc/xdg/) *could* exist on osx, I was going to just insert the osx-specific version in front.
[20:57] <mmcc> for example, default_config_path = '/Library/Preferences:/etc/xdg'
[20:58] <dobey> mmcc: that's probably doable. i have no idea what real OSX apps expect.
[20:58] <alecu> gatox: I can't hear you anymore
[20:58] <gatox> ah
[20:58] <gatox> alecu, well, i was just saying:
[20:59] <alecu> crap, it must be my isp again
[20:59] <gatox> alecu, that i'm going to ask mandel if this structure is possible in windows, and if he says yes, go with it, or in the other case, start thinking about another possible structure
[20:59] <alecu> since they've opened a customer care center round the block, the internet connection has been crapier.
[20:59] <alecu> gatox: awesome
[21:00] <mmcc> dobey: an app written just for osx will almost certainly only ever write files to your home, and it'll put everything under ~/Library - Caches, Preferences, and "Application Support"  for misc other data
[21:01] <mmcc> and that's what u1 should do, but since dirspec is supposed to be more broadly usable I thought it couldn't hurt to allow it to return search paths that have fallbacks to linux style paths
[21:01] <dobey> right
[21:02] <mmcc> although I am not sure I have a good use case for that, really. maybe if I'm using dirspec to read a file written by a linux utility that doesn't use dirspec, and also doesn't follow osx conventions…
[21:02] <dobey> well the freedesktop base dir spec doesn't say anything about osx, i think. but it probably should
[21:02] <dobey> it also doesn't say anything about windows, but we support it in dirspec
[21:03] <mmcc> yeah. I'm looking at the spec again now… IIRC it doesn't mention macs
[21:04] <gatox> bye all!! see you tomorrow people! :D
[21:06] <mmcc> bye gatox
[21:09] <mmcc> dobey, now that I read the spec again I think the right thing is to define the osx-specific defaults but also include the xdg defined versions as fallback, *including* putting the default ~/.config at the front of default-config-path, so the search goes like this: osx standard home path, XDG default homepath, osx standard global path, xdg default global path(s)
[21:11] <dobey> mmcc: we can't have both the osx and xdg home paths though, because they aren't path (separated by ":") variables. they're just single paths
[21:19] <mmcc> dobey: I know - I was suggesting adding the xdg default value for e.g. config_home to the beginning of the config_path
[21:20] <mmcc> because the spec says you search in config_home, then you search through config_path. so we'd be searching osx-home,xdg-home,osx-global,xdg-global(s)
[21:20] <mmcc> effectively
[21:21] <dobey> mmcc: no, there would be no xdg-home there
[21:22] <dobey> or well, xdg_*_home would be the same as whatever osx would expect it to be
[21:23] <mmcc> right - this is what I meant: http://paste.ubuntu.com/1099076/
[21:24] <mmcc> the config_path variable starts with the default value for config_home from the xdg spec
[21:24] <dobey> right, that would be wrong
[21:25] <mmcc> can you expand on that? :) The spec doesn't say not to put things under $HOME in config_path…
[21:26] <dobey> the spec says you should look in $XDG_CONFIG_HOME first, then in $XDG_CONFIG_DIRS. that doesn't mean that $XDG_CONFIG_DIRS should start with a different value for CONFIG_HOME than CONFIG_HOME is defined as
[21:28] <mmcc> hm. ok, fair enough.
[21:30] <mmcc> so then i think it should use the osx conventions only - since only providing the xdg default fallback for the global location doesn't seem right…
[21:35] <dobey> well, i think we do need to provide the fallbacks for the global locations, in the library
[21:36] <dobey> otherwise it's useless to developers who expect it to behave with the POSIX paths
[21:36] <dobey> but on the other hand, some of these directories also just don't exist on OSX
[21:36] <dobey> so i think we need to see what does exist in those situations as well, and use what makes sense for covering the most cases with the least code
[21:39] <mmcc> wtf
[21:39] <dobey> ?
[21:39] <mmcc> can't seem to get it to send my response, but it sends 'wtf'
[21:39] <mmcc> sorry
[21:39] <dobey> heh
[21:39] <mmcc> so, /usr/share and /usr/local/share both exist and have lots of crap in them on both my macs... /etc exists (symlink to /private/etc) but /etc/xdg does not
[21:41] <mmcc> if we provide the global fallbacks, that's fine - the spec says just ignore nonexistent entries in the *path
[21:41] <dobey> right
[21:41] <dobey> and that is done already, automatically by the APIs in dirspec
[21:41] <mmcc> ok, I'm convinced. osx specific HOME locations, and global search paths that start with the global osx location but include fallbacks for global xdg defaults
[21:46] <alecu> mmcc: I think "ubuntu-sso-proxy-creds-qt" is still used; it's "ubuntu-sso-ssl-certificate-qt" the one that should be commented.
[21:47] <alecu> mmcc: I'm talking about https://code.launchpad.net/~mikemc/ubuntuone-windows-installer/package-everything/+merge/115596
[21:47] <mmcc> alecu, indeed - thanks! I need a vacation.
[21:47] <mmcc> ok, not really. maybe just a nap
[21:51] <mmcc> alecu, ok pushed a fixed version. I did briancurtin's suggested style change too. Thanks!
[21:51] <alecu> mmcc: great!
[21:56] <mmcc> just saw a note that mac app store submissions now require an icon at 1024x1024 resolution
[21:58] <alecu> isn't it already time for vector pictures?
[21:58] <alecu> mmcc: what's the best way to test this new setup-mac.py?
[21:59] <dobey> mmcc: i should send apple a note requiring them to give me a 300dpi display for submitting an app to their store
[22:00] <mmcc> alecu, i suggest trying to run it - the change description has some notes, but I'm sure I probably missed some thing
[22:01] <mmcc> dobey - heh. they'll be glad to, for only $2200
[22:02] <mmcc> alecu, the quirk is that setup-mac currently assumes it's in a separate branch under the buildout's parts/ directory
[22:02] <mmcc> so if you have an existing buildout, go to parts and branch lp:ubuntuone-windows-installer
[22:02] <alecu> mmcc, oh, ok. That's what I need to know.
[22:02] <dobey> ok, well, time for me to go. will have to finish up these releases in the morning i hope
[22:02] <dobey> have a good evening all
[22:03] <mmcc> bye dobey, thanks for hashing out that dirspec stuff with me (again :) )
[22:04] <mmcc> alecu: then grab branches of the stuff I mention in the description, and when you run it, I guess temporarily symlink /etc/ssl/ to ubuntuone-syncdaemon/data
[22:05] <alecu> mmcc: ln -s /etc/ssl ubuntuone-syncdaemon/data ? or viceversa?
[22:06] <mmcc> vice versa. make /etc/ssl a link to ubuntuone-storage-protocol/data
[22:07] <mmcc> I meant storage-protocol the first time too
[22:08] <alecu> ack
[22:08] <mmcc> alecu wait there's another bit - you need current trunk of py2app also
[22:08]  * mmcc needs to consolidate these notes, sorry
[22:08] <alecu> mmcc: where should I install py2app?
[22:09] <alecu> or should I use brew for that?
[22:09] <alecu> mmcc: also: when running "PYTHONPATH=$PYTHONPATH:. python setup-mac.py py2app" I get this error:
[22:10] <alecu> error: /Users/alecu/canonical/ubuntuone-windows-installer/scripts/devsetup/parts/package-everything/scripts/bin/ubuntu-sso-login-qt.py: No such file or directory
[22:10] <mmcc> no, don't use brew, you need to get it from bitbucket…
[22:10] <mmcc> and you will need to run setup-mac.py prepare first (you can run it as setup-mac.py prepare py2app)
[22:10] <mmcc> sorry this is rough - thanks for being the first to wade through it
[22:11] <mmcc> I'm looking for the full notes. I think I even needed to get dev versions of py2app's dependencies
[22:12] <alecu> DONE!
[22:13] <mmcc> really?
[22:13] <alecu> I've just clicked on the control pannel .app
[22:13] <alecu> mmcc: great work, congrats!
[22:13] <mmcc> thanks, but I don't believe you :)
[22:14] <alecu> mmcc: The control panel is totally broken, but it's not your fault :-)
[22:14] <mmcc> what's broken for you? it should be almost totally working, depending on how recent your source branches are
[22:15] <mmcc> also - did you have to get py2app from bitbucket? and did it install OK with its deps?
[22:16] <mmcc> and finally, what os x version are you using?
[22:18] <alecu> mmcc: I've not even installed the latest py2app yet, so this is probably it.
[22:18] <alecu> mmcc: lion
[22:19] <mmcc> ok, interesting.
[22:19] <alecu> mmcc: also: probably not all trunks are up to date. And I've not started sso, u1-client, etc.
[22:19] <mmcc> so how far does it get?
[22:19] <alecu> mmcc: I just wanted to test your branch, and it seems to be building everything as expected :-)
[22:21] <mmcc> heh, fair enough - no need to debug everything. yes it does seem to be doing what it should. can you maybe do a quick ls of UbuntuOne.app/Contents/Resources/Ubuntu SSO Helper.app/Contents and check that it's created symlinks?
[22:21] <mmcc> symlinks that aren't broken? that'd be the best test of the current change
[22:21] <alecu> mmcc: as soon as I open u1cp, it opens a dialog that says "Sorry, an error has occurred and Ubuntu One needs to close." But the control panel is shown beneath it, and the web links at the botton show up.
[22:22] <mmcc> alecu: ok, sounds like out of date branches.
[22:22] <mmcc> or the same issue I found on Lion. that's a todo- for now it may not build right on Lion
[22:23] <alecu> mmcc: I see that both Fraeworks and PkgInfo are symlinks to ../../../x
[22:23] <mmcc> sounds good
[22:26] <alecu> mmcc: I've approved it.
[22:26] <mmcc> thx alecu.
[22:50] <mmcc> anyone still around for a really trivial review of a typo fix in dirspec? https://code.launchpad.net/~mikemc/dirspec/fix-1026369-typo/+merge/115633
[22:53] <alecu> mmcc: done
[22:53] <alecu> and EOD!
[23:29] <mmcc> and I'm out - see everyone on Tuesday