=== barlas_ is now known as barlas [10:37] hello [10:37] My ubuntu One doesn't seem to work [10:37] is this a canonical product? [10:37] I put files in the folder [10:37] but they don't appear on the web [10:42] Hello ?? === rodrigo_1 is now known as rodrigo_ [11:50] Heyho, just wanted to ask if there is a way to make my documents folder the default syncing folder? [11:50] fummy, not at the moment [11:51] damn, thanks anyway [11:51] fummy, such possibility is being evaluated at the moment, but currently only ~/Ubuntu One folder get synced [11:51] Can't you remove the documents folder and link it to ~/Ubuntu One? [11:52] ill give it a try [11:55] to easy :) [11:55] thanks alot [11:55] NPs. [11:57] cya [13:36] Moin. === rmcbride changed the topic of #ubuntuone to: Have a question? Ping rmcbride | Updated client software is now available to everyone running Ubuntu 9.10. Please run Update Manager to install it, and then restart the client. Enjoy 9.10! | https://one.ubuntu.com | https://launchpad.net/ubuntuone | Current Testing Client Revno is 276, Protocol Revno is 73 [14:59] Desktop+ MEETING BEGINS. Say 'me' to claim a slice of the stand-up meeting, then take your turn by saying DONE/TODO/BLOCKED. [15:00] me [15:00] me [15:00] me [15:01] me [15:03] me [15:03] vds, urbanape? [15:04] me [15:04] teknico? [15:04] Maybe u will catch up. teknico, start 'er up. [15:04] shall I go? [15:04] DONE: planned the new work on funambol phone sync with Chipaca and vds; defined personal and national holidays for the next two months in canonicaladmin.com; started investigating SMS integration for phone sync with vds (story-0015, #399646) [15:04] TODO: continue SMS integration for phone sync (story-0015, #399646) [15:04] BLOCK: none [15:04] next: CardinalFang [15:04] ah, teknico was first :) [15:05] DONE: desktopcouch execution context added as parameters (three days of work), so complex testing will be possible soon. [15:05] TODO: Figure out Bug#481806, processing files exist. Refactor replication and add testing. [15:05] BLOCKED: None [15:05] jblount, catch! [15:05] DONE: FACE duty! [15:05] TODO: Review day, sort missing images in 9.04 install instructions, sort through recentish bugs to figure out what branches I can get done the week before UDS is over, figure out what I want to do for the next 6 months [15:05] BLOCKED: Nope [15:05] Chipaca_: you! [15:05] DONE: started people working on neglected aspects of u1. finally getting enough estimates to do some planning (still missing some from dobey, urbanape). Finally got my eyes on the U1 client app spec. [15:05] TODO: hunt down the "indicator-applet-session" api. take the afternoon off to spend with my family, pack, and rest before my trip. [15:05] BLOCKED: negative [15:05] NEXT: rodrigo_ [15:05] • DONE: More evo-couchdb bug fixing. Started looking at unterminated strings problem in notes API [15:05] • TODO: Talk to Ara about writing mago tests for evo-couchdb. Conflict resolver tool in pair tool. Look at becoming a MOTU (https://wiki.ubuntu.com/UbuntuDevelopers). openSUSE/Fedora packaging with aquarius. API documentation for couchdb-glib. Make sandy's snowy test suite work with our server (http://git.gnome.org/cgit/snowy/tree/api/tests.py). Discuss with jdo and aquarius about oauth token per app, not per machine? Push evo-couchdb [15:05] • BLOCKED: no [15:05] next: vds [15:06] DONE: Exploring full sms integration with teknico #399646 [15:06] TODO: code review [15:06] BLOCKED: nope [15:06] [15:06] I guess urbanape can report when is back... [15:06] Thanks, all. [15:08] CardinalFang: Thanks [15:10] CardinalFang: yes, thanks [15:15] me: DONE: Sprinting, made some good progress on the U1 web UI and got us on latest Lazr-JS and YUI 3.0.0 final, TODO: More sprinting, get our buildout composing lazr-js rather than having it inline in the source, BLOCK: None [15:16] soz, folks [15:18] urbanape: No worries, statik says sprinting gets you out of stand ups :) [15:18] don't mind poking back in. that's the magic of this here innertubes [16:04] Hi all, I just started syncing my notes with Tomboy, and I wanted to know: is there any way to share notes with others? [16:05] Mainly I have a notebook I would like to make "public" [16:06] krisives: Not yet, but we've been thinking about it. Would you mind describing how you would like to use a feature like this? [16:06] Sure. I originally just went to link someone to my notebook like this: [16:06] https://one.ubuntu.com/notes/edit/62f624ef-1bf9-4f8c-bd1f-8b82e59564f7 [16:06] But of course they couldn't view it [16:07] Interesting. Thanks for the details! [16:07] I like what is coming out of UbuntuOne so far, but I would love to get involved with the front-end part of it. I've been making rich applications using YUI for a while now, and I think it could be pretty neat [16:07] Is there an API ? [16:08] krisives: There is an API for the storage protocol, I don't think we've got anything public that you can use (like json or whatevs) yet. [16:09] I have a Rhythmbox plugin I have been working on for a while that lets users create a transparent layer of re-tagging their files, so they don't have to actually modify their ID3 tags or anything, and I would love to use UbuntuOne for that [16:09] krisives: That's really interesting. Are you thinking of storing in the users desktopcouch so they could have it available on other machines / on the web? [16:10] Well, the trick with this plugin / source that I made is that it's actually Open Source and Free [16:10] The audio indexing algorithm isn't on some third party private server [16:10] It runs on your desktop [16:11] krisives: Sure, what I meant to say was "How would using would you be using Ubuntu One" [16:11] What I'm mainly looking to store is tagging and meta information about media files [16:12] I'm not interested in storing any binary data, like media files/content [16:12] krisives: you'll likely be interested in desktop couch [16:13] krisives: examples of how we're using it can be found in tomboy notes, evolution contacts, and firefox bookmarks [16:15] Is that by using ~/UbuntuOne? [16:15] Here is an example of how my plugin works btw [16:16] If you had the plugin enabled and went to change some tagging information it would store the new tagging information in the cloud/database instead of modifying the ID3 tags at all [16:17] The goal here is so that you can acquire music from any sources and keep them rather unorganized, but still have a tagged collection. [16:17] krisives: no, ~/Ubuntu One is used by file sharing only, desktopcouch uses couchdb to store structured documents [16:17] I think I've heard of couchdb, isn't that Berkley ? [16:18] krisives: so, as joshuahoover pointed out, desktopcouch fits for your usecase [16:18] Sorry, I get it [16:18] krisives: no, http://couchdb.apache.org/ [16:18] verterok: ty [16:18] Are there Python bindings for desktop couch ? [16:19] krisives: yeas, https://edge.launchpad.net/desktopcouch [16:19] Thanks [16:19] https://launchpad.net/desktopcouch [16:20] y'r welcome :) [16:20] Are there docs ? [16:20] krisives: what kind of docs? [16:20] Python docs for it's "API" [16:21] krisives: good question, I don't know... [16:21] joshuahoover: ^ ? [16:21] I'll branch it and check it out [16:22] pydoc desktopcouch gives me some stuff [16:23] krisives: we're working on it...we spent most of our time prepping things for release and had to neglect the developer support side of things...now we're going to focus on building out things like the docs, how-to's, good examples, etc....i'm putting together a wiki page today with what we have so far...it'll be at http://wiki.ubuntu.com/UbuntuOne/Developers [16:23] I have been documenting Compiz for the last few weeks, if you guys want help with docs I'd love to help out :) [16:23] I'd rather look at Python code than C++ (Compiz switched to C++ from C thankfully recently) [16:26] krisives: That sounds great, it's something we could really use help with right now. [16:27] Do you guys use LP primarily? [16:27] Compiz uses git :( [16:27] Everytime I complain I get sent to: http://whygitisbetterthanx.com/ [16:27] krisives: Yeah, LP and bzr and awesome. [16:28] So if I branch the desktopcouch code as I decipher it and doc it we can handle a merge ok later ? [16:28] Yeah, we use LP's review process, shouldn't be a problem. [16:29] * krisives praises LP [16:29] I'm working on a plugin system based on Bazaar right now ;) [16:29] For a web application kinda like how WordPress does it [16:29] Also seems nobody has decent PHP bindings for Bazaar, so I'm making those too :( [16:34] * jblount is pretty sure most of the LP hackers avoid PHP at most costs [16:42] krisives: the only thing I know about PHP <-> bzr is xmloutput [16:42] I've just been making bindings that talk to `bzr` using stuff like `bzr log`, etc. [16:49] hello--my u1 client is configured to connect automatically on start, but it doesn't seem to do so--the menubar icon shows a red X unless I click it and choose Connect [16:49] if I update a file in the Ubuntu One directory, I get a notification saying u1 is updating my files, but it doesn't actually make it onto the server, as seen thru the web UI [16:50] what do I have to do to get it to actually connect at startup? [16:50] rmcbride: around? ^^ [16:55] feutete_: so, if you choose connect, it connects? [16:56] krisives: that's cool that you're doing php bindings for bzr...should be useful to quite a few people [16:56] joshuahoover: yup [16:57] joshuahoover: I just connected it, and am watching to see if it pushes the new files to the server [16:57] feutete_: ok, can you post what is in your ~/.config/ubuntuone/ubuntuone-client.conf file? [16:57] feutete_: also, if you have a ~/.config/ubuntuone/syncdaemon.conf file, please post that as well [16:58] feutete_: http://paste.ubuntu.com/ [16:58] joshuahoover: I'll get those shortly. FYI, it did push the new files to the server [16:59] feutete_: that's good :) i'd like to get to the bottom of why some people are having problems with ubuntu one client not connecting automatically [16:59] joshuahoover: here is the ubuntuone-client.conf: http://paste.ubuntu.com/317962/ [17:00] joshuahoover: there is no syncdaemon.conf [17:00] feutete_: ok, hmmm....very strange...the config file is correct...i thought maybe it wouldn't be for some reason [17:01] feutete_: have you restarted the client since setting it to connect automatically? [17:01] joshuahoover: yeah, and I also see "Connect on start: Automatically" in the U1 client preferences [17:02] joshuahoover: yes the prefs have been set to connect automatically for several days now, and i have the same problem every time I restart my machine [17:02] it never seems to connect automatically [17:02] feutete_: ok, hmmm... [17:02] feutete_: i've never been able to reproduce this problem but i know several users have reported it [17:03] feutete_: i'm curious what would happen if you set it to remember last...also, if you quit the client now and start it back up, will it connect automatically? [17:04] joshuahoover: I wondered about remember last, too. I'll give that a try. Let me check about quitting and restarting the client [17:04] feutete_: thanks! [17:10] joshuahoover: it looks like if I quit and restart the client, it automatically connects and pushes any updates. So, it appears that the problem is generally on boot [17:15] joshuahoover: Hi! [17:15] rmcbride: hi! :) [17:15] joshuahoover: I see you were able to help feutete_. Thanks [17:15] feutete_: ok, that's good to know! i suspected that...are you on a wireless network? [17:15] * rmcbride is back in teh house for the time being [17:16] joshuahoover: Currently, I'm on a wired, but I have seen the behavior in both situations [17:17] feutete_: ok [17:17] rmcbride...this is the mysterious "set to auto connect but doesn't auto connect on boot" issue [17:18] joshuahoover: Seems like some kind of timing issue WRT the connection state when we try to connect the first time. I see it occasionally myself but haven't been able to find a pattern [17:18] I know there's a bug on it... [17:19] rmcbride: yep, there is a bug...several :) [17:19] rmcbride: i've never seen it personally, on my box or any test environment...wired, wireless, never [17:21] joshuahoover: maybe I should ship you my laptop....it happens on every boot :) [17:21] feutete_: :) [17:22] joshuahoover: FWIW, this install of 9.10 was an upgrade--not a fresh install of 9.10. Not sure if that would factor in at all, but... [17:22] feutete_: shouldn't matter [17:23] feutete_: is there anything in your ~/.cache/ubuntuone/log/oauth-login.log files beyond "starting ubuntuone-client"? [17:24] joshuahoover: yes, lots: http://paste.ubuntu.com/317975/ [17:24] feutete_: ok, that's actually a good thing [17:25] feutete_: in terms of possibly telling us what might be going on [17:25] rmcbride: do you know if the client wouldn't connect because it couldn't reach the syncdaemon? [17:26] joshuahoover: dbus could be in a wierd state from that message [17:27] feutete_: forgive me if I missed this earlier, do you have anything in the syncdaemons-exception.log (same path as teh other one)? [17:27] feutete_: in particular I'm looking for something like "UnicodeDecodeError". [17:29] joshuahoover: no, syncdaemon-exceptions.log is empty, as are the older versions of it (i.e. syncdaemon-exceptions.log.2009-11* [17:29] feutete_: ok, thanks [17:29] hmm [17:29] feutete_: i don't have an answer for you right now unfortunately...we've got to look into this further [17:30] joshuahoover: no worries. it's not too difficult to manually connect the client at boot [17:30] feutete_: yeah, just a pain [17:30] joshuahoover: it's all good. Thanks for the help [17:53] joshuahoover, my client behaves exactly as described by feutete_ [17:55] i.e. upon initial loading gnome it is anways in non-connected state despite "Connect on start" set to Automatically [17:55] let's nail it down... [17:55] * rtagger leaves to return with logs... [18:10] oauth - Starting Ubuntu One client version 1.0.2. DBus Error: Did not receive a reply. Not interesting. [18:11] rmcbride, in order to start productin debug log, what key should be defined in syncdaemon.conf [18:11] rmcbride, sorry, ubuntuone-client.conf [18:11] rtagger: if we get a traceback, it will wind up in the ~/.cache/ubuntuone/logs/syncdaemon-exceptions log [18:12] rtagger: otherwise severe behavior will be in the syncdaemon.log as well. We don't need to enable debug unless we know there's something at a lower level that we need [18:12] rmcbride, nope, this time no exceptions, DBus failed to answer, I wonder why. [18:12] rmcbride, pleeease, what's the key for ubuntuone-client.conf :) ? [18:13] rtagger: I'll have to look. One moment [18:16] rtagger: it may well be in syncdaemon.conf, as far as logging goes. Still looking through my notes [18:16] rmcbride, ~/.config/ubuntuone/syncdaemon.conf [18:17] joshuahoover [__main__] 14:24 joshuahoover log_level = DEBUG [18:17] rmcbride, oops, so it is log_level=DEBUG, not debug=1 :) [18:18] rtagger: ah yes [18:18] rtagger: that would be the one [18:19] okay, brb :) with more logs about client not starting... [18:26] okay, any additional debug level for oauth.log ? [18:27] rmcbride, my spamming the chanel is re: joshuahoover: dbus could be in a wierd state from that message [18:28] rtagger: we've got a couple of things that are being worked on WRT establishing the connection [18:29] rtagger: my guess is that netmanager is not in a state to respond to the dbus message when we first try [18:29] rtagger: in some cases [18:29] rmcbride, I have the same issue, the client won't connect on startup and requires manual re-connection. My oauth-login.log contains the same messages from dbus library complaining about dbus... [18:29] rmcbride, my network connections are handled by NM and set as system default [18:30] rtagger: yes, and that's what leads me to believe there's a timing issue there. I get that too, just not 100% of the time [18:30] rtagger: I'm trying to locate teh master bug report for that kind of connection problem [18:30] rmcbride, is it possible to patch oauth-login-producing code, so that we at least know what call producess such error [18:30] rtagger, I can reproduce it 100% [18:31] rmcbride, i mean I can reproduce it 100% [18:31] rtagger: I suppose such a thing is possible. The developer(s) working on that issue might know more. I'm looking up the report now [18:32] rmcbride, any developer here in awake state on Friday, 13th? [18:33] rtagger: I'm _A_ dev, but that code isn't something I typically work on. Once I confirm which bug report is the master for this issue I'll see if there's anyone around who is working on the issue. [18:34] rmcbride, I guess I found the knob to increase the logging level for oauth-login.log... [18:37] rtagger: to confirm, you're seeing an Introspect error and/or "DBus Error: did not recieve a reply", correct? [18:38] rmcbride, upon initial start, the following message is repeated 3 times in oauth-login.log: DBus Error: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. [18:38] rtagger: OK. [18:40] I know I've seen this, but the bug search is being uncooperative [18:40] still digging [18:41] rtagger: you might want to go ahead and file a new bug on this with your details that you've given here and the log. I'll get it escalated and assigned as needed. [18:41] rtagger: if I can't find the old master bug this will be the new one. [18:41] rtagger: it seems that Fri 13 has affected my bug search :) [18:42] rmcbride, since I have no interesting info about the bug except "me too" message, I will try making oauthdesktop cooperate... [18:42] rtagger: OK. I'm still looking. wanted to give you teh option if you so chose. [18:42] I'm starting to wonder if this was fixed and is a regression [18:50] rtagger: can you look at your syncdaemon.conf and past the [bandwidth_thottling] section for me? I found a bug that references the d-bus error with some interesting entries there [18:51] rmcbride, there is one coming from the distro, in /etc/xdf/ubuntuone/syncdaemon.conf, are you interested in it? It was not changed by me, the per-user version was just created by me to contain the debug-enabling statement [18:52] That would have default values and would be of interest. If there's no user-created section that would be the default [18:52] rmcbride, http://paste.ubuntu.com/318032/ [18:52] rmcbride, basically, -1 [18:53] right, but it shows throttling as disabled, which should be correct with that value [18:53] rtagger: well I THOUGHT I had found a possible cause. [18:53] still digging [19:00] rtagger: I have a bug you can "me too" on if you wish. https://bugs.launchpad.net/ubuntuone-client/461614 [19:00] rtagger: if you can attach your logs to that it would be most helpful [19:01] rtagger: as the initial reporter on that didn't have many logs to attach, according to apport [19:01] rmcbride, still, I can't make oauth code produce more info, even when manually changed LOG_LEVEL to logger.DEBUG in oauthdesktop/logger.py :( [19:02] rtagger: I don't know that there is more info to get. dbus isn't always especially helpful in that regard [19:02] rmcbride, yep, but still, is this network manager or gnome keyring... [19:03] rtagger: we do have a pending branch of the test client that may make that easier to determine [19:03] rtagger: as it will change the connection dependency to be less netmanager specific [19:03] rtagger: based on the behavior I'd say that it's netmanager we're having issues with. That's what it looks like when it happens to me anyhow [19:04] the keyring should already have the token if you've authed the machine in the past [19:04] rmcbride, subscribed to the bugreport; but in my case network manager has everything it needs already as the connection is established on a system-wide basis (i mean before nm-applet kicks in) [19:04] so it's likely you have the token and the "hey is this OK" sequence is falling over for lack of an established connection [19:04] hmm [19:04] well that's useful information too [19:05] You might also mention about the lack of information from the oauthdesktop logger [19:05] I could be wrong and we may be able to bludgeon more info from dbus [19:09] rmcbride, great, i changed the sources in oauthdesktop to write to a different log file and this is ignored. Do you know where the real sources for oauthdesktop are living... ? [19:10] rtagger: in lp:ubuntuone-client [19:11] verterok: I think he's looking for the location on the installed system [19:11] verterok, erm, yes, but locally... /usr/share/pyshared/ubuntuone seem to contain the sources but their modification does not change the behavior... Even after killing the processes... [19:11] hmm. taht should be the right location [19:12] rtagger: probably because you have an old .pyc, and as the app is executed by a regular user, can't write a new pyc [19:12] rmcbride: ^ [19:12] verterok, removed pyc files for all installed versions of logger.py... [19:12] verterok, okay, killing all ubuntuone pycs... [19:14] is ubuntuone-applet performing some usefull stuff besides displaying the cloud and producing DBus signals? [19:14] i mean is it necessary to kill it as well? [19:15] it would be a good idea [19:15] it will try to start syncdaemon, left to its own devices [19:16] it does handle connections though, so you'll want to start it as well (it can be started after sychdaemon and will use the existing instance to connect) [19:16] wow [19:16] restarted the applet, got debug from oauth [19:17] anything useful? [19:17] rmcbride, not yet, going to reproduce with clean logs, initial state so I will need to reboot and will return here with more info [19:18] OK sounds good. I'll be around [19:23] rmcbride, http://paste.ubuntu.com/318051/ [19:24] rmcbride, it is not gnome keyring... [19:29] hmm [19:29] well at least that eliminates that possiblity [19:29] but it's not very forthcoming with what the non-responsive app actually is... [19:30] rmcbride, the root_formatter is not applied to the logger, need to hack it a little bit so that we see the times [19:30] rtagger: good point [19:33] rmcbride, DBus signal is firef, but it should not timeout, right? [19:33] rmcbride, *fired [19:33] rtagger: I don't think that it should, but I'm not a complete dbus guru (yet) [19:34] verterok: ^ [19:35] rmcbride, rtagger: probably calling a method timed out, not the signal [19:35] dbus signals are fire and forget [19:35] verterok, so it means that either the applet is calling some external method or... the applet is calling some external method :/ [19:36] heh, yes [19:37] rmcbride, I wonder about the following - the initial startup is pretty heavy, lots of applets, Empathy autologin, trackerd is starting, Tomboy is loading. Could that be some kind of heavy system load sign?.. [19:38] verterok, hmm, If i start dbus-monitor from the autostarted applications... Will it show dbus timeouts and sender/target that caused this? [19:38] verterok, I mean, session bus is initialized at that time already... [19:39] rtagger: startup load could well influence that I suppose. [19:39] rtagger: yes, but you need terminal + dbus-monitor, and I don't know if it's going to show the timeout [19:39] rtagger: quite probably the dbus call is to start/connect syncdaemon [19:40] verterok, is aplet starting syncdaemon immediately ? [19:40] rtagger: if you have autoconnect, I think it's a yes [19:40] okay, going to reproduce with root_logger being nicely formatted... [19:46] rmcbride, not much more, http://paste.ubuntu.com/318080/ [19:46] rmcbride, is it possible for logger to produce stack traces for every logged message? [19:47] rtagger: I don't know first hand but I'll see if I can find out [19:47] verterok: do you know the answer (asking elsewhere as well) ^ [19:48] rmcbride, 'cause this is definitely Applet time-outing after some mysterious call... [19:50] rtagger: that's my interpretation as well. certainly would be tough to figure out where to put a pdb tracepoint without such a log [19:50] well tough-ish [19:50] rmcbride, now I see only lineno, funcName, module of the caller. They may be useful, though.. [19:50] rmcbride, rtagger: I'm not aware of such capability [19:51] rtagger: that information would certainly help. [19:52] CardinalFang: didn't you do something with full tracebacks and logging in dekstopcouch? [19:52] CardinalFang: btw: the context branch looked good, at least yesterday evening [19:53] thanks. [19:53] thisfred, do something? /me reads up the log. [19:54] CardinalFang: rtagger is trying to log full tracebacks if I read it correctly [19:54] thisfred, yes, so far I added all the relevant logger entities, so I hope this will be the last reboot, brb [19:54] I thought we (for very you values of we) did something clever to do that [19:55] thisfred, rtagger, the logging module has a 'exception(msg,...)' method/function that logs the current caught stack after a message [19:55] ha [19:59] http://paste.ubuntu.com/318103/ [20:00] hmm. [20:01] thisfred, rtagger, the logging module has a 'exception(msg,...)' method/function that logs the current caught stack after a message [20:06] let me see what I just posted... === kenvandif is now known as kenvainde [20:08] sd_dbus_error, awesome === kenvainde is now known as kenvandine [20:08] Yea :0 [20:09] :/ even [20:09] Handle DBus errors for crucial syncdaemon calls [20:12] It's logging exactly what dbus tells it, apparently [20:13] rmcbride, don't see another solution except decorate all dbus calls that use sd_dbus_error so that they will call some logging routine first and then call sd_dbus_error [20:13] rmcbride, if there is a finite amount of such calls :) [20:14] rmcbride, erm... wait, CardinalFang exception(msg)... [20:16] hola [20:16] HI dobey! [20:16] who what when where why how? [20:16] hi [20:16] * rtagger reboots... [20:17] dobey: rtagger is working on what I described [20:17] dobey: his rebooting indicates to me he's changed the logger on his end and is retrying [20:17] dobey: he should be back on in a minute or two [20:17] right [20:18] i think most all those issues are due to syncdaemon starting slow [20:18] dobey: http://paste.ubuntu.com/318103/ is the most recent. And yea startup time does seem to have something to do with it [20:19] I blame dbus for having next-to-useless error messages, but that's just my gut reaction [20:19] "It could be this, this, this or this, but maybe not" Gee thanks dbus. [20:19] the messages are useless, but 'didn't reply fast enough' really is probably the best it can do for 'the app is starting very slowly' [20:20] I'll hold off on followup until our user returnbs [20:20] returns even [20:21] Heya, is it possible for me to host my tomboy sync server? [20:21] krisives: tomboy includes its own sync server. we just implement the same protocol [20:22] dobey: I guess I meant, is it possible to host my own ubuntuone server? [20:22] Although for Tomboy I can implement their protocol [20:22] rmcbride, Stacktrace: "None" [20:22] rtagger: argh. [20:23] rtagger: however dobey has clarified that it's likely syncdaemon that is slow to start in that case [20:23] krisives, No, we don't give that part away. It's still in development, too. You can host tomboy sync, of course. [20:23] Is UbuntuOne ever gonna be free? [20:23] (FOSS) [20:24] krisives: you can write your own server with the protocol library, which is AGPL [20:24] Everything that runs on your machines, it is already. What runs on our machines, it isn't and we are not planning it. [20:24] krisives, ^ [20:25] rmcbride, yep, sd_dbus_error handles such kind of errors only :) [20:26] rtagger: all dbus errors are handled the same, unless they're for special calls : [20:26] :) [20:26] rtagger: I blame a headcold on me not parsing the sd part of that earlier [20:26] :) [20:26] blah [20:34] man this wifi is laggy [20:36] rtagger, we can't know when you're listening if you don't quit IRC before you reboot. We talk away, and eventually the TCP connection times out and you go away. [20:37] CardinalFang, sorry for that, I'm still trying to find out how to look at the history... [20:38] CardinalFang, so, it is syncdaemon [20:39] it times out when get_rootdir is called, then several times during current_status() requests. [20:41] rmcbride, so, it is not NetworkManager, not gnome keyring... It is simply syncdaemon not ready enough to service dbus calls... [20:41] it doesn't time out [20:41] it's just that initial startup is very slow sometimes it seems [20:42] dobey, I mean not syncdaemon, but the applet calls to it get timed-out on initial startup when the system has a lot of work to do [20:42] well it shouldn't matter how much work sd needs to do. the calls should return immediately [20:43] maybe we need to fix some thread/async bits in sd to be a bit better === jussi01 is now known as jussi01_ [20:53] dobey, is sd performing some intensive disk operations on startup, i.e. something that can let dbus calls not to be answered in time? [20:54] well i'm guessing that it's doing something that blocks the main thread from allowing the dbus calls to function [20:54] Is it threaded or an event loop? [20:55] it's the glib main loop [20:56] which in syncdaemon is tied to the twisted reactor [21:02] Yeah. We could use reactor.callInThread() to make whatever is so expensive/blocking run in a thread that doesn't block execution. [21:02] dobey, ^ [21:03] yeah, but i don't know what it is. i think it's local rescan stuff [21:03] i think verterok was going to look at it [21:04] CardinalFang: if it's local rescan, we can't defer it to a thread [21:04] what we should do is throw the dbus stuff in another thread [21:06] the main loop still has to dispatch it. if verterok is correct, then the main loop is busy, a few frames down from the execution of the rescanner, waiting for it to return. [21:08] dobey, CardinalFang: also we can't defer to a thread the dbus stuff, as it might query data structures that aren't thread safe [21:08] Damnit. [21:08] we need to make stuff thread safe [21:08] and not block other things [21:09] we can bump the timeout of the applet dbus call [21:10] verterok: i've seen logs where it's taken 7 minutes for syncdaemon to come up and recognize the call [21:10] so i don't think we want to increase the timeout to be that long [21:10] dobey: so, we need to fix local_rescan if it's taking 7 min to finish [21:11] yes [21:12] and i think we need to evaluate what isn't thread safe, and why it isn't, and see if we can't fix it and throw stuff in a thread [21:12] Perhaps we can just make the rescanner more polite. I bet some "yield" magickery every N operations would solve it. [21:14] Pushing the dispatch into a generator may take some work. [21:15] well, i don't like code that's not thread safe, or async code that's not threaded, not threading async code is sort of like putting out a fire by burning down another building [21:15] Then again, it's twisted, so there's almost certainly somthing smarter we can do with Deferreds. [21:15] CardinalFang: I "think" that the rescanner release the reactor on each directory tree [21:15] it is definitely twisted :) [21:15] dobey: ok, you don't like twisted...we know that :) [21:16] twisted has some nice stuff [21:16] but it has some nasty stuff too :) [21:17] Deferreds are nice, but they're better with Threads [21:25] dobey, the start up time is not local rescan [21:25] dobey, those seconds/minutes without returning control [21:25] dobey, it's the metadata loading... we have a bug for that [21:25] verterok, ^ [21:26] facundobatista: oh, good point, I missed that [21:26]