[00:11] <rtgz_> dobey, ping
[00:11] <rtgz_> who wants to live forever?
[00:14] <rtgz_> okay, since dobey is away I will tell the fairy tale. The emblems are broken but the fix is pretty easy. It looks like the code was refactored for some reason and some pieces went missing
[00:22] <rtgz_> Done, patch sent, battery's dying, wife's asleep :)
[00:23] <rtgz_> And directories are not handled properly but that would be another fix :)
[00:23] <donpdonp> rtgz_: i want to live forever! i assume that was an offer of some sort. :)
[00:24] <rtgz_> donpdonp, don't know, i became a little bit crazy after finding the reason behind the emblems, so that was just an attention-attractor, sorry, no U1 support for eternal life for now.
[00:24] <rtgz_> donpdonp, but you may file a feature request :)
[00:25] <donpdonp> ok. carry on providing freedom in distributed storage.
[00:34] <eric_Idaho> how do you sync all you files w/ this service
[00:35] <eric_Idaho> z/
[00:35] <eric_Idaho> ?
[03:50] <hackel> Anyone know if someone is working on UbuntuOne support for gnote?
[05:34] <chiapagringo> hey, how us U1 working?
[07:32]  * rtgz really needs to learn how to do the bzr things...
[08:01] <rtgz> ubottu, search bug for timestamps not being preserved, launchpad search does not help
[08:01] <rtgz> ubottu, pleeeease
[08:53] <rtgz> Note to self and ubuntulog: Is CouchDB sync happening independently from syncdaemon connection state, i.e. replication is being performed even if we force our "cloud" to be disconnected?
[08:59] <rtgz> lp does not allow to link tickets. Why?
[09:15] <teknico> rtgz, you can use tags to link tickets together
[09:16] <teknico> as in, put the same tag in two or more tickets you want to link
[09:16] <rtgz> teknico, hm... good idea, I will try this next time :). Thanks!
[09:16] <teknico> then you can refer to them with a link like https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bugs?field.tag=apport-bug
[09:17] <teknico> you're welcome :-)
[11:33] <rtg|z> UbuntOne notifies "finished updating 0 files" if no files were added, only removals were made
[11:39]  * rtgz is uploading 2.6 Gb of data, wanna see how this is handled...
[11:40] <aquarius> rtgz, I put 9GB of music into U1 a few days ago :)
[11:41] <rtgz> aquarius, are you a user of free 2Gb account?
[11:42] <aquarius> rtgz, nope, paid account
[11:42] <rtgz> aquarius, eeexactly
[11:42] <aquarius> rtgz, oh, you're testing "what happens if I go over quota"?
[11:42] <rtgz> aquarius, yup
[11:44] <rtgz> aquarius, if I had 50Gb account it would take forever to test it since my ISP caps the upload to 1Gb and I don't have 50Gb of data... Unless i craft it via /dev/random...
[11:44] <aquarius> heh
[11:44] <rtgz> * 1Mbit/s
[11:49] <rtgz> hmmmm
[11:50] <rtgz> guys, if sha1 sum matches something that you already have on the server then it is not uploaded, right?
[11:53] <rtgz> ah, false alarm, it is not hashed so Nautilus shows it as (checked) (see bug 479475, comment 2)
[11:53] <rtgz> misleading, indeed.
[11:54] <rtgz> ok, since this is gonna take some time, will go see the real clouds (since sun is missing for some reason)...
[12:50] <statik`> hello hackers
[13:49] <urbanape> morning, all
[14:01] <dobey> rtgz: hrmm
[14:02] <rtgz> dobey, emblems ?
[14:02] <dobey> yes
[14:04] <dobey> rtgz: and yes, couchdb sync has nothing to do with syncdaemon
[14:04] <dobey> rtgz: couchdb has built-in replication support, which we use
[14:08] <rtgz> dobey, yup, then ubuntuone-client-applet controls file sync only, everything els happens automagically
[14:09] <dobey> yes
[14:10] <rtgz> dobey, sorry about hit-post-run cycle in that ticket, it was too late in the evening, I was on the battery so I wanted the logic of debugging to be available no matter what :)
[14:16] <Chipaca> I want you all to know: UNTESTED CODE IS BROKEN CODE
[14:16] <Chipaca> ok, thanks, you can continue now
[14:17] <Chipaca> dobey: you have a critical bug assigned to you. Please work on that before anything else bar none (well, mostly. I think you can go to the doctor's)
[14:17] <dobey> you're too kind to the code
[14:17] <dobey> ALL CODE IS BROKEN CODE
[14:17] <rtgz> Chipaca, http://www.google.com.ua/search?q=No+marshaller+for+signature+of+signal
[14:18] <rtgz> Chipaca, it looks like ubuntuone-nautilus has some share in the results :(
[14:18] <Chipaca> nessita: is that link from rtgz relevant to your crash from minutes ago?
[14:19] <nessita> Chipaca: let me see, I was running nautilus with gdb to try to gather some helpful info
[14:19] <rtgz> Am i missing some replies ? nessita?
[14:20] <nessita> rtgz: what can I do for you?
[14:20] <rtgz> dobey, but I clearly remember that some time before karmic went into production the emblems were actually changing somehow, at least they were different and then, after karmic release it all turned to checkmarks
[14:21] <rtgz> nessita, are you debugging the Nautilus for UbuntuOne emblems?
[14:21] <nessita> rtgz: not really, I'm trying to reproduce a bug for the syncdaemon and nautilus crashed on me, the bastard
[14:22]  * rtgz had pyinotify crashed on me yesterday after clicking 'connect' button in the Nautilus and syncdaemon stopped seeing the files... But I hope that's only because I was switching libraries too fast...
[14:24] <rtgz> Hmmm... 2009-12-03 13:11:41,386 - pyinotify - ERROR - The path /home/rtg/Ubuntu One/testing/untitled folder of this watch <Watch wd=109 mask=3064 auto_add=False proc_fun=None path=/home/rtg/Ubuntu One/testing/untitled folder dir=True > must not be trusted anymore
[14:25] <dobey> Chipaca: hrmm, that is not critical. i am not sure why it is marked as critical.
[14:25] <rtgz> Erm
[14:26] <Chipaca> dobey: because a lot of people are getting it
[14:26] <rtgz> Launchpad OpenId page: You are signing into: Ubuntu One             Your info will be sent to the blog.
[14:26] <rtgz> the blog o_O ?
[14:26] <Chipaca> heh
[14:26] <urbanape> the borg. Typo
[14:28] <nessita> Chipaca: bug report #491896 I couldn't get any more info using gdb :-/
[14:28] <rtgz> btw, may I start a flame about the default state of the emblems?
[14:28] <nessita> Chipaca: it happens all the time on my installation
[14:28] <Chipaca> rtgz: probably not. You can start a discussion, however. But, mailing list is probably better than here
[14:30] <dobey> sigh
[14:30] <dobey> i think the problem is already fixed
[14:30] <Chipaca> dobey: the critical?
[14:30] <dobey> yes
[14:30] <Chipaca> dobey: how?
[14:31] <Chipaca> dobey: actually I should've said "great! how?" :)
[14:31] <rtgz> btw, my upload rate to U1 is 1Mbit so it hits the ISP shaper, don't know how to reproduce "Slow upload" speed in this case...
[14:31] <Chipaca> rtgz: slow upload seems to be due to lots of small files, not few big files
[14:31] <dobey> facundo's fix to the error handling, where syncdaemon/protocol was thinking some other error was "INTERNAL_ERROR"
[14:32] <Chipaca> dobey: there are two things
[14:32] <Chipaca> dobey: one is that before (and in karmic right now), getting INTERNAL_ERROR on authorization was interpreted as auth failure
[14:32] <Chipaca> dobey: that was fixed by facundo's branch
[14:32] <Chipaca> dobey: another is starting syncdaemon without a token
[14:32] <rtgz> Chipaca, ah, so it is not the single file which goes via snail mail to U1, it is the number of files together taking more than expected, I see
[14:33] <Chipaca> dobey: that is being fixed also (right, __lucio__?) so that syncdaemon goes to auth failure in that case also
[14:33] <dobey> Chipaca: starting syncdaemon without a token is harmless because it doesn't give us AUTH_FAILED
[14:33] <__lucio__> Chipaca, dobey: in the queue, yes.
[14:33] <dobey> so it wouldn't cause a loop of authentication
[14:33] <rtgz> There was an error sharing the folder 'testing/Perl Development Toolkit':
[14:33] <rtgz> callback() takes exactly 2 arguments (1 given)
[14:34] <dobey> but i have a branch in review that avoids starting syncdaemon before we get the token
[14:34] <dobey> in the applet
[14:34] <Chipaca> dobey: sorry, I didn't follow that. How is it harmless? it blows up in the user's face
[14:34] <Chipaca> dobey: the problem is nautilus also
[14:34] <dobey> Chipaca: how does it blow up in the user's face?
[14:34] <rtgz> Nautilus = There was an error sharing the folder 'testing/Perl Development Toolkit':
[14:34] <rtgz> callback() takes exactly 2 arguments (1 given)
[14:34] <Chipaca> dobey: syncdaemon currently raises NoAccessToken when started without a token
[14:34] <rtgz> re: bug nessita has posted
[14:34] <rtgz> the ShareCreateError was not properly handled in the code
[14:34] <dobey> Chipaca: yes, but that isn't shown to the user.
[14:35] <Chipaca> dobey: they get the apport dialog...
[14:35] <rtgz> once it is handled, the error message is shown as I provided
[14:35] <rtgz> dobey, Chipaca, nessita ^
[14:35] <nessita> dobey: that branch needs tests, I had to remove my Approve on it
[14:36] <dobey> Chipaca: only if they're running lucid
[14:36] <dobey> Chipaca: apport doesn't pop up automatically in stable release, as i understand things
[14:36] <dobey> nessita: huh?
[14:36] <rtgz> SYN
[14:37] <nessita> dobey: the branch you're referring to, doesn't provide any tests
[14:37] <nessita> dobey: so "Needs Fixing" as per what Chipaca mentioned a few minutes ago
[14:38] <dobey> -ENOTPOSSIBLE
[14:39] <rtgz> nessita, may I give you the DEB file so that you check whether the crash is actually an unhandled ShareCreateError signal?
[14:39] <nessita> rtgz: sure!
[14:40] <rtgz> nessita, http://buzz.rtg.in.ua/~rtg/ubuntuone-client-gnome_1.1+r283-0ubuntu1~ppa1~karmic_i386.deb
[14:40] <nessita> dobey: what's not possible? :-)
[14:40] <rtgz> nessita, that is just the standard r283 + the patch from bug #479475
[14:41] <dobey> nessita: unit tests for the applet
[14:41] <Chipaca> dobey: why?
[14:41] <dobey> nessita: to do so basically means rewriting the entire applet as a mocked object, which means the applet isn't being tested, the mocked object is.
[14:41] <Chipaca> dobey: 1 sec
[14:42] <Chipaca> dobey: *maybe* you can convince me that adding tests to the applet now, when it is about to die, is silly
[14:42] <Chipaca> dobey: *maybe* :)
[14:42] <dobey> Chipaca: well i don't think python lets you import scripts from bin/ either
[14:42] <rtgz> nessita, afterward, exit nautilus completely, nautilus -q, since it does not want to reload the libs just because there is a new one...
[14:42] <nessita> dobey: I disagree. Test one: if we have no token, syncdaemon is not started. Test two: if we do have a token, syncdaemon is started. I let you discuss the details with your manahger :-)
[14:42] <dobey> Chipaca: and adding tests that are going away in a few weeks seems silly as well
[14:42] <Chipaca> dobey: but, going forwards, if we were doing the applet from scratch, I'd definitely want it done TDD
[14:43] <dobey> also, integration tests are not unit tests
[14:43] <Chipaca> dobey: I didn't say unit tests, necessarily
[14:43] <nessita> Chipaca, dobey: the logic authtoken-syncdaemon should not be in applet code. For instance, you will need that exact same code on the non-applet application
[14:44] <Chipaca> dobey: and for the parts that are not dying (e.g. nautilus), I want us to add tests to that
[14:44] <dobey> nautilus is even more difficult to test
[14:45] <dobey> nessita: the oauthdesktop code is a module and is already tested.
[14:45] <Chipaca> dobey: I know, I'm not saying it's blowing and making glass
[14:45]  * Chipaca wonders if that expression translates well
[14:45] <nessita> Chipaca: I think it would be a good exercise to separate logic from view, so you can be sure to have tests for the business logic
[14:45] <nessita> dobey: yes, and I'm not saying you test oauth. I'm saying I would like to see tests for the oauth<->syncdaemon code
[14:45] <Chipaca> nessita: yes. But again, the applet is dying.
[14:46] <dobey> nessita: it's going away.
[14:46] <nessita> Chipaca: yes. But again, there is code that you will be using in the new app.
[14:46] <dobey> no
[14:46] <Chipaca> dobey: oauth <-> syncdaemon isn't, which is I think nessita's point
[14:46] <dobey> Chipaca: yes it is
[14:46] <Chipaca> dobey: oh? why?
[14:47] <Chipaca> dobey.verbose = 1
[14:47] <dobey> Chipaca: because having a thin wrapper to check that a token exists and start the syncdaemon or request one, is silly. syncdaemon should be doing that check itself for lucid
[14:47] <dobey> syncdaemon should say "oh we don't have a token, make a dbus call to get one"
[14:48] <nessita> dobey: you're coupling interests
[14:49] <dobey> eh? i am trying to decouple them.
[14:49] <nessita> dobey: ok, let me rephrase :-)
[14:50] <nessita> Chipaca: by "design", which layer should be managing authentication, and which layer can assume is already authenticated?
[14:50] <nessita> __lucio__: ^ same question for you
[14:51] <Chipaca> nessita: authentication is one thing, getting the token is another, right?
[14:51] <dobey> no
[14:51] <dobey> auth includes getting a token. if you don't have a token, you're not authenticated.
[14:51] <urbanape> IMO it only needs decoupling if there will be alternate means of getting credentials.
[14:51]  * __lucio__ reads
[14:51] <nessita> Chipaca: hum, I see them both as one thing
[14:51] <urbanape> two separate steps.
[14:52] <dobey> urbanape: auth should have NO relation to the applications requesting auth
[14:52] <urbanape> authentication can happen according to whatever rules we wish. We happen to act on oauth tokens as the credentials.
[14:52] <dobey> urbanape: which is not how it is now. currently auth is very tied to the start-up of syncdaemon/etc... stuff
[14:52] <Chipaca> hold on
[14:52] <dobey> and that's what needs to be decoupled
[14:53]  * nessita holds
[14:53] <Chipaca> when nessita says "authenticating" I hear "connecting to the server, showing our creds, and getting an AUTH_OK message"
[14:53] <urbanape> why does it need to be decoupled if that's the only way we will authenticate people? If there are no affordances for alternate means of authenticating, I don't see a need for decoupling.
[14:54] <Chipaca> urbanape: I think when you say authenticating, you're saying something else
[14:54] <urbanape> authentication is the process of establishing the identity of the requestor
[14:54] <Chipaca> ok, so we agree :)
[14:54] <urbanape> I wrote pluggable authentication system for Zope. I get the authn/authz distinction.
[14:55] <Chipaca> urbanape: *you* wrote the pluggable auth system for zope?
[14:55] <dobey> when i say authentication, i am talking about the openid/oauth process, and not the use of those credentials by other applications to validate themselves with another part of our services
[14:55] <Chipaca> urbanape: wow :) i have some friends that hate you, but wow :)
[14:55] <urbanape> Chipaca: for Zope 2. Tres Seaver and I
[14:55] <urbanape> Chipaca: hah!
[14:57] <Chipaca> urbanape: unfortunately, what dobey just said is not what I said I understand nessita means by authentication, but it does match your definition. Is that your intention?
[14:58] <dobey> it's a very important distinction, especially if we're going to switch to having per-app authorization tokens
[14:58] <dobey> as opposed to one token per user, per machine
[14:58] <urbanape> I may have missed some context
[14:59] <urbanape> what is the behavior/process that nessita suggests needs decoupling?
[14:59]  * Chipaca gives nessita back her voice
[14:59] <dobey> and it means the piece that gets the token, can't be starting syncdaemon or other apps, when something else requests a new token
[15:00] <nessita> Chipaca: I still don't get the difference of concepts
[15:01] <CardinalFang> MEETING BEGINS.  Say 'me' to claim a slice of the stand-up meeting, then take your turn by saying DONE/TODO/BLOCKED.
[15:01] <Chipaca> nessita: we continue after the standup
[15:01] <teknico> me
[15:01] <urbanape> me
[15:01] <CardinalFang> me
[15:01] <aquarius> me
[15:01] <Chipaca> me
[15:02] <dobey> me
[15:03] <vds1> me
[15:04] <jblount> me
[15:04] <CardinalFang> teknico, go!
[15:04] <teknico> DONE: done more reviews, triaged my 20 bugs, finished exposing SMS methods in Funambol Server API (#381398)
[15:04] <teknico> TODO: expose Funambol Server API via REST/HTTP, disable free phone sync after 30 days (#403941)
[15:04] <teknico> BLOCK: none
[15:04] <teknico> next: urbanape
[15:05] <urbanape> DONE: Went through my bug list and marked many "fixed released", updated some to tie to specific branches, commented on some. Basically cleaned my shit up.
[15:05] <urbanape> DONE (cont'd): Chatted with aquarius, CardinalFang, and thisfred about desktopcouch delete propagation techniques. Got some good feedback on Bindwood 0.5 PPA release.
[15:05] <urbanape> TODO: Get some branches landed, work on SRU for Bindwood 0.5 PPA release.
[15:05] <urbanape> CardinalFang: The comfy CHAIR!
[15:05] <urbanape> BLOCK: None
[15:05] <CardinalFang> DONE: some work on attachments.  thinking and talking about record deletion of deletion.
[15:05] <CardinalFang> TODO: finish attachments.
[15:05] <CardinalFang> BLOCKED: My understanding of attachments.  Bah.
[15:05] <CardinalFang> aquarius, sir!
[15:05] <aquarius> ⚀ DONE: music store planning; music store user flows mockup; discussion about delete propagation in DC
[15:05] <aquarius> ⚁ TODO: look at oauth-enabling twisted; make tomboy first-sync experience nicer; continue work on desktopcouch developer docs; write up things learned at UDS/sprint; work with rodrigo on Music Store, much more music store architecture planning; talk to thisfred and vds about sequence numbers etc; list of music store tasks for joshuahoover; feel less rough
[15:05] <aquarius> ⚂ BLOCKED:
[15:05] <aquarius> Chipaca: go
[15:05] <vds1> DONE: proposed branch to close #381398 again mail to funambol support, skype with funambol, support ticketing with funambol support on the same topic, packaging funambol and sort timestamps out
[15:05] <vds1> TODO: looks like the next thing is the 30 days plan but I'm not sure, I'll find out soon
[15:05] <vds1> BLOCKED: nope
[15:06] <vds1> jblount: go go go
[15:06] <jblount> DONE: Touched base with mt. about getting stuff finalized on /files/, got a branch landed
[15:06] <jblount> TODO: Work on the invoices for mattgriffin
[15:06] <dobey> i think vds hit a time dilation bubble
[15:06] <jblount> BLOCKED: Nope
[15:06] <jblount> Next: EOM?
[15:06] <CardinalFang> Thanks, all.
[15:06] <dobey> no no no
[15:06] <urbanape> next is Chipaca
[15:06] <dobey> you sill humans. you have erred. :)
[15:06] <Chipaca> DONE: ran around the city doing paperwork and trying to build my tech base back up to a tolerable level. TODO: get back on top of bugs, plans, planning, etc. BLOCKED: no
[15:07] <Chipaca> NEXT: dobey
[15:07] <dobey> ☺ DONE: Triage, Found/fixed #491573
[15:07] <dobey> ☹ TODO: Fix #437165, Review/Fix #479375, Finish Backporting, Triage, Prepare releases/SRUs
[15:07] <thisfred> aquarius: re sequence numbers and such: I'm about to start on a funambol exchange timestamps branch
[15:07] <dobey> ☹ BLCK: None.
[15:07] <dobey> now you can EOM i guess
[15:07] <vds1> dobey: I wish I have, I could fine more time to fix the new office :)
[15:08] <thisfred> (oops sry for disrupting, thought the meeting was over) aquarius: so any discussion would be good sooner rather than later
[15:08] <dobey> aquarius: "oauth-enabling twisted" <- eh?
[15:08] <urbanape> thisfred, aquarius: Thinking on the funambol thing: I think it would be really helpful for us to come up with a shared understanding of the processes whereby we sync information that is multi-homed (lives on the desktop but gets synced to the cloud for replication, not just resident in the cloud (or Desktop Couch))
[15:09] <aquarius> dobey, the twisted getpage stuff
[15:09] <aquarius> dobey, I have a plan to look at it to see how hard it is to make it do oauth
[15:09] <urbanape> Having the algorithm hashed out for how various apps should approach syncing/merging would mean that all our apps act consistently WRT DesktopCouch.
[15:09] <thisfred> urbanape: +1 on shared understanding
[15:09] <urbanape> I'm sure I've been going over the same space with bindwood
[15:09] <aquarius> thisfred, yep, it would be good to chat about it
[15:10] <dobey> aquarius: but... why would we do that anyway?
[15:10] <thisfred> urbanape: although funambol and bindwood are different in that all communication to and from funambol goes through a single point
[15:10] <aquarius> dobey, hrm, I am now trying to remember what put it on my list :)
[15:10] <urbanape> all communication to and from Firefox goes through a single point, too.
[15:10] <thisfred> our server, and hence we can do all the funambol timestamps there
[15:10] <urbanape> ah
[15:10] <urbanape> funambol isn't dc?
[15:11] <urbanape> doesn't use, rather
[15:11] <thisfred> urbanape: correct
[15:11] <urbanape> ah
[15:11] <urbanape> why not?
[15:11] <thisfred> urbanape: it's a server application
[15:11] <urbanape> doesn't use Couch at all?
[15:11] <dobey> "Why in Golgafrinchum would we do that?"
[15:12] <urbanape> to whom was that addressed, your bathiness?
[15:12] <dobey> nessita: where are you confused about the authn/authz separation?
[15:12] <thisfred> urbanape: the data (contacts) is in couchdb, and ultimately ends up on the desktop
[15:12] <thisfred> but funambol only talks to the cloud server directly
[15:12] <dobey> urbanape: generally about twisted+oauth
[15:12] <urbanape> ah
[15:12] <nessita> dobey: I don't know what those two are :-)
[15:13] <dobey> nessita: authentication vs. authorization
[15:13] <nessita> dobey: well, I see those two as a single layer
[15:13] <dobey> nessita: ie "i am me" vs. "i allow this other thing to access my information"
[15:13] <urbanape> authentication is the means of establishing identity. Authorization is the means of determining whether an identity is allowed to do something.
[15:13] <urbanape> they're very much not a single layer
[15:14] <nessita> urbanape: from my point of view (syncdaemon) yes they are
[15:15] <dobey> nessita: you're confused about what "authentication" in syncdaemon actually means then i guess?
[15:15] <dobey> nessita: what syncdaemon does isn't exactly authentication of the user. it validates that it was authorized by the user to access user's data.
[15:17] <nessita> dobey: are you referring to the  AUTHENTICATING state on the state machine?
[15:17] <urbanape> What are the processes at work? Something gets the credentials, something verifies the credentials, something authorizes verified credentials.
[15:17] <dobey> nessita: yes.
[15:18] <nessita> dobey: so it's correct to expect to have the access token when the syncdaemon is running :-)
[15:19] <dobey> no
[15:19] <dobey> that would be equivalent to expecting that the user already typed in their password when they go to a newly visited web page
[15:20] <nessita> dobey: but the user goes to a newly visited page because he want to. The syncdaemon is not started by the user
[15:21] <Chipaca> dobey: re #437165, please also check all the ones with tag no-access-token
[15:21] <hackel> I never would have thought a program like Ubuntu One would need to be so complicated (obviously it is), I've never had more problems with something like this in my life!
[15:21] <nessita> the user triggers some user-application, like the applet, nautilus, or similar. So those apps should be ensuring the token is present
[15:21] <Chipaca> ok, bbiab
[15:22] <hackel> Last night I added about 48M of files and it's been trying to sync them for the last 10 hours...it seems to take about 5 seconds for each file (which are only 10-20k each), and use up 100% cpu in the process. :(
[15:22] <dobey> nessita: no, applications needing a token should request one if they don't have one
[15:22] <hackel> It's also timestamping the syncdaemon log files in 2030....
[15:23] <nessita> dobey: IMHO syncdaemon is not an "application", but a core to other applications
[15:23] <dobey> nessita: it's not a gui application, no
[15:24] <dobey> nessita: it is a consumer of ubuntu one services. some applications might be GUI things, some might be services like syncdaemon.
[15:24] <dobey> nessita: but consumers that need credentials should request them if they don't have them.
[15:24] <dobey> nessita: not blindly expect they are always available
[15:24] <urbanape> dobey: +1
[15:25] <nessita> dobey: but if you don't design some dedicated layers to do dedicated job, you'll end up with a lot of duplicated code
[15:25] <nessita> so, I agree syncdaemon shouldn't die like a rat in that case
[15:25] <dobey> nessita: "request" here is "call a dbus method"
[15:25] <nessita> we have a ticket for it, let me grab the number
[15:25] <dobey> it's not a code duplication issue
[15:27] <nessita> it is, you'll end up with N applications all implementing the same "if token doesn't exist -> get token, If that fails, do that, etc etc"
[15:28] <dobey> it's like all those applications implementing try: import ssl; except ImportError: do_something_else
[15:28] <dobey> or all of them implementing main()
[15:29] <nessita> I'm that sure is an accurate comparison
[15:29] <nessita> :-)
[15:29] <urbanape> then it's not problematically duplicated code.
[15:30] <dobey> try: authenticate(); except INVALID_TOKEN: get_a_token()
[15:30] <dobey> there is only so much you can do with that to avoid duplicating it
[15:30] <dobey> not all applications use the same protocols
[15:30] <nessita> heh I meant I'm *not* that sure
[15:30] <urbanape> not all applications use the same language/libraries
[15:31] <dobey> and as i said, if we're going to do per-application tokens, then each app is going to have to request separately anyway
[15:31] <dobey> urbanape: and that too, but that's actually easier to solve for us, than solving the protocol problem
[15:31] <dobey> urbanape: we can presume that anyone integrating with u1, will probably want to use our client libraries.
[15:33] <dobey> urbanape: however, we can't presume they are all the same application.
[15:35] <nessita> dobey, urbanape: this is the issue we're gonna fix on syncdaemon for the noaccesstoken problem #488414
[15:35] <urbanape> dobey: well, the applications should be working at the authorization level. I think it's conceivable to change that try: except: to:
[15:35] <dobey> the noaccesstoken thing isn't actually a problem right now.
[15:35] <urbanape> hrm
[15:36] <nessita> dobey: it is, there are tons of bug reports
[15:36] <dobey> urbanape: yes, the application says "i am not authorized, allow me to get some authorization plz"
[15:36] <urbanape> and so the authentication step could be decoupled.
[15:36] <dobey> nessita: the NoAccessToken thing is a symptom though, not the problem.
[15:37] <dobey> urbanape: well authentication and authorizing an app will be coupled in the new log-in ui stuff. but it will be separate from the applications themselves
[15:37] <nessita> dobey: I agree, but we need to do something about it, people can't connect to the cloud and are hating us because of that ;-)
[15:39] <dobey> nessita: one valuable metric for that i think, is how many of those bugs are filed from a 1.0.2 versioned package vs. from a 1.1 versioned package
[15:39] <verterok> nessita, dobey: in the current state, Syncdaemon can't call oauthdesktop to get a token...because that implies starting the applet
[15:40] <dobey> verterok: well the dbus call will start the applet. but for lucid that won't be the case.
[15:41] <dobey> verterok: for karmic we have to live with what we have :)
[15:41] <nessita> dobey: so, we have 2 scenarios. The one I care about now (because of the amount of bug reports) is karmic
[15:41] <nessita> dobey: I know that everything will be better on Lucid :-)
[15:43] <dobey> nessita: yes, but we need to determine the problem first. i am pretty certain that the presence of NoAccessToken in the exceptions log isn't the problem.
[15:43] <dobey> it is merely a symptom
[15:44] <nessita> dobey: I agree, but I think we first need to provide a fix, and the look for the root of the problem
[15:45] <dobey> nessita: but provide a fix for what? hiding the symptom and just throwing hands up and exiting instead isn't going to show us the problem :)
[15:45] <rtgz> dobey, yep, NoAccsesToken is preceeded by something failed earlier, but I can't reproduce it locally at the moment.
[15:46] <dobey> rtgz: reproducing NoAccessToken is pretty easy
[15:46] <rtgz> dobey, yep, if I don't put the token there, right :)
[15:47] <rtgz> dobey, but it is hard to make it work first, then suddenly make it stop working as it happens, according to some bug reports
[15:48] <rtgz> dobey, and I definitely cannot tie up the issue with CouchDB empty management database which got populated after user restarted couchdb and restarted applet...
[15:48] <dobey> it's nothing to do with couchdb
[15:48] <CardinalFang> Breakfast!  Back in a bit.
[15:48] <dobey> breakfast?
[15:48] <dobey> brunch more like it
[15:48] <dobey> we stop serving breakfast at 10:30
[15:49] <nessita> dobey: ok, so. Let's round up a bit: right now, the syncdaemon has no ways of getting a token if it doesn't have one, so it's needs to be started only when there is a token in place. Ergo, for now we need the applet to start syncdaemon only when the token was gathered.
[15:49] <rtgz> dobey, yes, it is not, however ubuntuone-client-applet somehow interracts with desktopcouch.records, which read some pairing info from management db, i guess
[15:49] <dobey> nessita: and that's what we do
[15:49] <nessita> dobey: the branch you proposed does that, as per you commit messages
[15:50] <dobey> well unless you somehow try to avoid using the applet. but that's not realy supported
[15:50] <nessita> dobey: the branch you proposed doesn't have any test that backups that commit message, so until Lucio and Chipaca say otheriwse, I can not approve
[15:50] <dobey> rtgz: yes, it puts the token in desktopcouch AFTER it gets a token
[15:53] <dobey> i need to get one of those cupcake 3d printers
[15:53] <dobey> i could make a fortune selling replacement door handles for nissan sentras
[16:24]  * rtgz 2.0 GB Used (98.8%)
[16:24] <rtgz> added one more file of 70 Mb and...
[16:24] <rtgz> nothing
[16:25] <rtgz> so if user puts more than 2Gb he might never know that the files are not being synced anymore until he visits the Web UI that says 'Upgrade to 50Gb'...
[16:25] <rtgz> is this bug filed?
[16:26] <rtgz> and checkmarks... grrr. I hate checkmarks-by-default, sent a message to ubunutone-users mailing list...
[16:27] <rtgz> where's the "Community iFace" message?
[16:28] <dobey> what message?
[16:30] <rtgz> dobey, the one that used to be in the room subject line... at least it was so some weeks ago
[16:30] <dobey> rtgz: i guess whoever was setting the topic for that hasn't been doing so
[16:30] <dobey> joshuahoover: was that you doing that?
[16:35] <rtgz> ok, nobody knows about ignoring the files that exceed the quota?
[16:36] <rtgz> Bug #404098
[16:40] <joshuahoover> dobey: i was when i was on face duty
[16:40] <joshuahoover> webm0nk3y is on face today
[16:41]  * webm0nk3y blushes 
[16:58] <dobey> must eat... bbiab :)
[17:16] <rtgz> Here's what came to my mind the other day
[17:17] <rtgz> it is possible to get more than 2Gb in free accounts IF:
[17:17] <rtgz> 1. the user is determined enough
[17:17] <rtgz> 2. GOTO 1
[17:17] <rtgz> Hm..., should I file that as a private bug instead
[17:18] <rtgz> but that is not a bug in the real sense, it is just a workaround, I guess...
[17:19] <joshuahoover> rtgz: yeah, it's possible...but (imo) if a user wants free storage that bad, then he/she is paying a price, just not to us :) their time (setting up multiple accounts, managing files across multiple accounts, etc.) must not be worth too much
[17:19] <rtgz> joshuahoover, ah, i guess you know how this is possible :)
[17:22] <rtgz> And... additionally, we might need to check that "Shared with Me/someshare from someone" folder is also protected by 'The other user has used all his quota, so stop adding more files'
[17:23] <verterok> rtgz: getting syncdaemon working for multiple accounts isn't a simple task
[17:30] <rtgz> okay. next: Is there a bug report regarding the 'Share' dialog on the Web UI
[17:32] <rtgz> It is good to know that i have shared my folder with openiduser19154... but I'd rather have it as an email
[17:33] <joshuahoover> rtgz: i don't think there is a bug for that
[17:36] <rtgz> joshuahoover, I searched for e-mail, email, share, openid - no results, going to create one
[17:36] <joshuahoover> rtgz: great, thanks!
[17:49] <rtg|bugReportGen> joshuahoover, https://bugs.launchpad.net/ubuntuone-servers/+bug/402775/comments/1
[17:50] <rtg|bugReportGen> ah, there are several Joshuas here
[17:52] <joshuahoover> rtgz: hmmm...well, apparently that's not quite true based on what you're seeing
[17:53] <rtgz> joshuahoover, and dialog contains <h7> with "view and copy" in it that got display: none... strange, ok will comment and file new bug for other stuff
[18:03] <rtgz> Has web ui got some nice common name, like... oneweb, frontier or something like this :) ?
[18:05] <webm0nk3y> I wish we did have a cool name :)
[18:05] <dobey> it's not a separate project (yet) no
[18:05] <webm0nk3y> hehe
[18:05] <dobey> farfignugen
[18:05] <webm0nk3y> dobey, what does the exception: NoAccessToken: No access token found generally mean for users?
[18:06] <webm0nk3y> dobey, do they need to reauthenticate the client?
[18:06] <rtgz> dobey, okay, farfignugen-share-dialog - new tag for bug reports
[18:07] <rtgz> dobey, driving pleasure?
[18:09] <dobey> webm0nk3y: yes. it means there's no token in the keyring
[18:09] <dobey> webm0nk3y: it's generally a symptom of some other problem though, as most of the reports with that are of the form "ubuntuone won't connect"
[18:10] <dobey> which means it's not trying to do the auth process for some confounded reason
[18:10] <dobey> rtgz: i like driving, usually, yes
[18:10] <dobey> i don't tend to like other people driving though. they tend to make a mess of the roads
[18:16] <rtgz> "$email has not accepted the share you sent just now", huh? o_O
[18:17] <rtgz> ah, then it goes to "has not accepted the share you sent 5 minutes ago"
[18:18] <webm0nk3y> rtgz, nice bug tag!
[18:18] <webm0nk3y> hehe
[18:21] <rtgz> webm0nk3y, yup, like dobey said. Now I will try to memorize that... Can I tag the tag with the URL of the conversation...
[18:32] <dobey> __lucio__: why is bug #472287 critical?
[18:36] <rtgz> good
[18:37] <rtgz> no more bug reports planned today
[18:46] <webm0nk3y> dobey, is there still a dependency on Network Manager?
[18:47] <dobey> elaborate please
[18:47] <webm0nk3y> "Unable to contact NetworkManager".
[18:47] <dobey> the fix is not released as an update to karmic yet
[19:00] <hackel> Why is Ubuntu One sooooo slow?  It's taking like 12 hours to upload 50M (8000 files, 5 seconds each!)
[19:07]  * rtgz is uploading madwifi, will see how fast it goes
[19:08] <__lucio__> dobey, i dont know.
[19:12] <rtgz> hackel, there appears to be a pretty noticeable overhead for a single file to be processed locally. This is a known issue and the team is working on that, you may subscribe to the bug #485004 and mark that it is affecting you as well
[19:13] <hackel> rtgz:  Ahh, thanks.
[19:34] <rtgz> nautilus does not have 'refresh' method for files... utime() seems to be the only way... but that's bad...
[19:36] <dobey> why is that bad?
[19:36] <rtgz> dobey, http://www.youtube.com/watch?v=ydb6KvfCKbM
[19:37] <dobey> oh youtube, thou hath failued me
[19:37] <rmcbride> statik: bip appears to be down?
[19:38] <rtgz> dobey, i can give the url of the theora/vorbis file if youtube is not acceptable
[19:39]  * rtgz wants to have html5 youtube w/ gstreamer playing the video...
[19:39] <dobey> rtgz: the video doesn't play/queue properlly
[19:39] <dobey> rtgz: you can do that already
[19:39] <dobey> although i don't think it uses gstreamer
[19:40] <rtgz> dobey, gstreamer on linux, quicktime on mac, something else on windows...
[19:40] <dobey> but would be better to embed totem playing the mp4
[19:40] <dobey> rtgz: i think on linux firefox just uses libogg
[19:41] <dobey> or rather, it looks like it probably uses a statically linked internal copy of libogg/libvorbis
[19:42] <rtgz> dobey, oops, outdated knowledge, I remember the talk somewhere on mozilla that were searching for applicable implementation
[19:42] <dobey> but anyway
[19:43] <rtgz> dobey,  http://buzz.rtg.in.ua/~rtg/Bug%20%23491777.ogv
[19:46] <dobey> rtgz: so thumbnails get regenerated?
[19:46] <dobey> rtgz: that is a bug in nautilus probably then
[19:46] <rtgz> dobey, yes
[19:46] <dobey> it shouldn't be doing that for mtime changes
[19:46] <rtgz> since utime() sets the file modification time to now, nautilus drops the thumbnail (since it might be a brand-new file) and calls the thumbnailer again
[19:47] <rtgz> mtime?
[19:47] <dobey> atime, mtime, ctime (access, modification, creation)
[19:48] <rtgz> dobey, yes, I just thought  that there are more xtimes, yup, mtime is sufficient to make it regenerate the thumbnails
[19:49]  * dobey thinks that is a nautilus bug
[19:50] <dobey> i wonder if just changing atime would work instead
[19:51] <rtgz> dobey, nautilus could provide something like update_file_emblems, update_file_thumbnail calls so that it would not need to guess the action
[19:51] <dobey> it doesn't need to guess
[19:52] <dobey> thumbnails should only get regenerated if the contents changed (if the md5sum is different)
[19:54] <rtgz> dobey, it does not store the checksum, it is the job of the external indexer to perform that
[19:55] <dobey> what external indexer?
[19:55] <urbanape> well, crap. I don't know what's happened now, but this branch seems to have withered on the vine. Time to recreate it.
[19:55]  * rtgz recalls that MacOS X has something built in for metadata... But I have never used an OS X
[19:55] <dobey> the checksum is stored
[19:55] <dobey> the filename of the thumbnail is the md5sum of the file's path
[19:55] <rtgz> dobey, yep, the file path, but not contents
[19:56] <dobey> yeah i forgot the thumbnail spec was dumb and didn't specify contents
[19:56] <urbanape> rtgz: xattrs?
[19:57] <dobey> it uses extended attributes, yes
[19:58] <rtgz_> Sorry, router crashed
[20:02]  * rtgz_ gets new openwrt firmware...
[20:07] <dobey> Chipaca: https://bugs.edge.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/437165/comments/15 <- comments?
[20:11] <Chipaca> dobey: reading...
[20:16] <Chipaca> dobey: is there a bug for the handling of 50x?
[20:19] <dobey> i don't know
[20:25] <Chipaca> dobey: we never picked up the discussion re NoAccessToken and nautilus and such
[20:25] <Chipaca> dobey: we are getting a lot of users clicking 'connect' in nautilus for the first time, and having nothing happen
[20:25] <jblount> BBIAB need to go pick up new glasses.
[20:27] <dobey> Chipaca: ok. that's easy to fix. we need to make syncdaemon call the dbus method to get the token, instead of raising an error and doing nothing
[20:27] <Chipaca> dobey: what is the dbus method to get the token?
[20:29] <dobey> login(realm, consumer) on com.ubuntuone.Authentication
[20:30] <Chipaca> dobey: and what does that answer with?
[20:30] <Chipaca> dobey: if that answers with the token, we just got rid of gnomekeyring dep in syncdaemon :)
[20:30] <dobey> it returns immediately
[20:31]  * Chipaca bashes his head against a rock
[20:31] <dobey> but it does the browser open/etc.../etc... in the background
[20:31] <Chipaca> dobey: and how do we know when it's done?
[20:31] <dobey> it has to
[20:31] <dobey> otherwise it would just timeout
[20:31] <dobey> Chipaca: listen for the NewCredentials signal on that interface
[20:31] <Chipaca> dobey: yes, but usually you pass in a callback or something
[20:32] <dobey> well on dbus you listen to signals :)
[20:32] <Chipaca> dobey: and if we already have creds?
[20:32] <nessita> Chipaca, dobey: are you taking into account this bug #485824?
[20:32] <Chipaca> dobey: does it do the browser dance, or does it just signal somehting?
[20:32] <dobey> if the token is already in the keyring, then you don't get the NoAccessToken
[20:32] <dobey> nessita: that isn't changing for karmic, no
[20:32] <Chipaca> dobey: right, but I was wondering if we had something where we could get rid of the keyring dep
[20:33] <dobey> Chipaca: not for karmic. once we fix up the new log-in ui stuff, sure
[20:33] <Chipaca> dobey: ok, good
[20:33] <Chipaca> __lucio__: I have good news, and bad news for you
[20:34] <Chipaca> __lucio__: the good news is that I'm passing all the no-access-token bugs back to you
[20:34] <__lucio__> Chipaca, whats the source of the issue?
[20:35] <Chipaca> __lucio__: nautilus does not check with the keyring, it just starts syncdaemon
[20:35] <Chipaca> __lucio__: and, that is correct behavior
[20:36] <Chipaca> __lucio__: syncdaemon should handle not having a access token, by calling the appropriate service that gets one, and listening for the event
[20:36] <Chipaca> __lucio__: read up to what dobey explained so lucidly
[20:36] <__lucio__> Chipaca, ok. right now the applet provides that service. what should we do about that?
[20:36] <Chipaca> __lucio__: dbus handles that
[20:37] <Chipaca> __lucio__: and there is a bug for lucid timeframe to make that be provided by oauthdesktop, which will be in its own package
[20:37] <Chipaca> __lucio__: that's the bug above nessita mentioned
[20:38] <__lucio__> Chipaca, ok, so right now we call dbus, the applet should answer. later on, oauthdesktop will take care. ok?
[20:38] <Chipaca> __lucio__: correct
[20:38] <dobey> __lucio__: yes, for lucid, there won't be an applet. the dbus service will be more robust, etc... :)
[20:39] <__lucio__> verterok, nessita: everything ok with that?
[20:39] <dobey> Chipaca: and i've assigned that oauthdesktop bug to me
[20:40]  * Chipaca hugs dobey
[20:40]  * verterok reads the backlog
[20:40] <nessita> __lucio__: I have no idea what "right now we call dbus" means. Are we doing that already? do we have to make that happen?
[20:40] <Chipaca> dobey: while you're at it, I assigned the one of splitting oauthdesktop out to tim, but maybe you would be a better assignee?
[20:40]  * Chipaca is being devoured by mosquitoes
[20:41] <dobey> Chipaca: yes, that should be me too. i don't know the bug # though
[20:41] <Chipaca> dobey: #440351
[20:41] <__lucio__> nessita, means we have to make syncdaemon get the token using dbus
[20:41] <Chipaca> dobey: bug 440351
[20:42] <dobey> oh
[20:42]  * Chipaca smiles evily
[20:42] <nessita> __lucio__: sounds reasonable. Is it complicated?
[20:42] <Chipaca> dobey: maybe you want it assigned to tim for a while :)
[20:42] <dobey> i think that's a different problem
[20:42] <__lucio__> nessita, really easy
[20:42] <verterok> __lucio__: I'm ok with it, I need to check if oauthdesktop properly implements the async api
[20:43] <Chipaca> bug 440351
[20:44]  * Chipaca notes the mosquitoes in question are aedes aegypti
[20:44] <dobey> that's the same bug, but you just changed the summary
[20:44] <dobey> i call shenanigans!
[20:44] <nessita> Chipaca: dengue?
[20:44] <Chipaca> dobey: yes, I changed the summary to make it more findable. Any shenanigans were completely unintentional. We are working for your safety.
[20:45] <dobey> Chipaca: headless support is a very different problem from splitting oauthdesktop into a separate package/project
[20:46] <Chipaca> dobey: apparently all we need is to depend on oauthdesktop and only recommend the keyring
[20:46] <dobey> Chipaca: which won't work
[20:46] <Chipaca> dobey: why?
[20:46] <dobey> :)
[20:47] <dobey> because keyring is a requirement
[20:47] <Chipaca> dobey: you pass in oauth from the commandline, and it should work. At least, it worked when I tried it on ec2 a while ago
[20:47] <Chipaca> (from source, I mean)
[20:47] <dobey> Chipaca: you mean, for u1sync
[20:47] <Chipaca> dobey: yes
[20:48] <dobey> Chipaca: oauthdesktop doesn't handle gnome-keyring not being there
[20:49] <Chipaca> heh, ok, it was the other way round then
[20:49] <Chipaca> right, oauthdesktop isn't needed for u1sync, and it is the bit that depends on keyring? was that it?
[20:49] <dobey> sort of
[20:49] <Chipaca> I know I looked at it before opening my mouth the first time
[20:50] <dobey> if oauthdesktop isn't there, u1sync will just ImportError
[20:50] <dobey> and if gnomekeyring isn't there, oauthdesktop will ImportError
[20:50] <dobey> so while it isn't necessary for it to be running, it is necessary to be installed
[20:54] <rtgz> dobey, found a bug regarding create share from nautilus... http://paste.ubuntu.com/334105/ . This error is not delivered currently in PPA and elsewhere since there is no signal handler for ShareCreateError. In fact, share is created...
[20:57] <Chipaca> dobey: can you please correct me on the bug, and change its title to something still yet more descriptive?
[20:58] <dobey> Chipaca: i already did that, yes :)
[20:58] <Chipaca> dobey: yay
[21:05] <rtgz> dobey, the patch for emblems is incomplete - share emblems do not show up, probably because they are returned w/o the leading basedir
[21:09] <rtgz> ok, this will be the last bug report for today, House M.D. is about to start...
[21:10] <dobey> i know it's incomplete. but i haven't had time to scrutinize it fully yet :)
[21:11] <dobey> Chipaca: what about the rest of bug #437165 then? :)
[21:14] <rtgz> dobey, If i ever go to sleep today, then I might fix that path tomorrow, this is pretty trivial and I haven't written in C for ssoooo long...
[21:27] <rtgz> Okay, definitely no more bug reports, time to sleep. Have a great $timeofday!
[22:01] <dobey> later!
[23:36] <wesley_> Can someone help me troubleshoot this?  http://paste.ubuntu.com/334187/
[23:37] <verterok> wesley_: hi
[23:37] <wesley_> hi verterok.
[23:37] <verterok> wesley_: could you pastebin the contents of: ~/.config/ubuntuone/syncdaemon.conf ?
[23:38] <wesley_> Thanks mate: http://paste.ubuntu.com/334189/
[23:39] <verterok> wesley_: looks like you'r hittinh Bug #455544
[23:39] <wesley_> Ok cool - any way to turn off bandwidth throttling?  I think I turned it on and then off.
[23:39] <verterok> wesley_: basically, you need to disable bandwidth throttling :)
[23:39] <verterok> wesley_: the simples way is:
[23:39] <wesley_> Is it the option "Limit Bandwidth usage"?
[23:39] <verterok> 1) quite the client
[23:39] <verterok> *quit
[23:40] <verterok> 2) rm ~/.config/ubuntuone/syncdaemon.conf
[23:40] <verterok> :)
[23:40] <verterok> wesley_: yes
[23:41] <wesley_> My client was showing the "limit bandwidth" as not enabled - but the syncdaemon log was showing it as enabled?
[23:41] <verterok> wesley_: the config says it's enabled
[23:41] <verterok> wesley_: the preferences app show it as disabled?
[23:42] <wesley_> Well the checkbox isn't checked in the preferences.
[23:42] <wesley_> However
[23:42] <wesley_> I did try re-installing the client as a solution.
[23:42] <verterok> wesley_: hmm, I think there is a bug about the preference app not getting the config correctly on startup
[23:42] <verterok> wesley_: no need to reinstall
[23:43] <joshuahoover> verterok: yes, there is a gui bug that's assigned to dobey i believe
[23:43] <verterok> joshuahoover: hi :) and thanks
[23:43] <joshuahoover> verterok: :)
[23:43] <wesley_> Well removing the config file did the trick anyway!  I must say I think this system is a great idea.
[23:43] <verterok> wesley_: cool :)
[23:43] <wesley_> Has anyone got a project for a windows client open?
[23:44] <wesley_> IE 7 doesn't seem to handle the ubuntu one web page too well - and I think the bulk of the market would be people who use linux at home and windows at work.
[23:45] <verterok> wesley_: I don't know of anyone working in a windows port
[23:45] <wesley_> Anyway - I'll leave the decisions to the experts!  Thanks and good night all!
[23:45] <verterok> wesley_: np, g'night!