[14:14] <mandel> hello, cann anyone tell me why I'm getting a 500 when I try to view contact data in ubuntuone?
[14:18] <rtgz> mandel, hm, looks fine for my contacts. Any additional messages?
[14:18] <mandel> nah, just a 500
[14:19] <mandel> but I'm testing my application on desktopcouch and I'm using the new attachment code added my Chad, I was wondering if that makes any diff
[14:20] <mandel> is there anyone that can look at the logs looking at my user? I;m wondering if is the avatar added by my app as an attachment 'cause evo and my code have no problem
[14:21] <mandel> I forgot to mention that the source of the docs in couchdb is my app
[14:21] <dobey> well i'm sure there's an OOPS id :)
[14:25] <urbanape> Morning, all
[14:27]  * rtgz looks at his watch - 16:27...
[14:27] <mandel> dobey, anyway to get it?
[14:28] <urbanape> (modulo localtime)
[14:29] <dobey> mandel: it should have been printed on the error page.
[14:29] <dobey> but it's working here ok too...
[14:29]  * aquarius checks too
[14:29] <mandel> really? 'cause I see the nice robot like cartoon but nothing else...
[14:30] <mandel> I'm wondering if it has to do with the format of my doc...
[14:30] <dobey> mandel: yes. but maybe the robot image thing broke that.. jblount ^
[14:32] <rtgz> is there any kind of test error page, when you get there it just manually crashes giving you the overview how the error message will be displayed? something like /oh-noes/ ...
[14:34] <rtgz> he he bug #498194
[14:35] <aquarius> mandel, interesting. I wonder if your contact records have changed and the web UI can't cope with that? That would be bad, if so. (Contacts web UI works for me too, btw)
[14:36] <mandel> the contacts that I create through the web ui work perfectly
[14:36]  * rtgz has a virtual machine for u1 tests, need new virtual lp account for a virtual u1 server :)
[14:36] <rtgz> mandel, is it only one account that causes this?
[14:36] <rtgz> mandel, sorry, one contact entry
[14:36] <mandel> the ones generated by my client are listed, but If I try to access the data, they brake
[14:37] <rtgz> mandel, i guess the server side devs might be interested in the record itself :)
[14:37] <mandel> rtgz, all the one generated from my side, Ill post one doc example, give me a sec
[14:38] <mandel> this is what I've got in my desktopcouch: http://pastebin.com/m4aab8848
[14:39] <mandel> only diff I can thing is that my collections do not have an _order, could that be it?
[14:39] <mandel> and I did not added it because it was not in the spec
[14:40]  * rtgz is waiting for replication to break his contact list as well...
[14:41] <rtgz> this is how contact sharing is implemented ATM :)
[14:42] <thisfred> mandel: which url are you getting the errors on?
[14:43] <mandel> thisfred, this is one of them: https://one.ubuntu.com/contacts/1019e2b361cd4217a9bdb25cdd736878/details/
[14:43] <mandel> but I can replicate the error with any contact that was made in my side
[14:44] <mandel> I can give you one that has no problems with my account, wanna it?
[14:46] <thisfred> mandel: I can not see your contacts so, that's ok, I was just looking for the shape of the url
[14:47] <mandel> thisfred, is just test data, so no problem...
[14:51] <aquarius> bah, make start keeps dying
[14:51] <aquarius> which makes it hard to run up a test version of the contacts web UI to put mandel's contact in :)
[14:51] <rtgz> yup
[14:51] <rtgz> Something has gone wrong (500)
[14:52] <mandel> rtgz, you reproduced the error?
[14:52]  * aquarius updates the sourcedeps. Again.
[14:52] <rtgz> mandel, yup
[14:52] <aquarius> le sigh
[14:52] <mandel> so, what could it be, 'cause I think there is nothing diff in the doc
[14:53] <rtgz> and edge server dies in the same way, no extra info to report.. :(
[14:53] <thisfred> mandel, what is your user id, so that we can grep through the logs for that?
[14:54] <mandel> mandel@themacaque.com
[14:54] <mandel> or mandel, is the email or the username?
[14:54] <thisfred> mandel: I mean the numerical id you'll find in the couchdb urls
[14:55] <thisfred> oh, webm0nk3y found it I think
[14:56] <mandel> you mean the id of the contact?
[14:56] <mandel> that would be this: 1019e2b361cd4217a9bdb25cdd736878
[14:57] <rtgz> mandel, i guess this is where replication goes to should be part of the URL, there is some kind of ID as well...
[14:58] <thisfred> mandel: rtgz yeah, the replication url is something like u/foo/bar/xxx/contacts, xxx would be your user id. But as I said, we've found it. No errors logged
[14:59] <mandel> rtgz, thisfred, ok
[14:59] <thisfred> so the error is not in couchdb, or in the python layer around it, it seems. The web ui itself maybe doesn't know how to deal with the attachment, although I find it strange that it would even notice it;s therte
[14:59] <thisfred> there
[15:00] <Chipaca> desktop+ meeting begins. aquarius, chad, dobey, jblount, mandel, rodrigo, rtgz, teknico, urbanape, vds: you know how it works: say "me" to get a turn, then in your turn say your done/todo/blocked status.
[15:00] <mandel> thisfred, the error happens with a simple doc with no attachment
[15:00] <CardinalFang> me
[15:00] <thisfred> aquarius: I'll try locally
[15:00] <rtgz> me
[15:00] <jblount> me
[15:01]  * Chipaca notes rodrigo and teknico are on holiday and thus won't me
[15:01] <mandel> me
[15:02] <Chipaca> aquarius: dobey: urbanape: vds: PING
[15:03] <vds> me
[15:04] <dobey> me
[15:04] <Chipaca> aquarius aquarius aquarius
[15:04] <Chipaca> urbanape urbanape urbanape
[15:05] <Chipaca> CardinalFang: go
[15:05] <CardinalFang> DONE: Sorted distro d-c bugs.  Some progress on releasing desktopcouch stable update.  Re-tagged d-c on releases, as the source-package bzr tools require tags.
[15:05] <CardinalFang> TODO: file a bug on tarmac about discarding tags.  Finish releasing d-c.  Pester james_w a lot.
[15:05] <CardinalFang> BLOCKED: Understanding.
[15:05] <CardinalFang> rtgz, give me the low-down!
[15:05] <rtgz> DONE: Marshallers and file emblems fixed (waiting for merge), diagnosed nautilus crash with Share on Ubuntu One dialog.
[15:05] <rtgz> TODO: Update ubuntuone-client-diagnose with the latest bug info. Check what can be done with folder emblems (got some ideas) - bug #440848. Dig into nautilus to find out why our routine is called twice. Ping dobey regarding bug #498136.
[15:05] <rtgz> BLOCK: none
[15:05] <rtgz> jblount, *whatever I should say*
[15:06] <jblount> DONE: Took last random holiday off
[15:06] <jblount> TODO: Make forum icon overlay thing, Work on layout issues for /plans and /support/account-assistance
[15:06] <jblount> BLCOKED: Nope
[15:06] <jblount> mandel: you!
[15:07] <mandel> DONE: Played with tags and group implementation in my app
[15:07] <mandel> TODO: Update UI in macaco-contact to refect changes
[15:07] <mandel> BLOCK: NONE
[15:07] <mandel> vds, go
[15:07] <vds> DONE: more testing sync with mobile phones, finally got a new sim card for the testing handset, started a branch to fix problem noticed testing with handset, code review
[15:07] <vds> TODO: more testing with mobile devices, setup funambol to send sms
[15:07] <vds> BLOCKED: no
[15:07] <vds> dobey: vai!
[15:07] <dobey> ☺ DONE: More initial new client work
[15:07] <dobey> ☹ TODO: Reviews, New Client Code, E-mail motu-council
[15:07] <dobey> ☹ BLCK: None.
[15:08] <dobey> aquarius, urbanape: fight!
[15:08] <urbanape> me
[15:08] <urbanape> woops
[15:08] <thisfred> mandel: when did you first notice the 500 error?
[15:08] <urbanape> DONE: Made some progress on manifest branch, ubuntuone-servers branch finally passed PQM, review of next branch should be easier
[15:08] <Chipaca> urbanape: go
[15:08] <thisfred> (our logs may be up to an hour out of date)
[15:09] <urbanape> TODO: Get other branch reviewed/submitted, keep moving on manifest branch
[15:09] <urbanape> BLOCK: None
[15:09] <mandel> thisfred, yesterday, during the night, but that is because I've never looked before
[15:09] <urbanape> aquarius: you're up, I guess
[15:09] <thisfred> mandel: ah ok, so we should have some in the logs then
[15:10] <mandel> thisfred, yes, and it is quite easy to reproduce, any contact I do in my side will break
[15:10] <thisfred> mandel: I'm going to try to reproduce this on my machine, if I can set the web ui and server all up correctly
[15:10] <Chipaca> desktop+ EOM. CardinalFang, dobey, jblount, mandel, rtgz, urbanape, vds: thanks!
[15:11] <Chipaca> CardinalFang: are you really blocked by (presumably your) understanding? is there anything we can do to unblock you?
[15:12] <mandel> thisfred, do you need any testing data? I can send you a bunch of different docs
[15:13] <thisfred> mandel: the one you pastebinned above fails yes? I'll try that one first
[15:14] <thisfred> thanks for helping us track this down!
[15:14] <mandel> thisfred, yes that one fails also rtgz  got the same error.
[15:15] <urbanape> taking an early lunch to run some errands. BBL.
[15:15] <CardinalFang> Chipaca, I may not be blocked.  I'm just bellayaching about how releasing is supposed to be easier and it isn't so far.
[15:15] <mandel> thisfred, I hope I could help more, but from the client side there i no much I can do :P
[15:15] <Chipaca> CardinalFang: apt-get install digestive-salts?
[15:16] <CardinalFang> It Depends on ubuntu-patience, which isn't available.
[15:17] <dobey> grr, lp apparently does funky stuff with diffs now
[15:20] <rtgz> wrote "invalidate extension date". Yeah, extension does not want to date again :/
[15:31] <dobey> verterok: is get_metadata going to start sending full paths?
[15:31] <verterok> dobey: fullpaths?
[15:32] <dobey> verterok: it looks like get_metadata currently has only "foo/blah" as the "path" in the dict. i think that will be problematic with the user defined folders, no?
[15:32] <verterok> dobey: get_metadata returns the metadata of a full path
[15:33] <verterok> dobey: no, because the info also contains the share_id (probably will be renamed to volume_id)
[15:34] <dobey> verterok: but that's not the local path of the folder is it?
[15:34] <verterok> dobey: yes, it is :)
[15:34] <verterok> dobey: but we can add a more fine grained methods for whatever metadata you guys need ;)
[15:34] <dobey> oh, it's not a hash id?
[15:34] <verterok> dobey: hash_id?
[15:35] <dobey> verterok: share_id
[15:35] <dobey> verterok: it's a path, and not a hash?
[15:35] <verterok> dobey: it's a uuid
[15:35] <dobey> or a uuid
[15:35] <dobey> i need the path
[15:36] <verterok> dobey: but you already have the path... it's the argument passed to get_metadata..right?
[15:36] <dobey> verterok: yes and no. we have the path when we make the call, but not when we finish it
[15:36] <dobey> verterok: async APIs are hell :)
[15:37] <verterok> dobey: don't know about that, I use twisted ;)
[15:37] <dobey> twisted doesn't do dbus :)
[15:37] <verterok> dobey: it does ;)
[15:37] <dobey> but yes, it's easier to deal with in a dynamic language like python
[15:38] <verterok> dobey: so, you need the fullpath in get_metadata? for what are going to use get_metadata output?
[15:38] <verterok> dobey: maybe we can add a new and optimized method...get_metadata is quite generic
[15:38] <dobey> verterok: we're calling get_metadata to determine what files need updating
[15:39] <verterok> dobey: so, we'r doing a get_metadata call for each path?
[15:40] <dobey> verterok: for every file under Ubuntu One, that gets displayed in an open nautilus window, yes
[15:40] <verterok> ouch? :)
[15:40] <Chipaca> sounds like that should be a single call
[15:40] <verterok> Chipaca: I was thinking on the same thing :)
[15:41] <verterok> dobey, Chipaca: I was also thinking in a get_me_the_sync_status_plzzz(<list of paths>) method
[15:41] <dobey> there is no way to do a single call for it in nautilus
[15:41] <Chipaca> dobey: no?
[15:41] <dobey> nope
[15:42] <Chipaca> dobey: get_metadata_for_all_files_in(directory) ?
[15:42] <dobey> we get a update_fileinfo call for every file individually, in the extension
[15:42] <dobey> Chipaca: we don't ever get a list of files
[15:42] <dobey> we'd have to do a lot of extra work to do that, and it would be very painful
[15:43] <dobey> though... one of rtgz's branches might make that a little easier, but not a lot
[15:44] <Chipaca> darn
[15:44] <rtgz> dobey, don't see how any of the branches might help that :(
[15:45] <dobey> rtgz: the one that stores the weak references to NautilusFileInfos
[15:45] <rtgz> dobey, yep, but there references like to go away after some time...
[15:46] <rtgz> and we can't get a fs snapshot... this will mean more caching inside the plugin which already contains a lot of them.
[15:47] <dobey> well, the big problem is we will never know when all the files are ready to pass on to the get_all_metadata call
[15:48] <dobey> so yeah, can't do that
[15:48] <rtgz> we might ... hm... there are 2 calls in nautilus - first for get_file_items and second get_background_items. The background one is called once per folder... we might try to collect all files, issue some combined request and later on wait for it to complete...
[15:48] <rtgz> need to check this
[15:50] <dobey> that's not what you think it is
[15:50] <dobey> get_background_items() is the call to get the menu items to add when you right click on the "background"
[15:51] <Chipaca> verterok: ok, so we can't bunch up calls without more work than makes sense
[15:51] <rtgz> dobey, true... debugged the sharing stuff for too long, now I try to attach these calls to whatever seems distantly connected.
[15:51] <Chipaca> verterok: can you make any async call response include everything that was passed in (that makes sense)?
[15:51] <aquarius> hi sorry back now
[15:52] <dobey> if the path were just the full path, we'd be fine
[15:52] <dobey> i thought it was anyway
[15:52] <verterok> dobey: we can add the fullpath
[15:52] <aquarius> ⚀ DONE: desktopcouch HTML API docs branch; bugfix branch for DC; add more DC docs to freedesktop.org
[15:52] <aquarius> ⚁ TODO: test music store!; 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:52] <aquarius> ⚂ BLOCKED: not being able to think of where to put DC API docs because I am clearly stupid
[15:52] <verterok> Chipaca: /me don't understand, please elaborate?
[15:53] <verterok> dobey: please file a bug about this, so it don't get lost in the holidays ;)
[15:53] <thisfred> mandel: one thing I see wrong with your document: you don't use uuids for the keys in the mergeable lists
[15:53] <Chipaca> verterok: do you have the full dbus api somewhere? (I know you put it on pastebin yesterday)
[15:53] <verterok> Chipaca: https://chinstrap.canonical.com/~guillo/syncdaemon_dbus_api.txt
[15:53] <thisfred> I'm trying the web ui locally now
[15:54] <verterok> Chipaca: oops, not public url
[15:54] <mandel> thisfred, really? let me check
[15:54] <dobey> verterok: how about we just fix it right now :)
[15:54] <verterok> Chipaca: http://pastebin.ubuntu.com/343768/
[15:54] <dobey> (although a bug needs to be filed too)
[15:54] <rtgz> dobey, yes, otherwise desync will happen once more :)
[15:55] <mandel> thisfred, from my code => (self.id = uuid.uuid4().hex)
[15:55] <verterok> dobey: I'm doing something completely different right now, and want to get it done asap :)
[15:55] <dobey> verterok: i'll make the branch, it's trivial :)
[15:55] <verterok> dobey: ok :)
[15:56] <mandel> thisfred, they are Mergeable sets, for example phone_numbers is a dict of keys and data, just like the spec
[15:56] <verterok> dobey: thanks btw :)
[15:56] <Chipaca> verterok: schedule_next is blocking, right?
[15:56] <rtgz> please please please merge my branches first, otherwise this would be the 3rd set of 3 branches :)
[15:56] <Chipaca> verterok: by blocking I mean not part of an async conversation
[15:56] <thisfred> mandel: yes, but the keys need to be uuid4 uuids
[15:57] <thisfred> if the spec isn't clear  enough about that, we need to fix it
[15:57] <dobey> rtgz: no, your one branch will just need to be updated
[15:57] <verterok> Chipaca: I think it's a yes: self.action_queue.content_queue.schedule_next(share_id, node_id)
[15:57] <rtgz> dobey, I can commit while it is in proposed state O_O?
[15:58] <dobey> yes
[15:58] <verterok> Chipaca: fwiw, all dbus calls can be async for the client it's just a matter of how the client make the call
[15:58] <verterok> Chipaca: yes, it's "blocking"
[15:58] <Chipaca> verterok: yes. So does the schedule_next throw a ContentQueueChanged?
[15:58] <thisfred> mandel: I don't think the web ui should break over this though ;)
[15:58] <mandel> thisfred, you mean that my ids are not uuid4?  as I said, I use uuid.uuid4().hex
[15:59] <rtgz> honk, btw
[15:59] <mandel> thisfred, isn't that correct?
[15:59] <mandel> and yes, I agree, it should not break 'cause of that
[15:59] <thisfred> mandel: hmm, we use a different notation
[16:00] <verterok> Chipaca: I can't find where ContentQueueChanged is fired
[16:00] <Chipaca> mandel: str(uuid.uuid4())
[16:00] <thisfred> right
[16:00] <mandel> thisfred, ahh let me know which one, so I can change the code (is a one liner)
[16:00] <mandel> ok, I'll change it
[16:00] <thisfred> I'm pretty sure this is the issue. I'll file a bug against the web ui
[16:01] <verterok> Chipaca: found it
[16:01] <verterok> Chipaca: no, it's poking with the deque dirtectly
[16:02] <mandel> thisfred, ok I made the changes on my code, lets try it with a new doc
[16:03] <verterok> Chipaca: basically calling: self.waiting.remove(cmd) + self.waiting.appendleft(cmd)
[16:03] <Chipaca> verterok: me suena, me suena :)
[16:03] <thisfred> mandel: let me know how that goes or if you want me to test it here
[16:04] <verterok> Chipaca: :)
[16:04] <verterok> Chipaca: should it fire a signal?
[16:04] <mandel> thisfred, will do, I'm  working on it right now
[16:05] <Chipaca> verterok: I don't know, I just started going down the api aking myself that kind of quesiton :)
[16:06] <verterok> Chipaca: ok, please file a bug if you think it should ;)
[16:06] <Chipaca> it's not used outside of u1sdtool, and won't be used outside of that during lucid
[16:06] <Chipaca> so, probably not. But as soon as dobey needs to integrate it into the desktop, hell yes :)
[16:08] <mandel> thisfred, is going to take me longer than I though (Can't set '1f1526e8-df92-465a-9eb5-9c0ef304395e'. uuid-like keys are not allowed.)
[16:09] <mandel> I'll try to be quick to fix the issue
[16:09] <thisfred> mandel: no hurry, let me know what happens, or chad/aquarius next week (I'll be on holiday)
[16:10] <mandel> thisfred, oki
[16:12] <rtgz> dobey, sorry if I ping you too much, but what should I set in lp if i have committed a fix for "Needs Fixing" review, "Work in progress"?
[16:14] <dobey> rtgz: no. you just push your fix, and reply to the comment saying you fixed it
[16:15] <rtgz> dobey, thanks :)
[16:19] <dobey> oh
[16:19] <dobey> launchpad is smarter now
[16:20] <dobey> so you don't even need to comment
[16:20] <dobey> it adds the commit info in the middle of the comments :)
[16:21] <dobey> verterok: https://code.edge.launchpad.net/~dobey/ubuntuone-client/getmetadata-fullpath/+merge/16340 :)
[16:23] <mandel> thisfred, made the changes, waiting for replication
[16:24] <thisfred> cool
[16:40] <mandel> thisfred, confirmed, it was the format of the id
[16:40] <mandel> thisfred, interesting bug :P
[16:41] <thisfred> mandel: yeah, python-desktopcouch enforces that format, but nothing else should take it for granted
[16:42] <thisfred> mandel: note that not using that format will break stuff, in that your telephone numbers might not show up or be deleted, but it should not cause errors ;)
[16:43] <aquarius> ?? couchdb _id has to have a specific format?
[16:43] <thisfred> aquarius: not the id
[16:43] <thisfred> aquarius: the keys in the mergeable lists
[16:43] <aquarius> ah, ok
[16:44] <mandel> thisfred, from my point of view by problems was related with the fact that I was not relying on desktopcouch to convert my set to a dict, something very probably for people using other languages
[16:44] <mandel> I meant very probable, pardon my english
[16:44] <mandel> :P
[16:44] <thisfred> mandel: yeah absolutely, so we need to make this a lot clearer
[16:45] <aquarius> what's the problem with using different ids?
[16:45] <mandel> thisfred, adding it in the spec should be good enough
[16:45] <thisfred> aquarius: that it will break
[16:45] <aquarius> thisfred, what will break? sorry, I know I'm catching up late here
[16:45] <thisfred> aquarius: we detect the uuids by the format with the dashes
[16:45] <aquarius> oh...
[16:45] <aquarius> so that's how we know if something's a mergeablelist?
[16:45] <aquarius> oof
[16:45] <thisfred> which is a hack, but there's really no other way
[16:45] <aquarius> that's a bit magic. :)
[16:46] <aquarius> that needs documenting, then :)
[16:46] <thisfred> indeed
[16:46] <thisfred> and: I haven't thought of another way, rather than there isn't one
[16:47] <thisfred> so nobody  stop looking for one! ;)
[16:47] <mandel> can't you just say that if it has _order it is a mergeable list?
[16:48] <mandel> for the list should be true, for a mergeable set, that is another story
[16:48] <thisfred> mandel: no, because we have mergeable sets as well, or at least we don't always have _order I think
[16:48] <aquarius> mandel, mergeablesets don't have _order, though
[16:48] <aquarius> so if we have to have the hack for one we might as well be consistent about it :)
[16:50] <mandel> documenting should be enough for know, at least that way someone will be able to find the problem
[16:51] <mandel> is there a doc validator?
[16:53]  * aquarius wags the waggy finger of disapproval about validators.
[16:53] <aquarius> :)
[16:56] <mandel> at least for the "bloody" id....
[16:57] <mandel> or for debugging, not to use them but for this things, they do help
[16:58] <aquarius> I agree
[16:58] <aquarius> the ID's a weird one, though. I don't think we'd have thought to put that in a validator anyway :)
[17:00] <mandel> well, is good to know why happens, I'll get back to my code, I wanna get ahead during the xmas
[17:07] <mandel> laters
[17:09] <burzki> hey.  new One user, general question .. i have a file on two different machines. have been updating between them manually.  i  upload through One, how will it know which version to sync from?  is there a timestamp process .. or ??
[17:10] <aquarius> burzki, the easiest way to deal with that, at first, is to put that file in your Ubuntu One folder on only *one* of the machines, and let Ubuntu One copy it to the other machine
[17:11] <aquarius> burzki, so, put the version that you consider "most recent" in the Ubuntu One folder, and wait until it's been synced to the other machine
[17:13] <burzki> aquarius, got it.  thx.  second part of my question relates to tomboy updates .. my notes on the two different machines are different sets of notes.  is there a way i can use One to stnc my notes so that the two collections become one and are then complete on both machines?  i'm concerned about one set wanting to 'write-over' the other .. ?
[17:20] <aquarius> burzki, that should Just Work
[17:20] <aquarius> burzki, one set should not overwrite the other
[17:21] <aquarius> burzki, however! I haven't actually, strictly, tried that
[17:21] <aquarius> so you might want to copy your .local/share/tomboy folder somewhere else just in case I'm wrong ;)
[17:21] <burzki> great.  i'll try it.
[17:21] <Chipaca> aquarius: that sounds like the kind of thing that could go in a screencast
[17:21] <burzki> thanks for clarification.
[17:22] <aquarius> Chipaca, syncing notes?
[17:22] <aquarius> burzki, when it works, do please come back and tell us that it worked so we don't have to add the caveat for the next person who asks :)
[17:22] <Chipaca> aquarius: "I'm Joe User and already have stuff on two notebooks. This is how I start using Ubuntu One to keep things in sync automagically."
[17:23] <burzki> aquarius, will do
[17:23] <aquarius> Chipaca, mm, good thought. the key thing is, for files, don't start off with two copies of the same file on the different machines, I think
[17:23] <aquarius> Chipaca, do we plan to change that? or will we always get conflicts if a file is alredy in the Ubuntu One folder when we start syncing, even if the file being synced down and the file already in the folder are the same?
[17:24] <burzki> Chipaca, i agree.  would be nice to have a page off the One homepage saying how all this works, or a little tutorial for this scene
[17:25] <Chipaca> aquarius: No Can Do; there is no application-independent way to tell that case apart from a conflict
[17:25] <Chipaca> aquarius: if they happen to be *exactly* the same, you shouldn't get a conflict, however
[17:26] <aquarius> Chipaca, oh, really? I thought we conflicted even if the files were identical
[17:26] <Chipaca> aquarius: at one point we did. I believe we no longer conflict on file creation erroring out with ALREADY_EXISTS
[17:27] <Chipaca> __lucio__: can you confirm or deny ^?
[17:27] <aquarius> ah, fantastic, that cheers me up no end, then :)
[17:28] <CardinalFang> urbanape, I'm trying to switch to GOOG Chrome browser.  How's the bindwood plugin coming?
[17:29] <__lucio__> Chipaca, we dont conflict on file creation. but we had a bug where a user copied the same stuff to two machines and had conflicts, so we have a bug there
[17:29] <__lucio__> aquarius, ^^
[17:30] <aquarius> __lucio__, cool, cheers
[17:30] <aquarius> __lucio__, since if that's a bug, it will get fixed :)
[17:31] <burzki> thx folks
[17:32] <__lucio__> aquarius, yeah, but i cant promise when, and i wouldnt bet critical stuff on that being fixed soon
[17:32] <__lucio__> aquarius, someone asked for udfs, we are doing those, but we had to not do something else, you know :)
[17:33] <aquarius> __lucio__, ah, I'm not asking for this conflict stuff to be fixed because I'm depending on it, it's just bitten me in the past :-) pure personal desire, which takes a back seat to stuff we actually need to get done!
[17:33] <Chipaca> aquarius: do not mention fixing bugs to __lucio__! You'll hear all about UDFs
[17:33] <Chipaca> aquarius: and you want UDFs for the music store, so shaddup :-D
[17:33]  * aquarius grins. I sho' do
[17:36] <urbanape> CardinalFang: it's a bit blocked on getting the env into the plugin. Looks like the only way that's gonna happen is with an NPAPI plugin.
[17:36] <aquarius> urbanape, yeah, I can't find a way around that, either :(
[17:42] <urbanape> yeah, sad
[18:09] <rtgz> btw, is tomboy note formatting fixed?
[18:17] <urbanape> jblount: if I submit the new-folder-inline-edit branch, will we be able to get the CSS fixed up in time for the next deployment?
[18:20] <statik> push it to zed :)
[18:20] <statik> then you are guaranteed that the related UI branches get done before it's merged to trunk
[18:22] <urbanape> is zed edge?
[18:23] <dobey> zed is like an edge for edge
[18:23] <urbanape> edgy.
[18:23] <dobey> z.one.ubuntu.com
[18:23] <urbanape> and how does one push to zed?
[18:24] <jblount> zed is not yet working, pushing to zed sounds like a bad idea.
[18:25] <jblount> urbanape: I can only give you a maybe, is there a bug that tracks the specific problems?
[18:26] <dobey> test driven development is like driving an SUV in the mountains
[18:26] <urbanape> jblount: nope, but I'll make some. It's about the positioning of the actions icons
[18:27] <jblount> dobey: Overrated and not as safe as you think?
[18:27] <dobey> jblount: pretty much, yes
[18:27] <jblount> urbanape: That'd be super great. If you assign them to me with a tag "next" they are really likely to get done soon(ish).
[18:28] <dobey> jblount: not built for handling rough terrain
[18:28] <jblount> Also, is anyone else creeped out when they see Jonathan Coulton after meeting urbanape ? Cause I am.
[18:29] <urbanape> jblount: will do
[18:29] <dobey> i haven't met jonathan coulton
[18:29] <jblount> urbanape: Also, z.one.ubuntu.com is for disruptive web ui changes, it will roll automatically every hour from lp:ubuntuone-servers/zed (or something) and will be using the production database.
[18:41] <dobey> verterok: i've been running contrib/test forever, and those tests aren't failing for me :(
[18:42] <verterok> dobey: the first error is from test_tools.py it should fail, as you changed get_metadata
[18:42] <verterok> dobey: there is a bug for the second failure
[18:45] <verterok> dobey: tests/syncdaemon/test_tools.py, line 141 is doing an assertion on the relative path
[18:49] <dobey> verterok: i changed the tests too
[18:50] <verterok> dobey: when? after proposing the branch?
[18:50] <dobey> oh test_tools i didn't realize was testing the same thing again
[18:50] <dobey> but that doesn't explain why it wasn't failing for me
[18:51] <verterok> dobey: right, it's weird that isn't failing
[18:53] <dobey> verterok: anyway, i pushed the fix
[18:56] <verterok> dobey: do we really need a different branch for the contrib/test change?
[18:57] <verterok> dobey: it's just an new option I forgot to mention in the merge proposal comment
[19:02] <dobey> verterok: maybe less so in this case, but one of the branches i worked on backporting, had unrelated changes to contrib/test, and was more work to backport. i don't know if this needs backporting also, but when i went to review the branch the comment said it was to fix the tests... but the contrib/test changes aren't to fix the tests, they were to help you encounter the failures
[19:03] <verterok> dobey: ok, sorry, I missed to add that to the comment
[19:03] <verterok> dobey: there is no need to backport this, as is justa  fix to the a test
[19:03] <dobey> verterok: it also makes it easier to reference specific changes later, if they're separate branches
[19:05] <verterok> dobey: yes, sure. also if the "extra" changes modifies other parts of the system, this is just a tool
[19:05] <verterok> and I included that changed because helped me to catch the bug
[19:05] <verterok> *change
[19:11] <verterok> dobey: my point is that his branch is a unit of work, splitting it is just overhead
[19:12] <dobey> verterok: i understand your point
[19:13] <dobey> verterok: i am thinking now :)
[19:13] <verterok> dobey: :)
[19:23] <dobey> verterok: hrmm, why did you have to add the test to POTFILES.skip?
[19:24] <dobey> and what the heck is creating tmp/ and not deleting it
[19:27] <verterok> dobey: because I'm using __import__, and intltool-update is...
[19:27] <dobey> ugh, tests
[19:28] <verterok> dobey: no idea about the tmp/ probably some old tests
[19:28] <dobey> verterok: if that's the line complaining, please file a bug against intltool also, so we can fix that :)
[19:28] <verterok> dobey: sure, in which package/project?
[19:28] <dobey> verterok: intltool
[19:29] <verterok> heh
[19:29] <verterok> thanks
[19:33] <verterok> dobey: Bug #498292
[19:35] <dobey> verterok: thanks!
[19:44]  * CardinalFang boggles at key modifiers getting stuck on.  First Shift, then Ctrl.  
[19:44] <dobey> CardinalFang: syrup enhanced sticky keys?
[19:49] <CardinalFang> Could be.  Seems to be synergy related, though I'm not ruling out keyboard layout wonkiness either.
[19:50]  * rtgz is in user-mode-linux instance
[19:51] <rtgz> is anything proxy-related needs to be tested for ubuntuone?
[20:02] <verterok> Chipaca: ping
[20:02] <verterok> rtgz: I think there is no proxy support :)
[20:03] <rtgz> verterok, yep, i want to experience this :)
[20:03] <verterok> hehe
[20:03] <rtgz> which makes me wonder "why?"...
[20:05] <Chipaca> verterok: pong
[20:06] <verterok> rtgz: time? :)
[20:06] <verterok> Chipaca: hi, I'm doing some configglue stuff, and wondering if you thinked about upgrading config files :)
[20:07] <Chipaca> verterok: what is this "upgrading"?
[20:07] <statik> i think core python doesn't work well with http(s) proxy yet
[20:07] <statik> i'd love to get the patches for that out of the python tracker and into python stdlib that ships in ubuntu
[20:08] <verterok> Chipaca: e.g: I have a config file with an option in [__main__], lets call this option: log_level ;)
[20:08] <verterok> Chipaca: and now I'm changing it to be in [logging]
[20:10] <rtgz> statik, but I've seen some bits of proxy support in syncdaemon sources o_O
[20:10] <Chipaca> verterok: you create a parser that sets the right value in [logging] while also prints a deprecation warning
[20:11] <Chipaca> rtgz: do you have a proxy handy where you can test?
[20:11] <verterok> Chipaca: a whole new parser right? extending TypedConfigParser
[20:11] <Chipaca> verterok: yes. Patches welcome! :)
[20:11] <verterok> Chipaca: jajaja
[20:11] <verterok> Chipaca: ok, I'll see how it goes, thanks!
[20:11] <rtgz> Chipaca, yup, right here, squid
[20:12] <Chipaca> rtgz: what happens if you run syncdaemon with the right http_proxy environment variables?
[20:13] <Chipaca> not sure if it's http_proxy, HTTP_PROXY, HTTPS_PROXY or https_proxy
[20:13] <Chipaca> one of those ;)
[20:14] <rtgz> Chipaca, yep, it is something lowercase
[20:14]  * rtgz needs PPA, NM is not working here...
[20:15] <dobey> rtgz: ppa:ubuntuone/stable
[20:16] <dobey> rtgz: or test the version in karmic-proposed instead
[20:16] <dobey> rtgz: then you can confirm the bugs are fixed and we can get the SRU out :)
[20:22] <rtgz> erm... do I have to do anything extra apart of just adding karmic-proposed deb line?... Candidate: 1.0.2-0ubuntu2
[20:26] <rtgz> guys, are you sure that it went to karmic-proposed? the Packages file does not list anything ubuntuone related
[20:27] <rtgz> dobey, ^
[20:28] <dobey> let me check
[20:28] <dobey> rtgz: you might be on a slower to update mirror
[20:28] <rtgz> dobey, main server, archive.ubuntu.com, just updated :-/
[20:28] <statik> rtgz, btw here is the relevant bug about proxy support in python stdlib, looks like there has been progress https://bugs.edge.launchpad.net/python/+bug/94130
[20:29] <rtgz> statik, yep... now i just need the client to test :)
[20:31] <dobey> rtgz: ok i guess it's not in -proposed yet
[20:31] <dobey> hrmm
[20:34]  * rtgz uses ppa:ubuntuone/stable
[20:36] <rtgz> 443 port blocked, proxy started. launching ubuntuone-client applet :)
[20:37] <rtgz> Authorization Error: [Errno socket error] [Errno 110] Connection timed out. Now trying magic variables...
[20:45] <CardinalFang> statik, have you seen "bzr builddeb" fail at the debsign stage?  I've worked around this once with someone, but I can't get it to succeed now.
[20:46] <CardinalFang> gpg: skipped "Chad MILLER <chad.miller@canonical.com>": secret key not available
[20:46] <dobey> CardinalFang: bzr builddeb -- -k'chad.miller@canonical.com'
[20:46] <CardinalFang> $ gpg --list-keys "Chad MILLER <chad.miller@canonical.com>"     # yields exactly what I expect.
[20:47] <dobey> CardinalFang: debsign apparently apparently doesn't get a proper match for some reason, when using "First Last <email>" but 'email' works
[20:48] <statik> CardinalFang: I set DEBSIGN_KEYID= in ~/.devscripts
[20:48] <CardinalFang> dobey,  gpg: skipped "chad.miller@canonical.com": secret key not available
[20:48] <CardinalFang> I've tried DEBSIGN_KEYID and DEBSIGN_MAINT, too
[20:48] <statik> or pass the short hex keyid to -k
[20:49] <dobey> weird
[20:49] <rtgz> yeah... it goes to the proxy
[20:49] <dobey> someone should fix debsign
[20:49] <rtgz> POST https://ubuntuone.com/oauth/request/ HTTP/1.0
[20:49] <dobey> someone not me
[20:50] <dobey> rtgz: getting an oauth token definitely doesn't work with a proxy
[20:50] <Chipaca> meeting begins
[20:50] <Chipaca> oops
[20:50] <Chipaca> wrong ... thingie
[20:50] <aquarius> wtf?
[20:50] <dobey> heh
[20:50] <aquarius> oh, good, OK :)
[20:50] <Chipaca> aquarius: there is no meeting
[20:50] <aquarius> I thought, god, I've been here 24 hours :)
[20:50] <CardinalFang> Well, he got our attention.
[20:51] <statik> CardinalFang, I have DEBSIGN_KEYID=608C0112 and it works ok
[20:52] <rtgz> dobey, yes, but it is... just several lines of code away... of course, if it is not buried down somewhere completely
[20:54] <CardinalFang> statik, Got it.  Thanks.  I was setting that as environment variable, which doesn't work.
[20:56] <rtgz> 2008!!!???
[20:56] <Chipaca> 2008?
[20:56] <Chipaca> the year of the awesome!
[20:57] <dobey> rtgz: but it is what?
[20:58] <rtgz> Chipaca, dobey, urllib bug is 1 year, 3 months old..
[21:02] <statik> and the bug report in ubuntu is from march 2007
[21:03] <dobey> what urllib bug?
[21:04] <dobey> rtgz: your statements are so incoherent right now :)
[21:04] <dobey> i have no idea what you're talking about
[21:05] <rtgz> RST
[21:06] <rtgz> ok, will try to not to output  debug messages to the channel
[21:06] <dobey> rtgz: i am confused. i have no idea what bug you're talking about :)
[21:08] <rtgz> dobey, i have read the lp bug report about python urllib not supporting HTTPS proxies and thought that it is silly to have a year w/o working urllib-based apps. Then I opened the original bug report and it goes back to 2006 :)
[21:08] <dobey> oh
[21:11] <rtgz> statik, ok i will update my urllib2, hope that it won't break too much :)
[21:24] <rtgz> statik, erm... it is already there for urllib2.py and httplib.py... but not for urllib (hm, no idea what's the difference, not python guy :) )
[21:25] <dobey> rtgz: what are you trying to do anyway?
[21:26] <rtgz> dobey, find out why ubuntuone client does not connect via HTTPS proxy
[21:26] <dobey> rtgz: the things in syncdaemon or storageprotocol with "Proxy" in them, probably aren't the kind of proxy you might think they are :)
[21:27] <dobey> rtgz: doing http[s] proxy with urllib2/httplib requires some extra work that we aren't doing yet, and haven't yet had time to do, as i understand it
[21:27] <dobey> rtgz: do do ssl verification, we also had to do some special magic with httplib
[21:28] <rtgz> dobey, storageprotocol/proxy_tunnel.py ...
[21:28] <dobey> rtgz: yes
[21:28] <dobey> rtgz: not exactly what you might think it is :)
[21:29] <dobey> rtgz: i think to support https proxies in syncdaemon, it needs to do some stuff with twisted, similar to how the bw throttling works
[21:52] <rtgz> ok. proxy support is really broken
[21:52] <dobey> yes :)
[21:58] <dobey> alright, i'm outta here for now
[21:58] <dobey> later