[12:16] <CardinalFang> aquarius, did you see my message yesterday about d-c pairing and couch?
[12:16] <CardinalFang> aquarius, you used "put", not "put_record".
[12:17] <CardinalFang> I haven't run the code, but I think that's not right.
[12:34] <aquarius> CardinalFang, I agree, it's not right; that code fails before it gets that far because of the 401 problem
[12:35] <aquarius> CardinalFang, how did you guys get on after I left?
[12:35] <CardinalFang> aquarius, well, I'm up early to get code out the door, if that tells you anything.
[12:36] <CardinalFang> aquarius, nothing new to report.
[12:36] <CardinalFang> aquarius, except statik merged some branches.
[12:36] <aquarius> kk
[12:37] <aquarius> want me to work on some of the stuff with you?
[12:37] <aquarius> is there anything you're doing that I can pick up?
[12:46] <aquarius> CardinalFang, or have you basically done it all? :)
[12:48] <CardinalFang> aquarius, hmm.  I've done nothing with actually getting oauth tokens, so "pairing storing oauth tokens".  Also, I plan to move some that code of yours yesterday into the desktopcouch.pair.couchdb_pairing.couchdb_io so it can be shared with the local stuff where possible.
[12:49] <aquarius> CardinalFang, hang on, I didn't quite follow that
[12:50] <CardinalFang> aquarius, ignore the second sentence for now.
[12:51] <aquarius> so...the things that you were doing, as I understand it, are: have the pairing app exchange oauth tokens as part of the on-the-wire protocol, and the daemon which starts and maintains continuous replication. If I read you right, you're working on the second (the daemon) but not the first (the pairing app)?
[12:53] <CardinalFang> aquarius, we need to get/generate oauth tokens for every pairing, as I understand it (which is really not at all!).  If you can make the function that gets the token from U1 (?), I can make the pairing tool exchange them.  Yes, I'm doing 2.  If you will do 1a, I'll also do 1b.
[12:55] <aquarius> ok. I've already done the code which initially generates the oauth token and stores it in the ini file; I'll write a function which can extract that token from the ini file so you have access to it
[13:01] <CardinalFang> Grr.  0800.  Must take the kid to the babysitter.  Back in a while.
[13:01] <thisfred> morning
[13:02] <CardinalFang> aquarius, a nice fat comment saying what the pieces mean would be gratifying too.  :(  I really must read up on oauth one day.
[13:02] <aquarius> kk (which pieces specifically?)
[13:03] <CardinalFang> Er, if I knew that, I might not need any comment.  There are three, or two opaque numbers, yes?
[13:03] <aquarius> right, so you want to know what the consumer key and token and token secret and etc mean? gotcha
[13:04] <CardinalFang> Yes.   Morning, all!
[13:05] <thisfred> best dog toy ever: ice cubes
[13:06] <aquarius> hey thisfred
[13:07] <aquarius> any word from jchris?
[13:07] <thisfred> aquarius: none: he wasn't online as far as I could tell yesterday, and on the mailing list nothing specific to our cause yet
[13:07] <thisfred> still going through
[13:18] <aquarius> kk
[14:24] <thisfred> aquarius: so, no mail from chris, and he's not on the channel now. jan____ is away, but we need to verify that this issue is treated with some sense of urgency, since you're blocked by it (correct?)
[14:25] <aquarius> correct
[14:27] <thisfred> ok, I don't know who on the #couchdb channel we can speak to about this, jason also isn't there. SteveA should we mail/call couch.io?
[14:27] <thisfred> rehi CardinalFang
[14:28] <aquarius> re CardinalFang. function to get oauth tokens now in a branch for approval
[14:29] <CardinalFang> Rgr.
[14:30]  * thisfred reviews as well
[14:43] <CardinalFang> aquarius, "oauth_token_secretsx" ?
[14:44] <aquarius> pants
[14:45] <thisfred> aquarius: your oldest branch, I'd like to review it, or is it obsolete by now?
[14:45] <aquarius> CardinalFang, fixed
[14:45] <aquarius> thisfred, which one?
[14:45] <thisfred> aquarius: if not, could you fix the conflict?
[14:45] <thisfred> aquarius:  lp:~sil/desktopcouch/create-oauth-tokens-startup
[14:46] <aquarius> kk, willfix the conflict
[14:46] <thisfred> awesome
[14:51] <thisfred> aquarius: also a conflict on your other branch(es) probably the same
[14:51] <aquarius> yeah, same one, I suspect
[14:51] <aquarius> I hate resolving conflicts
[14:52] <thisfred> the quickest way to resolve conflicts is not to generate them
[14:52] <aquarius> well, er, yeah :)
[14:52]  * thisfred runs away before aquarius rips off his arm and beats him over the head with it
[14:52] <aquarius> but that ship has sailed, I fear :)
[14:53]  * CardinalFang high-fives thisfred.
[14:53] <aquarius> aha, you two are in cahoots against me, are you? I see how it is
[14:54] <thisfred> aquarius: you're gonna hate me even more: the changes that are conflicting I have mostly undone on my latest branch...
[14:54] <thisfred> perhaps we should land that first
[14:54] <aquarius> land that first, I suggest
[14:55] <aquarius> since I am now confused by which bits need to happen where
[14:55] <thisfred> the conflicts will still exist but they'll be smaller
[14:56] <thisfred> I did a lot of hoop jumping to make the tests work, and then when the port was readable from the log, I had to unjump some
[14:56] <thisfred> or was able to, I should say
[14:59] <statik> me
[15:00] <CardinalFang> aquarius, outside that type, that branch looks good to me.
[15:02] <CardinalFang> MEETING BEGINS
[15:02] <CardinalFang> If you're here for the stand-up meeting, say "me".  Then "DONE", "TODO", and "BLOCKED".
[15:02] <CardinalFang> me
[15:03] <statik> me
[15:03] <dobey> me
[15:03] <teknico> me
[15:03] <aquarius> me
[15:05] <statik> urbanape, rodrigo_?
[15:05] <statik> DONE: Figured out that erlang packages can't have tests enabled because tests aren't included. Some reviews/merges.
[15:05] <statik> TODO: desktopcouch 0.3 release for feature freeze today. Nag urbanape and rodrigo about compat testing with couchdb-0.10
[15:05] <statik> BLCK: nope
[15:05] <statik> dobey, show us the way!
[15:05] <rodrigo_> me
[15:05] <dobey> ☭ DONE: Fixed overactive Fatal Error, Started prefs dialog
[15:05] <dobey> ☭ TODO: Finish prefs dialog, OAuth
[15:05] <dobey> ☭ BLCK: None.
[15:05] <dobey> teknico: bongiorno!
[15:05] <teknico> DONE: completed and landed a branch that improves the handling of login failures from our Funambol Server API code to the Funambol DS server, reviewed one more markgsaye's branch, fought with rabbitmq
[15:05] <teknico> TODO: working on the contacts CRUD web ui
[15:05] <teknico> BLOCKED: rabbitmq-server not starting anymore, but being solved
[15:05] <teknico> next: aquarius
[15:05] <aquarius> ⚀ DONE: various smallish desktopcouch branches
[15:05] <aquarius> ⚁ TODO: piston oauth in snowy; get DC0.3 done
[15:05] <aquarius> ⚂ BLOCKED:  couchdb patch which lets OAuth read users from the ini file doesn't seem to work
[15:05] <aquarius> In all the world there is only one rodrigo_
[15:05] <rodrigo_> • DONE: Submitted tomboy package with U1 as default sync server. Submitted branch to fix notes UI in production, and kept looking at it, because it's not clear it fixed it
[15:05] <rodrigo_> • TODO: Add more tests in couchdb-glib test suite. More openSUSE packaging. Add social services accounts config to about-me. Talk to Ara about writing mago tests for evo-couchdb. Propose couchdb-glib/evo-couchdb for GNOME 2.29. Store UUIDs for postal addresses. Conflict resolver tool in pair tool. oAuth authentication and signing of all couchdb-glib requests. Finish adding URLs to contact records in evo-couchdb. Add changes notificatio
[15:05] <rodrigo_> • BLOCKED: none
[15:05] <CardinalFang> DONE: Reviews yesterday. (But I'm on-call-reviewer *today*.  Dang.)  Replicator nearly finished.  Needs testing.
[15:05] <CardinalFang> TODO: Finish replicator.  Make pairing-tool exchange OAuth noise.  Also, grudgingly review today's branches and mark them all "Disapprove".
[15:05] <CardinalFang> BLOCKED: None
[15:05] <rodrigo_> nobody next, right?
[15:06] <rodrigo_> ah, missed CardinalFang :)
[15:06] <CardinalFang> teknico, How can we help?
[15:06] <dobey> he missed himself i think
[15:06] <teknico> CardinalFang, statik is valiantly taking care of the problem, thanks :-)
[15:07] <CardinalFang> Good man, statik.
[15:07] <CardinalFang> Okay, MEETING ENDS
[15:07] <teknico> dobey, e bonanotte ai sonatori ;-)
[15:08]  * CardinalFang is glad no one read his TODO.
[15:08] <dobey> bonanotte? little early for that, eh? :P
[15:08] <thisfred> you sleep with the fishes
[15:09] <aquarius> let's take it to the mattresses
[15:14] <urbanape> dangit
[15:14] <urbanape> DONE: Proposed an apparently broken branch for multi-downloads.
[15:14] <urbanape> TODO: Test bindwood against new CouchDB package.
[15:14] <urbanape> BLOCK: None
[15:14] <CardinalFang> urbanape, we sang arias of sadness at your absence from our meeting.
[15:16] <CardinalFang> aquarius, leave the oauth, take the canonical. So, oauth info is client-relative, not server-relative?  I get one set of credentials and use that single group of four values to talk to all paired hosts?
[15:16] <aquarius> no
[15:16] <aquarius> it's server-relative
[15:17] <aquarius> each server has its own set of keys
[15:17] <aquarius> think of the keys as being a multi-item password, basically
[15:18] <aquarius> so when you pair machine A with machine B, machine A needs to get its own keys (by calling the function), and then pass those keys to B (down the connection established by pairing).
[15:18] <aquarius> B then stores those keys in a paired-server document on B, with server: A
[15:19] <CardinalFang> aquarius, Right.  So  get_oauth_tokens()  is server end, for transmission at pair-time?  I store those somewhere and then retrieve them for a particular host at replication time.
[15:20] <aquarius> yes. Machine A calls get_oauth_tokens when another machine wants to pair with it, so it knows its own tokens and can give them to the other server
[15:20] <dobey> crap, i think i may have just lost DNS
[15:20] <dobey> sigh
[15:20] <dobey> my network is being really annoying
[15:20] <statik> CardinalFang, your TODO is why I offered to take reviews for you ;)
[15:20] <aquarius> the other server stores those tokens in a paired serve record, and then when the other server starts up replication, it reads the paired server record for A to know which tokens it needs to pass to A as part of the replication process
[15:21] <CardinalFang> statik, :)
[15:25] <statik> aquarius, thisfred: any news from couch.io on the oauth patch? If I merge lp:~sil/desktopcouch/not-so-random into desktopcouch and include it in a release today, will that break evolution-couchdb, bindwood, and quickly?
[15:26] <thisfred> statik: I see no one online that I know is couch.io to ask. Re: the breaking, I defer to aquarius' wisdom
[15:27] <aquarius> erm, let me check
[15:27] <aquarius> yes. It will break everything.
[15:28] <aquarius> Because it specifies that a valid user must be used for all access, and it is currently not possible to access couch as a valid oauth user if that user is specified in the ini file :(
[15:30] <CardinalFang> I think we need a flag-day when we change both at once.  We may need code that shuts down running couchdb servers in the preinst.
[15:33] <CardinalFang> aquarius, so, just to make sure, do we need python-couch package to take OAuth info as a key for instantiating client.Server objects, or does couchdb daemon read remote oauth stuff on-demand from its INI file?
[15:34] <CardinalFang> ^key^parameter
[15:34] <aquarius> CardinalFang, desktopcouch.records understands how to look up oauth tokens from the keyring to access the local desktopcouch, so you don't need to do anything
[15:34] <aquarius> if you use desktopcouch.records, that is
[15:35] <CardinalFang> Good, good.
[15:35] <aquarius> if you don't use dc.records, then you get to sign your requests yourself
[15:35] <aquarius> the stuff to make dc.records understand oauth and get the keys is lp:~sil/desktopcouch/dc-records-oauth
[15:47] <statik> aquarius, i wonder how much work it will be to make bindwood work with this oauth stuff
[15:55] <thisfred> brb dist-upgrade wants a reboot
[16:00] <aquarius> statik, there are already oauth libraries for JS
[16:00] <aquarius> bindwood will have to get the keys, of course, and do the signing itself (this is what happens when you don't use desktopcouch.records), but that's relatively easy.
[16:01] <aquarius> might need another shell-out-to-python to get the keys, thougth
[16:01] <statik> makes sense
[16:03] <statik> aquarius, should we ship a slightly modified version of your branch that doesn't turn oauth on, but makes it very easy to uncomment a line or something in order to enable oauth for testing? then we could do the changes needed in bindwood, evolution-couchdb, etc. in an orderly way, and finally flip the switch to turn on oauth
[16:03] <statik> i'm kinda worried about breaking the world with the next desktopcouch release, and how to coordinate the introduction of oauth
[16:07] <aquarius> We can do that, and I've been debating it in my head
[16:07] <aquarius> Question: is shipping DC0.3 without auth and then turning auth on (by uncommenting the line) after freeze a break of the freeze?
[16:10] <aquarius> statik, introducing oauth is essentially going to break the world for people who are not using dc.records. I can't think of a way around that.
[16:11] <aquarius> because they'll have to start authenticating when they were not before.
[16:12] <CardinalFang> Should we get 0.3 client out the door with trying auth, and then make 0.4 require auth?
[16:13] <statik> thats what i'm thinking
[16:13] <statik> 0.3 should let people integrate with auth
[16:13] <statik> and 0.4 should require it
[16:13] <CardinalFang> or, break things as soon as possible, since we may not be able to avoid breakage for people subverting us and doing it their onw way.
[16:14] <statik> since we are waiting on the revised COUCHDB-478 patch to even allow desktopcouch to work correctly with the OAuth, I don't see how we can require it just yet
[16:15] <statik> i'm all for getting the oauth code in so we can all be integrating with it
[16:20] <aquarius> the problem is..."integrating with auth" is hard if it's diabled
[16:20] <aquarius> disabled
[16:20] <aquarius> so I think that putting it out without auth being required is the same thing as there not being any auth at all
[16:21] <aquarius> hrm. I don't know what happens if you oauth-sign a request incorrectly when you didn't need to sign it at all
[16:22] <aquarius> and...your couch is visible on the network, and unauthenticated.
[16:22] <aquarius> which is Ungood
[16:22] <statik> aquarius, it's the same as there not being any auth at all for a normal user, but for a developer integrating they could tweak the local.ini to enable auth, right?
[16:23] <aquarius> they could, as long as that developer is prepared to break every app that talks to DC that they're not working on, like, say, bindwood
[16:24] <aquarius> statik, but I am beginning to think that it's a good idea to do what you're suggesting
[16:24] <aquarius> I did not think that having working oauth would take this long :(
[16:25] <thisfred> still none of the usual suspects online on #couchdb. I think jan____ is en route to Dublin
[16:26] <statik> aquarius, cool! i always wonder whether my ideas are crazy. when you start to agree with me, then I *know* they are. so, how should we do this? should I merge all your pending branches into desktopcouch, then you do one more to comment out the auth, then I release 0.3?
[16:27] <statik> CardinalFang, do you have an in-progress branch that needs to go into desktopcouch 0.3?
[16:27] <aquarius> disabling oauth means two things: comment out one line in the ini file, and then tell dc.records to not oauth-sign requests. I'm not even sure if we need to do the second
[16:27] <CardinalFang> statik, Yes!
[16:28] <aquarius> I have to go pick up my daughter and then have dinner with her and so on, so I'll be gone for about four hours, but then I'll be back.
[16:28] <CardinalFang> aquarius, Can we make records try without oauth on failure?
[16:28] <aquarius> CardinalFang, could do, but I'd be inclined to not do that
[16:28] <aquarius> since that's extra code we write now and then remove in 0.4
[16:30] <statik> aquarius, i hope we don't need to do the second
[16:31] <statik> if i send an oauth-signed request to something that doesn't require oauth, i would hope it just ignores the extra header
[16:31] <aquarius> I think that's what happens. I think.
[16:31] <joshuahoover> jblount, urbanape: either of you ever see an error in the web ui that says something along these lines: "this file is already being created by somebody else"
[16:31] <statik> cool, we have a plan. could thisfred do the branch to comment out the ini file so you don't have to work so late tonight aquarius?
[16:33] <thisfred> aquarius: could start on that right now, so I can ask you if I run into unforeseens...
[16:33] <thisfred> when you get back
[16:34] <aquarius> yes
[16:34] <thisfred> ok, starting on that
[16:34] <aquarius> I think that all you should need to do is remove the [couch_httpd_auth] require_valid_user = true part from create_ini_file
[16:34] <aquarius> but I have not tested this.
[16:35] <aquarius> that way there will still be an admin account and so on
[16:35] <aquarius> this will, I should note, not affect people who already *have* an ini file with that in
[16:35] <aquarius> but I think it's reasonable to get those people to delete the ini file
[16:35] <thisfred> excellent, I' try, test and deliver
[16:37] <statik> joshuahoover, you can ask gafton about that, i bet its from a stale upload reservation in the updown server
[16:38] <aquarius> right, off to get Niamh from second day of dance school :)
[16:38] <aquarius> bbl
[16:38] <joshuahoover> statik: thanks...just found a previous bug with the same issue
[16:52]  * statik runs tarmac-lander on desktopcouch
[16:54]  * dobey runs to get lunch
[16:58] <thisfred> aquarius: (running commentary, ignore until you're back) [admins] section *does* need to go in addition to require_valid_user, or we get the 401s. with those two sections commented out, the tests all run. Now merging all open branches into this to see if it doesn't break anything else.
[17:04] <thisfred> done
[17:08] <thisfred> prop0wzed
[18:20] <urbanape> pfibiger, https://code.launchpad.net/~urbanape/ubunet/tooltips-for-long-filenames/+merge/10674
[18:22] <statik> hi thisfred, i've got a conflict when trying to merge lp:~sil/desktopcouch/not-so-random
[18:23] <statik> thisfred, should I just merge your noauth branch instead, and that will pull in the others?
[18:24] <urbanape> statik, I updated my system (including CouchDB) and Bindwood still seems to run okay. I get no errors messages in my JS console (well, not about connecting to Couch, anyway)
[18:25] <statik> urbanape, fantastic! desktopcouch 0.3 will have optional oauth, and then later on we'll make it mandatory. that should give you a window to fix bindwood to support oauth
[18:28] <thisfred> statik: exactly
[18:28] <urbanape> I saw that exchange earlier
[18:29] <thisfred> statik: I merged them all into mine and resolved the conflicts
[18:29] <statik> thisfred, that is the best news i have gotten all day!
[18:29] <thisfred> the conflicts are on all 3 of aquarius' branches
[18:29] <statik> urbanape, thanks for testing bindwood and for the tooltips!
[19:06] <statik> thisfred, i'm pushing a 1-line branch now that fixes a problem with writing the bookmark file
[19:07] <statik> lp:~statik/desktopcouch/fix-bookmark
[19:07] <thisfred> statik: will review and then I have to go pick up my stuffs
[19:07] <statik> thisfred, awesome. hope all your stuff arrived safely!
[19:08] <thisfred> there's nothing fragile or very expensive in there. If the CDs are ok, I'm ok :)
[19:10] <thisfred> statik the tests pass but there's no proposal to +1 or is there?
[19:10] <statik> thisfred, i'm just proposing it now, one sec i'll paste the link
[19:13] <statik> https://code.edge.launchpad.net/~statik/desktopcouch/fix-bookmark/+merge/10677
[19:16] <Mandrew> hello how to ad files to the ubuntuone folder
[19:18] <thisfred> statik: I approved and approved
[19:19] <statik> ta
[19:21] <Mandrew> know one knows how to ad folders to ubuntuone?
[19:21] <dobey> Mandrew: on the desktop?
[19:21] <Mandrew> on the computer
[19:22] <dobey> right, but with the local desktop client, or via the web browser?
[19:22] <Mandrew> i didnt find any awnsers in the faq
[19:22] <Mandrew> on the desktop
[19:22] <dobey> locally you just put new folders in ~/Ubuntu One/My Files (though soon that will just be ~/Ubuntu One)
[19:23] <Mandrew> i tried to drag n drop into the ubuntuone folder it dint like that :)
[19:24] <dobey> you need to put it in "~/Ubuntu One/My Files" currently
[19:24] <thisfred> gotta go, be back in a couple hours
[19:24] <Mandrew> thanks m8 you solved my probz
[19:25] <Mandrew> Dobey yr d man
[19:40] <urbanape> apropos my somewhat stalled multi-download branch: do we preserve permissions on files in U1?
[19:44] <Mandrew> is there anyone that knows if there is possible to get a email adress that look like this mandrew@ubuntu.com or some like it?
[19:44] <statik> urbanape, i don't think we touch permissions
[19:45] <statik> Mandrew, email addresses like that are available for Ubuntu members or developers
[19:46] <Mandrew> can i become a member or how does that work?
[19:48] <statik> Mandrew, absolutely you can. membership is available to anyone who makes a significant and sustained contribution to the ubuntu community. You can contribute in any number of ways. There is a lot more information available here: https://wiki.ubuntu.com/Membership
[19:48] <statik> one good way to become a member is by working with the nearest LOCO team
[19:48] <Mandrew> nice work ill check it out
[19:49] <Mandrew> loco team?
[19:49] <statik> it's the name for local community teams of ubuntu advocates
[19:49] <statik> they do all kinds of different work, from training to marketing to programming to answering questions in the forums
[19:49] <Mandrew> is there one here in sweden?
[19:51] <statik> yes. https://wiki.ubuntu.com/LoCoTeamList
[19:52] <Mandrew> man your the greatest thanks alot m8
[19:52] <statik> happy to help, good luck with ubuntu
[19:53] <urbanape> statik, how do we not handle permissions? What happens on a second machine or on a shared machine? Do we stamp files with some default permission?
[19:53] <Mandrew> im new to ubuntu and linux but i just love it the concept with it
[19:54] <statik> urbanape, maybe i gave a wrong answer...chipaca or verterok or mentalguy would know for sure
[19:55] <verterok> urbanape: we don't handle permissions :)
[19:58] <statik> urbanape, dunno if you saw my comments in the other channel about zipstream - i can help get that set up as a 3rd party sourcedep if you want
[20:01] <urbanape> statik, we're not using the bare ZipStream.
[20:02] <urbanape> I had to munge it a lot
[20:02] <urbanape> there's probably room for a generalized solution that we can contribute back. I'd be happy to work on that.
[20:02] <statik> ah, even more fun. so we still need to maintain it as a separate lib, and send those patches back to spideroak
[20:02] <urbanape> yes
[20:03] <urbanape> okay, that's no problem.
[20:03] <urbanape> What I'll do then is to extract the bits that deal with the file selection (via the checkbox) and propose that separately.
[20:03] <urbanape> I think it'd be nice to get the zipstream stuff generalized and contributed back.
[20:03] <urbanape> and let someone else maintain it.
[20:04] <jblount> urbanape: In case I was clear when I was looking at it, I pretty much want to make babies with that branch. It makes me _very_ happy.
[20:04] <urbanape> yeah, I was silly not to have actually tried to open the resulting files.
[20:04] <urbanape> I just saw that the proper files were in the zip archive and were non-zero length.
[20:04] <jblount> urbanape: :), that's what dumb reviewers (like me) are for!
[20:04] <urbanape> but yeah, gibberish.
[20:07]  * jblount goes back to long meetings with limited breaks
[20:12]  * CardinalFang yells at twisted/dbus and its main-loop madness.
[20:30]  * aquarius returns
[20:32] <aquarius> ...to discover that all his branches have been rejected. Nobody loves me.
[20:32] <aquarius> :)
[20:33] <aquarius> statik, so...what remains to be done for DC0.3 now?
[20:33] <statik> aquarius, rejected and merged via thisfreds branch where he fixed up the conflicts
[20:33] <statik> dvcs ftw
[20:33] <statik> aquarius, i think we need a branch from CardinalFang, then we do the release
[20:33] <aquarius> yep. he's a lovely Dutch hero, yes he is
[20:33] <aquarius> omg it's done?
[20:34]  * aquarius breathes a mighty sigh of relief
[20:34] <statik> aquarius, don't take my word for it
[20:34] <statik> thisfred did the branch we talked about before you left
[20:34]  * aquarius grins
[20:34] <dobey> aquarius: you decided on "Gangsta Rap Made Me Do It"?
[20:34] <statik> and CardinalFang says hes working on something mysterious, it's connecting to my machine
[20:34] <aquarius> CardinalFang, how are you getting on with stuff? Need any help?
[20:34] <aquarius> dobey, Cop Killer. :)
[20:35] <dobey> aquarius: do you have to sing also?
[20:35] <statik> and the syncdaemon team is making AMAZING progress, with bandwidth throttling and resumable uploads and downloads
[20:35] <aquarius> dobey, I do not. I wouldn't want to embarrass all those professional singers at stage school by being way better than them
[20:36] <statik> and dobey is making a ui that everyone will love
[20:36] <aquarius> blimey, we're gonna rock harder than Ayers Rock for karmic. Coolness.
[20:36] <dobey> aquarius: oh. you totally should have picked "Still Alive" then
[20:36] <dobey> aquarius: the credits song for Portal
[20:37] <aquarius> one of the reasons that I'm looking forward to being out of crunch for the freeze is that I might get a chance to play Portal ;)
[20:38] <dobey> heh
[20:38] <aquarius> although I don't thin kthere's a wii port :(
[20:39] <dobey> doesn't look like it
[20:39] <dobey> but you can buy it on steam and play under wine
[20:40] <aquarius> plays under wine? nice.
[20:41] <dobey> i believe so
[20:41] <dobey> i have it on 360, so i can't confirm yet
[20:42] <dobey> however, i have been tempted to buy the awesome deal that valve had for all their games on steam
[20:42] <dobey> which is to say "every valve game, ever made, all for $100"
[20:44] <dobey> i think it was $100
[20:44] <dobey> whatever it was, it was a great deal
[20:44] <aquarius> that's pretty cheap
[20:44] <dobey> yeah
[20:44] <dobey> considering L4D is still like $50 in the box
[20:44] <aquarius> although when I (infrequently) play games it's on the wii; that's why I bought a wii :)
[20:45] <dobey> i bought a wii for the cool toys
[20:45] <dobey> (wii fit)
[20:47] <CardinalFang> aquarius, It's going.  Struggling with DBus weirdness.
[20:48] <aquarius> I'm happy to chip in if you'd like me to, elsewise I shall log off for the night
[20:49] <CardinalFang> aquarius, I think just trying will take less time than synching with you would.  Thanks though.
[20:50] <CardinalFang> aquarius, G'night.
[20:50] <aquarius> no worries :)
[20:50] <aquarius> I cherish my status as an impediment to progress ;)
[20:50] <aquarius> if you don't manage to finish (thisfred, statik, this applies to you too) drop me a mail with anything you'd like me to pick up on in the morning
[20:52] <CardinalFang> Rgr.
[21:05] <dobey> grr, gtk+
[21:07] <dobey> joshuahoover: btw, the applet no longer has the --signup/-s option. passing it is harmless, but it's not necessary :)
[21:08] <joshuahoover> dobey: ah, thanks :)
[21:11] <joshuahoover> dobey: is there an issue with the client crashing on startup?
[21:11] <joshuahoover> dobey: i'm seeing quite a few of those being filed within the past 5 days now
[21:12] <dobey> yes and no
[21:13] <dobey> joshuahoover: some of them are fixed by the branch i landed this morning
[21:13] <joshuahoover> dobey: very good...is there something i should look for in the logs that will tell me/clue me in that it's the same issue you fixed?
[21:13] <dobey> joshuahoover: others have python traces from syncdaemon, which seem to be the cause of failure
[21:14] <dobey> joshuahoover: if it doesn't have the syncdaemon-exceptions.log, it's probably just the fact that syncdaemon is being slow at start-up, and would be "fixed" by my branch from this morning
[21:14] <dobey> but that isn't in the nightlies/beta yet
[21:15] <dobey> and that bug is #414635
[21:15] <joshuahoover> dobey: good, i'll use that as the one to link others to
[21:31] <joshuahoover> dobey: i'm seeing quite a few that have this as the last line in their syncdaemon-exceptions.log: State START_CONNECTING can't handle the SYS_SET_CAPABILITIES_ERROR event ...you think this is unrelated to the bug you submitted a fix for?
[21:32] <dobey> it is a separate issue
[21:32] <dobey> pick one, mark the others a duplicate of it, and assign it to chipaca :)
[21:34]  * Chipaca hugs dobey
[21:34]  * Chipaca embraces dobey, even
[21:34]  * Chipaca extends dobey
[21:34] <Chipaca> et cetera
[21:35] <dobey> heh
[21:36] <joshuahoover> dobey: heh...got ya...thanks!
[21:36] <dobey> https://updown.ubuntuone.com/5d6e8680-5da0-4aff-9330-42caa0399a85
[21:39] <statik> dobey, i LOVE it! ship it
[21:43] <dobey> sigh
[21:43] <dobey> well now i have to hook it up
[21:49] <thisfred> and we're back, with 24 boxes of crap in the otherwise empty living room! :)
[21:54] <verterok> dobey: ping
[21:54] <dobey> verterok: hi
[21:54] <verterok> dobey: hi
[21:55] <verterok> dobey: I'm finishing the dbus api for bandwidth throttling, and re-realized that dbus don't support dict with multiple types :/
[21:56] <verterok> dobey: I was trying to  return a int as the value, to make your life easier
[21:57] <dobey> well, it supports {sv} no?
[21:57] <Chipaca> yeah, a{sv} works
[21:57] <dobey> using a variant for the value?
[21:57] <dobey> (although that is annoying
[21:57] <verterok> dobey: yes, but v don't support NoneType :p
[21:58] <verterok> dobey: so, what do you think of not including the key:value when it's disabled (None)?
[21:58] <dobey> verterok: what about a separate set of methods for enabled/disabled?
[21:59] <dobey> verterok: or returning a negative value for disabled?
[21:59] <verterok> dobey: whatever that makes you and the UX team happy :)
[22:00] <verterok> dobey: using perl isn't an option ;)
[22:01] <dobey> i wouldn't say perl
[22:02] <dobey> and we don't have time to rewrite in C
[22:02] <verterok> dobey: so: {download_limit:<int>, upload_limit=<int>}, with int: -1:off, 0-n: on?
[22:03] <dobey> ok
[22:04] <dobey> verterok: hrmm, though separate enable/disable might be better
[22:04] <verterok> dobey: what are we going to do with 0, that would just stop using the network :/
[22:04] <dobey> verterok: not use the network. it's the correct behavior :)
[22:04] <verterok> dobey: ok, that was the output of get_updown_limit (or something)
[22:05] <dobey> verterok: right, but as preferences, it would be nice if i set it, and those settings were saved, independent of me enable/disable the feature
[22:05] <dobey> verterok: i presume these settings are getting stored in ~/.config/ubuntuone/syncdaemon.conf ?
[22:06] <verterok> dobey: no
[22:06] <verterok> dobey: there is no work on syncdaemon side, I'm just starting
[22:06] <dobey> s/are/will be/ then :)
[22:06] <verterok> dobey: also, syncdaemon don't have persistent mechanism for preferences :O
[22:07] <dobey> verterok: you don't have configglue.write()?
[22:07] <verterok> dobey: we don't have the plumbing to do that
[22:07] <dobey> verterok: so i have to keep track of the settings, and hope syncdaemon doesn't get started without the applet?
[22:09]  * dobey doesn't like where this is going :(
[22:09] <dobey> and it's already 5 pm :-/
[22:10] <verterok> dobey: good point
[22:11] <verterok> dobey: I don't think the applet should track syncdaemon settings, as you pointed out, that will be a mess if SD is restarted
[22:12] <dobey> i wasn't even thinking about it restarting out from under the applet, but yeah, that's even worse :)
[22:12] <dobey> "I set it to use 128K/s, but now it's using 2M/s"
[22:12] <dobey> fun!
[22:13] <verterok> dobey: yes, a *lot* of fun
[22:16] <verterok> dobey: btw, configglue don't have a configglie.write method :(
[22:17] <dobey> configglue doesn't have any way to save settings?
[22:17] <dobey> sounds like it needs more glue
[22:17] <verterok> dobey: no, or at least I can't find it
[22:19] <dobey> :-/
[22:20] <dobey> does it give you a ConfigParser object?
[22:20] <verterok> dobey: no, an OptionParsr one :(
[22:20] <dobey> :/
[22:21] <verterok> dobey: exactly
[22:21] <dobey> can you create a ConfigParser and just cache the throttling settings?
[22:22] <verterok> dobey: also, we shouln't store all the options configglue load at startup, as some are CLI options
[22:22] <dobey> right
[22:22] <verterok> dobey: ok, let's file a bug about this, looks like it wants it's own branch
[22:22] <verterok> dobey: IMO syncdaemon should support this
[22:23] <dobey> it kind of has to
[22:23] <verterok> so, let's keep with what we'r doing now, it's bug not a feature...right ;)
[22:23] <dobey> otherwise the throttling config is entirely useless :)
[22:24] <dobey> "doesn't save my settings" is a pretty big bug, yeah :)
[22:25] <verterok> dobey: :)
[22:26] <verterok> dobey: I'm filling the bug ATM
[22:26] <dobey> great
[22:29] <verterok> dobey: bug #418882
[22:30] <dobey> hooray
[22:30]  * dobey waits for the conspiracy theory stories
[22:31] <verterok> dobey: ?
[22:32] <dobey> verterok: about how we had a bug about settings not being saved, before we had a release with settings :P
[22:35] <verterok> dobey: heh
[22:35] <dobey> statik: https://code.edge.launchpad.net/~dobey/ubuntuone-client/config-preferences/+merge/10699 <- feel free to approve :)
[22:36] <verterok> dobey: we can blame beuno :p
[22:36]  * dobey totally blames the design team
[22:37] <verterok> heh
[22:38]  * dobey wonders how long it will take to redraw 1000 frames in SVG