[05:32] <gregh7470> hi every1  :)
[05:33] <gregh7470> Q: If I install a firewall after I install ubuntuone are there any ports I have to forward?
[05:33] <gregh7470> I wanted to install GUFW
[08:30] <elky> gregh7470, i dont recall having to open anything specifically for it.
[09:10] <till> Good morning.
[09:29] <aquarius> hey till
[10:25] <jetienne> q. is there a client for ubuntu 8.10 ?
[13:48] <facundobatista> Hi all
[13:52] <statik> moshi moshi
[13:58] <facundobatista> statik, that means "hello" in some language?
[13:59] <statik> facundobatista: an informal japanese greeting
[13:59] <facundobatista> statik, hi then!
[14:00] <statik> hi :)
[14:01] <urbanape> Morning, all. Running my father-in-law to the airport. Should be back by standup time.
[14:05] <aquarius> hola statik
[14:05] <aquarius> I thought moshi moshi was what you shouted at huskies to make them pull your sledge faster
[14:06] <statik> hey there aquarius. heard about tomboy sync from rodrigo?
[14:06] <statik> that too
[14:06] <aquarius> statik: rodrigo_ said that he has it working but can't get the packages to work on jaunty
[14:06] <aquarius> statik: I'm going to put a video of it in the oscon presentation
[14:07] <statik> aquarius: i will be landing a branch today that makes the tomboy notes show up on m.ubuntuone.com all formatted for mobile phones. right now the css looks very iphonelike, but it works fine on android and pre also
[14:07] <aquarius> statik: rawk!
[14:08] <statik> readonly, no edit or search yet but should be *ahem* trivial
[14:10] <aquarius> cor, I should have videos of both of those, shouldn't I?
[14:10] <aquarius> both tonboy sync and local tonboy-save-to-couchdb-directly
[14:10] <till> thisfred: ping, when you wake up :)
[14:10] <thisfred> till: I'm awake :)
[14:14] <dobey> statik: moshi is mainly something you'd say on the phone :)
[14:14] <aquarius> dobey: aha, I need to talk to you
[14:14] <statik> i insist on using it completely incorrectly because i don't know any better
[14:14] <statik> :D
[14:14] <dobey> heh
[14:14] <jblount> Neat! kenvandine just linked this up on twitterdenti.ca: http://www.linux-magazine.com/Online/News/Common-Keyring-KDE-and-GNOME-Combine-Password-Management-Efforts
[14:14] <aquarius> dobey: I do believe your complaint about UnknownLoginError is unjustifies because you've parsed it wrong
[14:14] <dobey> statik: it's the american way! :)
[14:15] <dobey> aquarius: how so? it's getting raised for ssl cert validation fail in pycurl
[14:15] <dobey> and presumably for other pycurl errors as well
[14:16] <aquarius> dobey: because you're parsing it as an "unknown login" error, i.e., that the login was unknown. It is in fact an unknown "login error", i.e., something unexpected which happened during the login process.
[14:16] <aquarius> dobey: took me two days to realise what your complaint meant. :)
[14:16] <dobey> aquarius: no. i'm parsing it as unknown error having to do with login
[14:16] <aquarius> dobey: I can see how it could do with being renamed :)
[14:17] <aquarius> dobey: then what's wrong with it?
[14:17] <dobey> aquarius: however, that code has absolutley nothing to do with logging in
[14:17] <dobey> all it does is grab the request token afaict
[14:17] <aquarius> dobey: ah, the whole process is logging in.
[14:17] <aquarius> dobey: according to me it is, anyway. You could call it an UnknownKeyExchangeAndLoginAndEverythingError, I suppose
[14:17] <dobey> and the errors aren't unknown. it does that for any error raised by pycurl :)
[14:18] <aquarius> dobey: iyeah, the idea was to catch random stuff that goes wrong under one heading. :)
[14:19] <dobey> in that case, 'GeneralRequestError' would be a better name
[14:19] <aquarius> agreed
[14:19] <dobey> but either way, some of the errors we actually need to deal with in a useful way
[14:19] <dobey> like ssl cert validation failure
[14:19] <aquarius> dobey: yeah, if there *is* some useful way to deal with a given error then it ought to be trapped
[14:19] <aquarius> how can we usefully deal with that?
[14:20] <dobey> well, knowing *why* it failed and reporting that to the user is more useful than 'unknownloginerror'
[14:21] <dobey> because there are a bunch of bug reports about 'unknownloginerror' now, and i suspect a few are ssl cert failures, and a few are proxy failures, etc...
[14:21] <aquarius> depends on your point of view, I suppose. You get the actual error from the traceback, no?
[14:22] <dobey> no
[14:22] <aquarius> oh!
[14:22] <aquarius> then definitely I was wrong and wrapping them all up in one error is a bad idea.
[14:22] <aquarius> I think it might be a relic of the days when you got libnotify popups when something went wrong.
[14:23] <dobey> i don't know why we don't, as the code implies we should
[14:23] <dobey> but it's probably better to just re-raise the exception we got, since they're all wrapped up in the generic pycurl.error anyway
[14:23] <aquarius> we don't because mpt beat me with a big stick
[14:23] <dobey> for libnotify, yes
[14:23] <aquarius> agreed, yeah, just re-raise. Better, don't even trap it.
[14:24] <dobey> well, it looks like we log it
[14:24] <aquarius> k
[14:24] <aquarius> then your tweet complaint was justified. Gave me something to think about while drinking beer one afternoon, anyway ;)
[14:25] <thisfred> aquarius: didn't you ask about Ubuntu One on Intrepid? Someone's been trying at least: https://answers.launchpad.net/ubuntuone-client/+question/73276
[14:25] <aquarius> thisfred: I asked because someone in here asked and I was going to let them know
[14:25] <dobey> i think gtk+ is hosed in intrepid
[14:25] <thisfred> aquarius: ah, might have been the same person then
[14:26] <aquarius> dobey: can't be all that hosed, can it? since, er, applications worked
[14:26] <dobey> but i don't have intrepid anywhere to look at /usr/include/gtk-2.0/ with
[14:26] <dobey> aquarius: well, the header files anyway
[14:26] <dobey> although opensuse 11.1 apparently has the same issue
[14:28] <dobey> or maybe the nautilus headers are busted and gtk.h is ok
[14:30] <aquarius> could be. I only do Python :)
[14:38] <aquarius> dobey: second question: why is advertisePort.py now in utilities?
[14:38] <aquarius> dobey: it shouldn't be.
[14:41] <dobey> because it's a script that gets run, and not something that gets imported, afaict
[14:42] <dobey> so in my build fixes branch i moved it, because it made the most sense based on that knowledge
[14:45] <statik> aquarius: how would you feel about having desktopcouch.records and desktopcouch.contacts in a single python-desktopcouch ubuntu package?
[14:46] <aquarius> statik: fine as a source package. not sure about binary packages; lots of people will want .records without wanting .contacts
[14:47] <aquarius> dobey: it does get imported, and also it needs to go onto the desktop. It's not just a thing we run from make start; it manages the startup/port-export process for everyone's desktop couch
[14:47] <statik> aquarius: ok. reason i'm asking is because it's a tiny amount of code in .contacts, and it makes the packaging more complicated to split it (not impossible, just can't use the trivial rules file i've been using)
[14:48] <aquarius> statik: ah, if it's that tiny, what the hell
[14:48] <dobey> gets imported by what?
[14:48] <rodrigo_> aquarius, statik: unfortunately, tomboy syncing isn't working, it's failing on oauth
[14:48] <aquarius> dobey: ah, it doesn't get imported, it gets run by d-bus activation
[14:49] <dobey> aquarius: i think it has to be run manually because there is no .service file for it
[14:49] <aquarius> dobey: yeah, when I say "it gets run by d-bus activation" I mean "that is the plan"
[14:49] <aquarius> dobey: the .service file hasn't been written yet
[14:50] <dobey> aquarius: but if it needs to be installed to the desktop and run by the user via dbus, we should rename it and install it appropriately via setup.py. not as part of the python package :)
[14:50] <statik> rodrigo_: is the oauth something we can fix completely on our side, or does it require changes in tomboy?
[14:50] <aquarius> dobey: agreed, once we get that far
[14:50] <rodrigo_> statik: I am not sure, I've changed some stuff on our side, but keeps failing
[14:51] <rodrigo_> statik: I'm waiting for sandy to come back from vacation (today) to ask him
[14:51] <rodrigo_> statik: but if you know about oauth, I'd appreciate if you could have a look
[14:51] <statik> rodrigo_: sure
[14:51] <rodrigo_> statik: let me commit and push my branch
[15:01]  * vds thinks it's me time...
[15:01] <jblount> MEETING BEGINS
[15:01] <jblount> Welcome to the Ubuntu One desktop+ developers meeting. If you are here for the meeting, please resond with "me", we can try going in order of those repsponses. Format is TODO / DONE / BLOCKED
[15:01] <urbanape> me
[15:01] <vds> me
[15:01] <jblount> me
[15:01] <teknico> me
[15:01] <statik> me
[15:01] <dobey> me
[15:02] <CardinalFang> me
[15:02] <urbanape> DONE: Pushed a few more feature branches to ubunet for the new files UI.
[15:02] <urbanape> TODO: Finish up sharing popup, and try to reify some notes I made about a new details module for all these popup actions.
[15:02] <urbanape> BLOCK: None
[15:02] <urbanape> vds, if you please.
[15:02] <vds> DONE: landed all branches related to funambol-ds, some of code review, started a new branch to fix some ds-server db init, more test on ds-server with mark
[15:02] <vds> TODO: do some
[15:02] <vds> BLOCKED: no
[15:02] <vds> jblount your turn
[15:02] <jblount> DONE: Landed a js branch to clear the bug reporting form on focus, worked on delete functionality
[15:02] <jblount> TODO: Finish delete branch, start to get /files/new in better shape for public consumption
[15:03] <jblount> BLOCKED: Nope
[15:03] <jblount> teknico: rocknroll
[15:03] <teknico> DONE: discussed the script testing policy with markgsaye, testing scripts in utilities/
[15:03] <rodrigo_> me
[15:03] <teknico> TODO: more testing scripts in utilities/
[15:03] <teknico> BLOCKED: none
[15:03] <teknico> next: statik
[15:03] <statik> DONE: Face duty, code reviews, bug triage, a bit of webui hacking.
[15:03] <statik> TODO: help rodrigo with tomboy sync, anything aquarius needs for oscon, package lp:bindwood, talk to the platform team about various packages in the pipe.
[15:03] <statik> BLCK: none.
[15:03] <statik> next dobey
[15:03] <aquarius> me
[15:03] <dobey> DONE: Reviews, Small package fixes, Bug triage,
[15:03] <dobey> TODO: Do pycentral magic for 'make install', #378707
[15:03] <dobey> BLCK: None.
[15:04] <dobey> CardinalFang: Nobody expects it
[15:04] <CardinalFang> DONE: More spawning work.  Oh-so-close to finished replacing paste.
[15:04] <CardinalFang> TODO: Finish.  Eyeball pairing next steps and answer aq's questions.
[15:04] <CardinalFang> BLOCKED: None
[15:04] <CardinalFang> rodrigo_: heya!
[15:04] <rodrigo_> DONE: fixed notes views and added basic tests for them. Released couchdb-glib-0.4.2 with REVU fixes and submitted to REVU again. Continued trying to make tomboy syncing work
[15:05] <rodrigo_> TODO: fix oauth problem with tomboy. Fix and submit a new evo-couchdb package for REVU
[15:05] <rodrigo_> BLOCKED: none
[15:05] <rodrigo_> aquarius: your turn
[15:05] <aquarius> DONE: holiday, celebrate, it should be so nice; spoke with thisfred about couch packaging; finishing OSCON presentation; talk to dobey about refactoring and UnknownLoginError
[15:05] <aquarius> TODO: make videos of various things to demo in OSCON presentation; tidy up last bits of presentation; write demos; fly to OSCON
[15:05] <aquarius> BLOCKED: lsof stuff (nearing the point where it's not needed now!)
[15:05] <aquarius> and I think I'm last
[15:06] <jblount> MEETING ENDS
[15:06] <jblount> Well done everyone, I'll take a 6 minute stand up any day.
[15:06] <dobey> aquarius: you are aware that we aren't doing lsof any more in desktopcouch, right?
[15:07] <aquarius> dobey: tim's patch has gone in already?
[15:07]  * statik mumbles that proc walking is not any better than lsof
[15:07] <dobey> i didn't say it was better
[15:07] <aquarius> ok, then my last point should be "proc walking stuff".
[15:07] <statik> heh
[15:08] <dobey> hrmm
[15:08] <thisfred> aquarius: dobey statik: I think noone is happy with that code, but since couchdb trunk is a moving target, having it working without a patch that we need to maintain may be worth it for the short run
[15:08] <statik> yep, agreed
[15:08] <dobey> statik: btw *thwap* for not using tarmac on desktopcouch
[15:09] <statik> err, yeah
[15:09] <statik> i should be using tarmac
[15:09] <dobey> yes, yes you should
[15:10] <dobey> especially since it automagically preserves thea author :)
[15:10] <dobey> or well, hopefully my other pending branches will land soon and we can get an ec2 thing running tarmac for us
[15:13] <dobey> statik: hrmm, also, i think bug #400746 would probably be better off assigned to one of the syncdaemon guys, since i don't really know that code, and the issues are all syncdaemon performance problems, no?
[15:15] <statik> dobey: depends on whether there is a standard trick for doing a deferred startup that you could apply in the packaging or shortcut files so that it doesn't block the session i think. making local scan work faster is something verterok is working on, but i think the main thing that bug report is about is ubuntuone showing up on the bootcharts
[15:15] <statik> dobey: can you ask keybuk/pitti if there is anything they recommend?
[15:16] <dobey> statik: we can't do a deferred startup
[15:16] <verterok> statik, dobey: we could avoid starting the syncdaemon if the applet don't connect on startup
[15:16] <dobey> verterok: no we can't. the syncdaemon starting has nothing to do with the applet starting
[15:17] <verterok> dobey: who is starting syncdaemon if isn't the applet?
[15:17] <statik> dobey: can't do a deferred startup because the nautilus extension is triggering the syncd to start?
[15:17] <dobey> verterok: the syncdaemon is getting started by dbus activation, because nautilus queries it
[15:17] <dobey> ie, nautilus needs to know what directory is the Ubuntu One root, and if it is connected or not
[15:18] <dobey> and if there are any current transfers, and what folders are shared
[15:18] <statik> dobey: yeah that is sounding like something you can't work around outside of the syncdaemon.
[15:19] <statik> verterok: is it possible to make syncdaemon defer the initial local scan and answer those questions for nautilus cheaply without talking to the server?
[15:20] <verterok> dobey, statik: we could add new state to syncdaemon, to avoid local rescan, e.g: and start local rescan when "connect" is requested
[15:20] <verterok> I'm not sure that's the best solution...
[15:21] <verterok> statik: so, it's possible
[15:21] <statik> verterok: yeah, i'm not sure either. this is a serious bug though, it will get us kicked out of the desktop if we can't figure out some way to avoid slowing down startup
[15:22] <statik> (by kicked out i mean removed from the default installation)
[15:23] <verterok> statik: I think we could "delay" local rescan execution, e.g: doing a reactor.callLater, but I need to check the side effects of doing that.
[15:25] <statik> verterok: thanks! so i agree with dobey that this bug is something that doesn't seem that he can work around on the nautilus side unfortunately
[15:26] <verterok> statik: yes, but if the applet is autostarting it will connect the syncdaemon
[15:27] <dobey> the applet isn't autostarting until you actually sign up and authorize your computer
[15:29] <statik> __lucio__: ^ just revisiting our discussion from earlier, it seems that the startup time issues cannot be worked around by postponing startup of syncdaemon
[15:30] <toriq1> hi. is this the right channel for support question about ubuntu one?
[15:32] <statik> hi toriq1, you are in the right place
[15:33] <verterok> statik, dobey: can't the nautilus extension wait until nautilus is opened to do all this queries to syncdaemon?
[15:34] <dobey> verterok: nautilus is opened on start-up (the desktop is just a nautilus window)
[15:34] <statik> verterok: i don't know very much about nautilus but i think it is started in order to draw the desktop
[15:34] <__lucio__> statik: verterok: we need to understand the policy here. when syncdaemon starts (starts, not connects) it will re scan the disc and re hash whats changed. we have some fixes that improve the "changed set" detection and we are now working on making local rescan a much faster process
[15:34] <__lucio__> if thats not enough, we have to: 1- so local rescan at other moment and delay connecting, 2- despair
[15:35] <__lucio__> so/do
[15:35] <statik> __lucio__: i'm not sure the technical changes to accomplish this, but we need to find a way that rescan is taken out of the path of session start/bootcharts
[15:35] <dobey> __lucio__: i think part of the problem is that it's doing a lot of work when there's really nothing to do.
[15:35] <statik> a lot of this i'm just learning about as we discuss it here
[15:35] <verterok> __lucio__: I think we could delay LR, but I'm trying to understand why nautilus need all the info from syncdaemon if the ~/Ubuntu One folder wasn't opened
[15:35] <verterok> dobey: ^
[15:35] <dobey> __lucio__: ie, when the user installs a fresh karmic desktop, and they dont' have an account
[15:36] <dobey> verterok: because it doens't know that the ~/Ubuntu One folder is the folder where ubuntu one stuff is kept
[15:36] <dobey> verterok: and at some point when support arbitrary folders, we certainly can't hardcode ~/Ubuntu One as the folder
[15:36] <verterok> dobey: that's iin the config file
[15:37] <toriq1> is there any way to see what's happening when ubuntu one is synchronizing? (when the ubuntu is icon spinning)..
[15:37] <__lucio__> dobey: and what is syncdaemon doing in that case? what do the logs say?
[15:37] <toriq1> sometimes it doesn't stop, so I want to know what's happening when it doesn't stop..
[15:37] <verterok> dobey: agreed, but at some point it's somewhat far far away :)
[15:38] <verterok> __lucio__: it's just starting all the machinery as there isn't anything to scan local rescan isn't doing much
[15:38] <statik> should we have a fast dbus interface and a slow dbus interface? right now the problem is that any query to dbus starts up the syncdaemon who then does a lot of work, is that accurate?
[15:40] <verterok> statik, dobey, __lucio__: we could delay LR startup, but that isn't going to buy much, as the syncdamemon will start and I think that's the big issue
[15:40] <verterok> local rescan isn't doing anythig
[15:41] <__lucio__> if the user doesnt even have an account, then nautilus should skip talking to syncdaemon
[15:41] <__lucio__> that would be the fastests way to go around the issue
[15:41] <dobey> how does nautilus know the user doesn't have an account?
[15:41] <statik> __lucio__: the nautilus extension is in C, I think the way it would find out whether the user has an account is by asking the dbus interface right?
[15:42] <dobey> statik: language is irrelevant here
[15:42] <statik> oh
[15:42] <verterok> statik: which dbus interface: syncdaemon, oauthdesktop?
[15:42] <dobey> the syncdaemon doesn't even know if the user has an account, because we don't have a concept of accounts on the desktop
[15:42] <statik> right, all we have is a token maybe
[15:42] <dobey> we have an oauth token that may or may not be valid
[15:44] <statik> toriq1: this information is not exposed in the normal UI. you can use sdtool to find out what the syncdaemon is currently doing though, or look at the logs in ~/.cache/ubuntuone/
[15:45] <__lucio__> so, how long does it stak syncdaemon to quiese? when it has nothing to do? 0.1 second? 1 second? 10? 30?
[15:45] <statik> is there any other information that nautilus needs at startup besides which folders are managed by ubuntuone? maybe we could make an alternative way to discover that info
[15:50] <__lucio__> statik: dobey: whats the bugno for this?
[15:50] <dobey> https://bugs.edge.launchpad.net/ubuntuone-client/+bug/400746
[15:50] <dobey> hrmm, so it seems ok when there's no user
[15:50] <dobey> err, no account
[15:51] <dobey> my log in time wasn't excruciatingly slow
[15:52] <dobey> but this is r88 also, which is not in karmic yet
[15:53] <verterok> __lucio__, statik, dobey: it took ~1.5s (real) to start in a clean system (in my 2.0GHz macbook)
[15:54] <statik> verterok: yeah, so we still need to find a way to defer startup so that doesn't show up on the bootcharts
[15:55] <statik> trying to get under 10 second boot time a 1.5 second startup is still too much
[15:55] <verterok> statik: we could move more info to the config file, and the nautilus extension could use that
[15:55] <__lucio__> verterok: 1.5s? what was it doing????
[15:55] <verterok> __lucio__: starting? :p
[15:56] <__lucio__> verterok: libsyncdaemon-vm-metadata
[15:56] <verterok> __lucio__: there is no metadata! :)
[15:56] <__lucio__> verterok: for 1.5s? does syncdaemon make tea while booting and i didnt know about it?
[15:56]  * dobey stabs gnome-power-manager
[15:57] <verterok> __lucio__: http://ubuntuone.pastebin.com/m168916ae
[15:58] <statik> verterok: so i'm ok with the concept of putting more info in a config file, although i really like the clean interface we would get from asking dbus - when more and more people write code that interacts with syncdaemon i'd rather not have them touching the config file directly if there is an easy way to protect it. but if the config file is an easy win for now maybe we should do that. dobey, what do you think?
[15:58] <__lucio__> ok, so: nautilus wont talk to sd unless there is a token. nautilus will get the roots information from somewhere else than (the slow) dbus. someone autostarts syncdaemon one minute after boot
[15:58] <dobey> i don't think moving stuff to a config file is the right way to solve performance issues
[15:59] <dobey> especially once we want to add a preferences ui
[15:59] <__lucio__> verterok: what happens here?\#
[15:59] <__lucio__> 2009-07-20 11:52:25,612 - ubuntuone.SyncDaemon.HQ - INFO - HashQueue: _hasher started
[15:59] <__lucio__> #
[15:59] <__lucio__> 2009-07-20 11:52:26,405 - ubuntuone.SyncDaemon.DBus - DEBUG - using the real system bus
[15:59] <dobey> it shouldn't write directly, but tell syncdaemon to set the options
[15:59] <verterok> __lucio__: syndaemon get's the session bus
[16:01] <verterok> __lucio__: actually, all the dbus exposed objects are created and registered to dbus
[16:01] <dobey> so parsing the config file instead won't help anyway
[16:01] <__lucio__> verterok: 1 second of that?
[16:02] <verterok> __lucio__:  looks like dbus is the slowest thing in the wild west :p
[16:02] <dobey> at least, not without a lot more complexity
[16:02] <__lucio__> verterok: freedesktop is dbus based. how can it boot under 10 sec if just starting one app takes 1?
[16:03] <__lucio__> im not buying htat.
[16:03] <verterok> __lucio__: look the code, it's just creating s few objects a re registering them to the dbus session
[16:03] <verterok> s/re//
[16:03] <dobey> just looking at code doesn't tell you which parts are actually the slow spots
[16:04] <dobey> unless it's obviously bad code with obvious slow spots
[16:04] <verterok> dobey: just pointing out that it's very simple code
[16:04] <dobey> like spin_disk()
[16:05] <dobey> verterok: sure. dbusObject.get_root() is simple code too, until you realize it starts the syncdaemon and does local rescan, and possibly other things :)
[16:05] <dobey> we need some real profiling, and i have no idea how to profile python
[16:06] <dobey> to me, all python is slow :)
[16:07] <verterok> dobey: localrescan takes less than 0.01 seconds
[16:08] <verterok> __lucio__: In [8]: timeit.timeit('import dbus; dbus.SessionBus()')
[16:08] <verterok> Out[8]: 5.3944590091705322
[16:08] <__lucio__> verterok: 5 whats?
[16:08] <verterok> __lucio__: timeit unit? :/
[16:09] <verterok> __lucio__: seconds :p
[16:10] <__lucio__> verterok: right, just getting the bus takes 5 seconds and SD boots in 1
[16:10] <verterok> __lucio__: 10000 executions :p
[16:11] <__lucio__> informacion con cuentagotas
[16:11] <verterok> __lucio__: I'll run sd with lsprof and get a callgrind file
[16:11] <__lucio__> thanks guillo :)
[16:16] <verterok> __lucio__: sync.Sync is the main offender regarding startup time :O
[16:16] <__lucio__> verterok: elaborate please
[16:17] <verterok> __lucio__: is the one that it's created between HQ and DBus
[16:17] <verterok> __lucio__: I
[16:17] <__lucio__> and please point your dirty fingers at someone elses code :P
[16:17] <verterok> __lucio__: I'll profile sync itself to find the hotspots
[16:17] <verterok> __lucio__: :)
[16:20] <verterok> __lucio__: wihtout starting sync: http://ubuntuone.pastebin.com/m7ebc57cf, staring sync: http://ubuntuone.pastebin.com/m413111ec
[16:21] <__lucio__> verterok: ok, 1 second for sync.
[16:21] <__lucio__> nice :)
[16:32] <dobey> rodrigo_: we don't need to explicitly include gtk.h for 2.27.x (or 2.26.x) because the libnautilus-extension includes pull it in for us. but i guess in 2.24, they only included what they needed (which i wish everyone would do but upstream is on this kick to make it 'simple')
[16:33] <rodrigo_> dobey: isn't that part of the API cleanup for GNOME 3.0? to include only top level headers?
[16:34] <dobey> rodrigo_: i don't know if i would call it 'cleanup', but yes. we weren't including anything directly from gtk+ before this though. the nautilus-location-provider.h and such include <gtk/gtk.h> so we don't need to do it ourselves for 2.26+
[16:34] <dobey> rodrigo_: but 2.24 doesn't have those changes, so we do need to do it ourselves for them
[16:34] <rodrigo_> that's what I meant in my comment, that we need to do it also for 2.28/3.0
[16:35] <dobey> i think you're confused a bit :)
[16:36] <dobey> although for 2.28 or 3.0 we /might/ have to switch to using one nautilus-extension.h or something, if upstream is doing that for nautilus as well
[16:36] <rodrigo_> yes, I understand that part, that nautilus-location-provider.h already has it
[16:36] <rodrigo_> for 2.26
[16:37] <rodrigo_> which is part of the API header cleanup AFAIK
[16:37] <dobey> well, more likely it's because gtkfoo.h complains during compile if you include it instead of gtk.h
[16:39] <rodrigo_> yes
[16:39] <dobey> the point though is that we ourselves do not explicitly need to include gtk.h for any reason outside of the fact that nautiuls 2.24 doesn't do it for us
[16:39] <dobey> we could just require nautilus 2.26 for it, but that would be lame
[16:43] <rodrigo_> yeah, too lame :)
[16:44] <dobey> ugh
[16:45] <dobey> every time vcs-imports updates the couchdb-glib and evolution-couchdb projects, i get a bunch of mail :(
[16:46] <rodrigo_> dobey: oh, you're subscribed to it?
[16:46] <dobey> rodrigo_: well, the team is
[16:46] <dobey> and i can't override that it seems :(
[16:46] <rodrigo_> yeah, right
[16:47] <dobey> guess i need to file a launchpad bug for that
[16:47] <andresmujica> hi is possible to access an ubuntuone folder from a Java application? is there a workaround?
[16:48] <__lucio__> andresmujica: a workaround for java?
[16:48] <__lucio__> some people say python is such a thing
[16:48] <dobey> andresmujica: the local folder is just a regular folder
[16:48] <dobey> you can open() it with any language
[16:48] <andresmujica> hmm i cannot see it from my java app... let me check
[16:50] <andresmujica> duh. ignore my q.   thanks.
[18:22] <till> Ok, time for some comet hackery.
[18:22] <till> Does anyone in here know how the comet notifications work, in couchdb trunk?
[19:27] <billybigrigger> hey all
[19:28] <dobey> hi
[19:28] <billybigrigger> Installed: 0.90.3-0ubuntu1 <<<< just installed this, now it won't run from Applications>Internet>Ubuntu One
[19:28] <billybigrigger> it starts a process, but never opens any window
[19:30] <dobey> 0.90.4 was just uploaded to karmic today. it might not be published yet, but please upgrade and try it when it becomes available
[19:31] <dobey> it has a lot of fixes, and should make that work better
[19:32] <billybigrigger> ooooh ok :P
[19:33] <billybigrigger> speak of the devil, there it is :P
[19:34] <billybigrigger> oooh nasty message now :P
[19:34] <billybigrigger> http://imagebin.ca/view/P47-e1oV.html
[19:35] <dobey> GtkLabel fail
[19:39] <dobey> billybigrigger: hrmm, what does the far right end of that dialog say?
[19:41] <till> Ah, there's the man I'm supposed to talk to. :)
[19:41] <till> thisfred: evening
[19:41] <till> (in my timezone)
[19:41] <till> thisfred: I'm Till, I'm currently implementing the Akonadi couchdb resource and am wondering how the comet notifications are supposed to work, in trunk.
[19:42] <thisfred> till, in my timezone as well: ponged immediately after your ping, but I guess you missed that, or maybe freenode flaked out ;)
[19:43] <thisfred> till: I'm also still figuring out the _changes stuff myself
[19:43] <thisfred> but for now the idea is that it sends more or less what it used to send to the update notifiers, except there's a feed per db
[19:44] <till> thisfred: aquarius told me to talk to you about it
[19:44] <till> thisfred: so basically i sit in a blocking GET no a per db _changes url?
[19:45] <thisfred> till: yes, if you want the streaming version, which I think we do. So that's kinda bad. I think there will be a per server feed again, since that will be much easier to handle
[19:45] <thisfred> but it's not there yet'
[19:46] <billybigrigger> dobey, http://imagebin.ca/view/Zk4O4LZo.html
[19:46] <billybigrigger> theres the other half
[19:46] <thisfred> till, you can also just periodically get without streaming=true, and then keep state somewhere to know which events are new
[19:48] <till> thisfred: nah, I think I'll just pop it into a thread and block
[19:48] <till> thisfred: are the urls and formats documented somewhere?
[19:49] <thisfred> till: for the desktop side of things, this is doable of course. On the other side, we'll have thousands of dbs, and things are a little harder...
[19:49] <thisfred> till I'l try and see if I can dig up some links for you
[19:49] <till> I'm over here in happy desktop/devices land, where things are easy. :)
[19:50] <dobey> crikey
[19:52] <billybigrigger> dobey, should i file a bug?
[19:54] <dobey> billybigrigger: for the size of the dialog, or for the failure to launch your browser which seems to be configured to run "" ?
[19:54] <thisfred> till, actually there is a patch for a global _changes already proposed I now see. The mailing lists are just too high traffic to keep up.
[19:55] <dobey> maybe i should just make the code do a gconftool-2 --unset on some keys
[19:59] <thisfred> till, can't really find anything good on the web, but I can point you to this discussion, which has all the current features somewhat explained: http://mail-archives.apache.org/mod_mbox/couchdb-dev/200907.mbox/<214c385b0907060550y5e43887em8ca16cdd31d06c7a@mail.gmail.com>
[20:00] <thisfred> till, the url is always server:host/dbname/_changes
[20:00] <till> Cool, thanks.
[20:01] <thisfred> a running one you can look at is chris anderson's blog: http://jchrisa.net/drl/_changes ;)
[20:02] <till> Well, I've got a local trunk checkout running, hopefully I can trigger it there.
[20:08] <billybigrigger> dobey, i have a similar problem with thunderbird, trying to open links it doesn't want to open my browser
[20:08] <billybigrigger> but i have my browser set in preferred apps
[20:10] <thisfred> till, ok, good luck, the #couchdb channel is pretty friendly when anyone's awake, and let me know what you run into. I'm sorry I'm not of more help yet, but I'll be diving into _changes soon myself, if all goes well, and this mountain of other stuff magically evaporates as I expect it to ;)
[20:11] <till> thisfred: works fine, so far
[20:11] <dobey> billybigrigger: "gconftool-2 -g /desktop/gnome/applications/browser/exec" says what?
[20:11] <till> thisfred: I'm getting notificatinos from my own changes
[20:11] <till> thisfred: seems pretty straight forward
[20:11] <thisfred> till, cool
[20:11] <billybigrigger> dobey, chromium-browser, which is wrong, should be firefox-3.6
[20:12] <dobey> billybigrigger: and if you change it, does it then work?
[20:12] <billybigrigger> yes it does
[20:12] <billybigrigger> must have lost config somewhere
[20:12] <till> thisfred: do you guys have something server side yet that I can play with, btw?
[20:12] <dobey> billybigrigger: you aren't the only one to have had this issue
[20:12] <till> thisfred: I'm just curious, don't need it for my akonadi work, atm.
[20:12] <billybigrigger> dobey, hmm ok
[20:13] <dobey> billybigrigger: i don't think it's lost config, so much as just horrible usability and complexity
[20:13] <billybigrigger> well i remember setting it only a few days ago
[20:13] <billybigrigger> oh well, u1 is working :P
[20:16] <thisfred> till: another very exciting development in trunk is the _changes filters implemented today by chris anderson. They allow you to filter out changes you're not interested in with a little JS, and seem pretty flexible/powerful.
[20:17] <till> Nice.
[20:17] <thisfred> till: look in /share/www/script/test/changes.js for examples of usage
[20:19] <thisfred> till, oh missed your question: we may have soon, but not yet. I think someone was working on notes.
[20:19] <till> thisfred: notes would be interesting to play with, we're currently re-doing notes in KDE completely.
[20:20] <thisfred> till, I think rodrigo_  and/or statik would know a little more about that. Hopefully. Or I've just done an aquarius... ;)
[20:21] <till> I'll just hang around. :)
[20:21] <till> My boys don't let me code much, these days, so hanging around is good use of my time, I reckon. ;)
[20:21] <thisfred> till mostly for the server and the desktop to interact, we need oauth in couch working, which is what I'm supposed to be testing now
[20:22] <till> Ah, indeed.
[20:22] <thisfred> except that it's 9:30 almost, and I haven't had dinner yet, so first that.
[20:22] <thisfred> later all!