=== JanC_ is now known as JanC
=== M0hi is now known as IAmNotThatGuy
[06:21] <androidbruce> could anyone give me some advice on getting my songs to sync on my fresh installation? also is there a web interface to make sure I still have these songs?
[06:22] <androidbruce> ok i just found the interface
[06:22] <androidbruce> online. how can I make these songs sync? i've signed in. but rhythmbox still says transferring to your ubuntu one storage
=== M0hi is now known as IAmNotThatGuy
[11:16] <karni> hello world! wait.. that sounds familiar
[11:18] <Tm_T> no, never heard
[11:18] <karni> androidbruce: hey bruce. you can check the status of the sync daemon running: u1sdtool --status (alternatively: u1sdtool --waiting-content )
[11:29] <karni> beuno: aquarius: hey guys. I've got a question about conflicts - what if it so happens that modified date of a file on the phone is more recent, than a new version on the server (i.e. we've got a conflict)?
[11:30] <karni> beuno: aquarius: i'd prefer a simple solution for starters that we can improve later. things are kinda growing around the sync stuff pretty fast.
[11:31] <aquarius> karni, not sure. that's a syncdaemon protocol question, that one
[11:32] <aquarius> verterok's your man for that
[11:32] <karni> aquarius: ack
[12:06] <wolki> hi, I sometimes get conflicts with files that were deleted/replaced from the disk but not from the server. any ideas?
[12:08] <wolki> most often when generating pdf plots from r scripts that I then use in latex; sometimes the files get written very rapidly because i need to change the parameters slightly. it's very annoying because it breaks the build of the final document
[12:10] <wolki> I'm only editing these files from one computer at a time, so it can't be real conflicts
=== teknico is now known as teknico_away
[12:35] <verterok> aquarius, karni: hi
[12:35] <verterok> karni: sync based on dates sounds fragile, that's why the protocol is based on hashes
[12:37] <rye> wolki, what version of ubuntu & ubuntuone-client you are running?
[12:44] <wolki> rye, ubuntu version is maverick
[12:44] <wolki> ubuntuone-client is Version: 1.4.5-0ubuntu1
[12:58] <rye> wolki, could you please set ubuntuone-client to debug mode? https://wiki.ubuntu.com/UbuntuOne/Bugs - Running syncdaemon in debug mode ?
[12:59] <duanedesign> 'lo all
[13:05] <ralsina> good morning everyone
[13:40] <androidbruce> what does this mean, dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Process /usr/lib/ubuntuone-client/ubuntuone-syncdaemon exited with status 1
[13:41] <verterok> androidbruce: ubuntuone-syncdaemon crashed while dbus-activation was starting it
[13:42] <androidbruce> this must be why my music isn't coming back after a new installation
[13:42] <androidbruce> any ideas on how to resolve this issue
[13:43] <androidbruce> 64bit ubuntu
[13:45] <wolki> rye, I enabled the debug and restarted the daemon
[13:45] <wolki> now the deleted file has reappeared
[13:46] <rye> wolki, ok, after you notice that syncdaemon marks files as conflict - could you please open a bug report attaching syncdaemon.log and poke me or facundobatista with its number
[13:59] <wolki> rye: ok, I will, when it happens again
[14:00] <rye> wolki, thanks!
[14:01] <verterok> androidbruce: could you pastebin the logs? ~/.cache/ubuntuone/log/syncdaemon.log
[14:03] <rye> androidbruce, or, alternatively could you please run /usr/lib/ubuntuone-client/ubuntuone-syncdaemon directly from terminal?
[14:03] <karni> verterok: aha, thank you. so when the content of the file changes locally, and it so happens that server serves a new modified copy, I assume I shoult '.conflict' the local copy?
[14:04] <verterok> karni: yes...I think. syncdaemon tracks changes to local files, not sure if it's doable to do that on android :/
[14:05] <karni> verterok: it is, but we don't want the service to run all the time. thus, I thought I could peek on the value of modification date, and if it's different then the one stored as a meta, that would mean it's been modified.
[14:06] <karni> verterok: additionally, I can always check if the hash has changed (which would give the answer to question if it has really changed, or the modification time has just been bumped)
[14:07] <karni> verterok: I've been reading about FileShelf. You build dictionaries of mappings of mdid<->paths on every start of computer?
[14:08] <verterok> karni: let me think about that...I'm not entirely sure about a final solution :(
[14:08] <verterok> karni: FileShelf is the "old" metadata storage, yes we build a index on each startup
[14:09] <verterok> karni: now we have a new metadata storage backend, it's called tritcask
[14:09] <karni> verterok: Thanks. Let me rephrase again what I meant so we're on the same wavelength.
[14:09] <verterok> karni: which is a *lot* faster
[14:09] <karni> verterok: Oh.. i've seen tritcask here and there too.
[14:11] <karni> verterok:  So. Let's imagine a shared file is being modified by two of the clients, phone and a PC. The PC version gets to the servers first, and just while phone tries to upload -- it gets a response that oldHash is wrong, so it can't upload. It also receives a delta with the new file. Thus, I should .conflict one of those. Question is which one.
[14:12] <verterok> karni: the one that upload first wins
[14:13] <verterok> karni: there is an extra case there, what if both clients did the same change to the file? :)
[14:14] <verterok> karni: should it be marked as a conflict?
[14:14] <karni> verterok: Right. Oh, that's also true.
[14:15] <karni> verterok: I think that level of detail would extend blueprints on my schedule for next 2 months at least o_O (crap..)
[14:15] <verterok> karni: yes, that's what syncdaemon is all about
[14:15] <karni> Ok, I should stick to 'first upload wins' rule
[14:16] <karni> verterok: yeah, __lucio__ start's it with a comment "Here is the magic" or something along that line hahah
[14:19] <verterok> karni: what about let the user do the sync logic? hehe
[14:19] <karni> verterok: hahahahah that's quite smart ;D!
[14:19] <verterok> karni: is the client going to do autosync? or is always user triggered?
[14:20] <karni> verterok: it already does the sync periodically (but that can be turned off, and then is user-triggered)
[14:20] <karni> verterok: the frequency is set by the user (the least is 5 min I think, next 30 min, [...], daily, and off [manual] )
[14:21] <verterok> karni: and what about a setting to replace client files with whatever the server has?
[14:21] <karni> verterok: I think I'd do it like that for time being (which will save much effort ATM).
[14:22] <verterok> karni: something like the funambol app, server -> client,  client -> server or merge/sync
[14:23] <karni> verterok: That's worth considering, indeed.
=== teknico_away is now known as teknico
[14:45] <karni> I just realized how dumb is the Dropbox app o_O It's certainly got the looks. But hey, it doesn't do sync at all. It's just an android-native door to downloading files.
[14:46] <karni> You know what verterok, dropbox just overwrites the files on the server, even if they have been changed (/me laughs).
[14:47] <verterok> karni: heh, maybe that's a good enough first step as the sync logic...but I'm not the right one to make that call :)
[14:48] <karni> verterok: it's cool that we've got the "old hash not correct" thing.
[14:48]  * karni back to work
[16:20] <karni> beuno: Have you had a chance to test the fav item redownloading(sync) ?
[16:20] <beuno> karni, no!  can I have an apk  :)
[16:21] <karni> beuno: I'll provide the one from 2 days ago, as I'm having trouble testing periodic sync today and wrapping it up :< (slowdowns.. tried staging, failed)
[16:21] <karni> beuno: So yes, just a sec.
[16:25] <karni> beuno: @ priv
[16:27] <__lucio__> karni, whats wrong with staging?
[16:27] <karni> __lucio__: hey lucio. I'm basically stuck after the auth dance. logs are quite silet about that :<
[16:28] <karni> __lucio__: I'll try to squeeze more juice out of the logcat (used for android logging as you may know), maybe that'll give us more info
=== beuno is now known as beuno-lunch
[16:29] <__lucio__> karni, you are right, staging is ~dead
[16:30] <karni> __lucio__: oh..
[16:30] <__lucio__> mmh.. ~dead could be aprox-dead or not-dead
[16:30] <__lucio__> but i meant that it looks dead
[16:30]  * karni chuckles
[16:51] <alecu> facundobatista, when you have a minute, can you please let me know where should that new syncdaemon signal should live on?
[16:55] <__lucio__> karni, staging is back. hopefully it will stay like that for a while :) let me know if it breaks, it shouldnt, but we dont have alarms for it.
[16:57] <karni> __lucio__: thank you, I'll give it a try.
[16:57] <facundobatista> alecu, sí, did you merge my branch?
[16:59] <alecu> facundobatista, lp:~facundo/ubuntuone-client/unleash-the-queues-3 ?
[17:01] <facundobatista> alecu, sí
[17:02] <alecu> facundobatista, done
[17:03] <alecu> facundobatista, I'm looking at the diff right now at https://code.launchpad.net/~facundo/ubuntuone-client/unleash-the-queues-3/+merge/46281
[17:04] <facundobatista> alecu, ubuntuone/syncdaemon/action_queue.py, lines #448 and 466
[17:08] <facundobatista> alecu, you have to change that, and also the handler in ubuntuone/platform/linux/dbus_interface.py line 822
[17:08] <facundobatista> alecu, the number lines are not in the diff, but in real file
[17:08] <alecu> facundobatista, that's great. What would be better: adding a flag to the SYS_QUEUE_CHANGED meaning that the command was added or removed... or sending two different events for that?
[17:09] <facundobatista> alecu, I'd send two
[17:09] <alecu> facundobatista, send two different messages there, right?
[17:09] <alecu> not two messages in a row
[17:10] <alecu> let's say  SYS_QUEUE_ADDED and  SYS_QUEUE_REMOVED
[17:10] <facundobatista> exactly
[17:10] <alecu> facundobatista, ^ and we would remove all references to SYS_QUEUE_CHANGED
[17:10] <facundobatista> alecu, yes, it disappears
[17:11] <alecu> facundobatista, ok, it does not look complicated. nessita, what do you think? ^^^
[17:11] <karni> verterok: __lucio__: With staging, I get http://paste.ubuntu.com/554082/ . fs-1 is doing well ATM, so I'll stick with it. But in the evenings, when things go slow, I'd like to use staging. verterok: Would I have to change the createSocket to handle InetAddress, or passing that IP as a String is just fine?
[17:13] <verterok> karni: you need to use a token available in staging
[17:13] <verterok> karni:looks like it's working passing the IP as string, right?
[17:14] <karni> verterok: __lucio__ told me the regular token is fine. But no problem, I'll change the oauth to aim at staging.one.ubuntu.com
[17:14] <karni> verterok: well it starts authentication, so it looks like, yup.
=== beuno-lunch is now known as beuno
[17:17] <verterok> karni: if you get a new token for the test, it will not be in the staging db
[17:18] <karni> verterok: I fetched the token from staging.one.. and it authenticated, but it's seriously stuck on onClientSetup (which performs setClientCaps)
[17:18] <nessita> alecu: I was AFK getting some tea, I'll read the backlog
[17:18] <karni> verterok: let me look into the code
[17:19] <karni> verterok: it's stuck on final Deferred d = setCaps(Arrays.asList(caps)).getDeferred(); while using staging.
[17:20] <nessita> alecu, facundobatista: agreed on having 2 events, and yes, should be simple
[17:20] <verterok> karni: the code is the same as production...
[17:20] <verterok> __lucio__: do you know if there are any problems with staging?
[17:20] <alecu> nessita, ok, I'll tackle it.
[17:21] <karni> verterok: Please have a look here (it'll take you 30 sec) http://paste.ubuntu.com/554087/
[17:22] <__lucio__> verterok, we had, its working now.
[17:22] <verterok> karni: the code looks ok
[17:22] <karni> verterok: __lucio__: I don't want to bother you guys. I'll settle with fs-1. Hopefully things won't get slow [in the evenings] in the future.
[17:23] <karni> verterok: __lucio__: Thanks for your efforts!
[17:24] <alecu> nessita, I've added the bug for the cmdline option to open u1cp in a given tab: #702968
[17:25] <alecu> hmmm... bug #702968
[17:25] <ubot4> Launchpad bug 702968 in ubuntuone-control-panel "add command line option to open in a given tab (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/702968
[17:28] <nessita> alecu: awesome, thanks!
[17:29] <alecu> nessita, I'm getting credentials errors when running tests on u1client trunk: http://pastebin.ubuntu.com/554091/
[17:29] <alecu> nessita, perhaps it's due to me not having an updated u1ssoc?
[17:30] <nessita> alecu: it shouldn't be
[17:30] <nessita> alecu: ar eyou running trunk?
[17:30] <nessita> are*
[17:30] <alecu> hmmm.... I'm getting the exact same error when pointing PYTHONPATH to u1ssoc trunk
[17:31] <alecu> nessita, yes, both u1client trunk and u1ssoc trunk
[17:31] <alecu> nessita, those tests run fine if I just run them with ./contrib/test -t, but they fail when run with "make check"
[17:32] <nessita> alecu: give me one sec
[17:32] <alecu> nessita, no problem, this is not blocking me.
[17:33] <alecu> nessita, I'll try running those on my natty vm (currently testing on maverick)
[17:35] <nessita> alecu: I'm back, Jason wanted to ask about the bug of syncdaemon prompting the user for login
[17:35] <alecu> nessita, no prob.
[17:35] <nessita> alecu: so, I think you need to increse the timeout located at: tests/credentials/test_credentials.py:165
[17:36] <nessita> alecu: can you set something like 4 seconds and re run?
[17:36] <nessita> is a system load issue...
[17:36] <alecu> sure, I'll try that.
[17:37] <karni> Question: When is SYS_USER_CONNECT emitted? (apart from when user clicks the 'connect' button)
[17:39] <nessita> karni: is also emitted if the user has the setting autoconnect set to True (default since natty)
[17:39] <karni> nessita: So it's also emited on computer start (if autoconnect=True), is that right?
[17:39] <karni> 'computer start' heh.. sounded so unprofressional
[17:40] <nessita> karni: is not 'at computer start' but 'at syncdaemon start', that can be a different time
[17:40] <karni> nessita: right, all's clear. thank you :)
[17:41] <nessita> :-)
[17:45]  * karni is getting hooked more every day
[17:48] <nessita> karni: share some!
[17:48] <nessita> :-P
[17:49] <karni> nessita: I'm just excited to finally (at least _start_trying_) to implement proper queues. Things have been a little ad-hoc, but the complexity is increasing in such pace, that I need much more resonable handling of things.
[17:49] <karni> nessita: And the state machine diagrams and such of syncdaemon, of the queues, are really useful. Although I can't directly port that (becase we're running in a totally different type of environment).
[17:50] <nessita> karni: right. Are you aware we're unifying the queues, right?
[17:50] <karni> nessita: Could you elaborate on that?
[17:50]  * karni things he might not know what you know that you know ;)
[17:50] <karni> *thinks
[17:52] <nessita> karni: so, syncdaemon right now process meta data and content data. And those 2 go to different queues: a meta queue and a content queue
[17:53] <nessita> karni: facundobatista is working bery hard on having a unified queue, both for meta and content
[17:53] <karni> nessita: correc
[17:53] <karni> *correct (arghh.. loosing letters)
[17:53] <karni> oh
[17:53] <nessita> karni: so if you need something from that, or if you depend on having 2 queues, you need to speak with facundobatista ASAP
[17:53] <alecu> nessita, the timeout change fixed the tests
[17:53] <alecu> nessita, I upped it to 10, just for my tests.
[17:53] <nessita> karni: to see what you can do, since the queues being unified is something that it will be done
[17:53] <alecu> nessita, should I commit my branch with this value?
[17:54] <karni> nessita: as long as I'm on totally different platform, I don't think it matters. But'll I definitely talk to him
[17:54] <nessita> alecu: yes please. Less that 10 will not work for you? such as 5?
[17:54] <nessita> karni: aweosme
[17:54] <nessita> awesome*
[17:54] <karni> facundobatista: you have just a moment to say what adventages does the unified queue bring?
[17:54] <alecu> nessita, well, it would depend on how much load my system has :-)
[17:54] <nessita> right
[17:54] <nessita> ok, leave it 10
[17:55] <facundobatista> karni, it's not an unified queue, it's just a pool of commands: all running in parallel, everything is much faster (because of not waiting roundtrips to server)
[17:56] <karni> facundobatista: Can I please see the sources? (Any documentation/state diagrams would be also really awesome to see.)
[17:58] <facundobatista> karni, there's a branch: lp:~facundo/ubuntuone-client/unleash-the-queues-3
[17:58] <karni> I'm asking everybody so many questions I'm starting to feel guilty.
[17:58] <karni> Thank you.
[17:58] <facundobatista> karni, the change is huge, the benefit is that it's simpler now
[17:58]  * karni nods
[17:59] <karni> That's awesome facundobatista :)
[18:11] <erkan^> how delete I all contacts for adressbook ?
[18:15] <erkan^> I can not found "delete" by one.ubuntu.com :(
[18:15] <alecu> thisfred, ralsina, nessita, everybody else: can you please review this? https://code.launchpad.net/~alecu/ubuntuone-client/status-listener/+merge/46303
[18:15] <beuno> erkan^, there's no "delete all" for contacts on the web ui
[18:15]  * ralsina looks
[18:16] <erkan^> and one delete ?
[18:16] <erkan^> one contact
[18:16] <beuno> erkan^, sure
[18:16] <beuno> open the contact, and there's a trash can
[18:17] <beuno> erkan^, one trick you could use to delete them all
[18:17] <beuno> is to merge them all into one
[18:17] <beuno> and then delete that one
[18:18] <erkan^> i go see
[18:21] <alecu> nessita, is it fine for magicicada to die when using u1client trunk?
[18:22] <karni> facundobatista: Is it possible to summarize changes introduced in your branch, concerning the queues, in few sentences? It'll take some time for me to go through all the diffs. Just conceptually and generally, what has changed.
[18:22] <alecu> nessita, it cant find sdtools: from ubuntuone.syncdaemon.tools import SyncDaemonTool
[18:22] <erkan^> thank you for a feedback, beuno
[18:22] <facundobatista> karni, did that in the merge proposal
[18:22] <karni> oh! thanks
[18:28] <karni> facundobatista: Sounds like great changes. I'll jump into the source now. PS You might consider removing docs/states_queues.svg (or even better, assign someone to make new diagram)
[18:28] <facundobatista> karni, I have a note to fix that
[18:28] <karni> facundobatista: cool
[18:29] <nessita> alecu: what version do you have installed?
[18:29] <nessita> alecu: 0.3.0 should work fine, except for latests changes that facundobatista added
[18:29] <alecu> nessita, I've just updated magicicada to the latest packaged version, and it keeps failing.
[18:30] <alecu> nessita, oh, I think 0.2.0 was installed
[18:30] <alecu> nessita, anyway: don't worry right now.
[18:30] <nessita> alecu: 0.3.0 will defininetly work in latest officila SD. THe one in trunk, I can't say
[18:43] <ralsina> alecu: aprobada
[18:43] <karni> ubuntuone-client/ubuntuone/syncdaemon/docs/state_manager.svg still includes server_rescan
[18:43] <nessita> karni: as far as I know server rescan is a valid state
[18:44] <karni> oh sorry
[18:44] <karni> nessita: I thought generations have changed that
[18:47] <alecu> ralsina, gracias! thisfred approved it also.
[18:47] <alecu> so now it's on its way to trunk.
[18:57] <erkan^> I have a problem :(
[19:12] <alecu> rye, still around?
[19:15] <alecu> rye, well, if you see this... happy birthday!
[19:15] <rye> alecu, yep
[19:15] <rye> alecu, thanks :)
[19:15] <rye> erkan^, ?
[19:16] <erkan^> i have deleted adresbook by evolution (group: ubuntu one), aftern i go restart evolution and ubuntu one for adresbook doesn't sync, rye
[19:18] <rye> erkan^, erm, could you please provide more details as to how you removed the addressbook?
[19:20] <erkan^> I had remove an adresbook (group Ubuntu One) in Evolution. I went restart Evolution and a sync between Ubuntu One and adressbook Evolution, but I don't see contacts
[19:21] <erkan^> and one.ubuntu.com I see contacts
[19:21] <erkan^> How can that :/
[19:22] <karni> facundobatista: May I ask a tiny question about naming conventions? What does SYS_ stand for in, say, SYS_USER_CONNECT ?
[19:23] <karni> facundobatista: I can imagine it's 'system'. Just wondering why (e.g. user_connect can be invoked by user action, when he clicks the Connect button)
[19:24] <erkan^> do you understand my question, rye ?
[19:33] <facundobatista> karni, we used the generic SYS for system when the event didn't belong clearly to any SyncDaemon node :p
[19:33] <karni> facundobatista: thank you
[19:41] <rye> erkan left :( i've just tested removal of the addressbook
[21:10] <ralsina> dobey: are you making a release now?
[21:11] <dobey> no, trunk is broken
[21:11] <ralsina> dobey: that's why I asked, really, to stop you if needed :-)
[21:17] <dobey> hrmm. and it looks like building newer rhythmbox on lucid might be a pain, because it requires new stuff not in lucid too
[21:17] <dobey> perhaps should just delete the nightlies/stable of rbox store on lucid :-/
[22:15] <karni> Bitcask is cool. I imagine tritcask is even better.
=== gnomefreak76 is now known as gnomefreak
[22:19] <verterok> karni: not better, just a bit different :)
[22:19] <alecu> nessita, dobey: pynotify is a blocking library!
[22:19] <alecu> nessita, dobey: that means we will probably end up calling DBus directly.
[22:20] <alecu> https://bugs.launchpad.net/ubuntuone-client/+bug/703100
[22:20] <ubot4> Launchpad bug 703100 in ubuntuone-client "pynotify is a non-asynchronous library (affects: 1) (heat: 6)" [Undecided,New]
[22:20] <karni> verterok: uhm :) What is a 'marker' ? (something related to uuids that you guys use, or an empty interface..)
[22:20] <karni> verterok: I'm studying event_queue.py source atm
[22:20] <karni> verterok: I can ask facundo if you're busy
[22:21] <verterok> alecu: you can make it work with twisted ;)
[22:21] <alecu> verterok, yeah: calling it in a thread.
[22:21] <verterok> karni: a marker is a placeholder of a node_id we are waiting for
[22:21] <alecu> verterok, but we don't want that lib running inside syncdaemon.
[22:21] <karni> verterok: neat, thanks!
[22:21] <nessita> alecu: can you please check with neil? he ensures everything is non blocking
[22:21] <verterok> karni: mkdir foo/bar will create two directories
[22:22] <nessita> alecu: thought maybe he was just talking about libunity
[22:22] <alecu> nessita, probably.
[22:22] <nessita> alecu: he did ensure that libunity will not be blocking and that dbus API is not guaranteed to be trustable (ie ti will change a lot)
[22:23] <verterok> karni: bar needs to wait for the foo node_id
[22:23]  * karni nods
[22:23] <alecu> nessita, I'm just saying that I'm looking at the libnotify C code, and it says so very clearly: "/* TODO: make this nonblocking */"
[22:24] <nessita> alecu: that's bad
[22:24] <karni> verterok: You guys together with facundobatista, __lucio__, Chipaca and others did such a great work. I'm so inspired with those sources!
[22:24] <verterok> karni: thanks :)
[22:24] <facundobatista> karni, thanks!
[22:24] <verterok> alecu: we use inotify, well pyinotify :)
[22:24] <verterok> alecu: oh, pynotify :p
[22:25] <karni> :) It's a real pleasure studying those sources.
[22:25] <alecu> verterok, yeah, not "i"
[22:25] <verterok> alecu: hehe
[22:25] <verterok> alecu: I have a question, are you going to make syncdaemon send UI notifications?
[22:25] <alecu> verterok, already did!
[22:26] <verterok> oh
[22:26] <alecu> verterok, https://code.launchpad.net/~alecu/ubuntuone-client/status-listener/+merge/46303
[22:26] <verterok> alecu: I assume it's inside ubuntuone/platform... right?
[22:26] <alecu> verterok, right
[22:27] <alecu> verterok, the aggregation logic will be platform independent, so mandel can make good use of it
[22:27] <alecu> verterok, but the actual showing of notifications will be platform dependent, and live there.
[22:28] <alecu> verterok, anyway, the only notified event for now is "file published/unpublished"
[22:28] <verterok> alecu: making syncdaemon contribute to the UI was avoided since ever :(
[22:28] <verterok> alecu: let me look at the code first :)
[22:28] <alecu> verterok, we have discussed exactly this feature with facundobatista this evening
[22:29] <alecu> verterok, and also, it will all live in a new separate listener
[22:29]  * karni is falling in love with Python
[22:29] <alecu> verterok, that way we can listen to *all* events without going thru dbus
[22:29] <alecu> verterok, and only use DBus after doing the aggregation (not there yet)
[22:30] <alecu> verterok, for instance, say SD finds 10000 new files
[22:30] <verterok> alecu: yes, I get it. but syncdaemon doing UI stuff... :(
[22:30] <verterok> alecu: anyway. it's there
[22:30] <alecu> verterok, by doing the aggregation in the listener, we can send thru DBus only one call to show a message saying "10000 new files are being uploaded"
[22:31] <verterok> alecu: but I'm missing something...wasn't zg going to be used for the notifications?
[22:31] <alecu> verterok, it seems you have not read the past few mails :-)
[22:31] <verterok> alecu: no, I've been head down in server stuff :)
[22:31] <karni> What is this url used for? platform/linux/dbus_interface.py :: PING_URL = "https://one.ubuntu.com/oauth/sso-finished-so-get-tokens/"
[22:32] <alecu> verterok, by querying zg we only get the info for the stuff that has already been done, but we have no way to measure what remains to be done. So we better do the aggregation in the listener.
[22:32] <verterok> alecu: the unity integration...etc mail?
[22:32] <alecu> verterok, exactly.
[22:32] <alecu> karni, it's used by u1ssoc
[22:33] <alecu> karni, ubuntu-single-sign-on-client
[22:33] <alecu> sorry, it's ussoc
[22:33] <karni> alecu: I see. But still, I might find it usefull writing SSO for Android. This url is pinged to check the tokens?
[22:34] <karni> no.. sorry. Looks like getting tokens.
[22:34] <verterok> alecu: yes, I see
[22:34] <karni> alecu: Ok, nvm now :) No need to bother you at the moment!
[22:34] <alecu> karni, when the user has finished registering his device with "Ubuntu Single Sign On", that url makes the "Ubuntu One" servers get those tokens from the "Ubuntu Single Sign On" servers.
[22:35] <alecu> karni, does it makes sense?
[22:35] <karni> alecu: yes it does :) thank you
[22:35] <alecu> karni, no problem. Let me know if you have trouble with that, because I used to work on it :-)
[22:36] <karni> alecu: Oh, good to know :) I've got the oauth in place, but will get back to it probably in Feb for more 'SSO' candy.
[22:36] <alecu> karni, cool
[22:36] <alecu> verterok, anyway: don't worry about SD doing UI stuff. We will only be doing DBus calls, and in a module that's optional and that can be turned off.
[22:36] <alecu> verterok, and SD is already doing DBus calls to get NetworkManager status.
[22:37] <verterok> alecu: I'm not worried
[22:37] <alecu> verterok, "don't be disgusted" :-)
[22:37] <verterok> alecu: :)
[22:37] <verterok> alecu: neither thatr
[22:38] <verterok> alecu: just puzzled about the mixup it's being added to it
[22:38] <verterok> :)
[22:39] <verterok> alecu: but np, if we have some performance problems, I know who to assing the bug ;) hehe
[22:39] <alecu> hahaha
[22:41] <verterok> alecu: :)
[22:52] <alecu> nessita, thisfred: care to do a trivial review? https://code.launchpad.net/~alecu/ubuntuone-client/fix-notification-parameters/+merge/46358
[22:53] <thisfred> no way
[22:54] <alecu> :-)
[22:54] <thisfred> I'm having niquiladas at the bar
[22:55] <nessita> alecu: sure!
[22:55] <nessita> giveme 2 secs that I owe some screenshots to mpt
[22:55] <alecu> nessita, thisfred: try running the syncdaemon in that branch, and publishing/unpublishing some file.
[22:56] <thisfred> oh I already approved it :)
[23:21] <dobey> well did a libubuntuone release anyway
[23:26] <thisfred> failed to build
[23:26] <thisfred> no nyquiladas for you!
[23:34] <dobey> nightlies failed, yes
[23:37] <dobey> le sigh
[23:51] <dobey> oh well
[23:51] <dobey> welcome to the end of the rally