[02:33] <nomnex> Hi, I cannot use evolution-couchdb & ubuntuone. Install went fine but nothing happens
[02:33] <nomnex> Jaunty 9.04/Ubuntu One/Evolution 2.26
[02:39] <nomnex> anybody UbuntuOne/Contacts - Help
[02:40] <GreySim> nomnex: Have you looked at the wiki page for it (assuming there is one like there is for Tomboy)?
[02:41] <GreySim> nomnex: https://wiki.ubuntu.com/UbuntuOne/Tutorials/Contacts
[02:41] <nomnex> the tutorial on the UbuntuOne site. I don't find Wiki page
[02:41] <GreySim> Oh, okay.
[02:41] <GreySim> I don't know, I actually have not even set it up for myself yet.
[02:41] <GreySim> I had heard that Jaunty wasn't as well supported as Karmic.
[02:42] <GreySim> But I don't know exactly what that entails.
[02:42] <nomnex> according to the tuto. once couchdb is installed it should ask permission to access the keyring, but nothing happens
[02:43] <nomnex> there is a waring about OS version on another tutorial, but nothing on the contact tutorials. I assume 9.04/9.10 are supported
[02:44] <GreySim> Well, no clue here. I'm still on Jaunty myself, for a few more days. I wasn't going to setup Ubuntu One until upgrading to Karmic anyway.
[02:45] <nomnex> do you know how to I launch this couchdb?
[02:46] <nomnex> it is supported on Jaunty
[02:52] <nomnex> any one EVOLUTION-COUCHDB on Evelution 2.26?
[10:08] <nomnex> I try again: anybody for helping with Evolution-Couchdb on Evo 2.26, I can't get it to work with ubuntuone/contact
[10:18] <aquarius> nomnex, heya
[10:18] <nomnex> aquarius: hello
[10:18] <aquarius> nomnex, what happens when you try to use the couchdb addressbook?
[10:19] <nomnex> aquaruis: I followed the tutorial on the ubuntone page, downloaded the evo-couchdb and installed. nothing happens then
[10:19] <nomnex> I am on 9.04/Evo. 2.26
[10:19] <aquarius> ah, you need to be running 9.10 to get full use of evolution-couchdb, I believe.
[10:20] <nomnex> I have been looking on Launchpad evo-couchdb, I found a post with lib update for 2.26
[10:21] <aquarius> nomnex, evolution-couchdb talks to your desktopcouch, and I don't think you'll *have* desktopcouch if you're running 9.04. Let's check.
[10:21] <nomnex> aquarius: that makes sens, but why can I install it on Jaunty then?
[10:21] <aquarius> Can you run this command in a terminal: dbus-send --session --dest=org.desktopcouch.CouchDB --print-reply --type=method_call / org.desktopcouch.CouchDB.getPort
[10:22] <nomnex> aquarius: Error org.freedesktop.DBus.Error.ServiceUnknown: The name org.desktopcouch.CouchDB was not provided by any .service files
[10:22] <aquarius> nomnex, I'm not sure about why it's installable on jaunty if desktopcouch isn't available. Rodrigo would know (he's the author of evolution-couchdb) but he is inconsiderately on holiday :)
[10:23] <nomnex> Rodrigo, that was the name on the post. His he around sometimes?
[10:23] <aquarius> yep, he'll be around all the time from next week, he's just away this week :)
[10:23] <aquarius> ah, I know why; evolution-couchdb can be set up to talk to a system couchdb for testing. But it's not actually useful unless you have desktopcouch, which is only available in 9.10 and onwards
[10:23] <nomnex> escaping angry 9.04 users;-)
[10:23]  * aquarius laughs
[10:23] <aquarius> I bet that was his plan :)
[10:25] <nomnex> aquarius: thanks to clear that up. One more thing, desktopcouch will not be implemented on Jaunty for sure?
[10:25] <aquarius> nomnex, no, it won't be, at least not by us; it requires quite a lot of stuff that would be a nightmare to backport
[10:26] <aquarius> if someone else really wants it to happen then I'd be happy to talk about what would be required and give them some pointers, though!
[10:26] <aquarius> are you not able to upgrade to karmic?
[10:27] <nomnex> do you mind break it up to me. evolution-couchdb is the plug-in to communicate with a database. What is the desktopcouch, I am lost with all the terms. I will update on Jaunuary for good.
[10:28] <aquarius> CouchDB is a database. desktopcouch is a thing which provides every user with their own personal CouchDB (rather than one for the whole system, like mysql or other databases), and allows the data in that personal CouchDB to be synchronized with other computers and with Ubuntu One. evolution-couchdb creates an addressbook which stores its contacts in your personal desktopcouch.
[10:29] <aquarius> does that make sense?
[10:30] <nomnex> Yes, now it does. what do I need to install on a default Karmic install. desktopcouch, evolution-couchdb? or everything comes pre-installed?
[10:31] <aquarius> desktopcouch comes pre-installed. I can't remember whether evolution-couchdb comes pre-installed or not, but I'm pretty sure that it does :)
[10:31] <aquarius> (if not, you can just install evolution-couchdb)
[10:31] <nomnex> okay, thanks for your explanations aquarius:)
[13:39] <urbanape> morning, all
[13:41] <aquarius> nah, teknico is face today, we swapped :)
[13:41] <teknico> aquarius, no, joshuahoover2 is :-)
[13:42] <aquarius> teknico, ha! so you swapped with me, and then swapped again with joshuahoover2? :)
[13:42] <teknico> the second not really a swap, but yes :-)
[13:42] <teknico> he couldn't tomorrow
[13:44] <Chipaca> wheels within wheels! or swaps within swaps, or something
[13:55] <aquarius> hola mattgriffin
[14:01] <urbanape> ah, woops
[14:05] <dobey> hmm
[14:06] <dobey> this weather has got to go
[14:17] <rtgz> did I miss something?
[14:18] <dobey> probably? :)
[14:19] <dobey> aquarius: what does desktopcouch require in 9.10 that would be horrible to backport? just the new couchdb?
[14:20] <aquarius> dobey, new couchdb and its depdencies (erlang, for one)
[14:20] <dobey> aquarius: does it need a new erlang?
[14:21] <rtgz> dobey, the last thing i remember was to sign the canonical agreement for the changes to be merged. At the same time, these changes were approved/disapproved a number of times and I need to get glib-genmarshal into two different branches forked from existing branches which is a little bit more of manual work than I first expected... Is it possible to merge the changes and have marshaller generator added later as a single commit?
[14:21]  * rtgz hasn't typed much in IRC for some days so beware!
[14:21] <aquarius> dobey, yes; Couch 0.10 needs the Erlang version in karmic (r13, not r12)
[14:21] <dobey> hmm
[14:22] <aquarius> this is why I said it'd be hard. DC itself would run fine in jaunty, but it needs couch features that are only in 0.10+patches, and 0.10 needs a newer erlang, and backporting all that to jaunty sounds pretty non-trivial
[14:22] <dobey> rtgz: did you sign the agreement?
[14:23] <rtgz> dobey, I downloaded it, read it, understood it, agreed with it, attached it to the message, signed the message, signed the message with PGP and sent it
[14:25] <rtgz> dobey,  To: contributor dash agreement at canonical doc com and Elliot Murphy
[14:25] <dobey> rtgz: ok
[14:42] <dobey> rtgz: one of your branches is approved/landed now anyway :)
[14:44] <rtgz> dobey, oookay... the one w/o marshallers, the strcmp() one, ok.
[14:45] <dobey> rtgz: yes, the simple one :)
[14:50] <teknico> gotta go, so here's my standup report in advance:
[14:50] <statik> rtgz, welcome to the team!
[14:50] <teknico> DONE: more reviews, fighting with pqm to land branches, testing funambol sync
[14:50] <teknico> TODO: more testing funambol sync, holidays
[14:50] <teknico> BLOCK: none
[14:50] <joshuahoover2> yes, congrats rtgz and thank you VERY MUCH for all your contributions!
[14:51] <rtgz> statik, joshuahoover2 thanks!
[14:52] <rtgz> next stop - find out the reason why nautilus plugin crashes nautilus
[14:54]  * rtgz had every video for 2008-2009 years converted to vorbis/theora... It's amazing how many things I have been postponing... 
[15:04] <Chipaca> wot, no standup?
[15:04] <vds> Chipaca: please start it :)
[15:05] <Chipaca> MEETING BEGINS. Blah blah blah DONE, TODO, BLOCKED blah.
[15:05]  * Chipaca is good at this
[15:05] <vds> me
[15:05] <aquarius> me
[15:06] <Chipaca> CardinalFang: dobey: jblount: teknico: urbanape: PING!
[15:06] <Chipaca> rtgz: you too, don't be shy :)
[15:06] <urbanape> me
[15:06] <rtgz> O_O
[15:06] <urbanape> yeah, you're a contributor now
[15:06] <CardinalFang> me
[15:07] <rtgz> s/O_O/me/
[15:08]  * Chipaca read it that way already
[15:08] <Chipaca> dobey: jblount: teknico: last call
[15:08] <Chipaca> mandel: you too (say "me")
[15:08] <urbanape> teknico did his before running off
[15:09] <Chipaca> ah, I missed that
[15:09] <urbanape> easy to miss, what with the DONE, TODO, and BLOCK
[15:09] <dobey> me
[15:09] <urbanape> I thought I had missed the standup
[15:09] <dobey> ☺ DONE: Reviewed Nautilus fixes from rtgz, More initial new client work
[15:09] <dobey> ☹ TODO: New Client Code, Bug stuartm, E-mail motu-council
[15:09] <dobey> ☹ BLCK: None.
[15:09] <Chipaca> vds: you
[15:10] <vds> DONE: 30 free plans #403941 branch landed after fight with PQM and failing tests, testing sync with mobile phones
[15:10] <vds> TODO: more testing with mobile devices
[15:10] <vds> BLOCKED: waiting for the account form the sms provider...
[15:10] <Chipaca> aquarius: go
[15:10] <aquarius> ⚀ DONE: desktopcouch HTML API docs branch; bugfix branch for DC; add more DC docs to freedesktop.org
[15:10] <aquarius> ⚁ TODO: continue work on desktopcouch developer docs; publish DC HTML API docs somewhere (where?); look at Tomboy xml/html translator; work with rodrigo on Music Store; write up things learned at UDS; step-by-step guide to what happens during contact sync; hand off "pipe" to transfer data between two HTTP connections with twisted 9.0 to lucio's team; make tomboy first-sync experience nicer
[15:10] <aquarius> ⚂ BLOCKED: test music store; not being able to think of where to put DC API docs because I am clearly stupid
[15:10] <aquarius> urbanape (should that be urbaneape, I wonder?)
[15:10] <urbanape> DONE: Was Face, resurrected the manifest branch for Bindwood, had a few aha! moments about it. Tried to submit to PQM again. Fun fun.
[15:10] <urbanape> TODO: Get other ubuntuone-servers branch reviewed and submitted. Get Bindwood batch-pushing branch reviewed/merged.
[15:10] <urbanape> BLOCK: None
[15:10] <urbanape> rtgz: you're up!
[15:10] <rtgz> DONE: (null)
[15:10] <rtgz> TODO: Debug Nautilus crash with u1 ext, update ubuntuone-client-diagnose with the latest bug info.
[15:10] <rtgz> BLOCK: none
[15:10] <rtgz> CardinalFang, ping
[15:11] <dobey> Chipaca: oh, bad choice of words.
[15:11] <CardinalFang> DONE: read mandel's contacts-wrapper branch, and agonized over where it should go.  Do we want to get in the ORM and record-type business?  Some 'contrib' module?  Hrmpf.  One sick day, Wed.
[15:11] <CardinalFang> TODO: release karmic update for desktopcouch.
[15:11] <CardinalFang> BLOCKED: one
[15:11] <CardinalFang> dobey, sir!
[15:11] <dobey> ☺ DONE: Reviewed Nautilus fixes from rtgz, More initial new client work
[15:11] <dobey> ☹ TODO: New Client Code, Bug stuartm, E-mail motu-council
[15:11] <dobey> ☹ BLCK: None.
[15:11] <Chipaca> aaand.... that's about it
[15:12] <Chipaca> oh, me! DONE: talked with people, planned things, talked with more people. TODO: more. BLOCKED: no
[15:12] <Chipaca> EOM!
[15:12] <Chipaca> thanks all
[15:12] <urbanape> danke
[15:12]  * rtgz needs to write a plugin for such type of meeting :)
[15:12] <CardinalFang> I have a rallying-call plugin for xchat.
[15:13]  * rtgz always needs to write something :)
[15:13] <CardinalFang> http://bazaar.launchpad.net/~cmiller/+junk/warthogs_scripts/files
[15:15]  * dobey blinks at CardinalFang's code
[15:15] <dobey> *stan*up?
[15:16] <CardinalFang> dobey, what?
[15:16] <dobey> CardinalFang: your xchat plug-in has the function "stanup_meeting_begins"
[15:17] <CardinalFang> Oh.  Right.  Oh well.
[15:22] <rtgz> dobey, so is it ok to have glib-genmarshal added as a subsequent patch?
[15:24] <dobey> rtgz: the one branch needs to be split up so that the marshaller stuff isn't in it at all. and i'd rather avoid landing code that we know is going to be changed immediately afterward
[15:24] <dobey> rtgz: doing so makes it especially difficult to backport
[15:24] <mandel> CardinalFang,  hello, why the agony? :P
[15:26] <rtgz> dobey, okay, then I will create 2 new branches - one for emblems + glib-genmarshal and one for ShareCreateError which will use info from the first branch. Is it OK to depend this way?
[15:27] <dobey> you can have a branch which depends on another, yes
[15:42] <rtgz> dobey, lp: "Deleting a proposal for merging will also delete all the associated comments that have been made.", ok to proceed?
[15:50] <dobey> rtgz: which one are you deleting?
[15:50] <rtgz> both - fix-emblem-updating and fix-share-create-error-cb
[15:50] <rtgz> dobey, ^
[15:51] <dobey> ok
[15:51] <dobey> just don't delete branches/proposals for things that were merged :)
[15:53] <rtgz> dobey, no, not in "destroyer" mood this year
[15:53] <aquarius> are you even allowed to delete branches that have been merged? that seems like a bug, if so
[15:53] <dobey> yes
[15:54] <dobey> you can delete anything you "own"
[15:54] <dobey> well, except for bugs and comments
[15:54] <dobey> but i think deleting a branch, deletes all the comments on any merge proposals for it
[15:55] <dobey> as the proposals get deleted
[15:59] <dobey> is there an easy way to print the calling method's name, in python?
[16:01] <aquarius> the call stack knows that stuff
[16:02] <dobey> right
[16:02] <dobey> <- not a python developer, remember :)
[16:05] <aquarius> hang on, working on it :)
[16:09] <aquarius> sys._getframe(1).f_code.co_name
[16:09] <aquarius> why do you want this?
[16:09] <aquarius> that'll break if, for example, you are not in a function :)
[16:10] <dobey> because i'm debugging a weird error in my branch :)
[16:11] <aquarius> pdb?
[16:13] <dobey> even more foreign to me :)
[16:14] <aquarius> at the point at which you want to break, do "import pdb; pdb.set_trace()" and then when it hits that line it drops you into the debugger
[16:14] <aquarius> which is relatively simple; you've got single-step, step into, step out, like most debuggers, and you can inspect the environment and vars and so on
[16:24] <dobey> ugh
[16:25] <dobey> something is eating my variable
[16:27] <dobey> hrmm
[16:27] <dobey> apparently creating oauth.OAuthError() dereferences the original variable
[16:27] <urbanape> variablemonster
[16:27] <dobey> evil.
[16:28] <urbanape> V IS FOR VARIABLE, AND THAT'S GOOD ENOUGH FOR ME, 'CAUSE VARIABLE VARIABLE VARIABLE STARTS WITH 'V'!
[16:28] <joshuahoover2> urbanape: have you recorded that one before? sounds familiar
[16:29] <urbanape> OM NOM NOM NOM NOM NOM
[17:57] <mandel> aquarius: ping
[17:57] <aquarius> pong!
[17:59] <mandel> aquarius: hello, one quick question, is there a bulk update for records?
[17:59] <aquarius> not in the desktopcouch.records API. There is in python-couchdb.
[17:59] <aquarius> do you need it?
[18:00] <mandel> aquarius: I know about python-couchdb... well, it would be nice but it is not required
[18:00] <mandel> aquarius: not a big deal :P
[18:00] <aquarius> mandel, if you need it, adding it to the desktopcouch API would be reasonable -- we deliberately didn't implement everything, so as to see what people really needed
[18:02] <mandel> aquarius: well, I've started implementing groups and tags for my app and I want to let the user tag a bunch of contacts at once, so it would be nice to do it in a single put
[18:03] <aquarius> that's bulk updates, then :)
[18:03] <aquarius> I'd be interested in exactly how the API should look. Perhaps CouchDatabase.bulk_update([Recordobject, Recordobject, ...])
[18:04] <mandel> great, other quick questions, is there any doc which states where I have to put the views used by my app (I think you told me at UDS about a dir) and how to use the callback that tells about updates?
[18:05] <mandel> bulk_put might be a nicer name since we do not have an update
[18:05] <aquarius> first question: http://www.freedesktop.org/wiki/Specifications/desktopcouch/Documentation has the answers :)
[18:05] <aquarius> second question: that page should also have the answers but I haven't documented _changes yet
[18:06] <aquarius> CardinalFang, do we have any docs on how the _changes callback works?
[18:11] <mandel> aquarius: uh and an other funny thing, when the db starts asking for username and password on the browser, an app using desktopcouch can access it but evolution says "This address book cannot be opened.  This either means that an incorrect URI was entered, or the server is unreachable, Permission denied"
[18:12] <aquarius> that's because evolution-couchdb is looking for the tokens in the wrong place. Rodrigo's fixed this, but the fix isn't rolled out to a PPA yet.
[18:13] <urbanape> I'm more and more convinced that I should just use the locally-generated UUIDs for couch _ids, but crap. I don't want to put in a whole migration step.
[18:13] <mandel> aquarius, ok cool
[18:14] <aquarius> urbanape, can't you just start using them for new ones? they're not gonna collide with existing ones, that's the point of a uuid :)
[18:14] <urbanape> yeah, but then I'm dealing with two different ways of looking up docs in Couch. Two different means of identifying them.
[18:15] <aquarius> um, why? you don't care what an _id *is*, it's just a string that you pass around, no? Am I missing something?
[18:15] <aquarius> oh you're using the Moz IDs as the ID for a couch record?
[18:15] <aquarius> aha.
[18:15] <aquarius> yes.
[18:15] <aquarius> migration step for you, then
[18:16] <aquarius> that came out sounding rather harsher than I intended it to
[18:16] <urbanape> it's just that now, we do two requests to get a document based on our internal uuid. Well, a request to search for a doc with that uuid, and then a request to do something with that doc. So, yeah.
[18:17] <urbanape> aquarius: well, I'm proposing using the moz uuid for the couch id, since CardinalFang says that's the best practice.
[18:17] <aquarius> ah, gotcha, I understand.
[18:17] <aquarius> yeah. You'll need to rev the record_type_version
[18:18] <aquarius> which means that you can tell the difference between old and new records.
[18:18] <urbanape> why would the record type version need to change? No change to the schema
[18:18] <urbanape> just for this sake?
[18:23] <urbanape> I could migrate opportunistically, but that leaves a probably-disused code path for who knows how long?
[18:24] <urbanape> probably-disused after everything's been migrated...
[18:24] <aquarius> you're changing the meaning of one of the fields...
[18:26] <aquarius> anyway, I have to eat food before I die. Later!
[18:27] <urbanape> hrm. poo. I don't see how I'm changing any of the fields. I'm merely doing the Right Thing with the _id: client generated, rather than server generated.
[18:38] <zeroXten> o/
[18:41] <mattgriffin> zeroXten: hi!
[18:43] <zeroXten> heya. just listening to floss podcast, they mentioned something todo with sharing via ubuntuone
[18:44] <zeroXten> you add their email address and it appears on their machine?
[18:45] <mattgriffin> zeroXten: yeah. right now we only support file sharing. we'll probably develop more sharing features (like for contacts) in the future
[18:45] <zeroXten> does that user get warned or do you need a predefined relationship with them?
[18:46] <mattgriffin> zeroXten: but yeah... file sharing is easy with Ubuntu One. Right click on the folder in ~/Ubuntu One that you want to share and choose "Share on Ubuntu One"
[18:47] <mattgriffin> zeroXten: type their email address and we send a sharing request for you. if the recipient isn't an Ubuntu One subscriber, we guide them through the signup process. otherwise they just sign into the website with their account to claim the share.
[18:47] <zeroXten> oh, so they have to click an acknowledgement before it syncs
[18:47] <mattgriffin> zeroXten: as soon as they accept the share, the folder starts to download to their computer in their ~/Ubuntu One/Shared With Me folder
[18:47] <zeroXten> ahh cool ;)
[18:48] <mattgriffin> zeroXten: right
[18:48] <zeroXten> phew
[18:48] <Chipaca> zeroXten: yes, they do need to accept it :)
[18:48] <zeroXten> wasnt clear in the podcast :)
[18:48] <zeroXten> cool
[18:48] <mattgriffin> zeroXten: yeah. was there anything else that interested you from the podcast?
[18:48] <Chipaca> zeroXten: if you already have a share with the other person, things you put in the directory you've shared appear automagically
[18:49] <Chipaca> zeroXten: so you could do social engineering to do evil, but the bar is probably high enough
[18:49] <mattgriffin> Chipaca, zeroXten: that's a nice feature ... especially if you're working on a project and need to share multiple files periodically
[18:51] <zeroXten> yeah ok
[18:51] <mattgriffin> zeroXten: where did you hear about the podcast?
[18:51] <zeroXten> uhh, i guess my only other question prior to reading would be.. one sec
[18:52] <zeroXten> mattgriffin: i rss floss weekly on twit
[18:52] <mattgriffin> zeroXten: nice
[18:52] <zeroXten> on my g1
[18:52] <zeroXten> man, 3g on a bus is flaky
[18:52] <mattgriffin> :)
[18:53] <zeroXten> anyway, is it possible to have the client connect to a private ubuntuone? ie for business use etc
[18:56] <mattgriffin> zeroXten: good question. the sync client is open so it can be studied/altered/improved in any way. the server is not open but i think most of the functionality can be analyzed to build your own server.
[18:57] <zeroXten> heh cool
[18:58] <zeroXten> not gonna happen anytime soon tho :) my projects list is already too big :)
[18:58] <mattgriffin> zeroXten: to be honest though, ubuntu one would get the most widespread value if we had client support on more platforms. some developers have produced some great results for Fedora and Kubuntu but we would love to see (and would greatly encourage) people porting the sync client to other platforms (like your G1) :)
[19:00] <zeroXten> hehe. that would be cool indeed. i have only written one tiny app for android and java is not my idea of a fun time :)
[19:00] <zeroXten> that and im not a developer
[19:01] <zeroXten> but i might take a look when i get free time
[19:02] <zeroXten> right, battery about to die. laters
[19:02] <mattgriffin> zeroXten: please do. and tell your friends :) ... stuart (from the FLOSS Weekly episode) has a G1 so he'd be interested in it as well
[19:06] <CardinalFang> I have an Android device too.  I'd love to-do and note synch.
[19:06] <dobey> tomdroid should already work to sync notes :)
[19:07] <CardinalFang> I can not create notes, though, last I checked.
[19:08] <CardinalFang> thisfred_, what do you make of this?  https://bugs.edge.launchpad.net/ubuntu/+source/desktopcouch/+bug/461356
[19:08]  * thisfred_ looks
[19:09] <thisfred_> CardinalFang: hmm looks like an incomplete/broken installation. Either that or the import paths are somehow wrong for that user
[19:10] <thisfred_> they have python-desktopcouch installed it seems
[19:11] <thisfred_> I have no idea how that could happen
[19:11] <CardinalFang> I'm un-marking that as private.
[19:11] <thisfred_> it's failing to import desktopcouch from /usr/lib/desktopcouch
[19:12] <thisfred_> CardinalFang: do we somehow do something wrong wrt dist-packages?
[19:12] <thisfred_> because I would expect the python code to live in a pythony place
[19:13] <thisfred_> so, in brief: no idea, sry
[19:22] <CardinalFang> thisfred_, it should be in /usr/share/pyshared/desktopcouch
[19:23] <thisfred_> CardinalFang: right. I have no idea how ubuntu does those things now
[19:23] <rtgz> bzr guys, can I push a certain revision from my local branch, i.e. will bzr push -r 295 lp:~someone/... work ?
[19:24]  * rtgz is a newbie in distributed versioning control systems
[19:24] <rtgz> mattgriffin, ^ :) sorry if this is completely off-topic
[19:25] <dobey> no
[19:25] <dobey> push only works on branches
[19:26] <dobey> it pushes all committed revisions
[19:26] <rtgz> dobey, all committed, so if I haven't committed "next" revision then I am safe to push
[19:26] <rtgz> hm, -r option was so tempting...
[19:27] <dobey> hrmm
[19:28] <dobey> the docs for -r are so lacking
[19:28] <dobey> i guess it would push everything up to that revision, and not stuff after it perhaps
[19:32] <rtgz> dobey, woo-hoo
[19:33] <rtgz> dobey, -r revision creates branch with this revision as the head :)
[19:52] <rtgz> hm, after I made necessary changes for the emblem I can reproduce the bug with create share dialog segfaulting nautilus... But I haven't touched that part at alll!...
[19:53] <rtgz> #0  0x006d52c2 in g_path_get_basename () from /lib/libglib-2.0.so.0
[19:53] <rtgz> #1  0x00e379a2 in ubuntuone_nautilus_share_dialog_construct (item=0xb7453d60,
[19:53] <rtgz>     user_data=0x83da820) at ubuntuone-nautilus.c:451
[19:53] <dobey> hrmm
[19:53] <rtgz> in case someone is interested
[19:53] <rtgz> it's too quiet here
[19:55]  * rtgz wonders why he installs dbg symbols _after_ they are required...
[19:56] <dobey> weird
[19:56] <rtgz> this time: (nautilus:29705): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()
[19:56] <rtgz> and it crashed
[19:56] <rtgz> i guess the previous time I have hit extremely unitialized memory...
[20:00] <rtgz> dobey, Here's the screenshot: http://picasaweb.google.com/roman.yepishev/Bugs#5416297336262720994
[20:02] <dobey> huh
[20:03] <dobey> brb
[20:25] <rtgz> okay, got the full bt with g_warning causing the same data->path-related segmentation fault #4  0x0052b486 in IA__g_strdup_vprintf (
[20:25] <rtgz>     format=0xc63164 "share construct: data->path = %s",
[20:25] <rtgz>     args=0xbfffe03c "e _w\001")
[20:27] <CardinalFang> rtgz, what's in the frame above this?
[20:27] <CardinalFang> I'm interested in the "args".
[20:28]  * CardinalFang hasn't touched GDB in 10 months.  That's a record for him.
[20:30] <rtgz> copying to paste.ubuntu.com ... 0% done
[20:31] <rtgz> CardinalFang, http://paste.ubuntu.com/343673/
[20:34] <CardinalFang> rtgz: I'm no expert but the word "closure" piques my interest in that, especially because the memory is not what you expected.  Your probably not using some malloc replacement that auto GCs, are you?  Hrm.
[20:37] <rtgz> CardinalFang, no idea yet, I haven't written much glib code yet...
[20:37] <CardinalFang> rtgz, what's up at frame 7?  ubuntuone_nautilus_share_dialog_construct (item=0x88c9100, user_data=0x86e4428) at ubuntuone-nautilus.c:449
[20:40] <dobey> line 449 is the call to destroy the dialog
[20:43] <dobey> rtgz: what revision of the code is this crashing on?
[20:44] <rtgz> dobey, this is trunk + some additions for marshalling, let me copy-paste the relevant code
[20:49] <rtgz> dobey, http://paste.ubuntu.com/343676/
[20:51] <rtgz> dobey, it is not ready for commit, really, I was just applying the changes and testin...
[20:53] <rtgz> dobey, wrong file
[20:55] <rtgz> dobey, http://paste.ubuntu.com/343677/
[20:58] <dobey> hmm
[21:01] <dobey> that doesn't match up with your backtrace either
[21:02] <dobey> oh, nevermind, i remembered the line # wrong
[21:03] <dobey> doesn't make any sense though
[21:23] <rtgz> dobey, so data->path comes with something bad
[21:23] <dobey> well yes i see that
[21:24] <dobey> but i don't see how :)
[21:32] <rtgz> dobey, cannot reproduce now, need more unitialized memories
[21:36] <rtgz> dobey,   file = g_list_nth_data (files, 0); path = g_filename_from_uri (nautilus_file_info_get_uri (file), NULL, NULL); Still blame this
[21:44] <dobey> rtgz: worst case that should return NULL
[22:27] <rtgz> data->path = U\x89\xe5\x83\xec(\x89]\xf4\xe8\xf9\xfc\xff\xff\x81\xc3\xd6\xe0\u0007
[22:35] <dobey> hrmm
[22:37] <dobey> but how
[22:51] <rtgz> dobey, rogram received signal SIGSEGV, Segmentation fault.
[22:51] <rtgz> IA__g_path_get_basename (
[22:51] <rtgz>     file_name=0x775f2065 <Address 0x775f2065 out of bounds>)
[22:51] <rtgz> i am lucky this evening
[22:53] <rtgz> grrr, forgot to add debug output to the dialog_construct code...
[23:01] <rtgz> data->path gets rewritten somehow, and it looks like something strange is happening with the pointers in share_cb_data... (sorry for spamming, just for logs) :)
[23:14] <rtgz> dobey, http://paste.ubuntu.com/343697/
[23:15] <rtgz> So
[23:18] <rtgz> it appears that nautilus caches the share_cb_data pointer for the folder (volia-traffic_), line 83. Then when menu is called (line 95) get_menu_items is called again, with the same path, share_cb_date gets free()d (since it is old, line 99) and we create a new instance, line 101. But when share_folder is called, it receives the original pointer, which might point to anything now.
[23:18] <rtgz> dobey, ^
[23:18] <rtgz> now the question is why it does not crash all the time..
[23:20] <rtgz> get_menu_items is called once for every file in the directory and the next time is when user selects the file icon.
[23:35] <rtgz> oookay
[23:35] <rtgz> http://paste.ubuntu.com/343703/
[23:35] <rtgz> Why is get_menu_items called when we click on the menu item???
[23:45] <Scunizi> Hey mattgriffin.. header topic said to ask you.. when manually logging into one.ubuntu.com and choosing Note>Add Note .. there is no clear defined way to "save".  Quite by accident I hit the "Edit" button which seemed to effective act as a Save button.. Is that the way it's suppose to be?
[23:46] <Scunizi> Or anybody really :)
[23:46] <mattgriffin> Scunizi: yeah. have any ideas on improving the usability?
[23:47] <mattgriffin> Scunizi: or does that work for you?
[23:47] <mattgriffin> Scunizi: perhaps not because you're asking me about how it works ;)
[23:49] <Scunizi> mattgriffin: well.. perhaps when you're already in "edit" mode the button wording changes to "Save"
[23:50] <mattgriffin> Scunizi: excellent suggestion. would you open a bug for this? http://bugs.launchpad.net/ubuntuone-client
[23:51] <Scunizi> mattgriffin: sure.. I'm surprised nobody else has suggested this ..
[23:51] <mattgriffin> :)
[23:51] <Scunizi> all it takes is one I guess :)
[23:52] <mattgriffin> that's true
[23:57] <Scunizi> mattgriffin: there you go! Bug #498018 .. https://bugs.launchpad.net/ubuntuone-client/+bug/498018
[23:57] <mattgriffin> Scunizi: excellent. thank you.
[23:57] <Scunizi> Wow.. Is ubottu linked to the channel?
[23:57] <Scunizi> for bug reports?
[23:58] <mattgriffin> Scunizi: hmm... i guess so. i don't think it used to be that way.