[00:01] <duanedesign> hello PeDor
[00:02] <PeDor> duanedesign, hi
[07:07] <karni> good-early-evening everyone :)
[10:01] <JamesTait> Hey karni. :)
[10:28] <rye> hi, anybody wants to analyze your couchdb replication log?
[10:28] <rye> i.e. see how successful the replication was?
[10:30] <JamesTait> rye: Right now?
[10:31] <rye> JamesTait: there's a script for that now @ http://people.canonical.com/~roman.yepishev/us/ubuntuone-desktopcouch-diag.py :)
[10:32] <rye> since i am to tired of parsing the logs with those huge debug statements
[10:32] <JamesTait> rye: Wow, good work!
[10:32] <rye> JamesTait: just want to see whether it will work on some machines other than mine
[10:35] <JamesTait> rye: Looks useful. Much more readable!
[10:36] <rye> JamesTait: will soon be even more useful, but basically logs are no longer that black as in black box
[10:36] <JamesTait> rye: Is this the kind of output you're expecting? https://pastebin.canonical.com/40781/
[10:36]  * rye hates blackbox
[10:36] <rye> JamesTait: congratulations, you have all databases failing the sync
[10:36]  * JamesTait just noticed a typo in WARNING on line 90.
[10:37] <JamesTait> rye: Yep. :) I'm just looking to see if I have new dailies to update to
[10:37] <mandel> JamesTait: wow, I really hope that not all the users get those results, is that 0% all the time?
[10:37] <rye> JamesTait: ok, thanks, hm, WARING
[10:38]  * rye goes and adds grouping for bidirectional sync
[10:38] <JamesTait> mandel: Exactly that. :) That's the price I pay for being on the bleeding edge. ;)
[10:39] <mandel> JamesTait: haha, I've got the same, but I'm the bleeding edge on windows, which is not better :P
[10:39] <mandel> but it should next wee :)
[10:39] <mandel> k
[10:39] <JamesTait> mandel: But seeing it presented like that is a whole lot more readable than a bazillion tracebacks. :)
[10:40] <mandel> JamesTait: certainly,  we do have a lot of verbose stuff in there, I suppose it useful at times
[10:41] <JamesTait> mandel: Oh absolutely. We need it to try and figure out what's going wrong. But the output from rye's script is perfect for a quick "is everything OK?" check.
[10:41] <rye> you know, [ blah for blah in list if 'something' in list ] reminds me of postfix perl statements which were nearly banned by Perl Best Practices by Conway...
[10:46] <karni> JamesTait: hi James :)
[10:48]  * karni has finished lecture and is back on ubuntuone-files
[10:51] <JamesTait> karni: Hey, how's it going?
[10:51] <karni> JamesTait: quite busy with everything else then the project! so not so good. but I'm trying to sqeeze in more hours this week (including forthcoming weekend)
[10:52] <karni> JamesTait: all in all, I'm currently porting file upload/download to the new app version
[10:52] <JamesTait> karni: I know that feeling well - not enough hours in a day!
[10:52] <karni> JamesTait: but it already has a dashboard, and separate litss for '/Ubuntu One', UDFs and Shares
[10:52] <karni> JamesTait: totally. day should have at least 32 hours ;d
[10:53] <karni> JamesTait: there's college, but mostly there are many favours I do for friends/family and, thus, 'waste' time which slips thourgh my fingers
[10:54] <JamesTait> karni: http://dbeat.com/28/
[10:54] <karni> JamesTait: so I decided to give the project some momentum since it was in stall for at least 1,5 weeks
[10:54] <karni> JamesTait: I'm loving it!
[10:55] <karni> JamesTait: the only problem might be the college, but I'll see what I can do with that ;D
[10:55] <JamesTait> karni: Well that's your top priority right now, I'd say.
[10:56] <karni> JamesTait: it's kinda easy (at least before the exams ;P) and I seriously want to bring that project again into light :)
[10:56] <karni> rewrite takes some time, but it was definitely worth it! :)
[10:56] <JamesTait> karni: I'm in a similar situation - my spare-time project isn't getting the love it needs right now.
[10:57]  * karni nods
[10:58] <JamesTait> karni: I keep dabbling in other things, many of which have been on the back burner for a while. But I'm getting a hunger for it again now, so I think it might get a spark pretty soon.
[10:59] <karni> JamesTait: I'll keep my fingers crossed for that. I feel that such projects, self-derived, have in the end really awesome outcome
[10:59] <JamesTait> karni: Sure, because it's personal, a labour of love.
[10:59] <karni> exactly
[11:00] <JamesTait> karni: Just keep up the great work, doing what you can, when you can. :) It'll be worth it.
[11:02] <karni> JamesTait: thanks :) I hope you'll also find some time for your projects!
[11:02]  * karni jumps back into eclipse
[11:02] <JamesTait> And hopefully some sleep, somewhere along the way. ;)
[11:03] <karni> JamesTait: that's some serious issue ;D yesterday I wrote CardinalFang I'd push the source today and just dropped dead onto my bed haha
[11:04] <JamesTait> karni: It's a difficult balance to strike, sometimes. :)
[11:05]  * karni agrees :)
[11:29] <rye> JamesTait: could you please re-download script, re-run it and re-pastebin the output ?
[11:29] <JamesTait> rye: Certainly.
[11:29] <rye> JamesTait: thanks ^_^
[11:32] <JamesTait> rye: https://pastebin.canonical.com/40785/
[11:38] <rye> JamesTait: ok, nearly right. So, now to second phase, actually finding out why the replication did not work :)
[11:38] <rye> JamesTait: 28 attempts, 27 failed, 0 succeeded (0%)
[11:38] <rye> my math seems to be a bit off
[11:39] <rye> and i know why - this is an ongoing attempt to sync gwibber_accounts
[11:39] <JamesTait> rye: Also - 27 attempts, 28 failed, 0 succeeded (0%)
[11:40] <rye> JamesTait: hmmm, may I have your /home/jtait/.cache/desktop-couch/log/desktop-couch-replication.log pastebinned to as the ultimately broken replication example?
[11:40] <JamesTait> rye: You preempted my question. :)
[11:44] <JamesTait> rye: It is sanitised, right?
[11:44] <rye> JamesTait: well, you can e-mail it to me and I will say whether it is :)
[11:45] <JamesTait> rye: I can see lots of 'HiddenHidden' in things like token_secret, which suggests that it is.
[11:46] <JamesTait> rye: rye: https://pastebin.canonical.com/40786/
[11:48] <rye> JamesTait: you know, line 16416 is awesome, illegal database name for oldcontacts :-/
[11:49] <JamesTait> rye: Not sure why that is. It was my old contacts.couch copied over from my old machine. There's also u1contacts.couch which is a backup. :)
[12:05] <kazade> Hi guys, I've just updated my U1 client on Lucid using the stable ppa; how long roughly should this take:  "INFO - loading metadata from old version '4'" ?
[12:06]  * kazade remembers he has a ~10,000 file pictures folder in U1
[12:31] <kazade> ok, the ubuntuone syncdaemon is silently crashing :(
[12:32] <kazade> nothing in syncdaemon-exceptions.log, any help?
[12:33] <rye> ok, http://people.canonical.com/~roman.yepishev/us/ubuntuone-desktopcouch-diag.py is ready to be tested for log parsing. Issue detection is coming next
[12:33] <rye> kazade: hi, what ubuntu version are you running?
[12:33] <kazade> lucid + stable ppa
[12:33] <kazade> the log just says ""INFO - loading metadata from old version '4'"
[12:33] <kazade> but I can see from ps -elf | grep ubuntu that the syncdaemon is exiting
[12:34] <rye> kazade: okay, let's start it directly - /usr/lib/ubuntuone-client/ubuntuone-syncdaemon --debug ?
[12:35] <kazade> rye, just done that
[12:35] <kazade> it's printed "DEBUG: metadata version: 6" and then the loading metadata line from the log
[12:35] <kazade> it's sitting thinking about it atm
[12:37] <kazade> rye, it appears to be scanning directories
[12:39] <kazade> rye, it appears to be working now !
[12:40] <kazade> hmm, the daemon has stopped doing stuff. u1sdtool -s says that it's not connected
[12:40] <kazade> rye, should I try u1sdtool -c ?
[12:40] <rye> kazade: okay, i believe this is a result of my "fixing the bug"... http://askubuntu.com/questions/16286/
[12:43] <kazade> rye, yeah, looks the same. It seems to be working now, I ran u1sdtool -c and now it says it's processing queues
[12:43] <kazade> woah! and the log just turned into a stream of stuff :)
[12:47] <rye> kazade: well, yes. you may want to disconnect, ctrl+c syncdaemn then connect with background process
[12:49] <kazade> rye, yeah, that was my next question :)
[12:49] <kazade> thanks for your help rye
[13:38] <gord> hey, i'm not getting an album i paid for on the music store, just sits there forever in "transferring to your ubuntu one storage" - bought last night
[13:38] <beuno> gord, has it appeared in the web ui yet?
[13:39] <gord> beuno, yup
[13:41] <beuno> gord, then it's a problem with syncing files to your desktop
[13:41] <beuno> can you run a quick: u1sdtools -s
[13:41] <beuno> see what it says
[13:42] <gord> beuno, http://paste.ubuntu.com/541872/
[13:43] <beuno> hm
[13:43] <beuno> it looks fine
[13:43] <beuno> gord, and you're sure you don't see the files in rhythmbox?
[13:43] <beuno> or, rather, in ~/.ubuntuone/Purchased from Ubuntu One/*
[13:44] <beuno> if not, try desconnecting and reconnecting:  u1sdtools -q && u1sdtools -c
[13:44] <gord> yup, doesn't show up in rb or banshee and the files aren't in that folder
[13:44] <beuno> you can also install "magicicada"
[13:44] <beuno> which will tell you what u1 is doing
[13:48] <gord> beuno, nope, it just goes back to IDLE - it did upload a file i have been waiting for it to sync for a while though. but after that went back to idle
[13:49]  * beuno blinks
[13:49] <beuno> rye, this one's for you
[13:51] <gord> i am on natty, if you guys have dropped any crazy code into natty ;)
[13:53] <beuno> we probably have
[13:53] <beuno> but, it shouldn't arbitrarily sync down certain files and not others
[13:53]  * beuno nudges ChrisWoollard 
[13:53] <beuno> er
[13:53] <beuno> Chipaca, ^
[13:54] <beuno> (sorry ChrisWoollard)
[13:54]  * Chipaca nudges beuno back
[13:54] <Chipaca> what's up?
[13:54] <beuno> Chipaca, gord needs some client love
[13:54]  * Chipaca reads
[13:55] <Chipaca> gord: have you looked to see if it's on the web yet?
[13:55] <gord> Chipaca, yup, its there
[13:55] <Chipaca> hmmm
[13:56] <Chipaca> gord: is this your first album?
[13:56] <gord> Chipaca, nope
[13:57] <Chipaca> ok
[13:57] <Chipaca> gord: first, let's enable debug
[13:57] <Chipaca> gord: do you have a ~/.config/ubuntuone/syncdaemon.conf ?
[13:58] <gord> i do
[13:58] <mandel> nessita: stand up?
[13:58] <Chipaca> gord: could you ensure it has debug=True in the [__main__] section?
[13:59] <gord> Chipaca, okay done
[13:59] <nessita> mandel: yes, 2 minutes for it
[13:59] <mandel> nessita: ok
[14:00] <Chipaca> gord: ok, now killall ubuntuone-syncdaemon; mv ~/.cache/ubuntuone/log ~/.cache/ubuntuone/log.old; u1sdtool -c
[14:00] <nessita> me
[14:00] <mandel> me
[14:00] <nessita> alecu, thisfred, ralsina?
[14:00] <thisfred> me
[14:00] <ralsina> me
[14:00] <nessita> d-obey is on holidays
[14:01] <alecu> me
[14:01] <nessita> nessita: go!
[14:01] <nessita> DONE: conf call re: control panel, weekly meeting, proposed branch for bug #673670 and for bug #683649, proposed branch for bug #686606 (which required proposing https://code.launchpad.net/~nataliabidart/ubuntuone-dev-tools/check-exception/+merge/43292 )
[14:01] <nessita> TODO: syncdaemon autoconnect (create bug and code the solution!)
[14:01] <nessita> BLOCKED: nopes
[14:01] <nessita> NEXT: mandel
[14:01] <mandel> DONE: Look at the unmanaged heap arch in .Net to understand where possible memory link might occur. Implemented the IPC .Net side.
[14:01] <ubot4> Launchpad bug 673670 in ubuntuone-control-panel (Ubuntu) (and 1 other project) "Contact syncdaemon dbus service from backend (affects: 1) (dups: 1) (heat: 12)" [High,Triaged] https://launchpad.net/bugs/673670
[14:01] <ubot4> Launchpad bug 683649 in ubuntuone-control-panel "Management panel twins itself when CredentialsFound is received (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/683649
[14:01] <ubot4> Launchpad bug 686606 in ubuntu-sso-client "Use ubuntuone-dev-tools (affects: 1) (heat: 63)" [Medium,Confirmed] https://launchpad.net/bugs/686606
[14:01] <mandel> TODO: Work on the python side of the IPC. Client a general ICP client in Python so that it can be used by the UI.
[14:01] <mandel> BLOCKED: no
[14:02]  * mandel looks at his favorite dutch man, thisfred
[14:02] <thisfred> DONE: bindwood testing, thinking and investigation TODO: bindwood BLOCKED: no
[14:02] <thisfred> alecu: yo!
[14:02] <alecu> DONE: worked on Client to Server File Synchronization events (bug #674252). Control panel conf, weekly conf
[14:02] <alecu> TODO: finish zg
[14:02] <alecu> BLOCKED: no
[14:02] <alecu> eom?
[14:02] <ubot4> Launchpad bug 674252 in ubuntuone-client (Ubuntu) (and 1 other project) "Syncdaemon needs to store events into zeitgeist (affects: 1) (heat: 173)" [High,In progress] https://launchpad.net/bugs/674252
[14:02] <thisfred> oops sry
[14:02] <thisfred> ralsina: you!
[14:02] <nessita> thisfred: you're ignoring the boss!!!
[14:03] <ralsina> DONE: desktop conference call, discussed design assignments, reading code like a madman, bought notebook
[14:03] <thisfred> yeah, that's not a good idea ;)
[14:03] <ralsina> TODO: get the notebook ;-) understand said code
[14:03] <gord> Chipaca, u1sdtool died when doing that " Failure: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply." - had to do it again to get it to connect weirdly
[14:03] <ralsina> BLOCKED: no
[14:03]  * ralsina is goint to take measures
[14:03] <nessita> any closing comments?
[14:03] <Chipaca> gord: known issue; that's not u1sdtool dying but dbus timing out (but it worked, mostly)
[14:03] <ralsina> If anyone needs a designer, tell me
[14:03] <Chipaca> ralsina: I need a ux designer
[14:04] <nessita> ralsina: clothes designer?
[14:04] <ralsina> Chipaca: we all do
[14:04] <alecu> mandel, what's "unmanaged heap arch in .Net" ?
[14:04] <ralsina> Chipaca: just making sure we didn't miss any needed UX and stuff yesterday :-)
[14:05] <mandel> alecu, you can make COM object be able to use .Net object, that is placed in a special heap in the .Net runtime that gets ignored by the GC so that COM can take ownership of the memory management
[14:05] <ralsina> chipaca: we need to know how many asif clones to request at the factory
[14:05] <mandel> alecu: so, possibly memory leaks :P
[14:05] <alecu> mandel, ohhh...
[14:05] <ralsina> mandel: actually, that is guaranteed to be a leak. But if you do it on purpose you call it "manual memory management"
[14:06] <gord> Chipaca, went back to IDLE again, is there anything in particular you want to see from the log file? not comfortable with putting the entire thing on a public pastebin
[14:06] <mandel> alecu: the idea is simple, create IPC using WCF in .Net, make that COM visible so that pywin32 can instantiate it, then pass the python COM object that knows how to talk with sync daemon (and that was wrapped by COM) to the service to do the work, that ay .Net does the IPC, my COM object does the logi
[14:07] <Chipaca> gord: no, don't pastebin it; if this works like i think it'll work, i'll ask you to file a private bug with the logfile if that's ok
[14:07] <mandel> ralsina: yes, hehe although I'm hoping tat pywin32 is smart enough to use the python gc/ref count, although better save than sorry, so I wanted to make sure of how it works
[14:07] <Chipaca> gord: private bugs are only seen by you and us
[14:08] <gord> Chipaca, attachments on private bugs are public, have had this problem myself in the past :)
[14:08] <Chipaca> gord: now, is this an album that is not downloading, or just a song in an album?
[14:08] <gord> Chipaca, entire album
[14:08] <Chipaca> gord: ouch. really?
[14:08] <alecu> mandel, nice. Sounds reasonable.
[14:09] <mandel> alecu: the tests so far have worked.. but they were small, now I'm moving to the real thing, it is preaty cool to use WCF from python, a bit hacky, yet cool
[14:09] <Chipaca> gord: ok, do: touch "$HOME/.ubuntuone/Purchased from Ubuntu One/xyzzy"
[14:09] <mandel> well, I need to get back to the windows vm, ping me if you need me, but make sure is async
[14:09] <alecu> mandel, cool in a "I can't believe this is working!" way?
[14:10] <gord> Chipaca, o_O okay that fixed everything
[14:10] <gord> files coming through now
[14:10] <mandel> alecu: yes, hehe, is the kind of idea one has in the shower and needs to run half naked to grab a notebook to write it down
[14:10] <mandel> not that it happened that way :P
[14:11] <Chipaca> gord: figured
[14:12] <Chipaca> __lucio__: we still have that issue (in natty) where we sometimes need to nudge a directory listing for it to refresh
[14:12] <Chipaca> __lucio__: gord just had to touch a file in the music folder for his new album to download
[14:12] <__lucio__> Chipaca, logs please
[14:12] <Chipaca> __lucio__: he has a logfile, but he (understandably) doesn't want it public
[14:13] <Chipaca> __lucio__: and it seems attachments on private bugs are public?
[14:13] <__lucio__> Chipaca, email?
[14:13] <gord> email would be fine
[14:14] <Chipaca> gord: email john.lenton@canonical.com (me) and lucio.torre@canonical.com (__lucio__), if possible. Also, please compress the whole log directory and send that, rather than individual files (which will be big)
[14:16] <nessita> eom and reboot!
[14:18] <Chipaca> gord: I'm told there is now a private librarian that is used for private bugs; want to try that?
[14:18] <Chipaca> gord: ("no" is a completely reasonable and understandable answer, there)
[14:19] <gord> Chipaca, i'll test that with some less private data sometime ;) emails sent btw
[14:20] <Chipaca> gord: you might've not attached the attachment
[14:20] <gord> Chipaca, am smart i am
[14:21] <Chipaca> gord: had you mentioned "attachment" in the email body, evolution would've told you :)
[14:21] <gord> should file a bug against evolution "not psychic enough"
[14:23] <__lucio__> gord, whats the name of the file you touched?
[14:24] <gord> __lucio__, <Chipaca> gord: ok, do: touch "$HOME/.ubuntuone/Purchased from Ubuntu One/xyzzy"
[14:25] <Chipaca> __lucio__: clearly, magic files are called `xyzzy`
[14:30] <__lucio__> gord, how long before touching xyzzy did you purchase the songs?
[14:31] <gord> __lucio__, yesterday evening, so around 14 hours or so
[14:32] <__lucio__> gord, can you try: $ u1sdtool --list-folders, please?
[14:34] <gord> __lucio__, http://paste.ubuntu.com/541888/
[14:35] <__lucio__> gord, please, $ apt-cache policy ubuntuone-client
[14:36] <gord> __lucio__, 1.5.0-0ubuntu2 (assuming thats what you are after)
[14:38] <__lucio__> thanks
[14:45] <nessita> alecu: would you be able to review my brach today? ralsina gave it a code review, but I would also need a fieldtest and to check that the MVC design you started is maintained
[14:45] <alecu> nessita, yup, I'll do it right away while running tests.
[14:46] <nessita> awesome!
[14:46] <alecu> nessita, add-file-sync-status ?
[14:47] <nessita> yes
[14:47] <joshuahoover> alecu: how is the zeitgeist work going?
[14:48] <alecu> hi joshuahoover: it's coming along nicely. I'm trying to finish it today, and bugfix next week while working on bindwood.
[14:49] <joshuahoover> alecu: ok, so will it be ready for packaging next week?
[14:49] <alecu> joshuahoover, yes!
[14:50] <joshuahoover> alecu: cool, thanks! :)
[14:53] <alecu> nessita, why do you have a _status_changed_handler and a status_changed_handler?
[14:54] <alecu> nessita, there's no need for 's in "custom's"
[14:56] <__lucio__> Chipaca, gord: fixed in trunk. https://bugs.launchpad.net/ubuntuone-client/+bug/684408
[14:56] <ubot4> Launchpad bug 684408 in ubuntuone-client "Syncdaemon deleted all my user defined volumes (locally, at metadata level) (affects: 1) (heat: 8)" [Critical,Fix committed]
[14:57] <nessita> alecu: re: the handlers: one is private and the other is a public attibute with custom setter and getter
[14:57] <nessita> alecu: maybe I can improve that? I wasn't sure if I need the _... variable
[14:58] <nessita> alecu: fixing the custom's
[14:58] <alecu> nessita, I find that having both named almost equally is confusing
[14:59] <nessita> alecu: I think is standard naming convention when using property()
[14:59] <nessita> I took it from python doc...
[15:02] <nessita> alecu: custom's typo fixed
[15:10] <alecu> nessita, what's the reason you choose to make a signal per status instead of one signal with a "status" parameter?
[15:11] <nessita> alecu: that was another option, yes. But I'm trying to provide a high abstraction layer, and I think that one signal per status is higher level that passing a string that the caller needs to compare with a fixed set of strings
[15:11] <alecu> nessita, the handler of "status changed" usually wants to find out about *all* status changes anyway.
[15:12] <nessita> that kind of handlers can directly hook to StatusChanged in syncdaemon, I think
[15:12] <Chipaca> gord: what version of ubuntuone-client do you have?
[15:12] <Chipaca> gord: (apt-cache policy ubuntuone-client)
[15:12] <beuno> Chipaca, 1.5.0-0ubuntu2
[15:12] <beuno> that's what he said
[15:12] <nessita> alecu: also, from my POV, using dedicated signals improved the ability to expand the interface without breaking existing clients, let me expand on this
[15:13] <Chipaca> beuno: ah, tks
[15:13] <nessita> alecu: some client my compare the string inside the signal with a list of possible values and fail if the value is not on that list
[15:13] <nessita> alecu: so if we later add a new status, we may break clients (yes, is a client side bug, since they shouldn't fail)
[15:14] <ralsina> nessita alecu: is that an API that other app developers will use eventually?
[15:14] <alecu> nessita, hmmm... but the cost of making this is a lot more code both on the server and on the client
[15:14] <nessita> ralsina: ideally, yes. Is a dbus api
[15:15] <nessita> alecu: you think? I prefer this approach that checking string values
[15:15] <nessita> is cleaner and less error prone
[15:15] <ralsina> multiple signals is cleaner API
[15:15] <nessita> it may a be a bit more of coding, but it scales better (regarding quality, not amount of code)
[15:16] <ralsina> But that's just personal taste. And the extra code is simple, right?
[15:16] <nessita> ralsina: very, it could be metaprogrammed, but I decided to leave the black magic out of the source code
[15:16] <nessita> (this time at least :-P)
[15:16] <ralsina> hahaha, good choice (for now ;-)
[15:18] <ralsina> Besides, multiple signals means you can add extra signals without 3rd parties having to change their handlers. And you can deprecate and explain in the doc of the signal, instead of in the description of a string parameter.
[15:19] <nessita> exactly my point :-)
[15:23] <alecu> hmmm
[15:23] <ralsina> Basically: imagine the docstring in each case and decide :-)
[15:23] <alecu> that sounds fine for multiple unrelated signals
[15:24] <alecu> but I don't like it for related states
[15:24] <alecu> let's say we add a new state (with the corresponding signals, and all)
[15:24] <alecu> and an old client does not know about the new state
[15:25] <alecu> the old client will never find out that the state has changed (to a state it does not know!)
[15:25] <ralsina> alecu: depending on how the client handles the string parameter he will either:
[15:25] <alecu> if we use the Enum based way, the old client at least has a chance to show "status: unkown"
[15:25] <ralsina> 1) not know
[15:25] <ralsina> 2) crash
[15:25] <ralsina> 3) fail with a cryptic message
[15:25] <nessita> alecu: right, and I think that is correct. The old client maintainer should keep an eye on updates from our dbus api
[15:26] <ralsina> Or MAYBE give an error that someday will reach the developer :-)
[15:26] <Chipaca> are dbus signals hierarchical?
[15:26] <alecu> Chipaca, no
[15:26] <ralsina> Adding extra values to that enum *is* changing API. If you put it in signals you can't cheat yourself.
[15:27] <Chipaca> rats :)
[15:27] <nessita> alecu: one thing to note is that this set of states are related because we're putting glue within u1cp to make them related (which is good). For example, disabled information is got from a different source than the rest
[15:27] <alecu> nessita, that is good, absolutely agree.
[15:27] <nessita> so when you say a set of "related" signals... is not like the info comes from the same place
[15:28] <nessita> we're providing the abstraction layer
[15:28] <nessita> so I don't see a gain on reducing that abstraction by passing a string
[15:28] <alecu> nessita, right. But let's look from the client pov
[15:28] <alecu> nessita, the client does not care were we got those states from.
[15:28] <alecu> it just cares that the state it has access to has changed.
[15:29] <nessita> yes, but (big but!):
[15:29] <alecu> nessita, why "reducing that abstraction" ?
[15:29] <nessita> nopes, another scenario in favor of multiple signals: we may be adding finer status changes
[15:30] <nessita> a client would be abligated to receive every single state change
[15:30] <nessita> as many as we think we wanna track
[15:30] <nessita> and if a client wants to filter events, it will be forced to receive all and filter on his end
[15:31] <nessita> suppose a client wants to know only disconnected-synching
[15:31] <nessita> with this coding, he can connect to 2 signals and receive the info he wants
[15:31] <nessita> if we pass strings, and dedice for example propagate the queues changes, this client will be flood
[15:31] <nessita> flooded*
[15:32] <nessita> and siganls emission and processing is not super cheap
[15:32] <nessita> imagine if this client also logs all the string that he ignored
[15:33] <nessita> alecu, Chipaca, ralsina: we can evaluate adding an extra signal that propagates every state change using a string
[15:33] <nessita> specially, we can tackle this for the ubuntuone developer api task
[15:34] <alecu> nessita, agree on the "signals emission and processing is not super cheap"
[15:34] <ralsina> nessita: why not
[15:35] <nessita> but I'd keep the current schema of specialized signals
[15:35] <ralsina> nessita: I was going to suggest it but was afraid I would look like I was trying to make both of you happy ;-)
[15:35] <alecu> nessita, ok, I'll approve it like this, but since this will be a public API let's invite the developers of apps that will use this to discuss the API.
[15:35] <alecu> nessita, that would be the magicicada developers and rye :-)
[15:35] <ralsina> alecu: good idea
[15:35] <nessita> alecu: +1
[15:36] <ralsina> I would like to be there. I have a secret project that will use that API eventually ;-)
[15:36] <nessita> alecu: I can give some hints from magicicada POV: having tons of "if" in a handler is bad, it complicates the testing and the coding
[15:36] <alecu> ralsina, let me guess.... kubuntuone-control-panel?
[15:36] <nessita> OH YES
[15:36] <ralsina> nahhh
[15:36] <nessita> UFA
[15:36] <nessita> :-)
[15:36] <ralsina> I don't believe in s/g/k/ projects
[15:37] <alecu> :-)
[15:37]  * ralsina is too old to start copying gnome apps now
[15:37] <ralsina> nessita: say that like this "the string parameter increases the cyclomatic complexity f the handler beyond acceptable parameters"
[15:38] <ralsina> Noone argues when you say "too many ifs" that way
[15:38]  * nessita copy and pastes to her cool answers list
[15:38] <nessita> alecu: in magicicada, the string parameter increases the cyclomatic complexity f the handler beyond acceptable parameters
[15:38] <nessita> so, please, dedicated signals :-D
[15:39] <nessita> ralsina: I should fix your typo at least...
[15:39] <ralsina> yes, cover your tracks, lady
[15:39] <ralsina> you can even make pymetrics complain of that
[15:40]  * alecu brbs
[15:41] <nessita> alecu: anyway, thanks for the review!!!
[15:41] <nessita> and for the discussion, it was very good to think about this further
[15:49] <alecu> nessita, you're welcome! thanks for the code :-)
[15:49] <alecu> nessita, oh, and one more thing....
[15:49] <nessita> shoot
[15:49] <alecu> nessita, why do you make status_changed_handler a property?
[15:50] <alecu> nessita, just so it can be logged when it changes?
[15:50] <nessita> alecu: nopes, so we ensure we connect it to the lower layer when it changes
[15:51] <alecu> nessita, ok, fine.
[15:52] <alecu> nessita, I'm approving. I've run the tests, I've looked at the code, but didn't got around to testing it all "fo' real"
[15:52] <nessita> no problem
[15:52] <nessita> I did it, and in the next version I'll add rye to do so
[15:52] <nessita> he's awesome at finding bugs :-)
[15:53] <alecu> nessita, :-)
[15:53] <alecu> nessita, Approved. I'm letting you change the merge status, as we are supposed to do now, right?
[15:54] <nessita> alecu: are we? did I miss an email?
[15:55] <alecu> nessita, I think it was discussed when talking about tarmac automerging
[15:55] <alecu> nessita, not sure if by mail or irc
[15:55] <nessita> alecu: I wasn't aware of that, so maybe it was irc and I wasn't around?
[15:56] <alecu> nessita, the thing is that if code is added after switching the status on the branch tarmac (or otto, don't know) will complain
[15:57] <nessita> ah... right
[15:57] <nessita> alecu: works for me, thanks
[15:58]  * ralsina furiously dives into the pile of wikis and docs to find what the heck tarmac and otto are (ok, tarmac<=>landing makes sense)
[15:58] <alecu> ralsina, otto = ubuntuone-auto-pilot
[15:58] <alecu> https://launchpad.net/~otto-pilot
[15:59]  * ralsina immediately curses at the very concept of puns
[15:59] <ralsina> but ok, now it all makes sense again
[17:00] <SN4K3> ubuntu one using terminal?
[17:04] <facundobatista> SN4K3, sorry, what?
[17:14] <duanedesign> hello all
[17:15] <rye> duanedesign: moar scripts
[17:15] <rye> duanedesign: http://people.canonical.com/~roman.yepishev/us/ubuntuone-desktopcouch-admin.py
[17:15] <rye> duanedesign: http://people.canonical.com/~roman.yepishev/us/ubuntuone-desktopcouch-diag.py
[17:16] <duanedesign> awesome
[17:16] <rye> duanedesign: admin does listing, adding/removing databases and enabling,disabling replication
[17:16] <rye> duanedesign: diag attempts to parse couchdb logs and suggest something
[17:17] <facundobatista> Hola duanedesign
[18:24] <SpamapS> rmcbride: cassandra 0.7.0~rc2 uploading to PPA shortly.
[18:25] <rmcbride> SpamapS: awesome!
[18:26] <SpamapS> rmcbride: looks like there may be one more package we have to backport to lucid btw .. jna needs to be >= 3.2.7
[18:27] <SpamapS> rmcbride: its installed but not used because I accidentally left in in debian/jars
[18:27] <rmcbride> SpamapS: Cool. Thanks for the heads up. I'll add that to my notes.
[18:31] <rmcbride> SpamapS: is that as in libjna-java? I may need to backport to maverick as well for some of our dev environments, since that's currently 3.2.4-2
[18:32]  * rmcbride looks in debian/control to answer his own question :)
[18:32] <SpamapS> rmcbride: yeah
[18:37] <rmcbride> SpamapS: Seems to be the same version in natty and in debian unstable. we're needing a newer version than that?
[18:44] <SpamapS> rmcbride: no, we just need to backport 3.2.7 to lucid and/or maverick
[18:44] <SpamapS> rmcbride: I'm sure it will be a no source change backport
[18:45] <rmcbride> SpamapS: what I was getting at is I don't see 3.2.7 of libjna-java in natty or anywhere else.
[18:45] <rmcbride> just 3.2.4-2
[18:46] <SpamapS> oh
[18:46] <SpamapS> Right, I thought it was in unstable
[18:46] <SpamapS> and natty
[18:46] <rmcbride> doesn't appear to be in unstable either, unless my chdist is completely broken
[18:46] <SpamapS> ok, so yeah we'll just have to leave it in jars for the short term
[18:47] <rmcbride> OK. I'll note that and keep an eye out
[18:47] <SpamapS> getting test failures on rc2
[18:47] <rmcbride> d'oh
[20:11] <rye-mobile> to anybody using ubuntu one contacts on android 2.2- are you able to edit email addresses there?
[20:15]  * alecu lusts for a Nexus S
[20:15] <alecu> but no android around, sorry.
[20:22] <ralsina> alecu: you can run android in a VM: android-x86.org at least to test these apps
[20:49] <alecu> nice!
[20:49]  * alecu bookmarks android-x86.org
[21:07] <rye-mobile> i guess that's another acer "feature"
[23:06] <karni> recognize, recognize. /me left a party early to code more of ubuntuone-android-files :O .. sometimes I still suprize myself.
[23:08] <rye> karni: what android phone do you have?
[23:08] <karni> rye: HTC Hero
[23:09] <rye> karni: does it allow provider selection for contacts editing?
[23:10] <karni> rye: if you mean does it ask where I want to save my contacts (default contacts / ubuntuone contacts), then yes
[23:10] <karni> the option justlike that, I'd have to check
[23:10]  * karni looks into it
[23:10] <rye> karni: i mean when you edit the contacts, in case you have funambol/ubuntuone contacts installed, whether it prompts what provider to use for editing
[23:11] <karni> rye: I must admit I don't have the app installed at the moment. would you like me to check that out for you :)?
[23:12] <rye> karni: no, that's not critical at all
[23:12] <rye> karni: sorry for interrupting
[23:12] <karni> I didn't like that U1 Contacts overtook some default contacts handling behaviour
[23:12] <karni> rye: no, not at all. it'd take me 2 minutes, I can definitely check if you want
[23:13]  * karni installs app
[23:15] <karni> rye: first notice -- I installed the app. without opening it, I went to 'Contacts book' and edited one person. the default edit screen shows up and at that moment U1 contacts fires up with login screen. now that's what I didn't like, now I remember. U1 contacts overrode default 'edit contact' activity.
[23:16] <karni> I'll investigate further
[23:16]  * karni logs in
[23:17] <karni> rye: having initially selected no contacts to sync with U1 contacts, I can use the default 'edit contact' activity
[23:17] <karni> now i'll setup some contacts sync
[23:18] <rye> karni: activity, right, not provider (me is android noob)
[23:18] <karni> can't enter Menu -> Settings. it tell's me it's syncing, although there's no sync icon
[23:20] <karni> rye: can't go to settings activity. tells me sync is running (but it doesn't look like so)
[23:20] <karni> rye: tried killing the app, didn't help
[23:21] <karni> probably not selecting any contact types at the very beginning was a bad idea
[23:22]  * karni reinstalls
[23:29] <karni> rye: so it was about importing stuff to sync. ok, now I see sync icon
[23:30] <karni> rye: if I want to edit a contact that is being synced with U1C, I get a dialog:
[23:30] <karni> "Edict contact under account"
[23:30] <karni> - Ubuntu One Contacts
[23:30] <karni> - Other
[23:30] <karni> where Other is the default 'edit contact' activity
[23:31]  * karni doesn't like the U1C edit contact activity looks
[23:48] <rye> karni: ok, marking htc hero as funambol-friendly
[23:53] <JamesTait> rye: HTC Desire is the same.