[00:43] <uinfix> Ubuntu One shows "Disconnected" in Preferences any help ?
[05:08] <zmjb1> How do I find free tunes in Ubuntu One store
[05:08] <zmjb1> I'm new and exploring
[05:08] <zmjb1> whether I want to sign up
[05:09] <zmjb1> if it is worth my while
[05:09] <zmjb1> Anyone?
[09:36] <JamesTait> Happy Monday!
[09:39]  * karni struggles on statistics lecture :<
[09:39] <karni> JamesTait: happy Monday ;)
[09:39] <karni> god my tutor is hopeless
[09:39] <karni> *lecturer
[09:39] <duanedesign> :)
[09:39] <duanedesign> morning all
[09:39] <JamesTait> Hey karni. :) Good weekend? Get any of that sleep thing? ;)
[09:40] <karni> morning duanedesign
[09:40] <karni> JamesTait: did get some sleep, but college stuff took over majority of weekend time - so I'm pretty sad. hope to do some coding today in the afternoon
[09:41] <karni> but it was definitely constructively spent time, thanks :)
[09:41] <JamesTait> karni: That's good to hear. :)
[09:41] <karni> JamesTait: hope you got some rest, too
[09:41] <JamesTait> karni: I have two boys aged 7 and 4, so I never get rest!
[09:42] <karni> JamesTait: ^-^
[09:46] <karni> I had plans for u1files for android for the weekend. I ended up coding one simple networking assignment and reading up on my bechelor of sciense thesis
[09:47] <karni> I'm keeping Chad from making his contributions. I so need to get that code ready.
[09:55] <karni> JamesTait: if I can ask out of curiosity, what are you working on today?
[10:00] <JamesTait> karni: I'm working on the Ubuntu One server side, as usual. My tasks will be many and varied. :)
[10:01] <karni> JamesTait: oh, cool :) many, varied, and secret! ^ ^
[10:02] <JamesTait> karni: Well of course! This is the evil, closed-source Ubuntu One server, after all. :-P
[10:03] <karni> JamesTait: haha. I don't actually think of it that way :)
[10:03] <karni> Canonical has to make money out of services, U1 amongst others
[10:05] <JamesTait> karni: Conspiracy theories abound. "It's a trap!" It's a difficult balancing act.
[10:05] <karni> JamesTait: I was thinking of writing U1 server just for fun as bechelor of science project, but eventually thought it's a terribly bad idea. even if I succeeded, I wouldn't want to release it anyway.
[10:05] <karni> JamesTait: yes, I'm aware of that :<
[10:07] <karni> JamesTait: so until Canonical want's to release U1 server source, I'm still happy with it.
[10:13] <JamesTait> brb, rebooting
[11:08] <dutchie> hi, i have ubuntu one refusing to connect for an auth error or something, and i can't work out how to get the right credentials in
[11:08] <dutchie> http://pastebin.com/RsmxkU8a
[11:10] <karni> dutchie: try u1sdtool --disconnect; sleep 2; u1sdtool --connect; u1sdtool -s
[11:10] <karni> dutchie: paste it to pastebin, and post the link here
[11:10] <dutchie> it's the same as before
[11:11] <karni> alt+f2, type seahorse, <Enter>, find Ubuntu One token, delete it
[11:11] <dutchie> done, what now? the disconnect line again?
[11:11] <karni> dutchie: lucid or maverick?
[11:11] <dutchie> maverick
[11:12] <karni> killall ubuntu-sso-login
[11:12] <karni> u1sdtool -q; u1sdtool -c
[11:12] <karni> dutchie: ↑
[11:12] <karni> dutchie: after those two commands you should see the login screen
[11:12] <dutchie> yes, thanks
[11:12] <karni> dutchie: you're welcome.
[11:20] <dutchie> now it seems to be stuck on http://pastebin.com/Rp7iJSLk and just pops up the signin window every u1sdtool -c
[11:24] <karni> Not User huh..
[11:24] <karni> duanedesign: any hint's on that (dutchie) ↑ ?
[11:24] <karni> dutchie: i'm currently on a lecture, but stick around for more help.
[11:29] <dutchie> ok
[11:41] <duanedesign> dutchie: on maverick?
[11:41] <duanedesign> oop i see it now
[11:41] <duanedesign> :)
[11:43] <duanedesign> dutchie: ok after deletingthe token. sudo killall ubuntu-sso-login; u1sdtool -q; u1sdtool -c
[11:45] <dutchie> login window said success...
[11:45] <dutchie> and u1sdtool -s says "processing queues"
[11:45] <dutchie> thanks
[11:46] <duanedesign> connection: With User With Network ?
[11:47] <dutchie> yup
[11:50] <karni> duanedesign: ah.. I probably forgot about sudo ;) hehe
[11:57] <zyga> is the move operation between two shared folders a no-op?
[11:58] <zyga> I have ~/Ubuntu One/something and ~/Directory (also synced)
[11:58] <zyga> and I moved somethin from ~/Ubuntu One/something to ~/Directory
[11:58] <zyga> according to u1sdtool --waiting-content and --metadata it's being uploaded
[11:59] <zyga> is that really going to upload or will it notice that it already has the same file on the server
[11:59] <karni> zyga: I think it's like "remove the folder from A, upload the folder to B"
[11:59] <karni> zyga: I'm pretty sure it will upload. like 80% sure.
[11:59] <zyga> uh :/
[11:59] <zyga> that's not good
[12:00] <zyga> the same operation within a share is just a rename
[12:00] <karni> duanedesign: U1 will delete and re-upload a moved folder, won't it?
[12:00] <zyga> is this a well known issio?
[12:48] <twig11> I need help troubleshooting Ubuntu One. I'm running Maverick PowerPC on an iBook G4, and I used the Ubuntu One preference app to sign in the first time. It synced all right, but when I logged into my account online, it showed four connections for the same computer. I removed all but one through the web interface, and now whenever I open the Ubuntu One preferences app it just says synchronizing for a few seconds, then disconnects without a
[12:49] <twig11> Oh yeah, honk!
[13:55] <nessita> stand up in 5
[14:00] <nessita> me
[14:01] <thisfred> me
[14:01] <nessita> alecu, mandel, ralsina, dobey?
[14:01] <ralsina> me
[14:01] <mandel> me
[14:01] <alecu> me
[14:02] <nessita> nessita: go!
[14:02] <nessita> DONE: bug #688694
[14:02] <nessita> TODO: bug #674459 and bug #689646
[14:02] <nessita> BLOCKED: nopes
[14:02] <nessita> NEXT: thisfred
[14:02] <ubot4> Launchpad bug 688694 in ubuntuone-client (Ubuntu) (and 1 other project) "Add syncdaemon autoconnect option (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/688694
[14:02] <ubot4> Launchpad bug 674459 in ubuntuone-control-panel (Ubuntu) (and 1 other project) "After machine adding, show folders tab (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/674459
[14:02] <ubot4> Launchpad bug 689646 in ubuntuone-control-panel (Ubuntu) (and 1 other project) "Allow subscribe/unsubscribe from UDF list (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/689646
[14:02] <thisfred> DONE: bindwoodness TODO: more bindwood, hopefully get somewhere with the new functionality BLOCKED: no
[14:03] <thisfred> ralsina!
[14:03] <ralsina> DONE: I kinda understand the code now
[14:03] <ralsina> TODO: woking on getting my devel. environment up
[14:03] <ralsina> BLOCKED: no notebook until tomorrow, working on a sloooow VM :-(
[14:03] <ralsina> NEXT: mandel
[14:03] <mandel> DONE: Paperwork overhead (holidays, perdiem, taxes, etc…). Bug triaging. Still working on IPC by allowing a way to inject the logging to the COM object (we want a unified log).
[14:03] <mandel> TODO: Finish with IPC, add integration tests (python calling .net). Integrates solution in SD (maybe today is to early for that.)
[14:03] <mandel> BLOCKED: no
[14:03]  * mandel looks at alecu
[14:03] <alecu> DONE: pushed final zg for syncdaemon branch (bug #674252).
[14:03] <alecu> TODO: get it reviewed. start with bindwood. Buy tickets to dallas
[14:03] <alecu> BLOCKED: I hate dallas
[14:03] <ubot4> Launchpad bug 674252 in ubuntuone-client (Ubuntu) (and 1 other project) "Syncdaemon needs to store events into zeitgeist (affects: 1) (heat: 111)" [High,In progress] https://launchpad.net/bugs/674252
[14:04] <nessita> alecu: you're going to dallas?
[14:04] <mandel> nessita: now, I'm scared, how needs to go (my mail client is kinda shit this days…)
[14:04] <alecu> nessita, I am.
[14:05] <nessita> dobey: stand up?
[14:05] <mandel> nessita: do we have general mail with that or a wiki, or something (pidgin would be as good)
[14:05] <nessita> mandel: I'm lost, general mail with what? :-)
[14:06] <mandel> nessita: with who goes to dallas, I fear I lost it, or something
[14:06] <mandel> I never heard a word about it and I simply assumes I was not going :)
[14:06] <ralsina> AFAIK, it's like this
[14:06] <nessita> mandel: let's ask Chipaca (as far as I know you're not going)
[14:07] <ralsina> I was supposed to go, but I can't because of passport / visa problems
[14:07] <nessita> any other stand up comment?
[14:08] <ralsina> other than that I don't know who is going, you have to ask chipaca
[14:08] <ralsina> But I don't think there has been an announcement yet :-)
[14:08] <mandel> ralsina: ah, ok, I just want to be sure I did not loose the mail, for the rest, if it is on the air, it is on the air :)
[14:09]  * mandel is happy he did not screw it up
[14:09] <ralsina> or I am losing mail too :-D
[14:10] <mandel> ralsina: cool, that means I can blame the manager hehe
[14:12] <Chipaca> mandel: ralsina *is* the manager
[14:12]  * Chipaca fades into the shadows
[14:12] <ralsina> chipaca: I think he meant blaming me, yes :-)
[14:13] <mandel> Chipaca: I was blaming ralsina
[14:13] <mandel> always blame the new guy
[14:13] <ralsina> madel: we have to maintain a proper chain of blame here
[14:15] <mandel> ralsina: yes, if that does not work, well we will never get anywhere, the blame could me lost, and you never want to loose the blame 'cause if you do, you will not be able to wear white in your wedding
[14:15] <mandel> ok I think I lost it there :P
[14:16] <mandel> too much coffee
[14:16] <alecu> Chipaca, thisfred: I've set up everything so I can go to Dallas. Yahoo! (?)
[14:17] <thisfred> alecu: ok, then we better start getting tickets
[14:18] <dobey> what did i do on thursday exactly
[14:18] <dobey> meh
[14:19] <thisfred> fix things? :)
[14:19] <dobey> of course, but which things exactly :)
[14:23] <dobey> and that is the sound of X crashing
[14:24] <dobey> brought to you by Mozilla Firefox 4.0 Beta 7
[14:28] <nessita> dobey: hey there. A new bug was reported re: nautilus crashes and high cpu usage, and a new comment was added on bug #674876
[14:28] <ubot4> Launchpad bug 674876 in ubuntuone-client (Ubuntu) (and 1 other project) "Nautilus keeps opening when ubuntu one plugin is installed (affects: 5) (dups: 3) (heat: 40)" [High,Triaged] https://launchpad.net/bugs/674876
[14:30] <dobey> ok
[15:40] <mandel> dobey: ping
[15:44] <dobey> mandel: yo
[15:44] <mandel> dobey: hello, can you help me with a little thing?
[15:45] <dobey> what's up?
[15:45] <mandel> dobey: I do not know what is the best way to add some code to ubuntuone-client with the current autotools setup? I do know with a setup.py
[15:45] <dobey> mandel: to add python code?
[15:46] <mandel> dobey: yes, let me elaborate a bit more to try and make sense
[15:46] <dobey> mandel: if it's a new package, you'd need to add the directory to the pypackages variable in Makefile.am (like the others are defined), or if it's just a new .py file in an existing package, just add the .py file
[15:47] <mandel> dobey: we removed the SSO code from desktopouch that added the replication info to desktopcouch (it was not the place for it) we now need to add an extension point so that the scripts gets added to the desktopcouch extension point
[15:48] <mandel> dobey: I'll get you an example of the setup to be done so that it makes more sense, give me a min to find it
[15:48] <dobey> you mean, you want ubuntuone-client to install python code into the desktocouch namespace?
[15:49] <mandel> dobey: kind of, with the example it makes more sense
[15:50] <dobey> ok
[15:53] <mandel> dobey: I do not know if this are the best examples, but they do explain the idea: http://jimmyg.org/blog/2010/python-setuptools-egg-plugins.html
[15:53] <mandel> and http://reinout.vanrees.org/weblog/2010/01/06/zest-releaser-entry-points.html
[15:54] <mandel> dobey: we have defined the entry point in desktopcouch, and we should be adding a new entry in ubuntuone-client, since you are the one that knows the most about the package etc.. I wanted some gidence :)
[15:59] <dobey> maybe i'm confused, but this method of implementing plug-ins/extensions seems horribly inefficient.
[16:01] <mandel> dobey: what did you understand?
[16:02] <dobey> it iterates over every single installed .egg-info directory looking for the entry_points.txt and then has to load all of them, and then import the correct modules/functions for ones that match
[16:03] <mandel> dobey: yes, the loading of them is major crap
[16:04] <mandel> dobey: in our case we just have one, but I'm more than open to find a diff way to do it, do you know any other one? We can make the necesary changes in desktopcouch very fast
[16:05] <dobey> mandel: i have 132 .egg-info files in /usr/share/pyshared. that is a lot of disk access to end up loading nothing in the end
[16:05] <dobey> mandel: and i don't think the "hook up desktopcouch to the u1 syncing" necessarily belongs in ubuntuone-client
[16:05] <dobey> given that desktopcouch syncing should be able to work without file syncing at all
[16:06] <mandel> dobey: I agree is crap but I do not have any other idea. Regarding its inclusion i ubuntuone-client, I mention it because it is needed by the preferences dialog since if the code is not there the account info is not replicated
[16:07] <dobey> well why not similar to how bzr does it?
[16:07] <dobey> just load python code from a known path
[16:08] <mandel> dobey: mmm do they do that, that does not sound very secure...
[16:09] <dobey> mandel: uhm, how is it any less secure than loading arbitrary code from PYTHONPATH?
[16:10] <dobey> mandel: the way bzrlib loads plug-ins is not any less secure than simply using python to write code
[16:11] <mandel> dobey: just asking, not stating :)
[16:12] <mandel> dobey: what about zope interfaces, would you consider that any better?
[16:12] <dobey> i don't know what that entails exactly, but let's avoid zope
[16:13] <ralsina> In general, as long as you load from the system's python folders it's secure as long as the system itself is not compromised. If the system is compromised, nothing is safe.
[16:13] <ralsina> The home folder is something else, but we are not doing that here.
[16:13] <dobey> mandel: the entry_points concept is fine if it can be limited to only loading modules under say desktopcouch.plugins or something
[16:14] <ralsina> So don't worry too much about security
[16:14] <dobey> well we can worry about security, and just rewrite everything in Vala instead ;)
[16:14] <mandel> dobey: haha I was expecting that from you ;)
[16:15] <ralsina> Well, you know, all this applies just as well to C ;-)
[16:15] <ralsina> LD_PRELOAD is your friend and all that
[16:16] <dobey> well i don't think users screwing up their environment of their own volition is a "security problem"
[16:16] <dobey> more like a PEBKAC
[16:16] <ralsina> I'm just saying that so this doesn't get sidetracked too far. Security is not too important here, efficiency may be important here, maybe not even that important.
[16:16] <dobey> efficiency is very important
[16:16] <dobey> the blueprint is "make desktopcouch performance not suck"
[16:17] <ralsina> well, startup performance <> performance as a whole
[16:17] <dobey> adding lots of disk i/o to the process doesn't make it faster :)
[16:17] <ralsina> But sure, if there is a way to make this faster and it's not a huge problem, go ahead :-)
[16:18] <dobey> well there is, because it's only one plug-in we care about, and i don't expect lots of people are going to write plug-ins in this respect
[16:18] <ralsina> For example, have you seen yapsy?
[16:19] <ralsina> Very easy plugin mechanism, efficient, too.
[16:19] <dobey> mandel: why is the SSO bit being removed anyway?
[16:19] <mandel> ralsina, dobey: so, just to double check, we are doing the following in desktopcouch: http://paste.ubuntu.com/543111/
[16:19] <dobey> ralsina: well, it's Python. the whole language is a plug-in mechanism :)
[16:20] <ralsina> mandel: let me check the docs on that
[16:20] <dobey> mandel: i'm saying we should not be doing that. cannon vs. mosquito problem
[16:20] <mandel> dobey: because it means that there are Ubuntu One client specific bt sthat use SSO and Desktopcouch maintained in desktopcouch. This has two problems, one it drags Ubuntu SSO as a dependency that we do not need, in adds a extra concern to Desktopcoch that has nothing to do with us :)
[16:20] <dobey> well you only need it when using that bit of code
[16:21] <dobey> and it has everything to do with desktopcouch. it certainly has nothing to do with file sync :)
[16:21] <dobey> we can make it a "plug-in" and keep it in the desktopcouch tree, and just add another binary package in Ubuntu for it, and call it desktopcouch-ubuntuone or something
[16:21] <mandel> dobey: I agree, it is just used for the preferences, which are leaving for the new ones...
[16:22] <dobey> have it installed by default, and depend on the necessary bits, and et voila, happy
[16:22] <mandel> dobey: that sounds like a good idea :)
[16:22] <ralsina> I like it
[16:22] <dobey> the fact that ubuntuone-preferences is what sets up the replication in desktopcouch is a horrible thing, anyway
[16:22] <mandel> dobey: I'll need to talk with thisfred, vds and Cardinalfang about it, but I see no issues with that
[16:23] <dobey> why oh why is it snowing
[16:23] <mandel> dobey: yes… sometimes bad ideas happen, my parents had one around 1983 ;)
[16:23] <thisfred> dobey: I tend to agree. At the very least it should never break because of it
[16:23] <dobey> heh
[16:23] <thisfred> mandel: now you've gone and made me feel old :)
[16:24] <mandel> thisfred: did you follow the conversation :)
[16:24] <thisfred> not at all :)
[16:24] <dobey> syncing files should not depend on desktopcouch and syncing desktopcouch should not depend on files sync
[16:24] <mandel> thisfred: ok, quick summary, remember that SSO code we removed from desktopcouch?
[16:24] <thisfred> vaguely :)
[16:25] <mandel> ralsina: if we do this, that is, move the code to a diff package, there is nothing I know that block a new ubuntuone-client .deb
[16:25] <dobey> in fact, desktopcouch-pair should perhaps play some part
[16:25] <ralsina> mandel: nice
[16:25] <ralsina> How about what blocks a desktopcouch package? ;-)
[16:26] <mandel> ralsina: will lokk at it as soon as I agree with thisfred about destopcouch, he's smart, it should be quick :)
[16:26] <dobey> and if i can get my new spare time project in a workable state this week, it would be nice to start moving some of our projects over to using it
[16:28] <mandel> thisfred: I was saying, the SSO code was added so that the preferences pane knew about the account info, it was removed since it was ugly code and was out of the desktopcouch scope
[16:28] <thisfred> mandel: yep I agree
[16:28] <ralsina> mandel: cool
[16:29] <mandel> thisfred: dobey correctly says that it could be a diff package called desktopcouch-ubuntuone, that could be used to do so (dobey correct me if I\m wrong)
[16:29] <mandel> thisfred: which should b likw 20 lines of code or so, what do you think?
[16:29] <dobey> mandel: package, not necessarily project.
[16:29] <mandel> dobey: sorry I mean package :)
[16:30] <dobey> making a new project for one tiny file seems a bit much
[16:30] <thisfred> dobey: just to be clear, why not u1prefs? This is where the authentication for filesync is also taken care of or not?
[16:30] <dobey> mandel: yeah, i was just trying to make it clear for the general discussion
[16:31] <dobey> thisfred: a) u1prefs is supposed to be going away, b) prefs doing all the auth is dumb, c) filesync depending on desktocouch to do stuff is dumb d) desktopcouch depending on files sync to be able to sync to u1 is dumb
[16:31] <mandel> dobey: thx :)
[16:31] <dobey> thisfred: the currently working solution is working, but it's a horrible design and simply a quick solution based on past mistakes, rather than doing it the best possible way
[16:31] <thisfred> dobey: I didn't know it was going away, and I agree with c and d
[16:31] <dobey> thisfred: well u1-control-panel is supposed to replace it
[16:31] <thisfred> dobey: but the preferences doing the auth doesn't seem that bad to me
[16:32] <thisfred> dobey: and that won't be doing the authentication at all?
[16:32] <dobey> thisfred: it should be possible for me to install desktopcouch and connect it to my ubuntuone account, without having to install or use anything having to do with file sync at all
[16:32] <mandel> thisfred, dobey: It would be nice to talk with nessita, maybe we do not need this any more, it depends on u1-control-panel, but ofcourse we will be braking the current code
[16:33] <mandel> nessita: are you around?
[16:33] <thisfred> dobey: well, does filesync work without the u1 control panel?
[16:33] <dobey> thisfred: u1-control-panel does handle sign-up/login in the broad and vague "everything that falls under ubuntuone" sense, but that doesn't mean it should always be required to work
[16:33] <ralsina> I agree with dobey
[16:33] <dobey> thisfred: it should. whether it does or not though, i am not sure
[16:34] <thisfred> I don't see why it couldn't though, as long as IT does not depend on either, but it probably does
[16:34] <ralsina> Those dependencies seem backwards
[16:34] <thisfred> I'm not sure how they flow, right now
[16:34] <dobey> well syncdaemon *SHOULD* be calling the dbus auth method when you tell it to connect
[16:36] <dobey> u1cp should really just be a place that consolidates information, but not necessarily the place you must go to be able to do anything at all
[16:36] <thisfred> I vote for the clean solution, unless it's going to take a lot of time. I want to believe mandel when he says 20 lines of code...
[16:36] <thisfred> dobey: yeah I agree, it should just be a UI layer over command line API that exists
[16:36] <dobey> well i don't know what was removed exactly, but it should not be a hard problem at all to make it possible for desktopcouch to pair to u1, without requiring all the other u1 client stuff
[16:37] <thisfred> mandel: Do you know what to do, or do we need to think about how to do this?
[16:37] <dobey> but i'm guessing nothing is actually designed to work as i would think it should :)
[16:38] <thisfred> and also, do you have any time to do it?
[16:38] <thisfred> dobey: that's pretty much a given ;)
[16:42] <mandel> thisfred, dobey, give me 5 min, I got to sort something at home
[16:47] <nessita> mandel: I'm about to have lunch
[16:48] <mandel> nessita: ok, no worries
[16:48] <nessita> mandel: can I get back to you in 15 minutes?
[16:49] <mandel> thisfred: I'd like to talk with vds and CardinalFang before we do anything and see veryones point of view, I'm sure the can think issues that we have ignored, as soon as we have something done, I can find time
[16:49] <mandel> thisfred: although it depends on how much they give me for windows :P
[16:50] <mandel> nessita: sure, is a quick question, but certainly we can talk again when ever you finish eating does strange vegan things you eat :)
[16:52]  * nessita will be back
[17:00] <mandel> nessita: we talk about it tom, I need to visit a friend in the hospital (kidney replacement)
[17:10] <dobey> ok, must get lunch myself
[17:10] <nessita> mandel: i'm back
[17:11] <mandel> nessita: we were talking about the SSO  code that we included in desktopcouch and later removed, do you remember it?
[17:11] <nessita> yes
[17:11] <nessita> mandel: I read a bit of backlog but I'm not sure I got the problem/thing to solve
[17:12] <kklimonda1> hey u1 guys, I have a small question
[17:12] <nessita> kklimonda1: shoot
[17:13] <mandel> nessita:  the code was removed, then we added an extension point so that it could be added trough the setuptools, yet I had a question of how to add that in ubuntuone-client, my question for you is, is it worth it? will this code be used with u1-control-panel?
[17:13] <kklimonda1> against which project should I report a bug about my files disappearing completely from u1 server? beuno has tried to help me at the weekend (and I've managed to restore them from a local backup) but it still should be reported :)
[17:13] <beuno> kklimonda1, I'd gues the client
[17:13] <mandel> kklimonda1: was it my fault (aka windows?)
[17:13] <mandel> :P
[17:14] <nessita> mandel: so, the code that was added and removed was meant to do the pairing betweeb u1 and dc, right?
[17:14] <kklimonda1> mandel: not really, you can sleep safe - I won't be hunting you down :P
[17:14] <mandel> nessita: yes
[17:14] <mandel> kklimonda1: it that case, I would always blame rodrigo hehe :P
[17:14] <kklimonda1> beuno: ok, I have backed up all logs from ~/.cache/ubuntuone/log - I'm going to attach them all, hope that helps
[17:14] <nessita> mandel: so that code is independent from the control panel, as far as I know
[17:14] <nessita> mandel: and as far as I know we do need that code running
[17:14] <kklimonda1> mandel: unfortunately he has moved from the U1 team and I can't blame him anymore :/
[17:15] <nessita> mandel: what does that code do, exactly? what does "pairing" mean? :-)
[17:15] <mandel> nessita: ok, so, we do need that code, but it ha no place in u1-control-panel, or u1-client, right?
[17:16] <mandel> nessita: let me get you the explanation of a better developer, one min
[17:16] <nessita> mandel: can you describe what that code do exactly? we'll find the bets place for it. For example: how many times do we need that run? once per computer adding? once per computer restart?
[17:16] <nessita> once per syncdaemon restart? all the time?
[17:16] <nessita> yes, I'll wait
[17:19] <mandel> nessita: the person that reported this bug 629095 ahs a better idea
[17:19] <ubot4> Launchpad bug 629095 in desktopcouch (Ubuntu Maverick) (and 2 other projects) "Ubuntu One pairing code needs to be added (affects: 2) (heat: 37)" [Medium,Fix released] https://launchpad.net/bugs/629095
[17:19] <mandel> nessita: si soy malvado jejeje
[17:21] <mandel> nessita:  the pastebin is still there, and I'm hoping the bug refreshes your mind.. or makes you hate me more, one of the two (or both :) )
[17:21] <nessita> mandel: I remember the bug, but back then (and now) I didn't know what "pairing desktop couch with u1" mean
[17:22] <nessita> mandel: can you specify: how many times do we need that run? once per computer adding? once per computer restart? once per syncdaemon restart? all the time?
[17:22] <kklimonda1> beuno: I've created bug 689760 and attached content of the ~/.cache/ubuntuone/log there - hope that someone can figure out how did I end up deleting my files :)
[17:22] <ubot4> Launchpad bug 689760 in ubuntuone-client (Ubuntu) "files gone from the server (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/689760
[17:23] <mandel> hahaha ok, I though you knew, by looking at the code, it should be once per new token, yet we need to register to the dbus event somewhere, atm we do that in the desktopcouch service
[17:23] <mandel> nessita: ^
[17:23] <beuno> kklimonda1, thank you, facundobatista is probably the right guy to look into it
[17:23] <mandel> nessita: so atm everytime we start the desktopcouch service we register to the events
[17:24] <mandel> Chipaca: ping
[17:24] <nessita> mandel: right, so from my POV, we need to do that in a separated service. I'm working on a branch that provides credentials service specifically for Ubuntu One, and I think that that code should be located in that module
[17:24] <nessita> dobey: would you agree? ^
[17:25] <mandel> nessita: I believe that u1 desktopcouch pairing means setting up the management db so that it knows how to replicate your desktopcouch db with our servers, does it make sense?
[17:26] <nessita> mandel: I think so, but as per what you described, this code is being run every time dc is started on every boot?
[17:27] <mandel> nessita: yes, because if the user removes his credentials and creates new ones, we need to add the pairing accordingly
[17:27] <nessita> mandel: ok, but what happens in this scenario:
[17:28] <nessita> user adds its computer one single time, that adding emits CredentialsFound. Then, a bunch of apps requests to SSO the token for U1 for this user, and the CredentialsFound signal is emitted 800 times
[17:28] <facundobatista> kklimonda1, one example of the files you deleted?
[17:29] <kklimonda1> facundobatista: you mean an actual file, its name or what? :)
[17:29] <facundobatista> kklimonda1, the name, to search for it in the logs
[17:30] <mandel> nessita: nothing, lines 59 and 62: https://pastebin.canonical.com/36655/
[17:30] <kklimonda1> facundobatista: that's the point - they are not in logs, they were never downloaded back from U1 to my computer
[17:30] <mandel> kklimonda1: do you know a guy called kevin (it was kevin, right facundo?)
[17:30] <mandel> hehehe
[17:30] <kklimonda1> facundobatista: what I do, before each upgrade to the dev release is moving my $HOME to /home/BACKUP and starting up with the clean sheat
[17:30] <nessita> mandel: ok
[17:31] <nessita> mandel: do you have the bug report you're working on?
[17:31] <facundobatista> kklimonda1, you see the files in the web ui?
[17:31] <kklimonda1> mandel: nope, I was really drunk.. erm, I mean should I know him? ;)
[17:31] <kklimonda1> facundobatista: no, the whole ~/Pictures/ was gone
[17:31] <mandel> mandel: he is one of my stupid jokes, dont worry too much, you know me :)
[17:31] <mandel> nessita: let me find it
[17:32] <facundobatista> kklimonda1, so, if you don't see them in the web ui, it's not that they're not getting back from U1 into your computer, but that they're not anywhere
[17:32] <kklimonda1> facundobatista: I think I did uncheck "Synchronize this folder" because it didn't do anything and I decided >>hey, it's a good idea to "restart it"<<
[17:32] <facundobatista> beuno, kklimonda1 say you restored the files?
[17:32] <mandel> nessita: bug 668868
[17:32] <ubot4> Launchpad bug 668868 in desktopcouch (Ubuntu) (and 1 other project) "Move the SSO code out of desktopcouch (affects: 1) (heat: 84)" [Undecided,Confirmed] https://launchpad.net/bugs/668868
[17:33] <facundobatista> kklimonda1, to restart what?
[17:33] <mandel> nessita: the bug has to parts, remove it, which is done and add it somewhere, which is why we are talking :)
[17:33] <nessita> mandel: the add one I'm interested in
[17:33] <kklimonda1> facundobatista: to make ~/Pictures/ sync again :)
[17:33] <facundobatista> kklimonda1, I'm lost
[17:33] <mandel> nessita: we can add a new bug with the add one, and point to the original bug
[17:33] <nessita> kklimonda1: question: in the bug report you said you made a clean natty install. Does that involves a newly created home? did you keep the syncdaemon metadata untouched?
[17:34] <mandel> nessita: we have to decide the best location for this code
[17:34] <kklimonda1> facundobatista: ok, from the beginning - I've moved my $HOME to /home/BACKUP and installed natty from scratch
[17:34] <nessita> mandel: the new bug should be in ubuntuoneclient
[17:34] <mandel> nessita: as you consider more appropiate
[17:34] <facundobatista> kklimonda1, when you moved your $HOME, you were logged as you? was ubuntuone-syncdaemon running?
[17:34] <nessita> mandel: u1client for sure, then we need to decide where in u1client
[17:35] <kklimonda1> facundobatista: no, I've done it from the install cd when /home was mounted inside /target/
[17:35] <nessita> mandel: when dobey comes back, I want his opinion on putting that with the soontobeborn module to provide dedicated u1 auth
[17:35] <facundobatista> kklimonda1, ok
[17:35] <mandel> nessita: ok, he had an idea of what to do, so talk with him too and decide
[17:35] <kklimonda1> nessita: no - I've started with a new profile and only copied few files back (~/.mozilla, evolution config)
[17:35] <facundobatista> kklimonda1, you installed natty, and then what? moved stuff back? or added the machine to ubuntuone and downloaded everything again?
[17:35] <mandel> nessita: then let me know if you want me to help in that or not, but I'm kind of overloaded atm
[17:36] <kklimonda1> facundobatista: No, I've just added the machine to ubuntuone and tried to download files again
[17:36] <mandel> nessita: do you want me to file the bug, add an explanation and assign it to you?
[17:36] <nessita> mandel: please file the bug and assign it to me. Please add some detail (the kind of detail we discussed here), since I may erad the report later and don't remember what was about
[17:36] <facundobatista> kklimonda1, and at that point what happened? they did download?
[17:36] <nessita> mandel: yes!
[17:36] <kklimonda1> facundobatista: then, this saturday I've noticed that files weren't downloaded (~/Pictures/ was empty) so I decided to uncheck and check again "Synchronize this folder" in nautilus)
[17:37] <mandel> nessita: deseos == ordenes ;)
[17:37] <nessita> wow
[17:37] <nessita> :-)
[17:37] <kklimonda1> facundobatista: after that I've felt cold sweat run down ma back, I've logged into one.ubuntu.com and saw that the Pictures share isn't even there
[17:38] <facundobatista> kklimonda1, Pictures was not a share, right?
[17:38] <facundobatista> kklimonda1, and what beuno restored to you?
[17:38] <kklimonda1> facundobatista: erm, no - normal folder, not shared with anyone. My bad
[17:39] <kklimonda1> facundobatista: I keep there some pictures I've snapped with the camera and they were restored.
[17:39] <kklimonda1> facundobatista: but I also keep some other files and they were not
[17:39] <facundobatista> kklimonda1, ok
[17:40] <kklimonda1> facundobatista: my photos were in the Photos/ subfolder and it's restored completely
[17:46] <mandel> nessita: what is your lp username?
[17:48] <nessita> mandel: nataliabidart
[17:48] <mandel> nessita: dammed, I tried all the cominations of natty, nessita, natalia I could think of and I missed that one :P
[17:48] <nessita> :-D
[17:49] <mandel> nessita: let me know if you need more info bug 689772
[17:49] <ubot4> Launchpad bug 689772 in ubuntuone-client "Desktopcouch and Ubuntu One pairing is missing (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/689772
[17:50] <mandel> nessita: I tried to get as much history about the bug as possible, that conde has been jumping from one project to another for quite some time
[17:50] <nessita> mandel: I'll read it asap, one sec
[17:52] <mandel> nessita: np
[17:52] <facundobatista> kklimonda1, I really don't know what could have happened, all basics work here... and it's not possible to do post-mortem debug without the logs, :(
[17:54] <nessita> mandel: the bug is clear though you should re-read it and fix some typos (something you use positive sentences when meaning negative ones)
[17:55] <mandel> nessita: ups, I'll read it too see what happen, although I'm quite a positive person
[17:58] <nessita> jeje
[18:04] <dobey> nessita: what's up?
[18:05] <nessita> dobey: remember when mterry asked about how to authenticate a 3rd party service against U1? and we said that we should provide a u1-specific credentials service?
[18:05] <kklimonda1> facundobatista: bummers, I was afraid you would say that - it did look like some weird corner case. I've hoped that maybe there is something in server logs that wiuld at least state what has happened
[18:05] <nessita> dobey: I've been working on that though my branch is not finished yet. I'm bringing this up because I think that mandel's pairing code should go into that same module
[18:06] <nessita> dobey: and before moving on with that, I wanted to know what you think
[18:06] <dobey> nessita: well there are two parts to the problem
[18:06] <nessita> kklimonda1: you sure you didn't copy the ubuntuone metadata?
[18:07] <dobey> nessita: there are the bits that need to be passed to ubuntu-sso-client for authenticating to U1, and there are the parts that use the resulting credentials and do other things than simply authenticating
[18:07] <nessita> kklimonda1: the other thing I can think of is that in natty, folder autosubscribe is off by default, so your Pictures/Photos folder  wasn't synchronized at startup. Did you check u1sdtool --list-folders?
[18:07] <nessita> dobey: yes
[18:07] <dobey> nessita: and the marjority of the desktopcouch code in question falls under that second category i think, and should probably stay inside desktopcouch
[18:08] <nessita> dobey: but the fact that U1 needs pairing with dc seems a u1 problem, not a desktpocouch problem
[18:08] <nessita> dobey: that is tied directly to getting new credentials
[18:08] <nessita> (not even getting credentials but *new* credentials)
[18:08] <dobey> nessita: the real problem is that the architecture isn't really designed to deal with this problem
[18:09] <nessita> dobey: which architecture?
[18:09] <dobey> nessita: the "get new credentials" stuff should be initializable from withing desktopcouch
[18:09] <kklimonda1> nessita: I'm sure I didn't copy it. I didn't check u1sdtool --list-folders, I just went over all the folders I keep on U1 and checked the "synchronize this folder" checkbox - I see that both Music and Documents are on u1sdtool --list-folders list
[18:09] <dobey> nessita: ubuntu one
[18:10] <nessita> kklimonda1: and pictures wasn't... weird. Sounds like the problem happened right before the update, maybe
[18:10] <nessita> kklimonda1: don't you have logs in your old home?
[18:10] <nessita> dobey: ok, so if I'm following you correctly, I'm proposing to add a new module to u1
[18:10] <nessita> dobey: that will take care of auth + on new credetials will pair dc service
[18:11] <nessita> credentials*
[18:11] <kklimonda1> nessita: I know that Pictures wasn't deleted from U1 before saturday as I've published a file from it at friday evening
[18:11] <dobey> nessita: i think those two acts should be separate
[18:11] <nessita> dobey: how would you separate them?
[18:12] <kklimonda1> nessita: I should still have logs from my old home if you think they may help
[18:12] <nessita> dobey: 2 different modules? the problem is that a separated module will not know if the credentials are new or not...
[18:12] <nessita> kklimonda1: I do!
[18:12] <dobey> nessita: to sync desktopcouch to u1, i shouldn't have to deal with files syncing to be able to do it, if i don't want to sync files
[18:12] <dobey> nessita: currently, i have to set up files sync, and then let it set up desktopcouch replication, and then somehow manage to disable files sync
[18:12] <nessita> dobey: but I never proposed mix this file sync
[18:12] <dobey> it is a very weird architecture
[18:13] <nessita> dobey: I'm proposing a separated module, independent from file sync
[18:13] <nessita> like ubuntuone.credentials
[18:13] <nessita> no need at all to have file sync enabled...
[18:13] <nessita> or disabled or even running
[18:13] <dobey> nessita: yes, but authenticating to u1, and setting up desktopcouch to sync to u1 are separate actions. they should be doable in an independent manner
[18:14] <kklimonda1> nessita: attached to the bug 689760
[18:14] <ubot4> Launchpad bug 689760 in ubuntuone-client (Ubuntu) "files gone from the server (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/689760
[18:14] <nessita> dobey: are you sure? let me share what I'm thinking on:
[18:14] <nessita> dobey: suppose a 3rd party app requests tokens for U1, and they don't exist
[18:15] <nessita> dobey: when SSO creates the new set of tokens, the pairing should happen immediately
[18:15] <dobey> nessita: u1cp should do both. but i should be able to take both actions independently without the consequence of having the other necessarily be a requirement
[18:15] <nessita> dobey: u1cp should not be mandatory to operate with u1
[18:15] <dobey> i'm not saying it should be
[18:16] <nessita> dobey: but if u1cp handles the pairing... and u1cp is not mandatory...
[18:16] <nessita> how would you setup pairing without u1cp?
[18:16] <dobey> nessita: but lets say i am a third party app
[18:16] <nessita> let's
[18:16] <dobey> if i want to sync a file to u1, my requesting credentials should not suddenly cause desktopcouch to be paired with u1
[18:16] <nessita> dobey: hum point
[18:17] <dobey> well, presumably desktopcouch-pair can set up pairing.
[18:17] <nessita> dobey: what's desktopcouch-pair ?
[18:17] <dobey> although currently, it only deals with the LAN side of pairing couchdb
[18:17] <dobey> nessita: it's the tool to pair desktopcouch instances on your network
[18:17] <dobey> via avahi
[18:18] <nessita> dobey: but that's within dc project?
[18:18] <dobey> yes
[18:18] <nessita> I think that u1 should not "appear" in dc
[18:18] <nessita> but the other way around
[18:19] <dobey> well this is why the u1 bits should be inside a plug-in and we stick them in a desktopcouch-ubuntuone binary package
[18:19] <dobey> but they are in the desktopcouch source tree
[18:19] <nessita> dobey: right, the bug report is to remove it from there and add it somewhere in u1client
[18:19] <dobey> it shouldn't be in u1client
[18:19] <nessita> dobey: the question is where within u1client
[18:19] <nessita> no?
[18:19] <nessita> dobey: where then? (you're loosing me a bit)
[18:20] <dobey> it should be in desktopcouch
[18:21] <nessita> dobey: you're confusing me... you said that right now those bits "are in the desktopcouch source tree"
[18:21] <nessita> and should not be there
[18:21] <dobey> i didn't say they should not be there
[18:21] <nessita> dobey: but you agreed that u1 bits should not be in dc, right?
[18:21] <dobey> no
[18:22] <nessita> dobey: so you think that u1 bits should be in dc?
[18:22] <dobey> i don't see any good reason to not have the little bit of code for pairing with ubuntuone in desktopcouch
[18:23] <nessita> dobey: separation of concerns, of course!
[18:23] <nessita> u1 bits should not be inside dc, that's for sure, Just like u1 bits should not be in sso
[18:24] <nessita> u1 bits belongs to u1client (or a u1 specific project)
[18:24] <nessita> ralsina: I'm curious, are you following this conversation?
[18:24] <ralsina> Yes
[18:24] <ralsina> I am a bit confused, though
[18:24] <nessita> ralsina: I'm very skilled with destopcouch, you should know
[18:25] <dobey> as am i apparently
[18:25] <nessita> I'm not*
[18:25] <nessita> :-D
[18:25] <ralsina> :-D
[18:25] <ralsina> ok, then
[18:25] <nessita> ralsina, dobey: I'm confused too! :-)
[18:25] <dobey> eh, the skill level of desktopcouch code is irrelevent
[18:25] <ralsina> when you say separation of concerns, you mean "desktopcouch should not depend on ubuntuone" pr something else?
[18:26] <nessita> ralsina: kinda, more like "desktopcouch should not be u1 aware"
[18:26] <ralsina> nessita: right
[18:26] <ralsina> dobey: I thought moving those bits into a separate package was your idea :-)
[18:26] <dobey> that doesn't make any sense to me
[18:26] <dobey> ralsina: package yes; project no
[18:26] <ralsina> yes, I said package
[18:27] <dobey> u1client != desktopcouch
[18:27] <ralsina> in what PROJECT are they now, and where are they being proposed to be moved?
[18:27] <dobey> and it only moves the same exact problem to another place
[18:27] <dobey> merely the exact opposite
[18:27] <ralsina> desktopcouch => u1client, right?
[18:27] <nessita> ralsina: they are right now on desktopcouch project, I'm proposing moving them out. Not sure where to tough
[18:27] <dobey> that is basically what nessita is proposing, yes
[18:27] <nessita> though*
[18:28] <nessita> ralsina: actually, mandel wants to move it, and I think it makes sense
[18:28] <ralsina> well, since it's about u1 auth it makes sense (to me) that they be moved to the u1 project
[18:28] <ralsina> dobey: explain briefly why that move is a bad idea
[18:28] <dobey> i am proposing that the primary concern is the user experience, and that where the code lives is secondary
[18:29] <ralsina> dobey: it's either unimportant to you (and it moves to u1-client), or it's important to you and you can explain it :-)
[18:29] <dobey> ralsina: moving the desktopcouch pairing code to u1client simply reverses the problem; but it's still the same problem
[18:29] <ralsina> in what way does the problem persist? In that paiting desktopcouch nowe reuires u1?
[18:29] <dobey> if it is moved to u1-client; how would i pair desktopcouch to ubuntuone, without installing the filesysnc stuff?
[18:30] <ralsina> Maybe the filesync stuff should be moved to a separate package eventually
[18:30] <dobey> the real problem is that the way it currently works is just totally wrong
[18:30] <dobey> and moving the code doesn't fix that; it'd still be totally wrong
[18:30] <dobey> ralsina: file sync stuff is the only thing in ubuntuone-client
[18:30] <ralsina> dobey: not anymore after this change
[18:31] <ralsina> dobey: u1-client would become "file sync stuff and pairing to u1 accounts"
[18:31] <dobey> ralsina: well moving 30 lines of python into the file sync code, and then moving all the file sync code somewhere else, seems like a dumb thing to do :)
[18:31] <ralsina> That doesn't sounf like a stretch to me ;-)
[18:32] <dobey> each service should be able to operate independently of the others
[18:32] <nessita> dobey, ralsina: u1client also has the nautilus plugin, the icons, the libsyncdaemon code
[18:32] <dobey> putting everything in u1client, will not achieve that
[18:32] <nessita> the seitgesit code
[18:32] <nessita> the zeitgesit code
[18:32] <dobey> nessita: yes, but that's all related to the file syncing
[18:32] <ralsina> dobey: for pairing to u1 you need the u1 client. That shouldn't surprise the user, if the concern is for the user experience.
[18:32] <nessita> the gsd plugin
[18:32] <dobey> ralsina: ubuntuone-client is perhaps a misleading name for that project now
[18:33] <dobey> ralsina: 2 years ago, we only had file syncing service :)
[18:33] <ralsina> dobey: could be. Not changing it right now, either ;-)
[18:33] <dobey> really, ubuntuone-client would be "all the services"
[18:33] <dobey> but that's not what it is
[18:33] <dobey> the music store plug-ins are in there. the notes stuff isn't in there. the evolution bits aren't in there
[18:34] <ralsina> dobey: that's ok, noone says everything is perfect. We are discussing a small thing, don't think so wide
[18:34] <ralsina> In this specific case, the change in the user experience is "If I want to sync couchdb to u1, I now need to install u1-client"
[18:34] <ralsina> That doesn't sound bad to me.
[18:35] <dobey> ralsina: well it's a bit hard not to, when we have been having the other discussion of "move stuff stuff out of u1-client" and now this one where it's proposed to move something into it
[18:35] <dobey> it is if you consider what installing u1-client means
[18:35] <ralsina> dobey: why?
[18:36] <dobey> because, as i said, the name is misleading in that respect. and it would violate the "separation of concerns"
[18:36] <dobey> it just moves the concern to another place where it's not separate
[18:36] <ralsina> dobey: it breaks separation of concerns on both places
[18:36] <dobey> now, if ubuntuone-client was simply low level stuff and only dealt with authentication or something, that might be a different story
[18:37] <dobey> but it isn't
[18:37] <ralsina> OTOH I think way too much time is being wasted discussing a small change that has very little  visible effect in the end.
[18:38] <nessita> dobey: suppose we all agree that u1 bits should not be in desktopcouch source code. Where would you put it, if not in u1-client?
[18:38] <dobey> well as i said, i think it makes sense to allow connecting desktopcouch to ubuntuone without installing all of syncdaemon/zeitgeist/gnome/etc/etc
[18:39] <ralsina> dobey: then generate a separate package for these 30 LOC
[18:39] <ralsina> And don't make it depend on any of those.
[18:39] <dobey> ralsina: you're conflating package and project in that statement
[18:40] <ralsina> But put it in the u-client project, because it's the project that deals with u1, not on desktopcouch
[18:40] <ralsina> dobey: nope, not really, I think
[18:40] <dobey> i see no good reason to not keep the code on the desktopcouch side and generate the second package from there
[18:40] <dobey> instead of generating a mostly unrelated package from u1-client
[18:41] <nessita> dobey: the good reason is like you're mixing apples with oranges. By having the u1-dc bits on u1client, we're only mixing read apples with green apples
[18:41] <ralsina> dobey: desktopcouch is not about ubuntu1
[18:41] <dobey> nessita: not really
[18:41] <nessita> dobey: because...
[18:42] <dobey> nessita: because nothing in u1-client uses desktopcouch
[18:42] <nessita> dobey: the u1 service uses it
[18:43] <ralsina> dobey: that's not a very good reason, really.
[18:43] <dobey> backwards
[18:43]  * ralsina considers just deciding ;-)
[18:43] <dobey> that's like saying the google service uses firefox
[18:43] <nessita> no is not... but hey, ralsina is right, too much time in this :-(
[18:43] <ralsina> dobey: u1-client will also become the source of API for 3rd parties. That's a good argument to provide it there.
[18:43] <dobey> nessita:, alecu: is there a bug about the dbus issue in the cp tests?
[18:44] <ralsina> At least the source of SOME api for SOME 3rd parties
[18:44] <nessita> dobey: nopes, I can create one
[18:44] <dobey> ralsina: which api?
[18:44] <dobey> exactly
[18:44] <dobey> the files sync api
[18:44] <dobey> and it's already there
[18:44] <ralsina> dobey: to be determined eventually. Not just the sync files API
[18:44] <dobey> the desktopcouch api is elsewhere :)
[18:44] <ralsina> Yes, but that's not the api to sync desktopcouch to u1
[18:45] <ralsina> As you said you can use desktopcouch without u1. That's desktopcouch API
[18:45] <dobey> yes
[18:45] <ralsina> If you put it in a separate package, the dependencies argument doesn't hold water and it can be moved back to desktopcouch if it seems like a good idea some day in the future.
[18:45] <dobey> and i can use u1 without desktopcouch
[18:46] <ralsina> dobey: and you can use u1-client without installing this optional, separate package created from its tree.
[18:47] <ralsina> Remember that the user doesn't see projects, he sees packages. And really, we can move it back if this solution sucks without ay ill effects.
[18:47] <ralsina> Everyone semi-convinced? Enough to stop arguing at least? ;-)
[18:47] <dobey> moving code around sucks
[18:48] <dobey> especially if the argument is "we can move it back later if we think this solution sucks"
[18:48] <nessita> dobey: bug #689800
[18:48] <ubot4> Launchpad bug 689800 in ubuntuone-dev-tools "Dbus services are not isolated from session dbus (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/689800
[18:48] <nessita> dobey: I don't think we'll be moving it back, we may move it to a more specific u1-place in the future. A place that we don't know yet.
[18:49] <dobey> it doesn't matter
[18:49] <nessita> but right now, this code is bugging desktopcouch fellows
[18:49] <ralsina> +1 to what nessita says.
[18:49] <dobey> the point is that every time we move code, it sucks
[18:49] <dobey> why is the code bugging them?
[18:49] <ralsina> dobey: I promise you we won't move it again for a while. Really.
[18:49] <thisfred> I think we are spending too much time on this too, but I agree with dobey that u1 specific desktopcouch code is not out of place in the d-c project, as long as it is not in the desktopcouch package itself
[18:50] <dobey> and i thought thisfred and i already agreed on this like 4 hours ago
[18:50] <thisfred> in fact, there is other u1 specific code in there already
[18:50] <nessita> thisfred: which one?
[18:50] <thisfred> nessita: the replication service
[18:50] <ralsina> thisfred: ok, didn't know that
[18:50] <nessita> me neither
[18:50] <nessita> thisfred: does that need to be moved as well?
[18:51] <thisfred> well, in *theory* that could be made to replicate somewhere else
[18:51] <ralsina> In that case, the separatio of concerns there doesn't break by keeping the code, or that code moves too. Hopefully the first option ;-)
[18:51] <dobey> thisfred: oh right; though i was thinking mandel was suggesting it was removed as well
[18:51] <thisfred> but there are no other servers that implement our API
[18:51] <dobey> but either way it makes sense for that to be plug-in style code, and for the u1 service bits to be the default example plug-in
[18:51] <thisfred> dobey: I don't think so, but even if we move that as well, I don't see a problem with desktopcouch.ubuntuone as part of the source tree/project
[18:52] <dobey> thisfred: well, anyone could implement their own authentication/pairing API similar to ours, and have their own replication service
[18:52] <nessita> I think that ubuntuone.desktopcouh makes more sense, but as long as those u1 bits are not in the dc package, I can settle
[18:52] <thisfred> dobey: sure, but as long as that hasn't happened yet, I'm skeptical about the genericity of the code
[18:53] <dobey> thisfred: well i think the code is pluggable generally, there
[18:53] <ralsina> good
[18:53] <thisfred> what we call it I'm agnostic on, but I think for now the desktopcouch project is the best place for it
[18:53] <dobey> but u1 is the only service so far yes
[18:54] <thisfred> yeah it was built to be pluggable, and I don't know that it's not, I think it's probably 99% there
[18:54] <thisfred> anyway, that's a side issue
[18:55] <thisfred> sorry for injecting that
[18:55] <Chipaca> mandel: pong
[18:56] <ralsina> oooooooooook. So. It turns out there already is u1 code in dc. I don't see the urgency to move this code then.
[18:57] <ralsina> I do feel a separate package from the dc project is a good idea though?
[18:57] <thisfred> +1
[18:57] <nessita> ralsina: yes, let me confirm with mandel
[18:57] <ralsina> And ask the dc devels for opinions for much later in the future.
[18:57] <nessita> mandel: is there a current issue with leaving the u1 pairing bits on dc source code but putting those on a separated binary package?
[19:10] <nessita> ralsina, thisfred, dobey: as per mandel's report (bug #689772), seems like u1 pairing code is nowhere right now?
[19:10] <ubot4> Launchpad bug 689772 in ubuntuone-client "Desktopcouch and Ubuntu One pairing is missing (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/689772
[19:11] <ralsina> nessita: looks like it
[19:12] <nessita> thisfred: can you confirm/deny this?
[19:12] <thisfred> nessita: yeah, could be, I thought it had been moved, didn't realize we ended up removing it from everywhere instead :(
[19:12] <thisfred> I'll look at trunk
[19:13] <thisfred> nessita:  desktopcouch/application/replication_services/ubuntuone.py still exists
[19:13] <thisfred> but that doesn't do the initial pairing I think
[19:14] <thisfred> nessita: oh wait no:
[19:14] <thisfred> desktopcouch/application/pair/couchdb_pairing/ubuntuone_pairing.py still exists
[19:15]  * nessita checks
[19:15] <thisfred> nessita: but nothing except tests call it
[19:16] <nessita> thisfred: and who/what should be also calling it to make it run?
[19:16] <nessita> thisfred: also, there is a
[19:16] <nessita> ./desktopcouch/pair/couchdb_pairing/ubuntuone_pairing.py
[19:16] <nessita> and a
[19:16] <nessita> ./desktopcouch/application/pair/couchdb_pairing/ubuntuone_pairing.py
[19:16] <nessita> ?
[19:17] <thisfred> nessita: I have no idea. I assume it should be triggered by signing up for the service, or adding the machine
[19:17] <thisfred> nessita: one is deprecated
[19:17] <thisfred> nessita: it imports the newer one
[19:17] <nessita> thisfred: but the code that connects callbacks to the SSO auth service is ran?
[19:17] <nessita> ah
[19:17] <thisfred> nessita: that I don't know. mandel worked on that part
[19:18] <nessita> ok, I'll re ping him
[19:18] <nessita> thisfred: thanks!
[19:18] <thisfred> nessita: note it's past his EOD most likely
[19:18] <nessita> yes
[19:18] <thisfred> it's 8:15 PM in the old country
[19:18] <nessita> yeah...
[19:19] <ralsina> ok, this can wait until mandel is here, I'll catch him early :-)
[19:20] <nessita> ralsina: thanks!
[19:22] <dobey> nessita: hrmm, something is very weird with the u1cp integration tests
[19:23] <nessita> dobey: for example? alecu built that part, he may be able to help us
[19:24] <dobey> nessita: i have no idea yet, but i can't reproduce the problem with a simpler test in ubuntuone-dev-tools directly
[19:24] <karni> verterok: is volumeId + nodeId unique for an element (node) in the storage? in other words, can it happen that a Share and a UDF have same volumeId and nodeId, and only differ by volume type (Share vs UDF) ?
[19:25] <nessita> dobey: how is your test setup?
[19:25] <dobey> nessita: http://pastebin.ubuntu.com/543229/
[19:25] <verterok> karni: nope
[19:25] <dobey> nessita: and it passes every time
[19:25] <verterok> karni: volume_id+node_id is an unique identifier for a node
[19:25] <karni> verterok: just to be clear. if we have a volumeId and a nodeId, we have pinpointed the file/dir ?
[19:25] <karni> verterok: thank you :)
[19:26] <karni> verterok: the code is in my +junk, but it should be more usable as soon as I squeeze in few more hours for it..
[19:26] <dobey> nessita: also pases using com.ubuntu.sso instead
[19:26] <nessita> dobey: can you please try it with com.ubuntu.sso?
[19:26] <dobey> :)
[19:26] <nessita> dobey: ah...
[19:27] <karni> verterok: /me codes the project now
[19:27] <verterok> karni: cool, thx :)
[19:27] <karni> :)
[19:27] <nessita> dobey: is u1cp trunk failing when ussoc service is up and running?
[19:28] <nessita> dobey: and, can I have the full test source code to run it here?
[19:28] <dobey> nessita: yes it is
[19:28] <nessita> ah...
[19:28] <dobey> nessita: which full test source code?
[19:28] <nessita> dobey: the test case where the  test_dbus_session_is_private is running
[19:29] <dobey> nessita: i added it to the ubuntuone/devtools/services/tests/test_dbus.py in a branch of ubuntuone-dev-tools trunk where i'm trying to figure out the problem
[19:30] <dobey> nessita: so just copy/paste it there. i just put it in there real quick to try and create a minimal failure case
[19:30] <nessita> hum
[19:31] <dobey> but it passed instead
[19:32] <dobey> nessita: but what's weird, is that in u1cp, even if NONE of the integration tests are run, the system syncdaemon still gets started
[19:32] <dobey> nessita: so all it's doing at that point is importing the test_foo.py for integration tests
[19:33] <nessita> dobey: any idea how to debug further?
[19:33] <dobey> not really. there's no easy way to tell what exactly is causing it to happen
[19:34] <nessita> alecu: would you have some pointers/ideas? ^
[19:34] <alecu> nessita, dobey: pong.
[19:34] <alecu> nessita, dobey: sorry, I was logged in as another user, testing zeitgeist.
[19:34] <nessita> alecu: need a summary?
[19:35] <alecu> catching up.
[19:35] <nessita> dobey: why you added the DBusGMainLoop(set_as_default=True)?
[19:35] <dobey> weird
[19:35] <nessita> dobey: FYI, docstring should have triple double quotes, not '''
[19:36] <dobey> nessita: because the DBusClientTestCase in u1cp does it
[19:36] <dobey> although, weird
[19:36] <dobey> because i just ran the tests again and it didn't start the system sd
[19:37] <nessita> dobey: in u1cp, the system SD is started one time yes, one time no
[19:38] <nessita> which yes, is even odder
[19:38] <dobey> nessita: well so far, it has happened every time for me, until now
[19:38] <alecu> dobey, nessita: do you have a branch to test this, or is this just u1cp trunk?
[19:38] <dobey> trunk
[19:38] <nessita> alecu: u1cp trunk
[19:39] <nessita> dobey: hum... can you try replicating the
[19:39] <nessita>      28         name = bus.request_name('com.ubuntu.sso',
[19:39] <nessita>      29                                 dbus.bus.NAME_FLAG_DO_NOT_QUEUE)
[19:39] <nessita>      30         self.assertNotEqual(name, dbus.bus.REQUEST_NAME_REPLY_EXISTS)
[19:39] <nessita> so the test actually fails?
[19:40] <nessita> because here it doesn't fail even calling request_name 2 times in a row
[19:43] <dobey> huh
[19:43] <dobey> nessita: replicating it where?
[19:44] <dobey> nessita: that code in a test in devtools passes every time
[19:44] <nessita> dobey: in the same test, if we call request_name 2 times, the second one, the assert should fail, no?
[19:44] <dobey> oh, maybe
[19:44] <nessita> dobey: this should fail, right? http://pastebin.ubuntu.com/543240/
[19:45] <nessita> but is not failing for me
[19:46] <dobey> nessita: weird, it's not failing here either :(
[19:46] <dobey> wtf
[19:47] <nessita> dobey: something is odd
[19:47] <dobey> very
[19:51] <joshuahoover> nessita: ping
[19:52] <nessita> joshuahoover: 1/8 pong
[19:52] <joshuahoover> nessita: have you heard of users adding their computer to u1 on their maverick computers and the computer showing up twice in u1-prefs?
[19:52] <nessita> joshuahoover: yes, bug #687523
[19:52] <ubot4> Launchpad bug 687523 in ubuntu-sso-client (and 1 other project) "SSO service creates two tokens for one request (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/687523
[19:53] <joshuahoover> nessita: ah, thanks!
[19:53] <nessita> :-)
[20:01] <dobey> wtf is going on with dbus here
[20:06] <dobey> hrmm
[20:06] <dobey> i bet something somewhere is doing some nasty on import
[20:11] <dobey> nessita: found it!
[20:11] <nessita> dobey: what is it?!?!?!
[20:14] <dobey> -def publish_backend(backend=ControlBackend()):
[20:14] <dobey> +def publish_backend(backend=None):
[20:14] <nessita> dobey: that called my attention as well, but I don't understand what the problem is
[20:17] <dobey> nessita: because it's not the class name that is the default, but the initalized object, it is getting initialized when the file gets imported
[20:17] <nessita> argh!
[20:18] <dobey> nessita: and u1trial imports the test_foo.py (which in turn imports their things), to be able to determine what processes need to be run
[20:18] <dobey> nessita: and since that is done before the private dbus session is started, it connects to the one it's finding :)
[20:18] <nessita> dobey: right... awesome catch, really
[20:19] <nessita> dobey: wanna propose a branch? mark the bug as invalid in dev tools and put it on u1cp
[20:19] <dobey> nessita: yes am about to do that right now. though i did find another issue in devtools in the process, which i'll also fix :)
[20:19]  * ralsina reminds everyone that mutable default arguments in python are evil
[20:22] <karni> verterok: i'm not sure if it's best to ask you, but do you know how U1 knows where to dowload a file? say, during initial synchronization, how it constructs the path - does it recurse down directories and thus know the path?
[20:22] <verterok> karni: the path is in the metadata
[20:22] <karni> :O xDDD
[20:22] <verterok> karni: volume path + node path
[20:22] <karni> verterok: seriously xD?
[20:22] <karni> node path is in the meta? hahahahah
[20:23] <verterok> karni: the volume path is the only thing defined by the client
[20:23] <karni> God I get to know new things with you every day ;D
[20:23] <karni> (every day I code)
[20:23] <karni> hahah... oh man :)
[20:23] <verterok> karni: e.g: for UDFs it's the suggested_path
[20:23] <karni> verterok: oh, that's what you mean.
[20:23] <karni> no no, what I mean is:
[20:23] <verterok> karni: for shares is a bit more complex, share_name + 'from' + user_visible_name
[20:23] <karni> say, you have a file ~/Ubuntu One/foo/bar/star
[20:24] <verterok> karni: but that is defined by the client itself
[20:24] <karni> how does U1 know where to download 'star' during initial sync?
[20:24] <verterok> karni: "~/Ubuntu One/" is the root volume path
[20:24] <karni> does it pull first ~/Ubuntu One/*, then contents of foo/*, then bar/*
[20:24] <verterok> karni: foo/bar/star is in the metadata of the node "star"
[20:24] <karni> oh man.. so it's in the meta
[20:25] <karni> verterok: has it been there always.. ?
[20:25] <verterok> karni: hmm, let double check :)
[20:26] <karni> verterok: I constructed the path of the file in AU1 based on where the user navigated to.
[20:26] <verterok> karni: sorry, the path isn't in the metadata from the server
[20:26] <karni> oh ;<
[20:26] <karni> and I already was so happy ;)
[20:26] <verterok> karni: but in a delta, you have the node_id and the parent_id
[20:26] <dobey> nessita: https://code.launchpad.net/~dobey/ubuntuone-control-panel/fix-689800/+merge/43567
[20:26] <karni> yes
[20:27] <verterok> karni: and you get the contents in the delta in order
[20:27] <karni> so, should I recurese up? and construct the path?
[20:27] <nessita> dobey: review queued
[20:27] <verterok> karni: so, you always process from parent -> child
[20:27] <karni> in order
[20:27] <karni> aha, ok
[20:27] <karni> verterok: ok, thank you :)
[20:27] <karni> verterok: that's helpful
[20:27] <verterok> karni: do you have a checkout of client/syncdaemon code?
[20:27] <dobey> nessita: btw, i just noticed; why are the u1cp branches private?
[20:28] <verterok> karni: take a look to ubuntuone/syncdaemon/sync.py @ line 1046
[20:28] <verterok> karni: that's how the client process deltas
[20:28] <nessita> dobey: they shouldn't be, I asked a losa to make public the default
[20:28] <ralsina> dobey nessita: I approve
[20:28] <karni> verterok: ok, thank you. will do
[20:29] <karni> verterok: nice, thanks!
[20:38] <dobey> nessita: and https://code.edge.launchpad.net/~dobey/ubuntuone-dev-tools/fix-689851/+merge/43571 to fix the other issue i found in devtools
[20:40] <nessita> dobey: u1cp branch approved. SInce we're at it, can you add u1cp to be landed by tarmac please? veridy_command should be ./run-tests
[20:43] <dobey> ok
[20:43] <nessita> dobey: thanks
[20:44] <dobey> i guess i need to set up nightlies of that too
[20:46] <dobey> nessita: tarmac is set up now
[20:46] <nessita> dobey: yes please, all the packaging bits are ready, so it should not be a problem
[20:48]  * dobey really needs an EPOC
[20:50]  * ralsina is going away now. Anyone needs anything?
[20:51] <dobey> ice perhaps
[20:51] <ralsina> I could mail you some, but that's impractical :-)
[20:53] <nessita> dobey: devtools branch approved
[20:54] <dobey> heh
[20:54] <dobey> indeed. it would be water by the time it got here
[20:54] <dobey> and water mixed with bourbon isn't exactly what i was going for :)
[20:55] <dobey> of course, an EPOC that works on linux would be nice too
[20:55] <dobey> and emacs/firefox/X not crashing all the time
[20:55] <dobey> and cake
[20:56] <dobey> nessita: thanks
[20:56] <dobey> ok, quick break after all that crazy typing
[20:56] <ralsina> I'll try to do something about the cake whenever we meet in person :-)
[20:56] <ralsina> Have a nice evening everyone.