=== mr_ian_ is now known as mr_ian [02:06] Hey everybody. [04:52] honk [04:52] is there a cli for ubuntu one? === mr_ian_ is now known as mr_ian === CardinalXiminez_ is now known as CardinalFang === aquarius is now known as jono === jono is now known as aquarius [14:13] Morning, folks. [14:14] meh-ning [14:17] hey urbanape [15:00] smells like standup [15:00] *sniff sniff* yup [15:00] that's just the teen spirit [15:00] ah, basically the same thing [15:00] :) [15:00] * urbanape slouches [15:03] MEETING BEGINS AND/OR STARTS! Desktop+ crowd, say "me" to get your turn for DONE/TODO/PLANNING/BLOCK [15:03] me [15:03] me [15:03] me [15:03] me [15:04] me [15:04] me [15:05] aquarius, jblount, Chipaca? [15:05] me [15:05] (I forget who else, so forgive) [15:06] DONE: Separated out the lazr-js/YUI 3 from the new behavior and proposed the former for review. Will propose the latter shortly. [15:06] TODO: Get Bindwood into SRU pipeline, so people don't have to rely on the PPA build. [15:06] PLANNING: Bindwood improvements (manifest, threading, proper delete handling, &c) [15:06] BLOCK: None [15:06] CardinalFang: The COMFY CHAIR! [15:06] wait, what [15:06] DONE: Found cause of Bug#475447, and assigned to python-gobject. Landed attachments (yay). Made list of things to fix in desktopcouch. [15:06] TODO: Fix minor d-c bug 445611 ("expose revision in Record"). Release desktopcouch 0.6. Upload to Lucid. [15:06] BLOCKED: None [15:06] teknico! It's a fair cop. [15:06] Launchpad bug 445611 in desktopcouch "The Record class should expose the current record revision" [Medium,Triaged] https://launchpad.net/bugs/445611 [15:06] what is this PLANNING thling? [15:06] DONE: more reviews, funambol presentation, discussed timestamps code for Funambol with thisfred and vds (#399200), started work on disabling free phone sync after 30 days (#403941) [15:06] TODO: more planning with Chipaca and vds, finish disabling free phone sync after 30 days (#403941) [15:06] BLOCK: none [15:06] next: vds [15:06] DONE: did the review with a lot of people from the team, investigated on 30 days free plan, found problems with sync, triaged with thisfred, triaged problems with simplejson, discussing bout 30 free plan [15:06] TODO: check the sync works after the fixes, go ahead with the 30 free plans [15:06] BLOCKED: nope [15:06] rodrigo_: please [15:07] dobey: Chipaca asked for it yesterday [15:07] • DONE: XML<->HTML fixes. Face and review duty [15:07] • TODO: Conflict resolver tool in pair tool. Look at becoming a MOTU (https://wiki.ubuntu.com/UbuntuDevelopers). Make sandy's snowy test suite work with our server (http://git.gnome.org/cgit/snowy/tree/api/tests.py). Discuss with jdo and aquarius about oauth token per app, not per machine? [15:07] • PLANNING: contacts picker, music store, XML<->HTML move to lxml [15:07] • BLOCKED: no [15:07] next: dobey [15:07] ☺ DONE: Chat with John Lea about some issues in new client app spec, Triage, Client backports [15:07] me! [15:07] ☹ TODO: Planning, Verify client backports and bugs, 1.0.3 client release, SRU packages [15:07] ☹ BLCK: None. [15:07] aquarius: roll [15:07] I'm not sure how it differs from TODO [15:07] ⚀ DONE: work out how music store stuff all fits together; planning homework [15:07] ⚁ TODO: make tomboy first-sync experience nicer; continue work on desktopcouch developer docs; write up things learned at UDS/sprint; work with rodrigo on Music Store, some more music store architecture planning; step-by-step guide to what happens during contact sync; write "pipe" to transfer data between two HTTP connections with twisted 9.0; write lazr-js branch [15:07] ⚂ BLOCKED: music partner [15:07] jblount? [15:07] urbanape: yeah :) [15:08] urbanape: no, he wanted us to do the planning he sent e-mail asking us to do last week... "put it in your TODO to do that planning" :) [15:08] ah, my misread [15:08] aquarius: i think Chipaca is next [15:08] nm, then [15:08] ah, soz, Chipaca, go for it [15:08] DONE: hit people on the head re planning. TODO: continue hitting people on the head re planning, and get planning done. BLOCKED: no, except by people whose heads are harder than I can hit [15:09] * rodrigo_ gets his helmet [15:09] Chipaca: so, the planning thing, I understood last week that you wanted a planning for the week, is that so? [15:09] * urbanape is insensate in the head area, he assumes. [15:10] rodrigo_: for the week, every week. I also need a release plan, but that is different (and I have most of those parts) [15:10] Chipaca: and should we send it to you at the beginning of each week? [15:10] aha, it all makes sorta sense now. [15:11] your day on monday should start something like: read email, ingest caffeine, read friends blogs, do planning [15:11] we're supposed to email it to you? [15:11] I must have missed that bit [15:11] no, you're supposed to create branches for the work you'll be doing [15:11] ah, good. [15:11] empty branches, to be filled in when you actually do it [15:11] did that. ;) [15:12] aquarius: is your launchpad user "sil"? [15:12] I missed the original meeting on 30 Nov. and the one that presumably happened this past Monday. [15:12] Chipaca, yep [15:12] bbiab [15:12] branches don't correlate with 99% of the work i've done this week [15:12] nor me, really, but one does, so it got a branch [15:14] Chipaca, what about researching bugs? E.g., my #475447, "Ubuntu-One client/syncd cause 10 wake ups / second each". That took some time to figure out if it's legitimate and whose problem it was, and it didn't need a branch or work from me this time. [15:14] dobey: I thought you prepared SRUs in launchpad? [15:15] CardinalFang: could you have planned for that at the start of the week? [15:15] in any case, I'm open to suggestions as to how to plan with minimal overhead [15:15] Chipaca: there are revisions from trunk that i backported to stable, but that's just a matter of finding the revision that fixed the bugs we need to get fixed in the SRU (for those that have been fixed already) [15:16] bzr merge -c REVNO ../trunk; bzr commit --author "Original Author" is all the "branch work" really [15:16] Chipaca, I could have made a branch, but there was no way of knowing that I'd follow it from our apps -> twisted -> gobject -> pygtk source. [15:16] which is all insignificant as far as time goes [15:17] most of the work is searching through LP for the bugs, and matching them up with the revisions in trunk that fixed them. making sure the bugs are targetted properly, etc... [15:17] then i just gotta make a release of client today and do the SRU packaging, and submit it to get uploaded to karmic [15:18] thisfred, aquarius, I'm adding a getter property for d-c Record for record revision. This should be read-only, right? There's never a good reason to set the _rev on something, right? [15:18] CardinalFang, correct. [15:19] but hopefully i can start working on the new client bits [15:19] CardinalFang, if someone wants to explicitly do that then they can do it the hard way. :) [15:22] rodrigo_: CardinalFang: dobey: re the different bits you're working on that are not new features, would one day a week (more or less) be enough to cover that? [15:24] Chipaca: yes, but sometimes a branch needs a previous one, and it takes more than one day to get them approved, but generally yes [15:25] rodrigo_: waiting for a branch to be approved shouldn't be busy time :) [15:25] Chipaca: not really. at least not yet. maybe after this initial SRU hump, that will be fine. [15:25] rodrigo_: you can specify a branch needs another one when proposing now, btw [15:25] Chipaca: it is, at least for the contacts picker, which I guess is 'new features' though :) [15:26] dobey: ah, ok [15:26] rodrigo_: but waiting for review shouldn't block development [15:26] aquarius, thisfred, https://code.edge.launchpad.net/~cmiller/desktopcouch/record-expose-revid-bug445611/+merge/15953 [15:26] though i really wish i could spend some time working on infrastructure [15:27] CardinalFang: might not have time to look at it any time soon. Maybe after lunchish [15:27] thisfred, okay. it's v small, fwiw. [15:27] CardinalFang, a bit worried about record_revision.startswith("1-") -- can we depend on the couch people not changing that/ [15:27] ? [15:28] dobey: I'll ping you later to talk about that [15:28] dobey: most infrastructure work is best passed on to other people to do :) [15:28] I asked last week whether we can guarantee that revisions go 1-xxx, 2-yyy, 3-zzz, etc, and no-one was prepared to say yes :) [15:28] CardinalFang: right. This is a very leaky abstraction. I though the whole point was we didn't want to expose couchdb internals [15:29] CardinalFang: and if people do want to get at them, ._rev seems fair warning [15:29] aquarius: I think they don't, especially in the face of conflict resolution [15:29] ok, bbiab [15:29] aquarius, no. It could start with "0" next week. It's just a sanity test, not part of the code. [15:30] I do want to test that it's something I get from the DB. [15:30] CardinalFang, yeah, but if they change couch they'll break that test, and we're not relying on 1-* as the first revision, which means that we've got a test that tells us that couch has changed but there's no benefit to it [15:30] The only guarantee I have is that a subsequent revision id would lexically sort later. [15:31] Chipaca: ok [15:31] if it was protecting us because elsewhere we rely on that behaviour, it's certainly a good thing to test, but it feels a bit like we're just setting up to get a broken test there :) [15:31] or is that test really saying "is this record stored to the DB"? [15:32] aquarius, so, another put, get, test for greater-than. That would make me somewhat more sure that the value came from the DB. Would it make you happy? [15:32] what I'm wondering is: "is this record from the DB" is a useful question to ask; should we have an explicit way of answering it, rather than something sorta subsidiary like "does it have a revno"? [15:32] or am I misunderstanding the point of your test? [15:33] I would think the testing for is not None would be enough [15:33] I want to make sure it's something the user should expect and find useful. I test not-None, but I want something better. [15:34] sorry, I know I'm bikeshedding here [15:35] I still think it should be underscored, so as to warn API consumers from relying on any specifics. [15:37] aquarius, how is that now? [15:39] CardinalFang, nice, that looks good [15:39] will test [15:41] approving. [15:44] thisfred, okay, your complaint is that the very idea of revision id is too much internal knowledge of couchdb? [15:45] yes. I can see where it may be useful sometimes, but an _ method/property makes it clear it is not part of our API and subject to change at any time [15:46] that is an opinion though, so if I'm outvoted I can live with that and will approve the branch [15:46] I don't see how you can test for something being a CouchDB-related thing without having some internal knowledge of its state or representation [15:46] thisfred, it's your bug. aquarius any opinion? [15:47] is it?eh which bug? [15:47] ah [15:47] the branchname is a clue [15:47] thisfred, my opinion is: if we don't give people a way to get at that stuff, they'll just go around our API anyway. Knowing the revision number of something is useful (look at what you're doing with revnos elsewhere, for example) [15:47] thisfred, ah, it was assigned to you. I thought you reported it. [15:48] aquarius: if it's in our API, we are responsible for it not changing dramatically [15:49] thisfred, only sorta. I mean, we expose a revision number. We don't care what it is [15:49] aquarius: right, but then what's the point? I'd rather expose something useful, like _changes. As chad already has [15:50] aquarius: I forget what I'm using revnos for elsewhere [15:50] thisfred, same reason you're using revnos on the server; to be able to say "this document I've got? is it different from last time?" [15:50] aquarius: I don't think I do, much. [15:51] I explicitly try to hide that from consumers, by having the update_fields method [15:51] which behaves as if you update a single field in a document [15:51] update_field, likely [15:51] so you don't have to care about revnos [15:52] IMO that's an omission in python-couchdb [15:53] aquarius: actually, cloud_server does not use revision numbers anywhere, I don't think [15:53] I just grepped [15:53] the watchdaemon does, [15:53] but I don't know why, I didn't write that [15:53] it should probably use _changes [15:54] I thought you were using revnos for phonesync tracking? [15:54] nope [15:54] db sequence numbers [15:54] so, does this little exercise render the original bug Invald? [15:54] which should also be deprecated in favor of _changes I think [15:55] I don't know, teknico filed it [15:55] you can't deprecate seqnos in favour of _changes because you won't know what to put in "since" :) [15:55] maybe the contacts web ui relies on revnos [15:55] aquarius: why not? [15:55] I have another complaint. I mentioned it in the attachments branch. To store attachments in Record and make CouchDatabase.put_record add them, I need the revision id to add them the piecemeal way. for blob in blobs: put_attachment(container_id, container_revision, ...) . [15:56] So my step is put, get the latest(!), attach, attach, attach. [15:56] That latest might not be what I just sent. [15:57] aquarius: maybe I misunderstood that: we may have to still keep sequence numbers to query the _changes, but we would have a more efficient way to query for all the changes [15:57] CardinalFang, yeah. How do you propose to resolve that, though? [15:58] CardinalFang: I haven't done anything with attachments, but I gather they're not exactly a miracle of beauty in couchdb itself [15:59] CardinalFang: can that be handled the same as the update_field method does? (I guess that should move to d-c since it doesn't have the same code as the cloud_server does) [15:59] aquarius, I don't have a plan yet. Perhaps petition couchdb to return the record_id and the revision. [15:59] ... on put [15:59] http://friendpaste.com/2ppJfGsIzG25YmPJTigrnC [16:00] Re: bug #479475 (my favorite bug these days). 1. Shared With Me directory should be translated into $HOME/.local/share/ubuntuone/shares on DBus request and remember the original path to update nautilus view (I have it done in Vala, much like readlink(1), need some Glib/C magic). 2. Since it is unlikely that SD will be rewritten to report status for a directory (bug #440848), I think the first step is to make ~/Ubuntu One emblems reflect current state, i.e. un [16:00] synchronized, synchronized, transferring. Q/C? [16:00] Launchpad bug 479475 in ubuntuone-client "File emblems don't display correct sync status" [Medium,Triaged] https://launchpad.net/bugs/479475 [16:00] Launchpad bug 440848 in ubuntuone-client "UbuntuOne sync status emblems should apply to folders as well as files" [Wishlist,Triaged] https://launchpad.net/bugs/440848 [16:01] thisfred, what original bug did I file? [16:01] teknico: #445611 [16:02] bug #445611 [16:02] Launchpad bug 445611 in desktopcouch "The Record class should expose the current record revision" [Medium,Triaged] https://launchpad.net/bugs/445611 [16:03] CardinalFang: that would be helpful for Bindwood, as well. [16:03] well, not so much, actually. I thought it could before and talked myself out of it then, too. [16:04] thisfred, right, I need it in the contacts web ui [16:04] I should go for a bike ride sometime today. [16:06] CardinalFang: well, it seems all Client consumers disagree with me, so that would appear to be conclusive evidence ;) [16:06] API consumers, I mean [16:07] thisfred, any suggestions of a different way to detect attemps to changing the same record revision? [16:07] teknico: I don't know what that means? why would you wnat to detect attempts to change a revision? [16:07] revisions never change [16:07] thisfred, we talked about it :-) here's the sequence: [16:08] I'll have a look at the code [16:08] (I remember that we did, but not the specifics) [16:08] 1) a user opens the contact editing form, thereby loading rev.1 [16:08] 2) a sync changes the record, moving it to rev.2 [16:09] 3) the user tries to save the changed rev.1 [16:09] teknico: ah. Again this is better solved by using update_fields() [16:09] 4) the server code notices rev.1 is not current anymore, denies the changes, and issues a conflict notice to the user [16:09] which will update only the specified fields [16:10] places a bit more burden on the webui, because the form there needs to keep track of which fields changed or did not, but then it will work [16:11] can't you just *try* and save the thing? couch will give you a conflict anyway [16:11] thisfred, that's exactly what the web ui code is [16:11] *not* doing now [16:11] aquarius: not easily in python-couchdb [16:11] sounds like you're reinventing the couch conflict code, no? [16:11] but that's not the problem [16:11] the problem is, how do you know that the user is agreed with merging their changes with the ones coming from the sync? [16:11] aquarius: no, I'm doing preemptive conflict resolution in the case you only update one or a few fields [16:12] thisfred, that's not how you're supposed to do it ;) [16:12] clever, mind :) [16:13] the user was seeing some values, and they changed them accordingly [16:13] teknico: yeah, you're right [16:13] it does not seem good to end with something different from what the user thought it would [16:14] teknico: well, you never end up with something different than the user intended, it's just that they might have intended something else if they had had more information... [16:14] that's why I prefer to punt and have the user start again from the new, synced values [16:14] discarding the now obsolete user changes [16:14] yes, it's better. But more annoying ;) [16:14] You don't know that they're obsolete [16:15] thisfred, yeah, I know, it's a fast world, who cares about quality, and all that [16:15] I say: screw it! ;-) [16:15] In most case they won't be obsolete, I would bet [16:15] thisfred, the power of the ring is great, but you must resist it ;-) [16:16] They might be fixing a typo that someone else also fixed, in which case the changes will be identical (update fields is smart enough to not even write the change in that case) [16:16] or the user might have a different opinion than the other updater, in which case letting their change win is optimal [16:17] thisfred, that's like having bazaar merge together a different, but almost identical line :-) [16:17] aquarius: I should rename the function to force_update_fields, probably [16:17] thisfred, so it doesn't even fail when there are changes to the same fields? [16:17] and put tags in the docstring [16:17] teknico: it will never fail [16:17] it does sound a bit less like "please update these, if nothing's changed" and a bit more like "YAAR! I AM RIGHT! YOU LOSE, OLD CHANGES! YAAAAR!" [16:18] the values the method tries to change will always win, any updates to other fields will be preserved [16:18] thisfred, is that function already in trunk? DID I REVIEW IT? oh, the horrors ;-P [16:18] aquarius: you *only* lose updates to the fields you're changing, not to other fields [16:19] I don't know if you reviewed it, but it has been in trunk for months [16:19] this is like saying "I have only pissed on *some* of your chips", I think. ;-) [16:19] thisfred, oh, ok, that function has no notion of some fields having being changed by something else [16:19] I quite like teh cleverness of update_fields, though :) [16:19] aquarius: well, only on the chips I meant to piss onb [16:19] ;) [16:20] aquarius: I will rename it to force_update_fields, but then I think it could go into desktopcouch [16:20] so, in my previous scenario, if the sync changed field A, and the user changed field A too, the user will not ever see the value of field A coming from the sync [16:20] thisfred, I don't see I that could possibly be good [16:20] teknico: yes [16:20] correct [16:20] I don't see *how [16:20] well, I it's convenience over correctness [16:21] I agree that storing a conflict document would be better [16:21] thisfred, it's MySQL over PostgreSQL :-( [16:21] you take that back! [16:21] ;) [16:22] thisfred, "storing a conflict document"? [16:22] how would the user see that? [16:22] but I would like to store a conflict document with all the changes merged in, and have my version win [16:22] teknico: that would be up to the ui [16:22] you just ask couch for the document with ?conflicts=true [16:23] thisfred, if I can show the user a summary of the situation with conflict values in evidence, that's so much better :-) [16:23] and it will show you all conflicting versions [16:23] yes [16:23] I agree [16:23] thisfred, because you know how much love the user :-) [16:23] how much *I love [16:23] but python-couchdb completely ignores this AFAIK [16:23] recently I've seen talk of an async couchdb wrapper, what was it called? [16:23] hey me too, I love them even more: I assume they know what they're doing and that they mean what they say ;) [16:24] I don't know if couchdbkit does better, and if that's what you mean [16:24] thisfred, they can only do so if you don't hide stuff from them :-P [16:25] teknico: yes [16:25] mmm, no, it was Something Completely Different™ [16:26] so what I'd like optimally is: merge the changes to fields that don't conflict, and have the users changes for fields that do conflict win, *but* store the losing values in a conflict doc. then have the ui show the conflicting values [16:26] I don't know if that is possible, or how I would do it [16:27] I like it, except for the winning part [16:27] teknico: well, one of the conflicting versions wins. That is couchdb [16:28] teknico: unfortunately you have no control over which one [16:28] or maybe that's good, in case both sets of changes came from my method ;) [16:32] if (local && server && strcmp (local, server) == 0) { mark_as_synchronized } [16:32] local = "", server = "", ... grrr [16:34] * thisfred rethinks the method [16:34] perhaps I should have it barf on changes to the same fields [16:34] or store conflicts [16:34] if I can from python-couchdb [16:35] thisfred, at least an option to *not* have it apply conflicting changes silently [16:35] teknico: that's for wimps [16:35] :) [16:35] yeah you're right. [16:35] I don't think the function is used all that much, to put everyone's mind at ease. I just had fun writing it ;) [16:38] thisfred, then it'll be even more fun fixin^Wchanging it! ;-) [16:39] * dobey fixes up bugs for doing SRUs [16:40] dobey, have you got to nautilus or not yet? In case no, then good - I have some additional comments (as always...) [16:40] no [16:41] * rtgz hates that apt-get update erases his own little build of ubuntuone-client-gnome every time... [16:44] facundobatista: ping [16:45] yup, the emblems got 'synchronized' for files immediately because the server hash and local hash matched perfectly when file was dropped into the directory: both were equal to empty string... [16:47] teknico: I'll do this: if the merge of all changes succeeds, store it. if not, strore nothing return conflicting fields, with both values. Rename the method to try_update_fields. [16:47] No more silent anything, and no conflicts possible [16:48] wildly ugly code and function behavior though [16:48] can anybody tell me what 'server_hash' means for directories? [16:48] thisfred, that's brilliant, consider yourself hugged ;-) [16:49] teknico: it will mean work on the ui [16:49] so don't hug too soon ;) [16:49] the heavy lifting in that ugly code will beautify code elsewhere though :-) [16:49] true [16:49] rtgz: it's the hash of the directory content, that the server knows [16:49] thisfred, at worst i can just punt like I do now ;-) [16:50] and it's sort of unixy: return nothing in case of success [16:50] dobey, okay, local_hash then?... [16:50] but not very pythonic [16:50] rtgz: similar, but local version of it [16:50] showing the different values will require effort on the design side though [16:50] dobey, :).. I mean if i put a file into the dir, then hash should be recalculated, I guess [16:50] rtgz: empty local means it hasn't been hashed yet, empty server means it hasn't been created on the server yet [16:50] thisfred, when did python have something to say about return values? :-) [16:50] dobey, the local hash i mean [16:50] rtgz: yes [16:51] teknico: just an extra row of text inputs, with <-> arrows, so you can ajax them around [16:51] dobey, and if it does not then this is a bug report? [16:51] rtgz: if it's not rehashing, it's probably not getting the inotify event or something, so yeah, it's a bug in syncdaemon perhaps (or possibly in inotify) [16:51] rtgz: this sounds like the "syncdaemon not noticing new files" bug [16:52] thisfred, feel free to give advice to the design team, I just do what I'm told here ;-) [16:52] rtgz: i've seen a few reports of that nature, but don't know a bug # off hand [16:52] teknico: it's not very pythonic to have a method that does stuff, but if it fails returns something. An exception would be better. Can I return a conflicts dictionary as part of the exception? [16:52] dobey, syncdaemon has hashed the file but did not recalculate the directory info, Ok, will check that once more [16:52] thisfred, I think you can add custom attributes to an exception object, let me check [16:53] rtgz: ok, that might be the problem then :) [16:53] you can [16:54] word [16:54] that's the way to go then [16:54] class UpdateConflictException(Exception): def __init__(self, brokenness): self.brokenness = brokenness [16:54] and then people can get attributes of the exception when they catch it [16:55] thanks all, for fixing my code! ;) [16:55] aquarius: would you agree that this modified version of update_fields might have a place in d-c? [16:55] yeah, I think it does. It's a useful API. [16:56] what I'm not sure about is: should it be a completely separate way of working? surely every single access should work like this? [16:56] ok, I'll make a branch tonight, after I fix my other broken code ;) [16:56] aquarius: eh yeah, I would use this everywhere on the server. [16:58] aquarius: it might still be useful to have conflicts though: unattended processes can't resolve the conflicts, and it would suck if they could not write to the db [16:58] like sharing-sync [16:58] it still *is* a conflict. [16:58] aquarius: I mean, they would not have a good way to deal with the exception [16:58] it is pretty much never right for you to say "save my changes" if something else has happened in the interim [16:59] you can avoid it by updating the record. [16:59] aquarius: yeah that's what I'm doing now, but in the case the same field was changed, you need to pick a winner [16:59] or store a conflict [17:00] in the case where a user is driving, present the conflict to the ui, and have them picj [17:00] pick [17:00] I...think it's up to the app to pick a winner. [17:00] right [17:00] if it's possible to do unattended, then let the app that writes second do it [17:00] if it's not possible to do unattended, then don't run unattended [17:01] storing conflicts seems to me to not be the right thing to do; we just can't avoid it in a world with replication in it [17:01] aquarius: I would say store conflicts documents on exceptions when unattended [17:01] I'm not convinced [17:01] and then the user/app can resolve them later [17:01] also, can we? [17:01] aquarius: we can, through http if need be [17:01] isn't replication mildly magic? can we deliberately store a conflict? [17:02] hmm, I thought you could [17:02] bulk updates can [17:02] or can't they? [17:02] anyhow [17:03] I will ask for input when I start coding [17:03] now my trunk is broken, because there is no _add_record method anymore [17:04] that's good though [17:07] :) [17:19] lunch time [17:31] dinosaurs?.. [17:33] teknico: ok, let's do this thing [17:33] mandel: eh, hola! [17:34] Chipaca, it would be best to do it with vds too [17:34] Chipaca, hola :D [17:34] teknico: can you wait up that long? [17:34] also, I owe an answer to mandel since yesterday :-) [17:34] teknico: the planning is so much easier when one of the people that has to do things is away! [17:34] Chipaca, yes, I'll be around [17:34] teknico: ok :) [17:35] Chipaca, you're not getting away with that, you know ;-P [17:35] Chipaca, I'll entertain him teknico if you need him to stay for a while ;) [17:36] mandel, thanks, but I don't really need him to *not* be elsewhere right now ;-) [17:37] mandel, hi. attachments branch is merged. [17:38] CardinalFang, awesome, as soon as I can I'll add avatars to the contacts, thanks A LOT [17:39] mandel, de nada. Tell me if it's not exactly obvious how to use it. [17:40] CardinalFang, will ask you, within the limits [17:40] verterok, ping? [17:56] mandel, wow, bazaar is erroring out while trying to merge your branch :-/ [17:57] mandel, no, wait, PEBKAC [17:58] I'm too used to live in the server code :-) [17:58] teknico, hehe I've not heard PEBKAC in a long time [17:59] mandel, well, in this age of laptops, it reeks of viagra spam ;-) [18:01] teknico, you forget watches and university titles... [18:02] mandel, yes, I do, what about them? :-) [18:03] teknico, they go hand in hand with the viagra spam :P [18:05] mandel, no, I mentioned viagra in specific relation to the acronym, think about it ;-) [18:05] teknico, agg... you are to graphic for me hehe [18:22] mandel, can you please merge forward your branch? [18:22] I see unrelated changes in it [18:24] teknico, waht do you mean? [18:24] mandel, it looks like there have been changes in desktopcouch trunk since you branched it [18:25]